Hector,
>> Now of course we all know that if I used "!all" in my SPF
>> record, this would break messages from my users who:
>
> Do you mean "-ALL" hardfail policy?
Yes, sorry.
>> 1 - ... are currently offsite but set their From: line to
>> my domain, then submit mail through another provider.
>
> Roaming user. :)
... for which I think the correct solution is SMTP AUTH to *my*
relay.
>> 2 - ... post through a mailing list offsite which doesn't
>> munge "From:".
>
> 5322.From is not SPF related. You mean the 5321.MailFrom?
Yes, the SMTP "MAIL FROM". Sorry again.
>> 3 - ... send to recipients who in turn forward their mail
>> (without fancy workarounds) to a third site.
>
> A simple relay, sure, SPF has that problem you will only see
> for -ALL policies.
>> But if I understand correctly, it's being suggested that for
>> various proposals made here to work, either the sender's mail
>> system or the final receiver's mail system would have to become
>> aware of all of the "legitimate" (definition purposely left
>> out!) mailing lists to which its users subscribe.
[...]
>> I believe that some people have claimed that this problem is
>> easily overcome (or perhaps "worked around" would be a better
>> expression) by examining mail headers and gathering statistics,
>> and this may well be the case, but addressing the problem in
>> this way will always depend on heuristics, just like any other
>> anti-spam method.
> I agree. This is why it is a separate implementation issue. We are
> looking for a deterministic protocol solution. The lack of not
> having the "registration" in place first should not stop one from
> "checking" to see if it exist.
Certainly a protocol could be defined with "apply local policy here,
and return ACCEPT or REJECT based on the results", and from the point
of view of a protocol, that works and is implementable. We already
have that with SMTP, where we can return "550 Get lost spammer" if we
wish, based on whatever heuristics or rules we like.
But I thought the point of DMARC was to determine reliably
(using cryptographic keys and/or IP addresses as published by
the alleged originating domain in the DNS under their control)
whether the domain in the "From:" header is really responsible
for originating a given message, and I thought the problem
we're trying to solve here is how we can prevent DMARC from breaking
"mediated" mail (such as mailing list mail).
So far our options seem to be:
- Pass the mail through entirely unmunged, to avoid invalidating the
DKIM signature - which means giving up features that have been
useful on mailing lists for decades,
- Munge the "From:" header to have the mailing list "take ownership"
of the message, at least for messages sent by users in p=reject
domains - which is already implemented as an option in at least one
major MLM, but is not popular philosophically (because people
expect the From: line to specify the author of a post) or in
practice (because it makes it harder for the recipient to choose
to reply to the list or to the original sender as they wish),
- Come up with a scheme allowing the mailing list to "re-sign"
a slightly munged version of the message, which is what
I think we're arguing about.
The apparent problem is that a spammer or fraudster or malware
propagator can do to a message anything a mailing list can do. There's a
suggestion that if legitimate mailing lists can somehow be identified
(the "registration problem"), all will be well. If I can summarize
my understanding of the argument so far, some people are saying "apply
heuristics to the registration problem, that should take care of things
well enough", and others are saying "no, no, no, we had a deterministic
thing of beauty with DMARC, you mustn't wreck it with non-deterministic,
implementation dependent heuristics".
Well, I myself wouldn't call something a thing of beauty when it
wrecks the functioning of mailing lists when used as intended, but I
also think it's pointless to try to specify a protocol that allows for
implementation-dependent heuristic decisions to "solve this problem".
Any e-mail provider can already arbitrarily decide to ignore DMARC for
mail they think is list mail, if they want to. Sure, then they couldn't
call themselves "DMARC compliant", but who would lose sleep over that?
Honestly, are Google and Yahoo competing for each other's e-mail users
by advertising that they're the best because they're DMARC compliant?
Perhaps I'm naïve about the politics of all this (actually, that is
certainly the case!), but I suspect that almost all sites, especially
the big ones, do as they please.
If I can step back a bit, all DMARC does is ensure that the site in
the "From:" line signed (or, via SPF, transmitted) *this* message.
A malefactor can send DKIM-signed or SPF-approved messages as easily as
anyone else.
Some of the proposed solutions involve a mediating site making
modifications, and signing its specific modifications. A malefactor can
do that too, of course, but is this really any worse than the original
situation?
A receiver doesn't stop checking a message after it passes DMARC as
currently specified, because it may be that the site @spammer.com is one
whose messages we don't want, or it may be that [email protected]
had his account phished and is suddenly sending trash.
A receiver wouldn't stop checking messages after the munged and
re-signed version passes a "new DMARC", for the above reasons *and*
because it might not want messages from "@spamlists.com", or because
"[email protected]" could sometimes pass a bad message.
Nothing about DMARC or DKIM states that a message is okay - that part
is checked by other (yes, heuristic) parts of the mail system.
Nothing about an expanded DMARC or DKIM with "re-signing of
modifications" needs to be construed as stating that a message is
okay.
Hmm, Hector, I think you've forced me to convince myself that you're
on the right track: I think that the "registration problem" is a red
herring after all. There's no deterministic way to decide what's a
legitimate mailing list (or other re-signer), any more than there's any
way to deterministically decide what's a legitimate originator. Those
determinations are made heuristically outside DMARC.
Meanwhile, DMARC (and potentially an expanded "re-signing" version)
can verify only the authenticity of the originator (and of the
re-signer), and thus the authenticity of the original message (and of
the modifications), which is still useful.
>> What am I missing?
>
> Nothing. :)
... except a copy editor. ;-)
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
[email protected] +1 514 848-2424 x2285
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
