--On 13 September 2010 21:18:41 -0400 "John R. Levine"
<johnl(_at_)iecc(_dot_)com>
wrote:
The final version said
if a message arrives without a valid Author Domain Signature due to
modification in transit, submission via a path without access to a
signing key, or any other reason, the domain encourages the
recipient(s)
to discard it.
I think it's a reasonable interpretation to say that if you expect your
list software might break the signature, you're doing the sender a favor
by pre-discarding it since that's what the recipients should do anyway.
Absolutely not. The condition doesn't apply when you receive the message,
so the signer is NOT encouraging you to discard it, and the general rules
apply: you should deliver the message or notify the sender (or the sending
MTA).
It may be that the message can be bounced, with a non delivery
notification. For example, if the return path matches the content of a
signed header, and they're both in the domain of the signer, then you're
probably not issuing collateral spam. If you are issuing collateral spam in
this instance, then the fault probably lies with the controller of the
sender domain (for allowing intra-domain spoofing).
If the MLM owner knowingly breaks a signature, and either discards the
message or forwards it into a system that is likely to discard it, and do
not notify the sender, then the forwarder must be responsible for any harm
done. They really should reject such messages.
A real life exemplar: we're currently migrating a lot of non-modifying list
exploders into modifying Mailman lists. Most of these lists are internal,
but not all of them. In an ideal world, I'd check the domains of all
subscribers to see whether any publish ADSP=discardable before making the
changes. In practice, I suspect that I'm unlikely to do that. However, I'd
much prefer that message get bounced back to the sender than discarded as a
result of the change that I'm making. That way, they have a better chance
to spot the problem, and a better chance to diagnose it.
There are all sorts of reasons for publishing ADSP=discarable, from "the
domain isn't used to send email" (analagous to "spf -all"), to "our domain
is widely spoofed (because of it's sensitive nature), and we absolutely do
sign all our email". I'd suggest that it's not reasonable to discard the
latter email when it carries a good signature.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html