Hi!
On 7/17/26 17:58, William Weiner wrote:
You say there is nothing wrong with re-originating services and no need to do
anything special for them. The proposed sentence says exactly that - SHOULD NOT
treat as suspicious, evaluate on the same basis as any other Sender ADMD
originator. It asks nothing special of anyone; it asks receivers not to apply a
negative inference to chain absence. If the substance is agreed, writing it
down costs nothing. If some future policy author reads Section 11.4's
chain-of-custody language and concludes chain absence is a red flag, the
normative text is what forecloses that. Costless insurance against a known
failure mode.
I think this will not be possible. I guess more and more spam fighting
techniques will emerge that don't work with simple rules, but rather
with some kind of machine learning.
And once machine learning "sees" the headers of a mail, they _can_ pick
up on patterns linked to List-* headers, length of DKIM2 chain, Received
lines that evidence hops before i=1, or reply indicators
(In-Reply-To/References).
So _if_ a receiver should observe a pattern like "List-* mails with a
short DKIM2 chain but a longer Received chain are spammy" (e.g. their
customers mark much of that as spam in their frontends), they'd
legitimately use such patterns as a (weighed) criterion. If not (because
you actually originate a mail stream that's unusually "good"), they'd
"learn" that pattern as neutral or even as good indicator. Potentially
such machine learning would even (basically as reputation system)
"learn" that for i=1 d=foo, this pattern is spammy, while for i=1 d=bar
it's neutral or good.
I'm not sure if we should prohibit such machine learning techniques.
On the long tail: Apple Hide My Email, SimpleLogin, Firefox Relay, DuckDuckGo
Email Protection. These are not obscure operators. The category is also growing
into DKIM2's deployment window, not retreating from it. And BCPs regularly
address patterns that are not the majority case - nd= imaginary hops and
donotexplode are not mainstream deployment scenarios either.
nd= may cover b2c bulk mail (newsletters etc.).
Imaginary hops may cover forwards from mail @ customer.domain.example,
hosted at hoster.example.com when the host externally uses
hoster.example.com VERP mf= instead of injecting their VERP return paths
into the customer's domain's space. No idea how frequent that is, but in
a way, imaginary hops are no extra feature but just a description how to
work with the _existing_ features if you should have such a case.
I've seen that donotexplode might be good for banking mails etc. (b2c
mail aimed at one specific customer that is not supposed to reach more
than this one recipient - making single forwards ok, but explosion not ok.)
The DMARC mailing list case is the direct precedent: the WG believed the answer
was obvious, didn't write it down, and p=reject broke lists anyway. The cost of
BCP text when the answer is obvious is zero. The cost of its absence proved not
to be.
Here we have no sender policy "reject" feature in DKIM2 in the first place.
Hannah.
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net
www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr.
Verena Patzelt
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt,
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise
auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient of this e-mail, you are hereby notified that saving,
distribution or use of the content of this e-mail in any way is prohibited. If
you have received this e-mail in error, please notify the sender and delete the
e-mail.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
