On Nov 30, 2014, at 7:42 AM, Hector Santos <[email protected]> wrote:
> On 11/29/2014 7:04 AM, José Ferreira wrote: >> >> Like is said, they are rare but important. And some domain owners may not >> adopt p=reject for that reason. >> >> Jose Borges Ferreira > > Domains that publish a p=reject and don 't understand its possible outcomes, > shouldn't be our (IETF protocol standards development) problem. It helps to > know they exist, but they should not be the reason for throwing out the > proverbial baby out the window. Dear Hector, DMARC is throwing out three decades of defined header field roles for Author and Sender and is not compatible with email. This happens when the From MUST have the same domain as that of the Sender to achieve the DMARC required alignment. This is not possible when dealing with various third-party services, such as mailing-lists or even offering the disrupted services DSNs. > We are not going to solve the mailing list problem UNTIL the mailing list > folks (software developers) change their software TO SUPPORT Policy. We > still have people that are trying to avoid it, FOR 10 YEARS, and that > avoidance has not worked! Strongly disagree. DMARC does not permit legitimate and valid email to be accepted from a third-party service which disrupts valid email uses. These include: -- forwarding of email to a different domain (as might be done with alumni accounts) -- use of third-party services where the From header field properly retains the role of the Author as stipulated by RFC5322 DMARC assumes users are unable to understand message sources based on the Sender header field, where the source agent role has been defined. In fact, the Sender should not be placed into the From header field. Once that dubious practice becomes required, even guessing who authored a message becomes doubtful. > Its really that simple, however, the complete integrated solution is COMPLEX > (and costly) and for the most part, only a total system integration can > handle it. If you (speaking in general) only have a MAILING LIST package, > well, you need to wait for the other parts to fit in as well and vice versa. Is it really overly complex to make Sender header fields visible to users? This should remove justifications for rejecting otherwise valid and legitimate messages. If so, no changes would be needed when Sender header fields comply with either SPF or DKIM. It seems DMARC needs a fallback mode for policies imposed by DMARC domains to override miss-applying DMARC policy against normal email accounts. As it is now, the best that can be done is to downgrade p=reject to p=quarantine. Users are then expected to find valid messages being placed into their spam folders, which defeats stronger protections otherwise afforded when users are informed acceptance is based on a strict policy of either From or the Sender header field alignment. It only makes sense for transactional sources to exclude otherwise legitimate forms of email that includes the Sender header field. As such, DMARC should have a setting to explicitly include use of the Sender header field alignment. Otherwise, DMARC remains incompatible with email. > All I reading (and it seems to be subsiding) are ML folks trying to advocate > avoiding domains with strong, restrictive policies. Well, can't have it both > ways. Intentional ignorance and expectation that things will continue to > work and integrate well, is in my strong technical software engineering > opinion, unrealistic. If policies are to be strictly enforced, they should offer a mode that permits valid and legitimate email. As currently defined, DMARC can't. > All parts need to fit together and since its a multi-component integration > problem, there are only a few packages that can do that. That is what makes > this a long time difficult problem to solve. You have systems people, > operations, networks, mailing list people, etc and most have different goals > and agendas. DMARC is attempting to satisfy a narrow range of services where the From and the Sender header fields must be within the same domain. When domains such as AOL and Yahoo decide their users' messages must be strictly enforced in this manner, this non-compliant policy disrupts many normal, expected, and legitimate email. This disrupts email's agility at meeting a broad range of uses and has the effect of balkanizing these services. It is DMARC that is being unrealistic. Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
