[Mailman-Developers] dkim and email list software - potential solution
daniel at cacert.org
Wed Oct 7 15:21:08 CEST 2009
On Wednesday 07 October 2009 21:00:52 Ian Eiloart wrote:
> As far as I recall, Mailman removes DKIM signatures,
> and re-signs messages.
not that I recall though the MTA is free to sign it on the way out and I
encourage all list owners to do so.
> You're saying that with ADSP, that's not adequate unless Mailman first
> rewrites the "From:" address.
yes, as its easiest place in the whole signing verification scenario to make a
change that benefits the most people without adversely effecting anyone
> Some lists are configured to do this already,
I didn't know this. Anyone know who these are and if they incur any problems
as result of this rewrite?
> the question is what to do about those that don't.
> [not mailing list obligation to fix problem]..., but it is sensible to
discuss how list managers could address the problem,
> 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.
You can tell from the mailing list settings if it will break without
revalidating it. Same policies apply though.
> 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.
yes. very easy to do. including dropping broken sigs etc where dkim=all?
> Good before, "discardable" after: ....(cut).... Rejection at
> SMTP time
> The MTA would need to know whether the list was going to rewrite the From:
> header, I suppose.
yes - requested feature just added for this:
> 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.
> 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,
this actually is the hard bit. Options for the recipient verifier are:
1. has a List-ID (or other signature) - must be a mailist. This allows email
spoofers just to add List-ID tags or a simple email characteristic to bypass
2. manage a whitelist of maillists that have subscribers in the domain, that
can't be easily spoofed. Pretty easy for small domains but many thousand user
bases requires more admin time or run the risk of a user whitelisting a
spoofer IP address.
3. originator specified third party signatures - discussion (re)-starting on
IETF WG list on this. Bit labour intensive on the sender part.
> know the list was going to break or remove the signature. We should,
> however, look for a signature from the mailing list,
yes good. this falls nicely into #2 above, A strong signature of the email
list to whitelist. More fully mailing lists should DKIM sign emails (after
dropping invalid signatures).
> 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.
If you have a method of determining if it a list in 1-3 above then this works
as mailing list domains should gain good reputation quickly (though varying
list policy between lists or large list servers like sourceforge.net could
hide bad in the reputation of the majority).
If you are blindly assessing an email without knowledge that is a mailing list
what do you see? You can check the reputation of the domain on a third party
DKIM signature and treat this like a mail list above. What would it mean for a
new list domain/third party sender? My assumption, based on not much
experience with reputation services, is neutral reputation will allows the
Putting names on this. Phisher Mallory buys a domain friendly.org sets up DKIM
on it. Mallory sends email to Bob saying that Bob needs to validate his
credentials with Bank of Alice. The author of the email looks like Bank of
Alice (who says has an ADSP policy of dkim=all). Bob's university who filters
his email doesn't know about friendly.org, so checks it reputation:
(pick an ending)
a) it has a neutral reputation, so lets it though and Bob gets scammed.
b) it has a negative reputation. and gets blocked after Mallory got detected
sending lots of phishing email and gaining lots of money out of the Bank of
Alice's customers all for the cost of a domain that wasn't visible to the end
Sure this is all the receiver's problem. The receiver's problem would also be
easier if, say in 4 years time, when mailman 3 and 4 are common place, and has
been rewriting From addresses for years, and the end verifier has a small
whitelist on third party signatures and most spoofing is dropped using ADSP.
> 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.
Though it can contribute to reputation scores this is taking a strong
cryptographic signature method and contributing it towards a spam score. This
only goes so far defeating some forms of phishing.
The IETF WG Charter (http://tools.ietf.org/wg/dkim/charters) describes DKIM as
"Taken together[signature and policy], these will assist receiving domains in
detecting (or ruling out) certain forms of spoofing as it pertains to the
not there yet..but I can't too many easy solutions either.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Mailman-Developers