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

[Daniel Black]

On Wednesday 07 October 2009 21:00:52 Ian Eiloart wrote:
> As far as I recall, Mailman removes DKIM signatures,
yes
> 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 
significantly.

> 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,
thank you

> 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:
https://sourceforge.net/tracker/?func=detail&aid=2874043&group_id=269812&atid=1147704

> 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.
yes
> 
> 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.
agree
 
> 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 
checking.
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.
(http://mipassoc.org/pipermail/ietf-dkim/2009q4/thread.html)

> we
> 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 
email though.

Scenario 1:
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 
victim.

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 
signing domain."

not there yet..but I can't too many easy solutions either.

-- 
Daniel Black
Infrastructure Administrator
CAcert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091008/d976db71/attachment.pgp>