Michael Thomas wrote in
<799da3ac-0b80-4aa4-857d-25d1b1027...@mtcc.com>:
|A few points:
|
|1) A sender or intermediate can already send a new message per rcpt-to.
|This is an operational issue, and has nothing to do with DKIM. Indeed,
|lots of transactional mail already does this so you unsubscribe, etc.
But that DKIM2 draft mutilates SMTP to *only* work in this one
recipient mode: even if a mailing-list has hundreds of Gmail
subscribers, where ACDC would (could) send one message to all of
those in a single transaction, DKIM2 sends hundreds!
|2) In the case of a typical mailing list, for example, the original
|rcpt-to will not match the rcpt-to when the list expands the recipients.
|I've had a very hard time understanding this draft, but I'm guessing
|there must be some consequence for a signature where the rcpt-to is
|different than in the signature block. Assuming that it invalidates the
|mismatched (typically original) signature, that sure sounds like it
|breaks DKIM's mail forwarding survival requirement.
ACDC is activated when the receiver announces support.
The DKIM subsignature is created for the mailing-list.
The mailing-list then distributes further, creating normal
signatures and per-receiver-domain subsignatures as necessary.
There is no clash.
One thing is plain: until ACDC or DKIM2 have penetrated the
infrastructure, the current mess of DMARC and ARC will have to be
dealt with! This IETF has forced all those people to implement
this merde, and it likely takes a decade or something until it is
iterated away!!
Until then From rewriting etc has to be implemented.
And i'd only wish IETF would do this right not only for its
bugtracker.
Later on ...
Well, later on. A bit simplified:
- Eg mailing lists claim the message origin (O flag) *if* they
change the message.
+ For example this IETF must set it (subject tagging, footers.).
+ The NetBSD lists do not need to (leave messages unchanged).
- Receiving domains verify the highest numbered signature.
(Current DKIMv1 policy: a single successful verification is
enough.)
+ They can verify all up to the very first signature, possibly
having the need to undo the differential changes in order to
do so.
++ Any existing difference means the message has been changed!
+++ User interfaces / "server policies" *may* analyze the
differences.
There may be templates like "mailing-list" meaning "subject
was tagged" and "footer was appended", for example, which
can be tolerable changes -- automatically that is.
(User interfaces should allow users to confirm this.)
|3) Any intermediary along the mail path is completely at liberty to
|(re)sign a message already with DKIM.
Nothing changes. Is it ACDC aware, though, it has to integrate
into the sequentially numbered chain of signatures.
If an intermediate does not support ACDC, it depends, as written
in the draft: that part should already be pretty much mature.
|4) Every hop can already determine whether it thinks something is spam.
|I'm not sure what that has to do with anything.
Me too.
|5) I don't understand the supposed cause and effect of how that makes
|replay "impossible".
As written in my former email. Regarding ACDC that is.
I think you are right shall you have implicated that the "bounce
ID" should be regular, and an UUID, that receivers can use to
create a UUID cache to prevent that a man in the middle sends the
very same (correct) message to the very same (correct) receiver.
Thank you! I will add this to the iteration.
|6) As for Bcc, if the rcpt-to is somehow in the email message itself,
|you've broken the promise that the message not contain the Bcc'd address.
No. Yes for DKIM2 i think. No for ACDC.
Man in the middle can see the subsignature.
Other than that ACDC aware reciever removes the per receiver
domain subsignature before processing it further, so no one will
see the receiver list of that domain.
Man in the middle could be prevented by the encrypted subsignature
that was i think my very first idea.
|7) I think Dave made the point in his comments on the draft -- which
|deserves a reply -- that an intermediary can already change the
|mail-from if it wants bounce messages. I assume that almost all mailing
|lists do that so I'm not sure what the problem is.
Regarding ACDC this is not fully worked out -- it is an extension
to DKIMv1 that is a tool for SMTP which in turn gives options to
bounce or send delivery reports, which can be used. All open
source MTAs of value that i know support this mechanism; i am not
looking at the SMTP capabilities of Yahoo or Gmail or Microsoft,
but shall they not support it, they can take some of the time they
save by doing ACDC not DKIM2 for implementing it, possibly that
is.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
