-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At the end of January Dave Crocker posted a review of the then current
"-01" version of draft-gondwana-dkim2-motivation. This document has now
been split into an "-02" and draft-gondwana-dkim2-headers (-01).
Rather belatedly this is a response to that review, albeit spread over
14 (sorry) emails... ">>" is a quote from our document, ">" a quote from
Dave Crocker ... lines that do not start with a ">" are me speaking.
- -=-=-=-=-=-=-=-=-=-=-=-=-
>> 3. Basic ideas
>>
>> An email is DKIM2 signed by the originator -- in pretty much the same
>> way as is done in the existing DKIM1 standard. In practice the vast
>> majority of mail is signed using relaxed/relaxed methods. DKIM2 will
>> only allow relaxed/relaxed.
>>
>> Each "hop" that handles the email adds another, sequentially
>> numbered, DKIM2 header field.
>
>MTA or Intermediary/mediator, or both?
>
>If MTA, why?
That isn't answerable in those terms ... if you move an email between
different systems within the same organisation (whatever that term
means) then there's no necessity to document this in DKIM2 headers
(unless of course the message is changed).
However, if the message is then passed elsewhere then a DKIM2 header
will be needed to show that the message which was addressed (RCPT TO) to
one mailbox is now addressed (RCPT TO) another.
>Also, this adds overhead to basic email relaying.
Almost certainly, yes
>> A simple relay will only add a single
>> header.
>
>ahh. So this really is intending to add this requirement to every MTA, for
>every message.
apart from special cases yes
> *Why?*
to deal with the replay issue, to prevent backscatter (or rather to
enable systems to accept an email and then change their mind and
generate a DSN without creating backscatter) and to ensure that DSNs can
be passed back along the "outgoing path" correctly
>> Email service providers will often add two, one on behalf of
>> the actual originator the other for themselves. A relay that
>> rewrites email from one domain to another will add two headers to
>> record the rewriting.
>
>That's not a relay.
>
>Relays don't change the message. And they typically only add a Received:
>header
>field.
they generally change the destination mailbox as well ... there is an
old email architecture where machines with a high MX value accepted
email then sent it on to machines with a lower MX value when they had
come back online. People may still operate systems that way but I doubt
that many do. Those systems will not change the destination mailbox,
everyone else does.
>So this is really for Intermediaries and not Relays?
>
>Also, adding a DKIM signature isn't onerous, but it's not free, either.
>
>If this is for Intermediaries/mediators, how does this differ from ARC, and
>what
>are the improvements?
it differs from ARC by being simpler (one of very first design goals was
that DKIM2 could be explained in a 5 minute "lightning talk". I don't
think that ARC achieves that and it does less than DKIM2). It also
differs by changing the trust model.
>> If an email is accepted by a server but it is later found that it
>> cannot be delivered onward, or further analysis of its contents leads
>> to a determination that it should not be delivered after all, then
>> the previous hop is informed by means of a Delivery Status
>> Notification (DSN).
>
>Previous hop? Not the Originator? Why?
to achieve the goal of allowing all the systems that handled an email on
its outgoing path to become aware of delivery failures.
Those systems may feel empowered to deal with the delivery failure
themselves and not bother the Originator (both mailing lists and ESPs
may be in that situation).
Also when an email have been passed through a system to somewhere else
and a delivery failure occurs, that system may feel that it is prudent
(perhaps from a security or data protection standpoint) to hide the
identity of the "somewhere else" from the Originator -- but instead to
just report the failure as if the passing onwards had never occurred.
>> If a DSN is received for an email that was
>> previously relayed, then the DSN is passed back to the system that
>> delivered the email. Hence, DSNs are returned back along the
>> "outgoing path" until they reach a system that can take
>> responsibility for handling the report.
>
>Received by whom?
>Relayed by whom?
The organisation which received the email and sent it to somewhere else
will be given the DSN. It will not be sent to specific machine because
large-scale systems don't work that way, but it will come back to the
organisation who will then decide what to do with it.
>"delivered the email"? Should this have said 'originated'? If not, then the
>statement needs to be clearer about its reasoning.
it should say "relayed the email" ... and I will reiterate a point I
made earlier about this document not being in any way intended to be
final so we have avoided exact definitions of every term so as to be
able to put across ideas of the design without making the document
horrendously long
>
>DSN passed to the /delivering/ system??? Methinks originating is meant.
>
>Why is the 'previous hop' mediating notification of the originator?
because it feels empowered to do so -- for example that may be what the
contract between a brand and an ESP says will happen.
>Why is this path dependent?
>
> *Why is this extra handling overhead, and demonstrably fragile
> handing model being required for every message and every MTA?*
because systems further along a "forwarding path" will be unaware of the
contract between a brand and an ESP, will be unaware that the previous
hop was a mailing list, and will be unaware of the Data Protection (or
security) issues that could arise by sending a message back to the
Originator
>> The DKIM2 headers contain the source and destination of the e
>
>Oh? email addresses, or just domains?
MAIL FROM and RCPT TO values
>Is 'source' the signer or is that a third parameter? If same as source, why?
The signer is a domain and a selector as in DKIM1
>So this requires a separate message for each addressee, For every provider,
>everywhere, including sites with no DKIM Replay problems. /The incremental
>cost
>of the proposed mechanism is not small./
I published some data on that in early March
Yesterday (Wednesday) at $DAYJOB the percentage of mail delivered to
a single recipient (rather than 2 or more) was 99.8566% (I feel
justified in providing the precision because the total count was
many billions)
I also note that the chances of email being automatically classified
as spam increases with the number of recipients ... it doubles by
the time the number of recipients reaches 10.
ie: the non-small incremental mainly falls on spammers. Pretty much
everyone else either sends to just one person at a time or personalises
the email they send (with one-click unsubscribes (hurrah) or tracking
pixels (boo hiss)).
> *Given that DKIM Replay is not a universal problem, dealing with it
> should incur extra cost only for those having the problem.*
if only it were possible to predict whose email will be replayed
>> They may also request "feedback" from later entities as to the
>> quality of the email. This feedback is sent directly from systems
>> that choose to honor such requests to any all of the requestors that
>> the sender deems appropriate.
>
>'quality' is a pretty squishy topic. I believe there is no widespread,
>operational history with sharing such information, never-mind any standard for
>representing it.
"quality" was a way of saying "whether or not the this-is-spam button
was pressed; which may have occurred because your email was spam,
because it was boring, because my finger slipped, or because on
Wednesdays I hate everyone"
> *This, again, seems an open research topic, once the intended
> meaning is clarified.
> *
Feedback loops (as I think you acknowledged earlier) are a well-
established part of the email landscape -- and I think were even when
RFC5598 was written. So I'm far from clear what the research might seek
to establish.
>> Intermediaries that alter emails record their actions (so that later
>> hops can undo and check signatures). Intermediaries whose
>> alterations are too complex to be described or reversed will either
>> have to arrange to be treated as the originator of the message (if
>> they are near the start of the message's journey) or they will need
>> to implicitly trusted by any further intermediaries (if they are near
>> the end of the message's) journey.
>
>There is quite a lot to unpack with this paragraph, and quite a lot of work
>needed to satisfy its requirements. And before that, quite a lot of work to
>explain the reasoning and basis for it.
>
>"arrange to be treated as the originator" - huh?
An outgoing "security gateway" may make changes such as adding
disclaimers (or logos) to the end of every email, or may strip out
dangerous attachments (or those containing company secrets!).
[[[ at $DAYJOB$ I get 5 or so emails a day which purport to contain
a report of an MTA's experience in using MTA-STS when sending us
email -- but the actual attachment with the info has been removed:
ie these security gateways are very real! ]]]
Such a gateway may well wish not to provide any information that reveals
the original content of the email. If so then they need to be provided
with keys so that they can sign an initial (i=1) DKIM2 header
>"need to implicitly trusted by any further intermediaries" - huh?
>"if they are near the end of the message's" - huh?
Similarly an incoming "security gateway" may make changes such as
removing malware or rewriting URLs to use inter-stitials.
In such a case if the email is handled by DKIM2 aware systems thereafter
it may be better all round for those systems to unconditionally trust
the gateway (and the DKIM2 signature it applies) rather than messing
around with "undoing" the changes. Such trust, since the security
gateway would be at the organisations border (and the trusting systems
would be inside that border) does not seem hard to achieve.
>Please revise, to be more pedagogical for an average (or less than average)
>reader. I really did not understand what was meant and the reader should not
>have to guess or fill in the blanks.
This was already rewritten in #2.6 of -02 of the motivation draft
>> Intermediaries that duplicate ("explode") emails, record their action
>> so that any further systems that see multiple copies of the email
>> will not reject or discard the email as a "replay".
- --
richard Richard Clayton
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBZ/l0dmHfC/FfW545EQI/OwCeN1PUC2OBk9zgUMo2fViMqQj93lEAnRLv
QKmwhDOYcYiBQzu7HdqKzZga
=8TeI
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
