Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Spam

PayPal Asks E-mail Services to Block Messages 222

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.""
This discussion has been archived. No new comments can be posted.

PayPal Asks E-mail Services to Block Messages

Comments Filter:
  • SPF (Score:5, Informative)

    by ikegami ( 793066 ) on Wednesday March 28, 2007 @11:24AM (#18515939)
    This is the problem Sender Policy Framework (SPF) [openspf.org] tries to address.
  • by idiosynchronic ( 582249 ) on Wednesday March 28, 2007 @11:50AM (#18516289)
    My problem isn't PayPal - it's the frickin' parent company of eBay.

    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.

  • Re:That reminds me.. (Score:3, Informative)

    by nine-times ( 778537 ) <nine.times@gmail.com> on Wednesday March 28, 2007 @12:04PM (#18516465) Homepage

    I'm not sure how this analogy is relevant. Isn't Paypal asking service providers to block Paypal messages that lack signatures? Wouldn't it be more like: if there were fake police officers going through people's houses and stealing things, and in response then the police department asked citizens not to let police officers into their houses unless those police carried some kind of official ID.

    It doesn't sound unreasonable to me.

  • Tries but fails (Score:4, Informative)

    by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Wednesday March 28, 2007 @01:17PM (#18517431) Homepage
    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).
  • by marvinglenn ( 195135 ) on Wednesday March 28, 2007 @01:25PM (#18517549)

    The first thing they should do is change the "~all" to "-all" at the end of their SPF [openspf.org] 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"

  • by eli pabst ( 948845 ) on Wednesday March 28, 2007 @01:37PM (#18517723)
    I've seen phishing scam emails using obfuscated javascript for links to the actual phishing sites recently, so that isn't always a tipoff. Your grandma and grandpa aren't going to be able to download the page source and walk through the javascript to see what it's doing.
  • Re: Tries but fails (Score:4, Informative)

    by Dolda2000 ( 759023 ) <fredrik@dolda200 0 . c om> on Wednesday March 28, 2007 @04:09PM (#18519709) Homepage
    Since he does not seem to, let me take the chance to elaborate on that one. One of the greatest problems with SPF is that you can't forward messages, so SPF would mean the doom of mailing lists. To be more specific about the problem, if I send a mail to a list, it might come from me@foo.com, and in foo.com's SPF DNS record, I have stated the IP address for the mail servers from which mails are allowed to arrive. The mailing list may check that and be content, but then it forwards it to all its members, using its own mail server, which, of course, isn't recorded in foo.com's SPF record. Hence, all receiving hosts (that support SPF) will refuse the message.

    DomainKeys doesn't have a problem with that, though. It signs the message body and a select choice of headers (by default, all headers below the DomainKeys header) with a private key (which is only known to the submit servers). The receiving host checks foo.com's DNS for the public key, and verifies the signature. Obviously, this works with mailing lists as well, since it doesn't matter from which mail server the message arrives. All which matters is that the signature can be verified with the public key in the From address' domain's DNS records.

    Naturally, it isn't just mailing lists which run into problems. A lot of mail systems rely on forwarding.

  • by Fulcrum of Evil ( 560260 ) on Wednesday March 28, 2007 @04:23PM (#18519901)

    That means every mail server operator, even the home hobbiest, has to subscribe to some third-party authentication service like domain keys.

    I'm just a hobbier, not a hobbiest. Of course, public key stuff means you just have to generate a keypair and put the public one in your domain record.

  • by Trillan ( 597339 ) on Wednesday March 28, 2007 @05:03PM (#18520453) Homepage Journal

    From the RFC #2821 (which defiens modern SMTP):

    SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else. Constructing such a message so that the "spoofed" behavior cannot be detected by an expert is somewhat more difficult, but not sufficiently so as to be a deterrent to someone who is determined and knowledgeable. Consequently, as knowledge of Internet mail increases, so does the knowledge that SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. Real mail security lies only in end-to-end methods involving the message bodies, such as those which use digital signatures (see [14] and, e.g., PGP [4] or S/MIME [31]).

  • by Joseph_Daniel_Zukige ( 807773 ) on Thursday March 29, 2007 @01:53AM (#18525121) Homepage Journal
    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.

Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.

Working...