Slashdot Mirror
PayPal Asks E-mail Services to Block Messages
roscoetoon writes ""PayPal, the Internet-based money transfer system owned by eBay, is trying to persuade e-mail providers to block messages that lack digital signatures, which are aimed at cutting down on phishing scams, a company attorney said Tuesday.So far, no agreements have been reached,..." "...PayPal is using several technologies to digitally sign its e-mails now, including DomainKeys, Sullivan said. DomainKeys, a technology developed by Yahoo Inc., enables verification of the sender and integrity of the message that's sent." "...An agreement with, for example, Google for its Gmail service could potentially stop spam messages that look legitimate and bypass spam filters.""
Paypal more like Gaypal amirite?
or purpoting to be from paypal? Problem solved.
It sure would be nice to see this go through. If I had a dollar for everytime I have gotten an email from some fake paypal scheme I would be rich. Hopefully ISP's and Email providers will go along with this, because quite frankly, I hate it.
-- Josh
"Whoopie! Man, that may have been a small one for Neil, but that's a long one for me!" - Pete Conrad
What ever happened to email signatures/authentication/etc? Rather than mess around with specific providers, they should talk to the folks writing the software and develop or work with an existing standard for identity authentication. It's not like encryption/signatures don't already exist, the problem is in mass adoption and making it nearly thoughtless to do so that is the difficulty.
This is the problem Sender Policy Framework (SPF) tries to address.
How about Paypal just gives up sending email?
I've seen lots of spoof Paypal emails and some of them look frighteningly close to the real thing. Even if Paypal's sending legitimate email, what is it? Emailed receipts? Just what I want hopping from mail server to mail server. Emailed promotions? No thanks, does anyone REALLY want those?
If it's that important, do what businesses have been doing for a good century: certified postal mail. If you don't wanna pay the dollar fifty for it, then it must not be very important and, by definition, it makes it non-essential.
More Twoson than Cupertino
I'm sick of people entering my house through the open front door while I'm away, and stealing all my stuff. I want to make it illegal for people to just walk through open doors.
I know, you're thinking "why don't you just do something about your open front door?" But dammit, I've based my entire security model around having my front door open at all times, and I really can't be bothered to dream up a more secure system than a wide open front door. I'd much rather make it everyone else's problem instead.
Slashdot Burying Stories About Slashdot Media Owned
The issue here seems to be spam/phishing. I wonder if it's time to develop something like SMTP 2.0... an equivalent to a "new" e-mail system completely separate from the current one. Maybe it should have centrally managed servers for stricter authentication? Is the current system defective by design or just in need of some updated techniques?
Because hovering over the link in the mail is hard?
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
Why don't major financial insititutions all create a coalition that does exactly this. This coalition would issue signing certificates for the various members, who will then sign all of their email.
All that mail hosts would need to do is verify that the mail was signed by a valid certificate that was issued by the coalition. One certificate to verify against. The coalition can then issue revocation lists as necessary if a member's certificate is ever comprimised.
Seems like an ideal solution to reduce phishing. It could also be used by other organizations who could have their email signed in a similar way, which might allow these messages to bypass spam filters which would benefit the mail hosts.
I think of it as a way to implement a pseudo whitelist, which is by far the best way to ensure that you don't get spam.
Sometimes the best solution is to stop wasting time looking for an easy solution.
This is going to bring down the karma-o-meter but my hatred of eBay and Paypal is absolute. Paypal is not even a real bank. I am surprised also at the attitude of Meg Whitman and eBay in their reluctance..err..outright REFUSAL to assist authorities in NUMEROUS fraud investigations. What paypal charges in fees is also rape. I am truly AMAZED Gonzales and his crew have not used the Patriot Act against Paypal. Paypal/eBay is whom the Patriot Act as designed for. Paypal/eBay has destroyed lives and they are not being held accountable for it.
Shouldn't PayPal be more concerned with improving its abysmal customer service? Fuck them.
It should be sufficient to let the client handle this, domain's wishing that all mail from their domain should be signed can ADVERTIZE this fact and clients wishing to RESPECT that advertizement can verify signatures and filter incoming mail accordingly.
I guess I am just old-fashioned eh?
This is a great idea, but hard to enforce. Most people let anything and everything get to their systems because they don't want to miss that ONE KEY EMAIL~ and really, you're entrusting end-users with PGP. That's what it sounds like to me, and if that's the case, this has little chance of working in practise.
Let's stop dilly-dallying and just change "-1: Overrated" to "-1: Disagree" or "-1: Doesn't Subscribe to Groupthink".
It's just that email is NOT a good method to distribute ALL information.
Rather than re-working an existing system so it is more "effective" in handling a specific case, why not look at how best to handle that specific case?
We've been over this before with regular banks. You need two different channels to confirm a transaction to make it "safe" enough for the average person. Web and phone is good combination.
The whole idea of creating a newer, more secure and spam-resistant emailing standard has been out there for a long time. There are limitless "great ideas" on how it can be done but the problem is implementation and integration. We're already stuck in this way of doing things.
But somehow we need to answer the need and perhaps under the premise of protecting financials, there might be some potential for movement. I'm thinking that if a consortium of financial groups got together and decided that from here on out they will implement XYZ for all financial related electronic communication or whatever, that people would just download the client they needed and be done with it. I believe that people would be more willing to protect their financials by running a new client or application and I believe that eventually financial institutions would be willing to back the intiative if it meant they'd suffer less fraud.
I just hope that whatever gets pushed out is OSS based or at the very least available to OSS implementation.
Every smtp servers out there should implement DomainKey and SPF!
Yes, they try to do the same thing. However not everyone uses SPF (or DomainKey). Therefore the burden relies on the mail administrator. he should implement as many 'solutions' as possible to be compatible (ie: not flagged as spam).
The barrier to acceptance of any signature approach (and there are several) is getting everybody on board, or at least a large enough segment of the user population to make a compelling case for others to follow. Paypal might be that segment, because it (a) originates large volumes of email, and (b) has built the infrastructure to digitally sign them.
If Paypal can persuade the larger mail transfer agents to reject unsigned messages purporting to be from Paypal users, the case is made. That takes some administrative effort by the MTA but not a lot. Adding few more large players like Paypal requires only incremental effort on the part of the MTAs. Eventually, we get to a point where at some MTAs this filtering is no longer managed as a special case but becomes a general requirement.
Parity: What to do when the weekend comes.
Why doesn't Paypal sign its e-mails in the conventional sense (http://en.wikipedia.org/wiki/X509)? Every major mail client would flag it with a nice wax seal or similar and a reasonably knowledgeable user would have confidence in his PayPal messages. A little education from PayPal's site about looking for a good signature would go a long way to helping everyone else.
At the moment, since mail clients don't know anything about DomainKeys, we have NO WAY of knowing if mail really is from PayPal.
And perhaps a mail client consortium could manage lists of domains requiring valid signatures: mail from paypal.com and not signed goes straight to the junk folder; it's not completely different from the management of certificate authorities. Alternatively, at least for Thunderbird, a simple extension could do that job.
And of course this isn't a problem domain specific to PayPal, so their individual lobbying seems to be a drop in the ocean at best.
Andy
It's ironic that most of the PayPal/BankOfAmerica/eBay phishing spam I've seen simply links directly to images from the legitimate site, and that McCain's MySpace page was "pranked" with a simple .htaccess rule... same solution applies here, but PayPal et al won't apply it because they don't take any outside suggestions due to "intellectual property issues" (and yes, I've suggested it).
Getting what they deserve? Yeah, probably.
The spam and phishing from PayPal is insignificant compared to the crap I get through eBay should I try to auction or sell off an old computer system. (Next to charity donation, it's the best recycling system I have available) The last 3 auctions I did - it took me 6 weeks to get rid of a Tablet PC because the first auction was terminated by a Nigerian trying to defraud me, the 2nd derailed because of the first's premature termination, and the third because of buyer's reluctance to look at something that had been up for auction twice before. The laptop that followed was sniped by another Nigerian fraudster.
During the whole process, I probably received on the order of 12 'messages' about my auctions by spammers. 12 spams is pretty low, except that I have to delete them out of my email, delete them from the item's message queue, and then last delete them from the eBay "My Messages" inbox as well. If I have to delete spam from 3 different locations, and there's no simple way of informing eBay that a message is spam, they're obviously complicit, incompetent or they honestly don't give a damn.
I sent you an email offering you just this very thing the other day. My uncle, the prince of Nigeria, has been mortified by all the spam and phishing scams occuring all over the world. He set aside $100,000,000 dollars into a fund for those most affected. He asked me to track them down for him. Given the sensitive nature of this program we are delivering the funds strictly in cash. All we need for you is to send your car keys and the location where it is parked to this PO Box, and in a few days you will find a large suitcase in the truck.
Most paypal and ebay scam emails DON'T look legitimate. Most are so poorly formed they stand out as fake. From address is wrong, subject is formatted very differently etc... Anyone that uses Paypal regularly can easily see how bad of a job the scammers do in the fake emails.
Problem is, they are taking advantage of the fact that people like me make up 10% of the total population, the rest fall for it because they don't take the time to be careful.
Do not look at laser with remaining good eye.
We have spf for all our domains. DKIM is a pain if you have more than one domian, the dns bit is easy, the signing more iffy - result i gave up on dkim implementation.
yes we could could easily check for dkim signatures, but i have spf. already - i saw little point to dkim. Main problem here is that mail clients don't do much with this extra header line that the mta/dkim signer puts in.
The point to this is while its probably hard to fake, dkim does not offer much to the mail client. With more than one domain then dkim becomes a bitch to configure.
I found dkim to be a waste of time, spf however is not.
The day ebay tells me what i need to run a mail server (heard of rfc's ebay) is the day i tell ebay/paypall to go get lost.
I run my own domain, and while I haven't found a good API for checking domain keys yet, one thing I do is check to see if a domain key signature is present in domains that are known to use them -- for example, if a message claims to be from gmail.com or yahoo.com, I just make sure there is a domain key signature header in the message... no need to validate it. Sure a spammer could put a fake signature in, but then it would be block by the major mail providers.
Granted, this is only a short term solution -- I'm hoping that good support for domain keys appears for Exim before too much longer.
I am also using Sender Policy Framework, as one poster suggested, however it does have two significant limitations. The first limitation is that it doesn't work for forwarded account... for example, I use an @acm.org forwarder for some traffic, which means that the host connecting to my mail server is from acm.org, which won't be listed in the SPF entry for iwanttohireyou.com. There have been some proposed methods for re-writing From lines, but it's really not workable. In my case, I know what servers are allowed to forward mail to my domain, and I simply bypass the SPF check in those cases.
The other problem with SPF, that I see more and more, is that most spammers have stopped putting well known domains in their from lines and are instead using garbage domains, which of course do not have SPF entries. If SPF was universal, then the absence of an SPF entry would tell you something, but it isn't, so it doesn't.
Still, between SPF, domain keys, and well monitored RBLs, you can keep spam to a minimum, and I applaud PayPal for trying to get other ISPs to implement these sorts of controls.
-brian
SPF works with SMTP envelope addresses and prevents bounceback spam and SMTP forgery. Most phishing emails rely on MUAs displaying a sender address present in the email itself. This is what Microsoft's ridiculous (as in: technically unsound) SenderID proposed to solve. Because email data can be arbitrary, signing the message body (including the headers) is the only way to prevent message forgery. I've not looked at DKIM in a while so I'm not sure if it's become a viable solution yet?
OK, this is off-topic but it does involve PayPal and email. When someone is sending spam to PayPal with my (forged) address, I get weird probing of my email server from PayPal even though the mail isn't coming from my server. I don't know what they are trying to determine, but you'd think PayPal would figure out that most spam is forged. Has anyone else noticed this?
Ok, class, here's the header, now tell me what's wrong with it:
Date: March 28, 2007 9:36:46 AM EDT
From: admin@paypal.com
Subject: Your PayPal account access is limited.
To:
Reply-To: paypal@paypal.com
Return-Path:
Received: from 10.0.0.2 (ont-static-216.70.173.8.mpowercom.net [216.70.173.8] (may be forged)) by localhost.localdomain (8.12.11.20060308/8.12.11) with SMTP id l2SDfRsJ001136 for ; Wed, 28 Mar 2007 08:41:29 -0500
Received: from by ; Wed, 28 Mar 2007 17:30:46 +0400
Message-Id: >
X-Mailer: Internet Mail Service (5.5.2650.21)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--542976798523875"
X-Priority: 1
X-Msmail-Priority: High
Status:
You guessed it! NOW WHY CAN'T EMAIL READERS have a parser in them that goes-- hey, user, wake up, this is a weird message and you should be advised that things don't match up like they should (in this case, replyto, sender, and source/origin).
Egads.
---- Teach Peace. It's Cheaper Than War.
Every day it gets harder to run your own mail/web server. soon you will need an operating license to have one, and soon after that there will be a per-message charge for every email you send. Just one more step into turning internet into the one-way broadcast media TV and radio are.
And for those of us who already sign our e-mails and publish a public key, why doesn't PayPal simply distribute its public key block on its web-site, using HTTPS so that its integrity is maintained?
I've said it before and I'll say it again; email is stupid. I freaking HATE email. It's mostly spam and is rarely useful.
I rely on forums and chats for 99% of my useful communications on the internet.
The whole concept of email needs to be redesigned, as others have pointed out.
Paypal should communicate with users through it's site, NOT through email.
-- Boycott Shell
Not really. It's "fraud". That's all.
Correction: It would not stop the phishing attempts. It could stop the fraud from occurring. And that is the goal, is it not?
Let me give you an example of how to end the fraud without worrying about the SMTP protocol.
A customer setups up an account with a financial institution (FI). The customer provides information such as a phone number.
For any online transaction to be completed, the FI will call that number and ask the person to approve the transaction amount. Failure to approve the amount will result in the transaction being denied.
It's as simple as that.
Possibly. But without defining the requirements you're pretty sure not to hit them.
SMTP works and is widely deployed. You'd have to replace a LOT of infrastructure
Your post advocates a
( x ) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( x ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( x ) It will stop spam for two weeks and then we'll be stuck with it
( x ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( x ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( x ) Asshats
( x ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( x ) Armies of worm riddled broadband-connected Windows boxes
( x ) Eternal arms race involved in all filtering approaches
( x ) Extreme profitability of spam
( x ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( x ) Extreme stupidity on the part of people who do business with spammers
( x ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( x ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( x ) Why should we have to trust you and your servers?
( x ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( x ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
( x ) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
Unfortunately, SPF and DomainKeys (DKIM) are not the answer to verifying mail. Currently, as has already been discussed thoroughly, the adoption rate for both of these among legitimate senders of mail has been abysmal. Those few who have adopted these tools are in the minority, and as a result, it is impossible to rely upon these tools as definitive proof that a message is legitimate.
Compounding this problem is the fact that there is NOTHING in place to stop spammers from setting up a SPF record or perhaps a DKIM record for their domain. Some do not, but there are enough who do to make it nearly impossible to either accept or discard email specifically based upon these tools.
Spam is notoriously hard to identify. Unfortunately, the only way to totally resolve this issue would be to develop some sort of method by which to identify legitimate senders and also to preclude people sending spam from being identified as legitimate. Given our current technology, this is not currently possible.
The only way I can think of to eliminate spam on the internet would be for the Internet community to completely discard the current email structure and completely overhaul it to include some sort of sender verification, along with non-spam verification of mail.
http://www.sigcomm.org/HotNets-IV/papers/ballani.p df
Don't piss off The Angry Economist
Um, no.
If you owned a company who's (almost) exclusive way of communicating with customers is by email, would you give it up and tell the millions who depend on Paypal that they'll receive receipts by the mailman? Yes their customer service is shit so I won't even try to sugarcoat that reality. Right let's send an email to customers in Africa, the receipt for a purchase shall come in by Air-Camel straight from UK!
Yes, fake paypal emails do look very similar sometimes to the real thing, but if you fall for it, you deserve it. When I worked at a gas station, I was just surprised at the number of customers who would not read the simple instructions at the gas pump when they wanted to pay at the gaspump, and then when something wrong happened they'd come at me inside and bitch that the machine sucks. Well fuck them, I'd tell them "Just read the instructions. They don't sucks, See that man on #4, he did it... so you can too, no?". Even better, they'd come inside, pick a pack of gum and ask me what's the price when the price tag is right there where they picked the fucking gum.
Theres always a pattern to fake emails. You have to use "just a bit" of common sense. The very first emails ebay and paypal send you, just like any other company that operates online is that they will never ask for your information and with paypal you should always manually type the site when in doubt, x.com doesn't take long to type now does it?
PayPal is shit but the options are pretty limited so we have to make an extra effort as customers to avoid the most issues.
This *is* an email signature system, only at the MTA level rather than the MUA level like PGP. The idea is to make mass adoption easier, since, as you say, it's the main difficulty. So get off your butt and get DomainKeys working!
Don't piss off The Angry Economist
The problem with SPF is that it's really easy to implement, and works really badly. DomainKeys is a real solution to the problem, but it's harder to implement because you can't munge the email (which various MTAs are prone to do).
Don't piss off The Angry Economist
Probably because Paypal is deceptive in their own mails. Here's an excerpt from a recent PayPal mail as rendered by MailScanner:
Now they have the hypocrisy to complain about others not jumping through hoops for their mail? Give me a break.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Why the frak don't they just use PGP/GnuPG? Cripes.
It's already illegal to enter premises where you know you're not invited, even if the door is open. Were it not for the fact that your premise is COMPLETELY WRONG, this would a great satire.
Don't piss off The Angry Economist
I've gotten plenty of spams that look exactly like the paypal "you have paid X" emails. The only difference is that the site it links to is not paypal, but one intended to snarf your password.
It's always worth checking out when you get a notification that a possibly-fraudulant purchase has been made. In my case I just go directly to paypal in my browser (without using the link in the email) and check my account, but I'd bet a lot of people might get suckered by this one.
Is there a way to enable signature-checking for certain domains? I haven't really looked into it, but I'll gladly add a check for PayPal's sig to my Postfix/etc config files.
The first thing they should do is change the "~all" to "-all" at the end of their SPF records.
paypal.com. 3600 IN TXT "spf2.0/pra mx include:s._sid.ebay.com include:m._sid.ebay.com include:p._sid.ebay.com include:c._sid.ebay.com include:spf-2._sid.paypal.com ~all"
paypal.com. 3600 IN TXT "v=spf1 mx include:s._spf.ebay.com include:m._spf.ebay.com include:p._spf.ebay.com include:c._spf.ebay.com include:spf-1.paypal.com ~all"
The whores get mad when the sluts give it away for free.
Comment removed based on user account deletion
I think he was referring to their hobbit-like smallness.
...because "hacker" sounds way sexier than "code drone."
SMTP is not only defective by design, but defective by requirement.
Nobody ever meets the design requirements!
Next you're going to tell me they were on schedule too!
paintball
There are no technical solutions for stupidity and/or lack of common sense.
Jesus christ.
There is technology to digitally sign email with strong encryption, it has been around for ages. It is cross-platform, well-defined, and it works. It's cheap too.
Get some certificates signed by verisign or other CA, and do a little progamming.
It's not hard.
When i cancelled my paypal account (because i didnt trust it anymore, due to the numerous scams we are talking about here) part of the cancellation process was answering a little questionaire. When it asks why... "too many fake paypal emails" was one of the options & I chose it. They then went into a lengthy description of all the efforts theyre making on this front which was not at all convincing. I cancelled the account & added paypal to my filter. Anything from them (or more likely, pretending to be from them) gets tossed straight into the shitter without me ever seeing it. No more worrying about is it real or not, no worrying about someone getting my password & taking my dough. Paypal creates way more problems than it solves for a lot of people, its just not worth the effort anymore.
If enough people do this its byebye paypal.
What MTA are you using? I have a fully working domainkeys system set up and working perfectly with 3 different domains on Exim.
Why not adopt the principle of not having any URLs in the email, and instead having users copy & past an alphanumeric string into some box on the paypal website? Alternatively, they could use something akin to Bank of America's SiteKey method, where an image is presented to the user to verify that the site is the desired site. Unfortunately, at least one study (I couldn't find it quickly) has noted that a significant portion (at least 25% and perhaps > 50%) of those who use such systems still enter in their password if the image is incorrect or missing.
Honestly, I don't want no companie's own e-mail verification system. People - yes, real people, and surprise surprise quite a lot of us - use GPG for signing and encrypting e-mails and everything else, and there are lots of freely usable keyservers out there. But hell would freeze over if any company with their bucks dropping out from their a**es would ever just use a proven, available and easy way of e-mail signing. Just give all your users keys and you're done, they don't even have to know they have one. But no, come people, use our DomainKeys. Yup, companies, the ones we love. Right.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
I don't trust SPF enough to rely on it much. The only thing I use it for is to look up specific domains and find out what e-mail servers they use so I can whitelist those to skip the graylisting.
But any so-called legitimate marketeer can create an SPF record for their domains.
If you want to see how badly spf can be abused by regular ISPs, look at the SPF record for panix.com:
panix.com text = "v=spf1 ip4:166.84.0.0/16 ip4:198.7.7.0/24 ?all"
I assume they just added their entire IP blocks to the SPF record which totally defeats the purpose as far as I'm concerned. Their SPF record is worse than useless.
So any customer of panix.com in those net blocks can have a trojan on their computer using an e-mail address from panix.com and trick you into thinking it is legitimate.
Nope. For those domains that we receive legitimate e-mail from, I'll use their SPF record to find out what their addresses are and add them to the whitelist. But that is as far as it goes.
>We have spf for all our domains. DKIM is a pain if you have more than one domian, the dns bit is easy, the signing more iffy - result i gave up on dkim implementation.
No it isn't if you know what you are doing....... have all the domains use the same selector. A selector does not have to be a domain name....
>I found dkim to be a waste of time, spf however is not.
Wow... you have absolutely no idea what DKIM is or how to use it.
On its face, this seems like a good idea. But, there are bound to be problems related to interoperability with the various SMTP server implementations. Don't everyone groan at once when I mention M$ Exchange. I have thought of suggesting using OpenPGP but any joe blow could create a PGP public/private key-pair that purports to be from Paypal and use that key to send out phishing emails. I suppose Paypal could include a fingerprint of its key but I am not really sure. S/MIME might also be another option for digital signing.
It is not clear in the article if Paypal is asking that sites block all mail that is not authenticated, or just unauthenticated mail that claims to be from paypal.com or related domains.
The latter would be fine. The former would require every user in the world to get a new mailer, certify themselves with authorities and end the ability of those who wish to communicate anonymously through email to do so even when parties are consenting.
The latter could be accomplished with keys that allow one signed email to declare "All future mails from this address or domain must be signed." You would need a key for a site to set the rule for the entire domain, a key for a user could set it for a single user.
However, even this may be misleading security. Once users become convinced that all mail from paypal.com is now signed, phishers can trick them more easily by sending mail from paypa1.com (that's a "one" not an "el") or similar games. This mail, from paypa1, can even trumpet how you know you can trust it because you know that all mail from us is authenticated with wonderful crypto.
Of course, paypal can try to get command of any domain that might look like theirs, in every character set, but sometimes when you tell people something is more secure, but it still has _any_ window into it, you actually create a greater danger of social engineering.
Has it been over a year since you last donated to the Electronic Frontier Foundation
According to http://www.mail-archive.com/dev@spamassassin.apach e.org/msg19513.html
Rules to block unsigned eBay/Paypal mail should be in place by version 3.3.0
Why don't we cut off internet access to Africa. I figure if someone actually needs it, then they can submit a request like we all do in the business world... and we all know how well that works. (Do we get karma for sarcasm?)
The whole point of these responses is because of one thing - we've heard it all before. "Oh I know how to stop spam... do X". I've been hearing this crap going on 15 years now.
Spam is a problem. Yes. Is it a problem that can be solved in any meaningful way? Likely not. At least not without removing nearly every single benefit email has.
There are lots of problems in this world that are not easily solvable. Spam is one of them. And until someone like you, actually DOES SOMETHING THAT WORKS, then all your spouting off about proposals and solutions is just blah blah blah to me. Show me some results, then I'll be impressed.
But any so-called legitimate marketeer can create an SPF record for their domains.
SPF isn't really for verifying emails as legitimate, it's more for verifying emails as illegitimate. With SPF, if you receive an email from a host that claims to be from domain example.com, and example.com has a TXT record indicating that the host is permitted to send mail, it might be a legitimate email, or it may just mean that the host has joined a zombie network that read the user's email configuration. (or the SPF record is too liberal, or they set it to not reject based on other addresses, or the host is "legitimately" sending spam, etc.)
On the other hand, if example.com has a TXT record indicating that the host is not permitted to send mail, then you know that the email is illegitimate.
The most important thing that I see for preserving at least some semblance of verifying the source and intent of e-mail is the presence of a reliable chain of custody. The e-mail was received from this IP address, to this mail server, to this relay, to that relay, to this mail daemon, to be delivered to this account. Yes, this information can be spoofed to some extent, but it's sufficient in most cases to at least trace back to the first compromised system (in the case of outright spam/junk/phishing) or at least give a knowledgeable recipient some information to give credence to whether or not the sender might be who they claim to be.
With this in mind I'm really unhappy with Gmail. All mail that I've seen which comes from a Gmail account purports to originate from within the Gmail hive. At least Hotmail and Yahoo still preserve the IP from which the HTTP POST was made.
With respect to PayPal phishing e-mails, in particular, it's quite easy to look at the e-mail headers and say,"Heh. Nah. That doesn't even look close to legitimate."
the NPG electrode was replaced with carbon blac
Seconded. SMTP is more than adequate to maintain a reliable and trustworthy e-mail system. The cases of abuse which I've seen have been proof of concept, red herring, or simple examples of incompetent administrators. Granted many of those administrators are end users with compromised home systems, or administrators who manage, say, 1500 desktops in an office building where ten or twenty of the hacked boxes are in broom closets someplace. That still isn't a flaw in SMTP.
the NPG electrode was replaced with carbon blac
1) Are they paying me to implement their fix to their problem?
2) Have they started taking reports from people who find the fraud scams, then responding with the results of what they have done?
3) Do they have a working customer support system?
When the answer to the above is YES, then I might start caring.
Otherwise, it strikes me as THEIR problem, not mine.
How did the Nigerian try to defraud you?
Your god may be dead, but mine aren't!
But any so-called legitimate marketeer can create an SPF record for their domains.
Right, but a properly set up SPF record means OTHER people have a trouble spoofing 'so called legitimate marketeer'. So if you get a message from 'so called legitimate marketeer' and he's set up an SPF record you are reasonably assured that the message isn't from someone else trying to spoof being from 'so called legitimate marketeer'.
If the value of that isn't clear consider the normal spf use-case scenario:
Let's say "yourdomain" is a 'paypal' or an 'ebay' or a bank and you've set up SPF properly.
Then if the guy at marketeer.com or even bot-103455 of some botnet sends someone an email claiming to be from "yourdomain" then the recipient can safely and automatically discard those messages because they are coming from a mail server you at "your domain" didn't authorize.
Thus the only way users using SPF are going to get spam from "yourdomain" is if:
1) YOU spam them
2) YOUR mail server has been compromised and spammers are using it, in which case you have a chance to fix it.
3) one of YOUR users, who is authorized to use YOUR mailserver has been compromised and spammers are using that host to send spam. (e.g. bot-103455 happens to actually be one of your own users)
This puts spam control in your hands. It doesn't protect end users from spam in general, but it does give you significant control over whether they have to receive spam from "yourdomain".
The biggest weakness in SPF, in my opinion, is that it doesn't help you against typosquatter domains. If I own paypal.com and set up SPF correctly, there is still nothing stopping a spammer from spoofing paypals.com, which won't get blocked by SPF. So a user might still be fooled by a spoof email if they don't observe that the domain name being spoofed isn't quite right in the first place.
This latest B.S. ploy has nothing to do with protection of innocents via phishing scams. It has everything to do with eBay's overzealous "Big Brother" attitude. Ebay and Paypal have been actively tracking users, logging every single detail about what their users do for the better part of a decade. Essentially ebay wants email service providers to subsidize the cost of ebay tracking their own users via secured email.
"Jeremy, you need to get to an internet cafe and cut and paste some appropriate sentiments about me from the world wide
The problem is very simple. Websites like Paypal should NEVER send a link in an email message which asks for any information to be submitted, and they should announce this policy clearly to their users. If people are going to submit login or other information, they should always use a bookmark or type the url themselves. If everyone followed this protocol, phishing would be impossible.
Coins, money, checks and stock certificates have all been forged. One option would have been blaming the victims. Instead the industries involved developed anti-forgery technology and deployed it.
Today email is being forged for criminal gain. The anti-forgery technology already exists. Paypal is negotiating with their business partners to get it deployed.
We all benefit from closing off easy opportunities for crime. Blaming the victim doesn't work very well in the case of a pharming attack anyway.
How do we know the letters that were sent to the service providers weren't spoofed by scammers???
Maybe the scammers have setup their own "DomainKeys" or whatever that Yahoo thingie is? Then who'd be laughing? Well, I guess probably somebody over in Nigeria, or possibly ~37 kids down in a basement in Oregon...but then again who am I to speculate?
When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
I do understand what SPF is supposed to do, but what I am saying is that what it does combined with the way people set up their records, it is pretty much useless to me.
Consider the panix.com SPF record above. Assuming that the IP addresses covered include their whole domain and the presence of the "?all", what they are saying is that any e-mail with a return address of panix.com should be treated as legitimate.
Then there is the "~all" SOFTFAIL. So you might reject those or you might not, depending on how hard-assed you want to be about it.
If the only option was "-all" and only known, identified, legitimate SMTP servers could be listed, I'd be more impressed. If you're going to use "~all" or "?all" in the record, then you might as well not even bother creating the record. And listing your entire address block or blocks is just plain silly.
For what it's worth, we do have SPF records with "-all". It doesn't seem to have cut down on bounces of spams with forged e-mail addresses at all.
postfix - multiple instances of each on an public ip but on one machine, lots of spam garbage filters - while it might be possible its a pain for very little payback.
Thats another eight high ports open (inbound and outbound) where i think i have to filter one process chain into another aka sign->spam-check->send-here->then-here. we got stuck with postfix in outbound message signing before. The second domain got the dkim signature for domain 1 which is wrong.
nice idea - crap outbound message signing implementation.
Are you fucking kidding me? You can't tell a cop no under any circumstance!
Some people say we have rights - that's great. I wonder how wonderful it feels exercising their rights while they're being tasered.
Said the coward to the fool
Doing one of something is easy, even i could get dkim working with one - but doing many means things don't work or play happy with the other things the mail interacts with. Im a fool, but then there was an emperor once who wore no clothes.
I do understand what SPF is supposed to do, but what I am saying is that what it does combined with the way people set up their records, it is pretty much useless to me.
... yet.
But SPF does what its supposed to do. It gives you a way of allowing OTHER people to differentiate between spam and legitimate mail from your domain name. That is a huge benefit, even if most of them aren't doing it
The fact that you receive bounces of spams with forged email addresses just tells us that most mail servers aren't configured to check SPF properly. If they did, they could discard those messages as spam instead of bouncing them.
SPF isn't a failure, nor is it useless. But it requires wide-scale deployment to make any real dent in mail spoofing on the internet at large, and really it only prevents spoofing, not spam itself.
As for your panix domain example, that amounts to a pretty lame SPF record, and suggests they only have SPF to prevent getting rejected for not having SPF (which is a small step in the right direction at least), but they currently haven't taken the required steps to allow you to detect spoofing of their domain name. This is only REALLY a problem if their domain is getting spoofed to a relevant degree.
A domain like paypal, or ebay, or a bank has a big interest in giving mail admins the tools to detect spoofed mail from their domains, the average company, while they -do- likely have an interest in stopping spoofing of their domain, but have likely not been seriously afflicted with spoofing, and so don't simply care overmuch. Which of course, doesn't do mail admins like you any favours. But really, how much panix.net spoofed mail do you actually get, and is it really negatively affecting panix.net that you got it (beyond making their mail admin look like a lazy/incompetent twit)?
Point is SPF is an excellent anti-spoofing technology, and it works very well. It will never be successful as an anti-spam technology, because, as you yourself said, there is nothing stopping spammers from creating SPF records.
That's one reason I quit using postfix awhile back. I hated having to either relay via socket out to another program, and then having it inject it back into postfix. I can definitely see where this would be a pain as well.
The drawback with SPF is that to work properly the receiver needs to know who they have set up as forwarders - something Joe Sixpack probably has no clue about, and therefore his ISP has no clue either since Joe Sixpack signed up with the forwarder. So this makes checking SPF difficult for a big email service provider.
Another problem is that when a phish uses another MAIL FROM, Joe Sixpack won't notice that although the "From" header field says paypal, the "Sender" field is quite different (and yes, Outlook and other mass market email clients display this clearly):
In any case, they support *multiple* authentication methods. So take your pick. There really is no reason to pass on the forgeries.If they are asking us to do this, why don't they show us HOW, and hire some programmers to enable these features in exim4?
I've told them the solution is to get the account access off of the universal browser and onto special purpose browsers they build themselves, but no one listens.
In Japan, it is not uncommon to get a phone call or post card from someone claiming to be, for instance, a family member in trouble and in need of quick cash.
It's surprising how many people don't check first, and to the tune of hundreds of thousands of dollars at times.
The problem is not unique to the 'net.
The solution is special purpose browsers that the financial institutions provide their customers, which browsers do one thing only. (Well, okay, one kind of thing.) Connect to the bank and manage the user side of the account.
Asymmetric keys that the bank provides to the browser or the browser just does not connect. And the user calls the bank on the phone to let them know there might be an attack in progress. (Well, most users will think they are just complaining that the "browser doesn't work", but the guys at the bank are instructed to call the sysadmin any time a customer has trouble connecting.
Okay, to make it solid the banks would need an auxiliary domain name confirmation system (with asymmetric keys, yes) and the customers would need their own sets of asymmetric keys and maybe one-time pads that the pick up directly from the branch office, stuff like that, but the custom browser enables that.
One thing that paypal has done to try to help is that they always call you by name when they send you email. So if you get email that says, "Dear Sir" or "Dear Customer" or something like that, you can count on it being fake.
/dev/null any email from paypal that doesn't contain your name.
Of course, even if it calls you by your real name, a phisher could have harvested it from somewhere else, so it's no guarantee. But you can safely
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
True, Java has some issues with the temptation to do whatever the latest fad in dev management is, but as far as building a cross-platform browser sufficient to access your bank account securely, it would work.
With bouncycastle, of course.
Hmm. I suppose I should check whether bouncycastle is functional with the current gcj before I get too enthusiastic.