Terry Zink: Security Talk

Discussing Internet security in (mostly) plain English

Sender authentication part 20: Advantages of PRA vs MAIL FROM

Sender authentication part 20: Advantages of PRA vs MAIL FROM

  • Comments 3

Microsoft is shortly coming out with some documentation on SenderID and the business case for its implementation.  Hopefully by now I have demonstrated its usefulness.

The Purported Responsible Address has a couple of advantages when deciding to support SenderID vs SPF:

  1. It is the identity that is typically seen by users and therefore helps to detect phishing
  2. It is derived from RFC 2822 message headers, the Resent-Sender, Resent-From, Sender and From addresses.  This allows for easier adoption for forwarders.

The MAIL FROM has the following advantages:

  1. It helps to reduce "joe-jobs" by counteracting fake bounce messages (return-paths)
  2. Checking on the data can begin before the message data is received; this means that depending on the implementation, mail servers can save on bandwidth.

Both techniques can use the same SPF record format, though with SenderID the implementers need to know what they are doing since SPF classic was originally designed to be used on the envelope sender domain.

Leave a Comment
  • Please add 7 and 6 and type the answer here:
  • Post
  • For SenderID, if the PRA chooses one of the Resent-* headers, then it will not be the identity typically seen by users and help detect phishing. In that case, SenderID could be used to help phishing, not deter it.

    From: <someone@uses-senderid.com>

    Resent-From: <spammer@bad-guy.com>

    This case needs to be handled. It seems like SenderID needs a SSP doc like DKIM that allows domain owners to say they allow 3rd parties to ues their Domain in RFC822From. But I don't even like that idea because it will most likely end up being to permissive like SPF's ~all.

  • That's true enough, though I think that the Resent-* headers are intended to be used for forwarders and SenderID will extract that domain in order to prevent false positives.

  • This speculations about "the identity typically seen by users" is slightly nonsensical when it comes to compare techniques not used on average. If any of that stuff will ever become relevant, client software will upgrade.

Page 1 of 1 (3 items)