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(_at_)example(_dot_)com
A reasonable person who understands the definition for authentication
will be mislead into believing they are being assured by "myisp.com"
that "jon(_at_)example(_dot_)com" 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf