Jim Popovitch writes: > On Tue, Apr 15, 2014 at 12:13 AM, Stephen J. Turnbull > <step...@xemacs.org> wrote: > > Jim Popovitch writes: > > > > > Bingo! The dmarc folks (many of who are IETF participants) ignored > > > and performed an end-run around the standards process. > > > > Not really. The basic protocols (SPF and DKIM) are RFCs, and that's > > really what the IETF process is for. > > Interoperatabiliy and functionality is what a standards body is > for.
But interoperability and functionality of *what*? The IETF's mission is to define the interpretation of what comes off the wire, so that parties who have never met can communicate reliably. It's not to tell you not to send advertisements by SMTP or NNTP. It's not to tell you who you can trust to make your accept/reject decisions on Internet messages. > DMARC is a system that allows 1st parties to announce to 3rd parties > what to do with something delivered by a 2nd party, all without any > standards or feedback/care for the 2nd party. Well, yes, that's what "transparent protocols" like SMTP + DNS MX are all about. The MX doesn't need to know what the sender wants the recipient to do with the message, it just forwards it. If you don't want to be screwed as a second party, don't participate. And that's what your patch does. Right? Right! *Exactly* right! :-) But back to the MX example. xemacs.org is an oldish domain (registered in 1995, I think) with a *lot* of email addresses out in public on the web. So one of our secondary MXes backed out on us because most of the spam they were seeing was destined for us, and they didn't want anything that translated to their domain in our Received headers if it was going to go into a spam database somewhere. It was also getting to be a significant fraction of traffic to their MTA. I can't blame them! Given their situation, I think that was the right thing to do. We managed to get along. So IMHO the point of the RFC process is to make it easy for those who *want* to cooperate to do so. It's not to force anybody to cooperate with anybody else. > It sits atop 2 standards that were never intended for the purpose > (rfc5322.From blocking) they are being used for. So what? Who cares about *intention*? As Lindsay pointed out, "you can always use it for something else" (even if it's not broken!) The question is were DKIM and SPF designed to accomplish the purpose of authenticating "From" well? IMO, probably not -- they are sender, not author, authentication. Does it make sense to pay attention to DMARC "reject"? I think not -- so it's a damn good thing it's not an RFC! I really wouldn't want to be in the position of criticizing Google for RFC non-conformance if they decided to ignore Yahoo! rejects.[1] ;-) My point is not to defend what Yahoo! did, or the DMARC standard. Simply that *policies* about when to emit/respect DMARC "reject" and "ruf" are out of scope for specification by RFC. Footnotes: [1] Which I actually think might be a strategically good move for them. "Don't break the world! Use Gmail and get your bank on the 'Gold Key' program!" ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
