John Levine wrote:
Adding Resent-* headers has no effect unless the DKIM signature
is set to break when they're added.
Depends on what resenders do, e.g., modifying the Subject might
not fly. Not permitted in 2822upd, but if an MDA adds "missing"
header fields they would then be a part of an otherwise perfect
2822upd Resent-* mail.
The Resent-* concept in RFC 822 is slightly different from the
2822upd concept, it treats "resending" as "forwarding". I'd be
not surprised if MUAs supporting the 822-variant "update" other
header fields.
Nothing about DKIM works if you take an ancient message and
remail it, since the keys are not long-lived.
DKIM does not say that old signatures indicate discardable mail,
that's an ADSP disease. Resenders are not necessarily involved
in DKIM at all. They follow RFC 822, 4406, or 2822upd as good
as they can (maybe not simultaneously, the RFCs are incompatible
wrt some Resent-* details).
I suppose that "discardable" makes it a little more explicit
that people might treat such mail unfavorably
As long as "treat unfavourably" boils down to "reject" it's fine,
"the sender can then make another plan", as EAI put it, it works
also for resenders.
But if "treat unfavourably" results in "discard" a mail is lost.
The name "discardable" suggests precisely that, "discard", with
legit mail vanishing in some black ADSP hole.
it shouldn't come as a big surprise that mail with stale or
broken signatures is less likely to show up in people's inboxes,
with or without Resent-* headers and with or without ADSP.
For folks publishing a "discardable" policy it's what they asked
for, no problem. But the draft does not mention that this also
affects innocent bystanders minding their own Resent-* business,
not at all interested in ADSP.
The name "discardable" is wrong. And independent of the name not
mentioning Resent-* of "ancient" mail at all is also wrong. Here
"ancient" could mean anything down to "yesterday".
RFC 4408 has section 9.3. ADSP needs a *long* section 6.4, where
you can bury "resent ancient mail" under appropriate weasel words.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html