As far as I recall, Mailman removes DKIM signatures, and re-signs messages. You're saying that with ADSP, that's not adequate unless Mailman first rewrites the "From:" address. Some lists are configured to do this already, the question is what to do about those that don't.
Dave Crocker suggests that it's not the business of the list to fix this. That's true, but it is sensible to discuss how list managers could address the problem, and it's certainly useful to be aware of the problem - even if we conclude that list managers should not attempt to resolve it.
It seems to me that it's sensible for the list software to test the DKIM signature before and after any changes it makes to the message. And apply these policies:
Good before, good after: deliver the message as normal.
Bad before (broken DKIM sig, or missing a sig that ADSP says should be there), reject the message at SMTP time, but that's the MTA's job.
Good before, "discardable" after: If the DKIM signature is good, and the return-path is is signed, we can comfortably generate a bounce message. Otherwise, I guess we should reject at SMTP time, or bounce to the From address, perhaps? Effectively, you're saying to the sender "you've asked the recipient to discard the message that I'm about to send on your behalf, I'm going to save them the trouble". The RFC warns that use of "discardable" means that you're unlikely to get the message through a mailing list, but I think it's better to alert the sender. Rejection at SMTP time might be more practicable because a significant proportion of such email is from addresses that don't accept bounce messages!
The MTA would need to know whether the list was going to rewrite the From: header, I suppose.
Bad before, bad after: (DKIM or ADSP fail), reject the message at SMTP time if possible. That's the job of the border MTA, though.
Bad before, good after: presumably this is a list that rewrites From headers, but I don't think we want this message, so we should reject at SMTP time. Alternatively, if the ADSP policy is "discardable", we can discard it without guilt. Again, this is probably the job of the border MTA.
If the ADSP policy is "all", then I don't see a problem. The recipient should not reject a message from a mailing list just because it doesn't carry a matching signature. This is expected behaviour: we know the message was sent with a signature, we know the message came from a mailing list, we know the list was going to break or remove the signature. We should, however, look for a signature from the mailing list, and we should apply initial reputation tests (and modifications) to the list, not the original sender. If the list has good reputation, we should assume that it tested ADSP, and found a good DKIM signature on the original message. We can, therefore continue and check (and modify) the reputation of the original sender.
That last paragraph makes the job of reputation assignment harder where mailing lists are concerned - but that's to be expected. The whole point of DKIM, as far as I'm concerned, is to allow more sophisticated assessment and assignment of reputation scores.
--On 1 October 2009 18:57:27 +1000 Daniel Black <daniel@cacert.org> wrote:
I proposed some ideas around DKIM compatibility with mail lists and tried to send here too. Obviously the anti-cross-post feature on mailman- developers@python.org is working well (which on some levels I appreciate).
As leading maillist product I'm keep to know your opinion. This has obviously been mentioned before never quite got momentum[1]. Now that ADSP (RFC 5617) is out it seems that validating domains with a ADSP policy of dkim=all seems rather weak as anything other than a temporary spam bias (until spammers catch on).
My nice controversial idea is to mangle the from: address in mailing lists in general so that the list domain becomes the author (for ADSP purposes) and those DKIM validating emails are given the ability to do more with ADSP than spam biasing.
Original post here http://mipassoc.org/pipermail/dkim-dev/2009- September/000202.html
Other ideas welcome.
-- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/