-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]
il.com>, Emanuel Schorsch <[email protected]> writes
>The use-case William describes (a mailing list sitting in the middle which
>isn't DKIM2 aware) seems likely and legitimate in the intermediate case.
For the avoidance of doubt, yes I acknowledge that this case may occur;
however I don't see why am intermediary that wished to improve
deliverability would wish it occur for very long: that is there will be
pressure on them to upgrade (which in this world of AIs finding long
standing security bugs they are likely to be doing anyway).
To be clear : mailing lists in particular will find value in receiving
DKIM2 messages and sending them on as DKIM2. So besides the spammers
(who are always early adopters) I expect mailing lists to migrate
rapidly to this arrangement.
>Presumably the mailing list is already taking ownership of the messages
>because of DKIM and DMARC.
I am not sure that "ownership" is a technical term, but I recognise what
you are saying -- they are applying signatures to messages to indicate
that they have seen them and are publishing a policy as to what they
think should be done with messages that they have not seem but where
someone else has represented that they have
>A forwarder in the middle then receives a DKIM1
>mailing list message (or message that just started out DKIM1 only) and
>needs to forward it along. In my mind, this is effectively a "new message"
>that the forwarder is sending, and the forwarder has to take ownership.
>
>Richard, do you agree for the medium term that it's legitimate for the
>forwarder to start a new DKIM2 chain having taken ownership as the
>originator?
there is nothing in the spec that prevents a system, for any reason at
all, from removing any and all existing DKIM2 signatures (possibly none
of them) and then sending the message with a m=1, i=1 set of DKIM2
header fields
issues may arise in practice as to whether the RFC5322 "From" header
field has any correspondence to the d= signing domain that is used
claims have also been made that extremely clever filtering systems would
detect that the message had a history before the m=1, i=1 information
was added and this will adversely affect the messages reputation.
Although I cannot rule out people building systems that did that I think
that their false positive rate for rejections would be so high that they
would eventually row back from that.
I am of course aware that there is proposed text for Todd's BCP document
that cautions people against examining message history -- I don't think
that text is worth bothering with; telling people how to build
reputation systems is not the IETF's business and no-one will take any
notice of anything other than their dashboards and the rate of customer
complaints when they do dumb things
>If so, am I understanding your position correctly, to be that
>this is already clear from the current text and doesn't need to be
>specified further (since the mail would be DKIM2 authenticated and so the
>current spec would not suggest rejecting it)?
correct
>Or are you saying in this
>situation the message is a lost cause, no further DKIM2 headers should be
>added and the message should just be passed along with only DKIM1
>authentication for downstream receivers to decide whether to reject based
>on that?
I am saying that as well -- as some gratuitous advice that might be
worth adding to the BCP to avoid people working it out for themselves.
If you are merely forwarding messages (whether you change them or not)
then adding your own DKIM2 header fields is almost certainly not going
to make much difference in the short to medium term to their
deliverability. The receiving system will treat them as they have
always done and will value your system as a source of valid messages on
the same basis as they have forever.
On the day that receiving systems insist that they will only accept
DKIM2 messages then == as soon as it becomes apparent that you will
gratuitously apply DKIM2 headers to other peoples mail -- then you can
expect to be heavily exploited by the bad guys. That is unlikely to be
an experience you cherish.
However, until receivers go to DKIM2 only, then the only real value in
adding DKIM2 header fields will be to receive DSNs (bounces) without
having to rig the MAIL FROM. Since the DSNs are tightly specified, then
you may value this information more than the bounce messages you
currently receive.
>DKIM1 currently allows the forwarder to pass along the message without
>modification. ARC helps forwarders comparatively more because now they can
>pass the mail along and don't make problems worse because if the next hop
>wants to take a stricter policy they can look inside the headers and see it
>came into the forwarder unauthenticated and reject the message (I can
>attest that this was very helpful as I deployed no auth no entry in the
>past to handle forwarders without lowering the bar).
my $DAYJOB$ experience with ARC is that "trusting" other people to get
it right is a snare and a delusion; and almost no-one (counting by
senders) uses it at all
> So if DKIM2's stated
>policy is that the forwarder should reject messages missing DKIM2 and not
>forward them along, then I think that is an unnecessary regression which
>can be solved in better ways by the spec allowing the forwarder to describe
>the situation accurately so they do not worsen the situation and enable
>reputation laundering or amplification attacks.
A system that takes in non-DKIM2 messages and emits DKIM2 messages is
not a forwarder, it is a submission server. IF you don't control access
to a submission server then you cannot, in the long term, expect it to
have a good reputation
>Some items that also aren't obvious to me from the spec:
>1) What does "don't pass it along mean"/"start a new DKIM2 chain".
I can't find "don't pass it along" in the document ... perhaps, if my
answers above have not been illuminating enough ... you could provide a
section number or page reference
> I think
>it means don't pass along the existing DKIM2 headers.
you should never "pass along" existing DKIM2 headers ... you must always
extend a chain of custody. If you cannot do that extension (because you
cannot provide signatures for appropriate domains to make the chain
work) then your choice is to start from scratch or not send the email
> (If right, I think
>it's worth just stating that) If you are going to send the message along
>consider it a new message and start a new chain claiming ownership starting
>at yourself.
there's that "ownership" word again ... the spec is very careful to say
what a signature means, which is solely that a system that is capable of
applying a signature has been privy to the contents of the email.
Anything you layer on top of that technical statement is not really a
matter for the spec
>There are different solutions to accomplish this: strip the
>previous DKIM2 headers, append "X-" to all the previous headers etc.
note that if you add X- then there is no way to prevent bad people from
modifying the mail to misrepresent what you received; so don't go there
>2) A clear and consistent way to describe I received this mail from xyz
>envelope MailFrom (identical to the DKIM domain).
why would I believe your assertion ? ARC thought that receivers would be
prepared to accept other people's assertions about how they had come
into possession of an email -- it turned out that receivers did not do
that; so it seems pointless to go down that path again
>3) I might be missing something basic but if the forwarder takes ownership
>and starts a new chain then do they also have to modify the fromHeader to
>align with their domain (This seems weird since they weren't modifying any
>text and the original DKIM1 still validates)? Or is there a way for them to
>say the chain starts with the previous message but got interrupted (similar
>to the "imaginary hop")?
I will be writing more about RFC5322 From header fields later on today,
but for the moment I would suggest that aligning RFC5322 information
with RFC5321 information is likely to improve deliverability
>4) I implicitly assumed that the spec would add some medium amount of value
>for a message that started off DKIM1 and at least allow securing the chain
>from that point forward (reducing DKIM replay potential by a small but
>non-zero amount).
some people believe that this is useful so the spec allows for recipes
in the i=1 DKIM2-Signature header field
the problem is that this does not provide any protection against DKIM
replay so a submission server (see above) that is doing this needs to
pay careful attention to what email is turning up and in what volume
>This allows a gradual transition as more and more of the
>ecosystem moves to DKIM2. But it seems like the spec's vision is more black
>and white maybe? Where you're either in the DKIM2 world or you're not, and
>there's no mixing between the two. If so, I do think that's worth spelling
>out. Personally, I'm concerned operationally if that will make the
>transition more challenge compared to supporting the partial case.
Almost all email goes from source to destination. Forwarding and mailing
lists are down in the noise from a volume point of view. Once systems
are capable of doing DKIM2 signing (and as Bron and others have been
demonstrating, Claude (etc) means that converting a system is an
extremely rapid process) then I expect they will DKIM2 and DKIM1 sign in
parallel.
The transition point when receivers, particularly the very large
receivers, insist on DKIM2 will not be gradual -- but they will look at
their dashboards and I expect them to be able to see that DKIM1 only
email has rapidly become a rarity. They will still have decisions to
make about what they do with unauthenticated or SPF-only email, but that
is not related to a "we ignore DKIM1" stance
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBapAOEmHfC/FfW545EQK8AgCg+0O55pZW341jYZGckN3XesKbzRIAoNzM
G3fjFOmcReFb5IM7VObH2BYJ
=COKn
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
