----- Original Message ----- > From: [email protected] > To: "Tim Draegen" <[email protected]> > Cc: "dmarc" <[email protected]> > Sent: Sunday, February 1, 2015 5:58:10 PM > Subject: Re: [dmarc-ietf] interoperability draft for review > > > 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?
at ESPs or domain hosters, dedicated IP address often comes at a premium, if possible. At google/microsoft/... email domain hosting, you get the google/microsoft/... hostname not something in your own domain. (if not mistaken) > > 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. I think we speak of something else here the alignment, but your point is valid too. Adding some text. > > Section 2.3 needs considerable expansion, and needs to talk about the > differences between simple and relaxed canonicalization. done > > 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. done > > 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.) merged > > 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. > done > What is the first sentence of section 3.2 supposed to mean? that we stole some text. > > Section 3.2.3 really needs to talk about why mailing lists perform the > message > modifications they typically perform. done > > 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. it is RFC5703 > > 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? Like the blue ribbon ASCI footer? :P In my personal experience when I pointed that an MTA was doing encoding and therefore breaking DKIM, the option was removed, nobody came back to me and said I cannot do that. toning down the language nevertheless > > 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? well, in this day and age with security vulnerabilities every week, how far do we have to support legacy mail systems? > > 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. I think we had in mind the AV that adds "scanned by Great AV, you should buy it". Can you give some samples of what you have in mind? I suppose a financial institution would add a disclaimer on all emails, but before DKIM. Also I don't think they would operate a mailing list or forwarder lightly... _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
