Murray S. Kucherawy writes:
> What gets added from here forward really needs to be as innocuous
> as possible. I believe we're in a position where things like SPF
> and DKIM are still young enough that their implementations are
> malleable,
I'm not sure what you mean. Now that I actually know what those
protocols do (and DMARC itself, for that matter), I don't really see
how they can be much improved. Do you mean the policy engines that
make decisions based on the output of SPF and DKIM implementations?
Going way out on a limb here, it's not even clear to me that getting
the simple delegation protocols[1] implemented would be of that much
incremental benefit to mailing lists and other forwarding Mediators
given that everybody and their brother seems to be taking a Monty-
Pythonic "wink, wink, nudge, nudge, say no more, eh?!" approach to
p=reject as receivers.
What would be ideal from my point of view (as a mailing list advocate,
though I don't claim to represent all MLM developers in this) would be
(1) The DMARC standard itself to achnowledge that "p=reject" really
means "we are very worried about the security implications of our
domain in the From field" (with different spin depending on
whether you're a bank or a large mailbox provider that has leaked
a lot of personal information to spammers, but basically the same
semantics for the mail system), and therefore
Receiving systems SHOULD treat a message that fails the From
alignment test with great care, including such measures as
quarantining the message in a special folder, deactivating links
and attachments in the displayed message, or displaying a warning
message that the message is likely to be inauthentic. Receiving
systems MAY reject such messages outright. Receiving systems MAY
treat as authentic a message that would otherwise be quarantined
or rejected under this protocol in the presence of strong evidence
of authenticity such as a valid signature of important header
fields and body by a well-trusted Mediator (see Security
Considerations for discussion).
I think this has almost no chance of actually happening, but it's
what I'd consider ideal.
(2) Some kind of Authentication-Results protocol, which would be one
of the "important header fields" mentioned in point (1). There
would need to be provision for multiple fields of this type, so it
would need to include the identity of the authenticating agent.
It occurs to me that this field might need a weak signature of its
own to establish authenticity in the presence of a chain of
Mediators.
This doesn't depend on (1) to be useful in the de facto presence
of people acting as in (1).
(3) I would really like to see some provision for reporting to mailbox
users when their mail is being discarded due to publication of
p=reject by their mailbox providers, especially in cases where a
Mediator is willing to put its reputation on the line by signing
the forwarded message.
Note that this would only be a burden to abusers of p=reject, as
in the case of transactional mail the responsible author is the
corporate entity, not the employee. So no further report would be
appropriate in that case, as the organization is already receiving
the DMARC reports.
> but trying to get every MLM, MTA, MUA, and MSA out there to
> suddenly use Sender universally and in a common way seems far less
> likely to be successful.
We can't even get the (displayed) From used in a common way, viz the
"From <sender> on behalf of <author>" usage. Technically, I
understand the point they're making, but real people think of
on-behalf-of as the kind of thing lawyers do: "Dear Miscreant: I am
writing on behalf of Mr. Offended Easley as his attorney. Cease and
desist. Sincerely, Beagle Leagle, JD" (and of course the actual RFC
5322 Sender is Ms. Para Leagle). Some real people do find that
confusing.
Footnotes:
[1] I'm of two minds regarding your (Murray's) more complex part-by-
part signing scheme. On the one hand, it's way cool, and should be
implemented for that reason alone. On the other, it looks expensive
and fragile and I suspect it won't get a lot of uptake for that
reason.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
