On Fri, 27 Mar 2015 15:22:04 +0900,
"Stephen J. Turnbull" <step...@xemacs.org> wrote:
> Michael Jack Assels writes:
>
> > What's a receiver supposed to do with unaligned mail whose "From:"
> > domain specifies p=reject?
>
> Whatever they want to. If they think they can do filtering better
> than the sender, they may choose to ignore it, and there's nothing
> that can be done about it. Furthermore, I don't see why anyone other
> than the receiver's mailbox users should care what the receiver
> chooses to do.
Right, but that leaves DMARC as just another factor to consider when
calculating a spam score. Actually, it's a little better than that;
it comes pretty close to the desired "really reliably reliable" for direct
mail flows.
> > Clearly, the domain owner is explicitly asking that the message be
> > rejected.
>
> No, they are not, not in the case of AOL and Yahoo!. Representatives
> of both domains have thanked MLM developers for providing mitigations
> so that messages that in the normal (until DMARC) course of events
> would fail From alignment can be delivered to DMARC-participating
> receiving domains which (since DMARC) would reject them. Thus, Yahoo!
> and AOL are clearly taking the position that they would like those
> messages to be delivered.
As I read it, that means AOL and Yahoo are taking the position that
DMARC's p=reject is The Right Thing To Do, while accepting that it's
going to give wrong answers for indirect mail flows, and that it's up
to MLM developers (and other producers of indirect flows) to deal with
it.
> Hector, J. Gomez, Franck, and others take the position that the world
> has changed due to spam and phishing, and therefore "what *was*
> normal" is now irrelevant. The new norm is conform to DMARC and other
> dictatorial sender policy frameworks or you're part of the problem.
>
> I disagree. Spamming and phishing are the problem, traditional
> practices of mailing lists are not.
>
> > If DMARC intends that this be merely one of many factors to
> > consider, then doesn't it boil down to nothing more than
> > p=do-whatever?
>
> No, there is valuable information in the policy. As far as I can see,
> the semantics of "p=reject" are
>
> We have a serious spoofing problem. It is so serious compared to
> the potential damage due to rejecting legitimate messages that we
> accept all responsibility for nondelivery and collateral damage if
> you choose to reject.
I can accept that that may be what p=reject means, but I can't take
seriously the idea that domain owners with p=reject really do take
all responsibility for nondelivery of legitimate messages. When
one of my users bangs on my door demanding to know why her message
message wasn't delivered, can I really refer her to a giant ESP for
an explanation? I don't think so.
I'd be happier to interpret "p=reject" as meaning
Spoofing is a serious problem. With a very high degree of certainty,
we assert that the message you're handling is not legitimate direct
mail. Please take this into account when deciding whether to accept
or reject the message.
This is worth a lot, despite the fact that it leaves the receiver with
two tasks: Determining the message is direct or indirect, and if indirect,
determining whether it's legitimate.
> > Yes, I know that receivers can and will do as they please, but some
> > receivers would be pleased as punch to cooperate in a scheme that
> > gave solid proof of a message's illegitimacy in every case where it
> > was asserted.
>
> Murray's point is that "proof of illegitimacy" is probably a pipe
> dream, as shown by past experience with "policy frameworks".[1]
> Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows
> in daily use by financial institutions and in other transactional mail
> flows.
I agree that absolute proof of illegitimacy for arbitrary messages is
hopeless, but DMARC actually provides a decision procedure for legitimacy
of in the restricted area of direct mail flows (assuming that mail from
compromised accounts is "legitimate"). For DMARC participants, legitimacy
and illegitimacy are equally easy to prove for transactional mail flows,
and equally hard to prove for indirect flows.
MJA
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
