John R Levine wrote:
You asked for an example. The point is, if mailing lists are that trivially spoofable, it will become a much bigger problem.Could you give a concrete example of a problem with some actual existing mailing lists that aren't tractable now but that forwarded signatures would solve?The spoofed message claiming to come from Harry Katz sent to ietf-mxcomp on April 27: http://www.imc.org/ietf-mxcomp/mail-archive/msg01146.htmlOK, that's one message out of more than 5000 posted to the list this year. I've seen more spam than that from 419'ers signing up for lists. This does not strike me as a problem so urgent that it's worth making a major design criteron.
As I said, the statistics don't matter because they're today's statistics and will change anyway, probably in the direction of more HTML. So the question is whether the body length count is useful enough to include for the cases where it does work. It is very little to add, and as I have pointed out is only used upon mutual consent of the signer and verifier.This scheme won't work on the yahoo groups example I posted yesterday. nor would it work on mail passing through my stock majordomo2 server.OK. It does work for plain text mail passing through yahoogroups.I asked some friends at Yahoo what fraction of the mail passing through yahoogroups is plain text vs. HTML. They need to dig up the numbers, but their approximate answer is that it's just about all HTML. Much though we may hate gooped up HTML mail, any scheme designed primarily for plain text mail is obsolete.
Or if people really like the idea (which I don't sense that they do) we could explore ways of making HTML messages survive too. But I agree that's probably wandering down a slippery slope.
How is this any different from a bunch of signed spam coming from any other address? ...The difference is that (and perhaps this is a different topic entirely) the signature on a mailing list or something trying to pose as one is likely to be invisible to the recipient. So unless you can reliably whitelist real mailing lists (and I contend you can't, without an external accreditation/reputation service, if you're verifying at the domain level), you're giving attackers a way to spoof.Unless there is some aspect of IIM that I've totally missed, all signatures are invisible in the MUA unless you do something either in the MUA or in a preprocessor to make them visible. I don't know about you, but I whitelist mailing lists with perfect accuracy. I whitelist the ones to which I subscribe, and I don't whitelist the ones to which I do not subscribe. Mail from mailing lists, genuine or otherwise, to which I don't subscribe isn't any less likely to be spam than mail from any other address.
See the recommendation in section 5.4 of the IIM draft.If you're a member of a large domain that does signature checking for you, isn't it really your domain that would need to do the whitelisting? How can a domain with thousands or millions of addresses keep track of which mailing lists are used by whom?
Or are you expecting users to maintain their own whitelists? You can maintain whitelists, but I don't think we can expect typical email users to have that sophistication.
Can you explain in more detail how mail from a list to which you don't subscribe would permit spoofing? The signature would say "this is definitely from foolist", and as far as I can see, the response is "so what, we have no interest in foolist."
Assuming ESP-maintained whitelists for a moment:1. A small group (~3) of attackers joins a large consumer ESP, and subscribe to a mailing list they operate on a throwaway domain. The mailing list signs messages, but accepts mail from any address. 2. They exchange a few messages via the list. The ESP whitelists it (not sure how that happens). 3. The mailing list membership is adjusted to include a bunch of harvested addresses in the ESP's domain. 4. Someone sends a spoofed message to the list, and being whitelisted by the ESP, it is sent to the larger group of their customers.
All of the HTML munging and such that we have been talking about has had to do with the body, not the headers. Aside from whitespace-removal canonicalization, the only thing IIM does in the body is the body length count. I think we need to consider header munging and body munging as two separate issues.But this whole discussion has been about the body length count, right?No, not at all. If you review my prior messages, I don't think I mentioned body length counts at all. This dicussion has been about the futility of assuming that list mail is processed in simple ways that we can canonicalize around. Bodies change, headers change, all sorts of stuff changes. The fact that you see list software that doesn't change messages means that you subscribe to a lot of techoid lists run by HTML haters. So do I, but that doesn't make us typical.
Added X- headers are no problem for either IIM or for DK with specific header signed (h= tag).How about the examples of header munging that occur at transit MTAs, such as the addition of [SPAM] to the subject line? I even have a mail forwarder address that does that for me. Should we be making allowances for that, such as by copying headers?Spam filters munge mail in as many ways as list managers do. For example, spamassassin can do anything from add an X- header to tag the subject line to encapsulate the entire message as a MIME attachment, and that's just one flavor of spam filter. Signatures are as likely to survive spam filters as to survive mailing lists, that is, not very.
Subject line tagging is not a problem for IIM.Encapsulating the entire message as a MIME attachment is probably a problem for everyone. Is the resulting message considered a new message or the "same" message?
So it looks like one of the modes of spamassassin will break. Isn't it still worthwhile to deal with the other modes?
I don't think that problem has gotten any easier, but we are solving a different problem. MASS signatures can be applied at any point the message is being modified. Considering the application and semantics of a MASS signature, I think it is an advantage if trivial modifications to the message do not _require_ re-signing.Have you looked at the debates that the S/MIME group had when they were designing their signature scheme? They looked at all the things that mail forwarders do and gave up on message signing, which is why the only thing that you're likely to see an S/MIME signature on is a base64 encoded body part. I don't see any reason to think that the problem's gotten any easier, or that we're smarter than they were, so I'm more inclined to figure out how we can make signatures useful on the paths that don't smash messages than to attempt to reverse engineer the paths that do smash.
-Jim
smime.p7s
Description: S/MIME Cryptographic Signature