Information AboutSender Id |
| CATEGORIES ABOUT SENDER ID | |
| e-mail authentication | |
| spam filtering | |
| microsoft | |
|
The Sender ID proposal had become the subject of controversy regarding holds Patents on key parts of Sender ID and licenses those patents under terms that are not compatible with the GNU General Public License and which are considered problematic for Free Software Implementations in general by free software groups like the Apache Software Foundation and the Debian Project . PRINCIPLES OF OPERATION Syntactically SPF and SenderID are almost identical: Replacing the string v=spf1 in a valid SPF policy by one of... # spf2.0/mfrom # spf2.0/mfrom,pra # spf2.0/pra,mfrom # spf2.0/pra ...yields a syntactically valid SenderID policy, and vice versa. The evaluation of SPF and SenderID policies follows the same general rules. The core SenderID specification has a normative reference to the SPF specification and thereby inherits exactly the same error handling, the same processing limits, and the same syntax details as SPF. Semantically there are only two differences: SenderID offers the feature of ''positional'' modifiers not supported in SPF. In practice so far no ''positional'' modifier was specified, let alone supported in any SenderID implementation. Except for this detail spf2.0/mfrom is semantically the same as SPF, ''mfrom'' stands for MAIL FROM, the checked identity in SPF. Because SPF is wider deployed than the later proposed spf2.0/mfrom publishers of sender policies wishing to protect their address in MAIL FROM Return-Paths generally prefer the classic v=spf1 format. Both spf2.0/mfrom,pra and spf2.0/pra,mfrom have the same meaning, they introduce a policy that can be used to check the ''mfrom'' as well as the ''pra'' identity. Last but not least spf2.0/pra introduces policies checked only with the ''pra'' identity. At this time it is not specified how SPF's for the HELO identity should be handled in ''pra'' checks, SenderID implementations could handle it as syntax error. The Purported Responsible Address or ''pra'' is determined by a tricky evaluation of the four mail header fields...
...finally resulting either in one address, the ''pra'', or an error for illegal combinations as explained in RFC 2822. Simplified the rules are Sender beats From
illegal to have more than one From-address without a single Sender-address. This ''pra'' scheme has the theoretical advantage of dealing with addresses in header fields that are often displayed by MUAs (Mail User Agents), unlike SPF's Return-Path header field or ''mfrom'' in SenderID terminology.
To be an effective anti-phishing tool, the MUA will need to be modified to display either the ''pra'' for SenderID, or the Return-Path: header field for SPF. The ''pra'' tries to counter the problem of ''phishing'', while SPF or ''mfrom'' tries to counter the problem of spam bounces and other auto-replies to forged Return-Paths. Two different problems with two different proposed solutions. STANDARDIZATION ISSUES Unfortunately ''pra'' has the severe disadvantage that forwarders and mailing lists can only support it by modifying the mail header, e.g. insert a Sender or Resent-Sender. The latter violates RFC 2822 and can be incompatible with RFC 822. With SPF mailing lists continue to work as is, and forwarders wishing to support SPF only need to modify the SMTP MAIL FROM in addition to the RCPT TO, not the mail. That's no new concept, with the original RFC 821 SMTP forwarders always added their host name to the reverse path in the MAIL FROM. The most problematic point in the core SenderID specification is its recommendation to interpret v=spf1 policies like spf2.0/mfrom,pra instead of spf2.0/mfrom. This was never intended by all published SPF drafts since 2003, and for an unknown large number of v=spf1 policies an evaluation for ''pra'' could cause bogus results for many cases where ''pra'' and ''mfrom'' are different. This technical problem — in fact only four letters ,pra in the core SenderID specification — was the base of an appeal to the Internet Architecture Board (IAB) . In response to another prior appeal the IESG already noted that SenderID cannot advance on the IETF standards track without addressing the incompatibility with a MUST in RFC 2822. SEE ALSO
EXTERNAL LINKS
|
|
|