On 3/22/23 4:00 PM, Emanuel Schorsch wrote:
On Wed, Mar 22, 2023 at 11:29 AM Murray S. Kucherawy
<superu...@gmail.com> wrote:
On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch
<emschorsch=40google....@dmarc.ietf.org> wrote:
In my mind, there are two important things I would like to see
achieved:
1) Distinguish indirect from direct flows (encode in some way
which server / mailingList the original DKIM message was
intended to come from). This is needed for domains that aren't
easily identifiable as direct flows (SPF isn't aligned by DKIM
in the direct case).
Wasn't ARC meant to solve this? What have the results been?
ARC has the same challenge that DKIM has when it comes to replay. How
do I know if this is direct mail or indirect mail? Which set of IPs
should I expect the direct mail to be sent from? ARC allows forwarders
to record/preserve authentication status but the same valid ARC
headers can be sent millions of times from all kinds of different
servers.
Note that DKIM has been able to sign auth-res from the very beginning.
Which is why ARC getting inserted into discussions like this is both
frustrating and just muddies the waters.
2) Give more info to identify benign indirect flows (E.g.
"forwarded on behalf of"). This is helpful for recognizing a
recipient's desired indirect flows.
I'm pretty sure this is easily spoofed. So is any sort of tagging
or header field manipulation mechanism. The spammer just needs to
make its mail look sufficiently like something you consider
legitimate, and they're in.
That is why it would be nice to see a solution less trivially
spoofable than existing forwarding headers (e.g. X-Forwarded-For). If,
for example, forwarded-for is recorded in the ARC header, then you can
restrict yourself to trusting a specific pair of "forwarded-for" and
ARC sealer, which is much more trustworthy than the header alone.
But, even an easily spoofable header is still useful. Easily spoofable
means that it doesn't provide much protection against phishing, but it
does make it substantially harder to scale for spam. Most people will
have a limited set of sources which they receive indirect mail for,
and those will vary widely between people. So if spammers, for the
Forwarded-For header, need to get the right value per recipient it
makes automating to a huge scale much more difficult.
But the spammer can also resign a message to make it look like an
indirect flow along with whatever headers you insert. In the end this
all boils down to how much you trust the domain sending you the message.
For the domain the spammer controls, you'd hope they have a neutral to
bad reputation. For legit mailing list providers, you'd hope they would
get a positive reputation over time. None of this has anything to do
with the problem that ARC purports to solve.
Mike
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
