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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ 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
