Last call for The intent of this posting is to generate broader discussion. Browser and MUA plugins may soon annotate email messages with identifiers contained within Authentication-Results headers. For Apple Mail, just setting changes can cause this header to be displayed above the message. The reason given for the Authorization-Results header is stated in section 1 Introduction: ,--- The intent is to create a place to collect such data when message authentication mechanisms are in use so that a Mail User Agent (MUA) can provide a recommendation to the user as to the validity of the message's origin and possibly the integrity of its content. '--- There is an essential consideration when using this header given in section 4.1 Header Position and Interpretation ,--- An MUA SHOULD NOT reveal these results to end users unless the results are accompanied by, at a minimum, some associated reputation data about the message that was authenticated. '--- This statement would have been more clearly stated as: ,== An MUA SHOULD NOT reveal these results to end users unless the results are accompanied by, at a minimum, some associated reputation data about the authenticated origination identifiers within the message. '== This consideration is to preclude the apparent endorsement whenever authenticated identifiers have obtained negative reputations. In addition, only authenticated identities are safely assigned negative reputations. Therefore, it is extremely important to understand what authentication means, and which identifiers can be authenticated. In addition, since reputation results are not included in this header, and there is no assurance reputations have been checked. The Browser and MUA plugins will need to obtain reputations for these identifiers independently to comply with section 4.1. With respect to Sender-ID, the auth-header draft and author presume the PRA email-address captured within the Authentication-Results header will be considered authenticated whenever the sending MTA is authorized by the SPF record located by PRA. This authorization, as the draft states, is denoted by "sender-id=pass". A presumption of the PRA being authenticated expects there will be PRA restrictions imposed by all SPF authorized MTAs. A presumption of PRA authentication is why the weakly authenticated IP address of the SMTP client that was authorized by the SPF record is omitted. Section 1.3 Definitions says: ,--- Generally it is assumed that the work of applying message authentication schemes takes place at a border MTA or a delivery MTA. This specification is written with that assumption in mind. ... It is also possible that message authentication could take place on an intermediate MTA. Although this document doesn't specifically describe such cases, they are not meant to be excluded from this specification. '--- The position of the Authentication-Results header, with respect to the Received header added by the border MTA, is unknown. Browser and MUA plugins will be required to guess which Received header was added by the border MTA, but even then, the Received header is not assured to include the IP address of the SMTP client. As such, the auth-results draft clearly expects that the SMTP client's reputation plays no role. Reputations are to be based only upon the PRA when applying annotations. : ^( 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 assigned a negative reputation, or of misleading those believing PRA are authenticated as a result of this misleading header. In addition, although SPF includes local-part macros that might invite DDoS attacks, these seldom used macros can only deny and not affirm the validity of a domain's local-parts. With respect to reputation in regard to SPF or Sender-ID, it is _only_ the IP address of the SMTP client seen by the border MTA that has been weakly authenticated. Unfortunately, the authentication-results header has neglected to include this SMTP client IP address. This omission might have been to mislead recipients into believing PRAs are authenticated, or to force adoption of PRA restrictions, or to deflect the affect of abusive behavior. For example, it is common to see less scrupulous ad campaigns or perhaps compromised servers emit abuse from specific IP addresses. Blocking all email that carry a specific domain seldom represents a measured or practical response to a problem isolated to specific servers. As such, the favorable annotation of spam may occur, or one compromised server may disrupt email from the entire domain. Blocking only servers that appear abusive would be far less disruptive than blocking by the domain. An assumption that a PRA has been authenticated whenever a Sender-ID pass result is obtained assumes all SPF authorized MTAs impose PRA restrictions for all email they carry. This also means any litigation against the holder of the PRA IP could then force those defending their own IP into not imposing these now essential PRA restrictions. No effort has been made to note when only SPF records have been published. But of course, such notification would call into question the expectation of PRA restrictions being imposed. :^( Adoption of this draft may then require the IETF to endorse Sender-ID. After all, email providers would rather have domains blamed for abuse, than the IP address of their MTA when failing to restrict access to bad actors using forged identities. DKIM seems like a far safer solution, since it does offer a valid means to authenticate the domain. This draft can be repaired by making minor changes. This can be done by having the content of the Authentication-Results header read: my-isp.com; sender-id=pass MTA/10.100.200.2/Authorized-by/@example.com rather than: my-isp.com; sender-id=pass jon.doe@xxxxxxxxxxx Both security and clarity is achieved without violating what this string is allowed to contain. There are no reasons that respect the security of the individual for not to making this change. -Doug |
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf