[Mailman-Users] Emails from yahoo members, are getting rejected by yahoo, "Service Unavailable".

[Stephen J. Turnbull]

Jim Popovitch writes:
 > On Tue, Apr 15, 2014 at 12:13 AM, Stephen J. Turnbull
 > <stephen at 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!"