Re: Last Call sender-auth-header

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Nov 21, 2008, at 11:02 AM, SM wrote:

At 20:00 20-11-2008, Douglas Otis wrote:
It is rather startling that adoption of an experimental RFC is being presumed by this draft. As such, those not adopting this experimental PRA RFC run the risk of being

There are existing implementations of these experimental RFCs.

Sorry, this should have said "universal adoption".

The sender-auth-header draft states "as to the validity of the message's origin" and describes both Sender-ID and SPF as "e-mail authentication methods in common use". When SPF records are published to mitigate MailFrom backscatter, it is not reasonable to assume authorized MTAs restrict MailFrom to only authorizing domains. There is _nothing_ to indicate MTAs require authorization and then bind authorizations to specific domain controlled accounts. Whether restrictions are imposed on PRAs or MailFroms based upon authentication-results headers for Sender-ID and SPF represents highly speculative and highly dangerous conjecture. Since these identities can not be authenticated in this manner, it would be perilous to assign negative reputations against these speculative domains as well.

While a lack of authorization might form a basis to refuse acceptance or to decide folder placement, there are no practical conventions, experimentally or otherwise, that supports this draft's presumption of authentication for either SPF or Sender-ID. The only (weakly) authenticated identifier is the IP address of the SMTP client seen by the border MTA, whether this SMTP client was authorized by Sender-ID or SPF or not. This information, which is essential to assess and assign reputation, has been omitted! The IETF should seriously question the motives for such omission.

Adoption of this draft may then require the IETF to endorse Sender- ID. After all, email

As I mentioned before on the mail-vet mailing list, this header is used to convey results of DomainKeys, DKIM, SPF and Sender-ID evaluation. It is not an endorsement of a specific evaluation method.

The typical user will see this header making the following statement--

Authentication-Results: myisp.com; sender-id=pass jon@xxxxxxxxxxx

A reasonable person who understands the definition for authentication will be mislead into believing they are being assured by "myisp.com" that "jon@xxxxxxxxxxx" originated the message.

For either SPF or Sender-ID, an assumption of authentication requires universal adoption of both MailFrom AND PRA restrictions by ALL authorized MTAs. Omitting the only "authenticated" identifier associated with either of these methods helps sell the lie that SPF or Sender-ID are authentication methods. Since there is not universal adoption of MailFrom and PRA restrictions by all authorized MTAs for both Sender-ID and SPF, this lie can act as a type of extortion.

Those mislead by this header will be even more prone to confidence artists. Confidence artists can now take advantage of current email infrastructure that does not impose the experimental restrictions and have their message receive misleading endorsements made possible by this header. Perhaps creating this problem is seen as a means to drive demand for MTAs that can bind PRA and MailFrom restrictions against validated accounts. Although such efforts are likely impractical in many cases, there is no way to "opt-out" other than not publishing SPF records. Since many may depend upon SPF to mitigate backscatter from larger providers, removing the local-part, adding the IP address of the SMTP client, and the term "authorized-by" is a reasonable solution that is much less likely to prove misleading. Unless of course, the desire is to mislead? Having the IP address available permits access to automated reputation assessments that have a reasonable chance at providing timely protection, unless of course the desire is not to offer protection? Protecting against just look- alike attacks likely represents a manual and slow process.

-Doug
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]