At 09:13 10-10-2008, Alexey Melnikov wrote:
Or rather "one wouldn't necessarily want to implement the whole
draft-kucherawy-sender-auth-esmtp-01.txt".
During a previous discussion, one participant stated that he wanted
to make use of the information from Authentication-results: headers
inserted by upstream MTAs (forwarding messages). What
draft-kucherawy-sender-auth-esmtp-01 proposes is a SMTP extension for
MTAs which support the proposal to transfer the
Authentication-Results information. That makes it easier to
determine whether the sending MTA is providing that information and
removal of "spoofed" Authentication-Results: headers.
But if the intention is that draft-kucherawy-sender-auth-esmtp-01 is the
mechanism for discovery, then the auth-header draft needs to be explicit
about that in the Security considerations section.
draft-kucherawy-sender-auth-esmtp-01 doesn't provide a discovery
mechanism as what we have been discussing about.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html