> Hi all, > Frank, Eliot, and myself have finished up a first cut at the WG’s 1st real > deliverable: > • Document describing interoperability issues with DMARC and indirect > mail flows and possible methods for addressing them.
> Please review at your convenience and submit comments, feedback, and > suggestions for text to this list. Frank and/or Eliot will be folding in > edits. A serious effort to cast issues in the language of RFC 5598 was made. > Find it here: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ > Our aim is to have this document ready for publication by end of February. <chair hat off> A few quick comments: The introduction classifies message transformations as a type of indirect mail flow. This takes a little getting used to, to say the least. For example, if someone's mail always traverses a relay which incorporates boundary filtering functionality that breaks DKIM signatures, and this in turn prevents them from performing DMARC checks, you may have a hard time convincing them that there's anything "indirect" about the path. Of course it all works if you define "indirect" as anything more complex than an agent that incorporates a DKIM signer sending directly to the agent that verifies the signature. (And even this could involve a transport encoding change that breaks a DKIM signature.) I admit there's some temptation to define things this way - but do we really want to go there? There also really needs to be a distinction made between indirect paths that involve final delivery and subsequent resubmission and those that do not. I for one don't have much expectation that if I resend a message that's been delivered to me without changing the From: field that it will pass muster. Message that fail because of the involvement of a simple alias are another matter. The last sentence in section 2.1 doesn't really make sense to me. There is no problem with having multiple SPF records point at the same server IP address or addresses, so multiple mail streams are not issue. Of course this doesn't make this sort of thing a good idea. Selecting the host name for use in HELO/EHLO do that SPF checks will pass, while theoretically possible, is entirely contrary to the purpose of the parameter and thus bad operational practice. Indeed, I have to question why this is in the draft. Are people actually doing this? Section 2.2 is incorrect in regards to how SPF mismatches on forwarders occur. Essentially all forwarders change the 5321.HELO/EHLO, but simple alias exansion usually does not change the 5321.MailFrom. In these cases the issue isn't that the 5321.MailFrom doesn't match the 5322.From, but rather that the SPF check may fail because the list of allowed IPs does not include the forwarder. Section 2.3 needs considerable expansion, and needs to talk about the differences between simple and relaxed canonicalization. 3.1.2.1 conflates at least two different meanings of the word encoding. Further, only changes to the transport encoding fall under the purview of an MTA; charset transcoding is a gateway function and needs to move to the proper section for that. 3.1.2.2 ismispositioned. An MTA that modifies, adds, or removes content isn't just an MTA, it's also performing the function of a gateway, boundary filter, mediator. etc. And once you get into such functions, AS/AV checks are but one possible action among many. I guess my suggestion would be to talk about AS/AV checks and message modification under boundary filter. That's where RFC 5598 positions such things. (I note in passing that a brief mention of AS stuff is already in section 3.2.5. Merging this section in there seems like a good idea to me.) I also don't see how outright blocking is relevant to the matter at hand. Sure boundary filters reject or discard messages all the time, but how are such cases relevant to DMARC interoperability? DMARC validation can't fail for a message that never made it to the validator. Section 3.1.2.3 "invalide" -> "invalidate" In section 3.1.3, Sieve is in no way limited to messing around with headers. For example, sieve extensions exist that can delete or modify message parts. That said, since Sieve operates on or around the time of final delivery, such modifications are supposed to be happening at a point past where DMARC checks have been performed. It's only when messages are reintroduced into the transport infrastructure with the same From: field that issues may arise, and this needs to be noted. What is the first sentence of section 3.2 supposed to mean? Section 3.2.3 really needs to talk about why mailing lists perform the message modifications they typically perform. I don't believe the use of X-Original-From is described in any RFC currently. If we're going to talk about it in section 4.3 we need to talk about how it's actually used or refer to some place that does. The Internet is a big place, and none of us are in a position to fully assess the state of play in every nook and cranny out there. As such, I'm very reluctant to make statements like "there is very little reason to modify the encoding of a message". What if there are good reasons to somwhere? Do we really want another round of the charset wars in this context? And as for transport encodings, like it or not, the standards say that if you're in possession of an 8bit message and the system you're sending it to doesn't support 8bitMIME, you either downgrade or bounce. Of course you can argue that this is obsolete, but do we really want to open this particular can of worms in this document? And on a similar note, try selling what 4.4.1.2 says to a financial institution that is bound by laws saying what must be and cannot be in the messages it emits as well as what's inbound messages destined for employees. I'm sure they'll find it amusing. That's it for now. </chair hat off> Ned _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
