On 4/19/2011 12:09 AM, Murray S. Kucherawy wrote:b
{{ stray thought: since the real concern is breakage, wouldn't it make
sense to focus on DKIM-Hostile, rather than DKIM-Friendly? Friendly
largely means being passive. }}
How about "DKIM-Cooperative"?
Semantically pretty good. Stylistically sounds terrible. But no, i don't have
a better suggestion.
MLM-like agents -> intermediaries.
{{ what does 'MLM-like' mean? }}
Specifically, intermediaries that mess with the envelope, typically changing
one recipient to many, and possibly altering the content.
Well, my main point behind a question like that is that the doc is using an
undefined term and that should be fixed, either with an explanation or a
different term that is already in common use.
{{ And indeed, here's an example of divergence. In email-arch, the author
does not (necessarily) perform submission. Submission is performed by the
Originator, in email-arch... }}
How does content get from an author to an originator? Or are they typically
the same agent?
The architecture doc just shows a line connecting them and no protocol spec to
cover the transition. Since, yes, it's usually the author, they are the same
entity in typical practice, but architecturally they are distinct with distinct
roles name.
Is it sufficient to change "performed" to "handed it to the originator to
begin its travel to its destination(s)"?
wfm.
This can be a human using an MUA or a common system utility such as
"cron", etc.
originator: The agent that accepts a message from the author, ensures it
conforms to the relevant standards such as [MAIL], and then relays it
toward its destination(s). This is often referred to as the Mail
Submission Agent (MSA).
{{ "relays it towards its destinations" is more like the definition of
a... relay. }}
So change "relays" to "sends" or "routes"?
'sends' is (almost) always safe...
receiver: The agent that is the final transit relay for the message
prior to being delivered to the recipient(s) of the message. Filtering
decisions based on results made by the verifier could be applied by the
receiver. The verifier and the receiver could be the same agent.
{{ email-arch: "2.2.4. Receiver The Receiver performs final delivery" }}
Those read the same to me. Are you proposing a change here?
Interesting. Yes I originally read it as different. But yes, I see that they
probably mean the same. mumble.
Minor body changes: Some lists prepend or append a few lines to each
message to remind subscribers of an administrative URL for subscription
issues, or of list policy, etc. Changes to the body will alter the body
hash computed at the DKIM verifier, so these will render any existing
signatures that cover those portions of the message body unverifiable.
{{ I'd have thought that citing the l= capability here would be
appropriate, for completeness. }}
I think it was there in earlier versions but was removed because the WG
generally dislikes use of "l=" for the reasons specified in the base
document. It also only handles appended text, but not prepended text, for
example.
Hmmm. Since it is not a deprecated feature, and since it's highly relevant to
this bit of discussion, I suggest saying /something/ about it, even if it's to
recommend against. Not sure what to suggest.
4.1. Author-Related Signing
If an author knows that the MLM to which a message is being sent is a
non-participating resending MLM, the author SHOULD be cautious when
deciding whether or not to send to the list when that mail would be
{{ I don't know what to suggest, but this section presumes that we can
reasonably expect authors to know about DKIM issues and in particular to
know that some MLMs screw up signatures. But we already know that
virtually no author is aware of any of these issues, nevermind know what it
means to be 'cautious'. Mumble. }}
Later on in Section 4.1, there's this:
However, all of this presupposes a level of infrastructure understanding that
is not expected to be common. Thus, it will be incumbent upon site
administrators to consider how support of users wishing to participate in
mailing lists might be accomplished as DKIM achieves wider adoption.
For the earlier text, how about some waffling, along the lines of:
In an idealized world, if an author knows...
Just to acknowledge up front that it's an easily-challenged scenario.
components (such as MTAs) that provide some DKIM services. For example,
the ADMD operating a non-participating MLM could have a DKIM verifier act
on submissions, enforcing some of the features and
{{ submissions? isn't this meant to refer to the receive-side of the MLM?
since 'submission' is an email term of art, this reference is confusing.
}}
So instead of "submissions", say "messages from list subscribers"?
belts and suspenders:
a non-participating MLM could have its DKIM verifier act on messages from
list subscribers
on
5.1. General
As DKIM becomes more widely deployed, it is highly desirable that MLM
software adopt more DKIM-friendly processing.
{{ I suggested deleting the above. It doesn't add anything. }}
I think it makes a statement that we (the WG) don't think the onus is on us
to make all the accommodations here.
Yeah, but I'll repeat that that text does not say anything useful but sounds as
if it thinks it is. (that's all sounds harsher than I'd prefer, but it's what
my fingers produced.)
Where the above practice is not observed and "discardable" mail
{{ "above practice is not observed"? Sorry but I don't know what that's
referring to. }}
The paragraph preceding proposes MLM interference with subscription actions
from addresses that use an ADSP "discardable".
Again, my point is that i think the current text, here, is likely to be
challenging for a reader.
arrives via a list to a verifier that applies ADSP checks which fail, the
message SHOULD either be discarded (i.e. accept the message at the [SMTP]
level but discard it without delivery) or rejected by
{{ Is this describing anything different than would/should take place for
mail that did NOT go througha list? The text seems to be describing a
special case but in fact it isn't. It's just an ADSP failure. }}
The issue is the one we observed with discardable mail that goes through an
MLM, where the implementation of "discardable" is a 5xx reply. So A and C
subscribe to list B, A posts discardable, A sends to B, B rewrites and relays
while keeping but breaking the signature, C gets it, DKIM fails, ADSP causes
rejection, C gets unsubscribed from B.
So yes, it's just an ADSP failure at verification time, but it has more
serious side-effects when there's an MLM intermediary.
Well, I think my point is that this failure is merely an exemplar of an entire
class of handling/routing failures and the text ought to make that clear.
5.4. Author-Related Signing
An important consideration is that authors rarely have any direct
influence over the management of an MLM. As such, a signed message from
an author will in essence go to a set of unexpected places, sometimes
coupled with other messages from other sources. In the future, as DKIM
signature outputs (e.g. the AUID or SDID of [DKIM-UPDATE]) are used as
inputs to reputation modules, there may be a desire to insulate one's
reputation from influence by the unknown results of sending mail through
an MLM. In that case, authors SHOULD create a mail stream specifically
used for generating signatures when sending traffic to MLMs.
"signed message from an author".
{{all messages are from the author. what distinctive condition is this
trying to describe? messages signed with the author domain? I don't
understand the point of the "As such" sentence. The rest of the paragraph
is also confusing to me. I'm not sure what to suggest to make it clearer.
}}
This came from a use case John submitted.
A and C are subscribed to B. A sends to B, which goes to C. But C doesn't
want to be on the list anymore and can't seem to unsubscribe. In
frustration, C begins reporting B traffic as spam, which begins to negatively
affect the reputation of A's signed mail.
1. We know it's not realistic to tell authors to create different streams.
It's
pretty much not realistic to tell authors to do anything in this space.
2. Does John's scenario care about the nature of the signature? Author domain
or any? I think it doesn't, but am not sure.
3. On reflection, I suggest tossing the reference to AUID.
4. The scenario that you cite as motivating this isn't obvious to me from the
existing text. Generically, the point is that behavior of an intermediary can
trigger recipient complaints that wind up reflecting back on the author, but
the
author has no control over any of it. This is certainly a fair point.
5. I'm not sure differing mail stream signature identifiers will help for
John's
scenario, because the bad rep is likely to accrue to the From: field domain...
As described, the MLM MAY conduct DKIM verification of a signed message
to attempt to confirm the identity of the author. Although
{{ Hmmm. This really does go entirely beyond DKIM semantics. Is the text
meaning to imply that any signature validates any From: field? Generally,
the document ought to distinguish between what can/should be done today
within existing specifications, versus what would be enhancements beyond
them. }}
I had thought this was clear, but I can add text to make it so.
There is text early on that says some of the things the document suggests are
just ideas and have no basis in reality yet, but merely illustrate possible
applications based on our experience to date.
Right. And that's a good start. But on reading the doc, I think there needs
to
be an explicit distinction between the two.
5.7. MLM Signatures
DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own
signatures when distributing messages. The MLM is responsible for the
alterations it makes to the original messages it is re- sending, and
should express this via a signature. This is also helpful for getting
feedback from any FBLs that might be set up so that undesired list mail
can generate appropriate action.
{{ I thought FBL behavior required prior registration. }}
Usually, but not always, especially with the FBL discovery work MARF is
doing.
hmmm. Back to theory, rather than actual practice...
DKIM signature it will add to the new message verifiers or receivers to
identify the DKIM signature that was added by the MLM. This is not
required, however; it is believed the
{{ this is describing a policy that is otherwise undocumented and
undeclared. If there is an explicit relationship between a d= name and a
list-post name, it should be declared explicitly, such as with a special
header-field defined to assert the relationship. }}
...or some out of band understanding that that's how this list operates?
This document probably shouldn't also register a new header field just for
this purpose.
Right. I'd be happy to have the doc merely note that this is entirely beyond
basic DKIM semantics and requires additional conventions, such as private
agreement.
Such MLMs SHOULD ensure the signature's header hash will cover at least:
o Any [AUTH-RESULTS] fields added by the MLM;
o Any [LIST-ID] or [LIST-URLS] fields added by the MLM;
o Any [MAIL] fields, especially Sender and Reply-To, added or replaced
by the MLM.
{{ This implies that there is semantics or security 'protection' in the
choice of header-fields that are hashed. None of this is valid in terms of
the current DKIM Signing specification. In order to make it valid, there
needs to be an additional specification defining it and specifying how a
recipient can know that the added semantics apply. }}
I think a slight shift in wording might make you happy without changing what
it's saying:
"Such MLMs should generate a signature that takes responsibility for at least
..."
Well, that's a respectable effort, if only DKIM semantics meant that hashed
fields specified what the signer is taking responsibility for.
But since the semantics are merely that the signer is taking (some)
responsibility for the (entire) message, and not only the signed parts of the
message, your language asserts a degree of precision that is greater than DKIM
semantics provide.
(Given that you and I are having this exchange, I'm pretty sure the general
community stands no chance of being clear about this. At the least this means
that our docs need to bend over backwards to emphasize the limitations.)
prepared for distribution (i.e. the "MLM Output" from Section 3.2). Any
other configuration might generate signatures that cannot be expected to
validate. As with any other DKIM signing operation, the
{{ "cannot be expected" is odd language to use about verification. either
is will verify or it won't. how can this be statistical, other than later,
in transit vagaries? }}
"will not validate" would work for me too, since "might" is also in there.
ack.
One concern is that having an MLM apply its signature to unsigned mail
might cause some verifiers or receivers to interpret the signature as
conferring more authority or authenticity to the message content than is
defined by [DKIM]. This is an issue beyond MLMs and primarily entails
receive-side processing outside of the scope of [DKIM]. It is
nevertheless worth noting here. In the case of MLMs, the presence of an
MLM signature is best treated as similar to MLM handling that affixes an
RFC5322.Subject tag or similar information. It therefore does not
introduce any new concerns.
{{ after re-reading this paragraph a few times, I find I don't know what it
is adding and also the next-to-last sentence confuses me. }}
It acknowledges that there are applications out there that think a DKIM
signature is a good thing regardless of any other piece of information
available. That creates a concern that all mail through a list is
potentially, apparently, endorsed by the list operator. Such interpretations
might not be wise if the verifier doesn't know how the list is actually
configured or filtered.
You're right about the last sentence though.
The text seems to be saying "receivers sometimes go far beyond the actual
semantics". That's an inherent problem, of course, for any occurrence of
multiple signatures.
I guess what's distinctive is that an MLM is likely to be the common source of
an additional signature, other than one provided in the author' organization or
the outbound border MTA's organization. (Think small enterprise connected via
large ISP.) In the long run, however, I'm suspecting that multiple signatures
will be different, particularly when the author domain is different from the
outbound border MTA. (My own example of dcrocker.net and songbird.com fits
this.)
I guess the only thing I'd suggest is, again, distinguishing theory from
practice. That is, the concern here is certainly valid theory -- the potential
for the problem is real -- but I believe there is no established pattern of
problem in practice.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html