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 <dan...@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-
develop...@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/
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
