[Mailman-Developers] dkim and email list software - potential solution
iane at sussex.ac.uk
Wed Oct 7 12:00:52 CEST 2009
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
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
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. 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-
> Other ideas welcome.
>  http://wiki.list.org/display/DEV/DKIM
IT Services, University of Sussex
For new support requests, see http://www.sussex.ac.uk/its/help/
More information about the Mailman-Developers