[Mailman-Developers] dkim and email list software - potential solution

[Ian Eiloart]

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 at 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 at 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.
>
> [1] http://wiki.list.org/display/DEV/DKIM



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/