Hello,
I have two spam-related questions, one relevant to Mailman and one not. Apologies for the one that isn't, but I hope you will endulge this query.
A person has been spoofing Email addresses on a number of blindness-related Email lists this week. I won't go into the particulars as it's probably of little interest to this list. They're also using some quite sophisticated techniques to hide their identity and point of origin, and this is definitely outside the scope of this list.
My questions here are more focused at helpping list/site admins to block such mail.
It's possible to use an IP address to block(at least temporarily) these messages. If I put this IP address into a Mailman spam filter, will this be checked *before* checking whether or not the person is a member of the list? I want to know if list admins can block these without bugging their site admins to do it upstream.
One idea I came up with for rejecting spoofed mail is for the receiving SMTP server to somehow check if the sending one is an MX for the domain given in the From header. Are there any obvious problems with this approach? Is anyone actually doing this? It seems so simple that there surely must be some reason why it's not done.
Geoff.
On 2/17/10 7:56 AM, Geoff Shang at geoff@QuiteLikely.com wrote:
- It's possible to use an IP address to block(at least temporarily) these messages. If I put this IP address into a Mailman spam filter, will this be checked *before* checking whether or not the person is a member of the list? I want to know if list admins can block these without bugging their site admins to do it upstream.
Probably better to do this in the MTA, not Mailman.
- One idea I came up with for rejecting spoofed mail is for the receiving SMTP server to somehow check if the sending one is an MX for the domain given in the From header. Are there any obvious problems with this approach? Is anyone actually doing this? It seems so simple that there surely must be some reason why it's not done.
A bad idea. MX records identify servers that RECEIVE mail for the domain. They say nothing about which servers can SEND mail for the domain. While in many cases, they are the same servers, there is no requirement that they be so and many large ISPs split the functions.
-- Larry Stone lstone19@stonejongleux.com http://www.stonejongleux.com/
Larry Stone wrote:
On 2/17/10 7:56 AM, Geoff Shang at geoff@QuiteLikely.com wrote:
- It's possible to use an IP address to block(at least temporarily) these messages. If I put this IP address into a Mailman spam filter, will this be checked *before* checking whether or not the person is a member of the list? I want to know if list admins can block these without bugging their site admins to do it upstream.
Probably better to do this in the MTA, not Mailman.
I agree that it may be better in the MTA, but to answer the question, yes, header_filter_rules are checked first.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Geoff Shang writes:
- One idea I came up with for rejecting spoofed mail is for the receiving SMTP server to somehow check if the sending one is an MX for the domain given in the From header. Are there any obvious problems with this approach? Is anyone actually doing this? It seems so simple that there surely must be some reason why it's not done.
It is being done, although not via the MX for the reasons Larry Stone gives. What you're looking for is call "SPF" or "DKIM" (these are actually two different protocols, and I think with the standardization of DKIM, SPF is probably dead). The way DKIM works is that hosts authorized to send mail from a domain are given special resource records in their DNS which provide a public key, and then some portion of the mail and/or headers is signed with an appropriate private key.
The problem is that setup is quite finicky, so most hosts not run by well-paid professionals don't do it. If all of your users are on Google or Yahoo, you'll be OK, I guess.
Stephen J. Turnbull wrote:
Geoff Shang writes:
- One idea I came up with for rejecting spoofed mail is for the receiving SMTP server to somehow check if the sending one is an MX for the domain given in the From header. Are there any obvious problems with this approach? Is anyone actually doing this? It seems so simple that there surely must be some reason why it's not done.
It is being done, although not via the MX for the reasons Larry Stone gives. What you're looking for is call "SPF" or "DKIM" (these are actually two different protocols, and I think with the standardization of DKIM, SPF is probably dead). The way DKIM works is that hosts authorized to send mail from a domain are given special resource records in their DNS which provide a public key, and then some portion of the mail and/or headers is signed with an appropriate private key.
There are still sites that check SPF and will reject mail for an SPF hardfail.
Note, if you run SpamAssassin, there is a Botnet module[1] available that will check the MTA that delivered to the trusted local network has full circle DNS and a host name that doesn't look like a 'home network' name.
[1] <http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar>
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Wed, Feb 17, 2010 at 15:23, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Geoff Shang writes:
It is being done, although not via the MX for the reasons Larry Stone gives. What you're looking for is call "SPF" or "DKIM" (these are actually two different protocols, and I think with the standardization of DKIM, SPF is probably dead).
That would be a surprise to the SPF folks, and the steady progression of folks who're implementing it ;)
SPF and DKIM solve 2 different parts of the problem of forged emails. Neither provides complete coverage, together they work well.
-- Please keep list traffic on the list.
Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche
Rob MacGregor writes:
That would be a surprise to the SPF folks, and the steady progression of folks who're implementing it ;)
Over the years a lot of things have been surprises to the SPF folks. I'm sorry for the misinformation, but the SPF promoters have been guilty of "excessive optimism" themselves. As for folks who implement these nostrums, they'll try anything. (I don't think that's wrong, stupid, or lazy. I just don't see it as a signal that the nostrum-du-jour is useful.)
SPF and DKIM solve 2 different parts of the problem of forged emails. Neither provides complete coverage, together they work well.
Please explain. AFAICR, neither works very well with mailing lists because they're both designed on the assumption that the endpoints are directly connected (in the sense that intermediaries like Mailman must be pure relays and not add anything to header or payload).
You can say that Mailman lists with value-added should re-sign, but that doesn't play very well because mailing lists are somewhat like common carriers. Making the Mailman list responsible for spam etc (which is what re-signing does) is going to kill a lot of discussion lists.
On Feb 17, 2010, at 8:35 PM, Stephen J. Turnbull wrote:
SPF and DKIM solve 2 different parts of the problem of forged emails. Neither provides complete coverage, together they work well.
Please explain. AFAICR, neither works very well with mailing lists because they're both designed on the assumption that the endpoints are directly connected (in the sense that intermediaries like Mailman must be pure relays and not add anything to header or payload).
SPF works at the envelope level, but without modification it breaks things like forwarding, is vulnerable to DNS cache pollution/poisoning attacks, etc....
DKIM works at the content level and cryptographically signs the headers, but is vulnerable to MTAs and mail gateways that may transform the content or the representation of the content in ways that would normally appear to be transparent, but in fact wind up breaking the cryptographic signature.
Both have their uses, and both have their own set of limitations. There are proposals on the table to try to help fix various known issues with these two tools, as well as to help fill in some of the other gaps. We'll see if these proposals get anywhere.
You can say that Mailman lists with value-added should re-sign, but that doesn't play very well because mailing lists are somewhat like common carriers. Making the Mailman list responsible for spam etc (which is what re-signing does) is going to kill a lot of discussion lists.
IMO, Mailman should not re-sign. If there was anything that would sign the outgoing messages, that would be the MTA and not Mailman.
Or, if Mailman is going to re-sign, then it should rename all but the minimum set of headers and then sign only the minimal set, in effect saying "I scanned the message on inbound and it didn't look like spam to me, and the users requested that these messages be sent on to them, so here's the minimal stuff I trust about this message".
At that point, if some downstream site marks the message as spam and this hurts the reputation of the site running Mailman, then the site running Mailman should ban the downstream site that inappropriately blamed it for sending the content that their recipient(s) asked to receive.
-- Brad Knowles <bradknowles@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Brad Knowles writes:
IMO, Mailman should not re-sign. If there was anything that would sign the outgoing messages, that would be the MTA and not Mailman.
But isn't that the problem? In the situation these methods are designed for, the MTA is signing mail for a trusted party, presumably a user (perhaps a system user such as "root" or "cron") in the domain. (When forwarding, the origin's signature can just be passed on.) But in the case of a mailing list, the list manager has trust information that the MTA doesn't (list membership, for a leading example). So even if the MTA actually does the signing, it's Mailman's responsibility.
Or, if Mailman is going to re-sign, then it should rename all but the minimum set of headers and then sign only the minimal set, in effect saying "I scanned the message on inbound and it didn't look like spam to me, and the users requested that these messages be sent on to them, so here's the minimal stuff I trust about this message".
It should also sign RFC 2369 headers, etc, too. (I assume that that's what you meant, but minimal could also mean "as little as possible".)
participants (6)
-
Brad Knowles -
Geoff Shang -
Larry Stone -
Mark Sapiro -
Rob MacGregor -
Stephen J. Turnbull