Slashdot Mirror

Obviously, a quarantine means that you won't see the false positive until you specifically go check, but you won't lose it, unless you don't check for it before the quarantine's auto-delete timeout.

There is no auto-delete timeout for the quarantine, not by default, and not that I can manually set without futzing in the code itself. I'm thankful for that, and so are my users.

Graylisting, by definition, introduces a delay in mail transmission.

A delay of 25 minutes is barely perceptable. Email is not IM, even though people assume the two to be interchangeable. They're not.

Besides, you could also use nolisting instead, if you so choose. I prefer to receive ALL of my mail, not potentially lose it without even knowing about it.

I was reading the article, and suddenly port knocking came to mind.

It's no wonder, since the article ends with a link to Unlisting - Port Knocking for SMTP: http://www.joreybump.com/code/howto/unlisting.html . :)

I'm the author, and currently advise against using Unlisting, in spite of its effectiveness. It is prone to block mail from sites that use a certain kind of load balancing, and subject to denial of service attacks. If you are considering a technique like Unlisting, please read the article for a description of some of the issues I've encountered after months of testing, and a brief rollout on a few production servers. I'd love to hear suggestions for overcoming these hurdles.

Nolisting, on the other hand, is a passive technique that doesn't share these weaknesses. So far, I've found it to be safe.

...and encourage readers to RTFA, where I've addressed many of the issues brought up in these comments. I also encourage people to try the technique, if they are in the position to do so (admins only, this is not a solution for endusers), and evaluate it for themselves. Or not. It's true that most new antispam solutions are dreamed up by crackpots. I might be a crackpot. If this possibility concerns you, don't be an early adopter. Wait and see.

It's true, in my experience, that Nolisting stops some spam with no false positives (in my experience). And that's a Good Thing. But it doesn't stop significantly more spam than a combination of other techniques, which I also implement. Some of those techniques use a lot of resources, such as content filters (often powered by perl) and virus scanners. Nolisting provides a way to free up some of those resources, possibly resulting in better performance and even hardware savings. These savings can be significant at large sites that currently scan each and every message that arrives.

Nolisting can be bypassed. I don't make any wild claims. Spammers can get past it easily by going directly to the secondary MX. Guess what? They already do that, and have been doing that well before greylisting was introduced. Nolisting significantly reduces the percentage of spam my MX processes, thereby freeing up resources. It's just one part of a layered solution.

I've limited secondary MX access by extending Nolisting into Unlisting (Port Knocking for SMTP): http://www.joreybump.com/code/howto/unlisting.html . It's wildly effective, except for one serious problem: A retry might originate from a different IP. This appears to be legal, and seems to be the result of load balancing strategies adopted by some important sites. For that reason I don't recommend it. It will randomly block messages from gmail, for example. You can't reasonably predict the IP a multihomed host will use for a retry, so be very skeptical of any approach that claims to have solved this problem.

Unwanted email is annoying. When it carries a payload, it is potentially dangerous. But I don't really view this as a security issue. I don't buy the argument that Nolisting is security by obscurity, and therefore bad. It's a form of access control, a gatekeeper, a prophylactic. It's an apple a day, not a cure for cancer. It's not addicting, fattening, or life-threatening. Try it, if you're looking for ways to improve the health of your mail system. Discontinue use immediately at the first sign of complications. Side effects include more sleep and time spent with your kids.

Nolisting rarely introduces delays. As I point out in the article, most relays retry immediately. Any relay that cannot get beyond Nolisting is seriously, seriously noncompliant. While I don't suggest Nolisting as a complete replacement for Greylisting, it is a viable alternative for sites that experience problems with Greylisting and find the delays it introduces to be unacceptable. As the name implies, Nolisting is meant to used without dependence on whitelists. Wider adoption and testing will determine if this ideal has been realized.

Like Greylisting, Nolisting breaks infrastructure to some degree. Many admins find this distasteful. I know I do. If Nolisting becomes widely adopted, logs will become fatter with "Connection refused" errors when the primary MX doesn't respond. I'm sorry for that. But our logs are already fat with 45x errors from Greylisting, RBL disconnections, SpamAssassin scores, etc. Nolisting might even help to make logs smaller, if you currently see a lot of these messages. Time will tell. Keep an open mind, and remember that we often make concessions to improve a system's overall health. Just reducing the possibility of another zombie being created on the Internet creates benefits for everyone.

Try it before you draw a c

Sorry - you're right. What I was thinking of was *unlisting* which is linked to right near the bottom of that same page (and reproduced here for convenience):

http://www.joreybump.com/code/howto/unlisting.html

There is a mention of unlisting at the end of the article that does that. This article on nolisting does not cover extra checks on the primary MX address.

Try Nolisting. It's nifty.

Nolisting twarts spam bots that ignore the secondary MX. If the primary MX always rejects connections and a large percentage of bots ignore the secondary MX, then a large percentage of spam never arrives.

Nolisting on the primary MX plus Greylisting on the secondary MX easily avoids 90% of spam.

Try Nolisting. It's nifty.
Nolisting + Greylisting + content analysis = less spam.

Greylisting works better with Nolisting. Install both and your users might just forget all about spam.

I'm thinking that if Nolisting can get rid of some spam, without any negatives factors, that will be great. There will still be spammers sending to backup MX servers, but at least if Nolisting can really deal with the fire-and-forget spammers that only try the primary MX, then that will be an improvement.

That site I posted also has another technique called Unlisting:

http://www.joreybump.com/code/howto/unlisting.html

Basically enforcing that MTA's try the MX's in the correct order.

I recently discovered this technique...sounds very interesting. Anyone try it? Comments?

Basically, set your primary MX to be always unavailable. Normal MTA's should usually immediately try the next MX server, but the fire-and-forget type of spam/UCE won't.

What are the exceptions? Certain PHP-based webmailers and the like?

See my other post with links on how to setup TLS for your mail server, more info on building the web-of-trust, and GPG downloads for your windows friends.

http://yro.slashdot.org/comments.pl?sid=132181&cid =11046941

Also note that the ======== http://link ======== at the end of the parent post has been mangled by Slashdot Submissions Co. and should be fixed before forwarding it on to your friends, or posting anywhere. Broken links have never impressed anybody.

WTF - Here are some links from the link above again. Sorry about the bandwidth wastage but I think it's worth people seeing as practices contained within are sure to benefit us all (in Utopia - yay!)

[--snip-- (abridged) ]

WinPT :: Windows Privacy Tray [sf.net] is a good place to direct your friends still using windows.

I think a resource for mail administrators on how to add TLS capabilities to their SMTP handlers could be healthy for the net as well. On there would be step by steps on how to TLS-enable sendmail, postfix, qmail, proprietary-this, and proprietary-gateway-that.
:: Sendmail
:: Exim
:: Qmail

If you're running Postfix you've got little excuse to not be running TLS.
http://article.gmane.org/gmane.comp.encryption.gen eral/979

My SMTP traffic is opportunisticly TransportLayerSecure. Is yours?

Get a free server certificate from cacert.org If you haven't already you should add their Root Certificate to the list your browser accepts. They will also remotely sign your PGP/GPG keys and issue free S/MIME certificates as well. Very cool, totally free, and a distributed trust model rather than a top-down, it'll-cost-you-$199.00-for-an-SSL-cert model.

For more keysigning fun DO NOT MISS http://biglumber.com/! Find people nearby and extend your web-o-trust.

Host a keysigning party at] your next LUG [debian.org] meeting .

You can get a email-address-verified signature at http://www.imperialviolet.org/keyverify.html

Learn about using subkeys .

- - - - - - GPG keys -- The new web. - - - - - - -

[--snip-- (abridged) ]

Does anybody know of a good clearinghouse with information on plugins for a variety of mailers I could send my dad, high school friends, or grandmother to?

Anybody know of a list out there that collects information on how to secure your email, what's it's all about, and general key maintainence issues (for "the everyday net user")?

WinPT :: Windows Privacy Tray is a good place to direct your friends still using windows.

I'd like to be able to say to a friend: "Here's my key. Go to keepitprivate.com and find a plugin for the email software you use. Then next time you send me some email, just be sure to put it in an "envelope" (it just takes one extra click or can be set to happen automatically). You don't even need to lick a stamp! I value your privacy as much as I hope you value mine!"

I think a resource for mail administrators on how to add TLS capabilities to their SMTP handlers could be healthy for the net as well. On there would be step by steps on how to TLS-enable sendmail, postfix, qmail, proprietary-this, and proprietary-gateway-that. My SMTP traffic is opportunisticly TransportLayerSecure. Is yours?
Red Hat :: Sendmail
:: Exim
:: Qmail

If you're running Postfix you've got little excuse to not be running TLS.
http://article.gmane.org/gmane.comp.encryption.gen eral/979

Get a free server certificate from cacert.org If you haven't already you should add their Root Certificate to the list your browser accepts. They will also remotely sign your PGP/GPG keys and issue free S/MIME certificates as well. Very cool, totally free, and a distributed trust model rather than a top-down, it'll-cost-you-$199.00-for-an-SSL-cert model.

For more keysigning fun DO NOT MISS http://biglumber.com/! Find people nearby and extend your web-o-trust.

Host a keysigning party at your next LUG meeting.

You can get a email-address-verified signature at http://www.imperialviolet.org/keyverify.html

Learn about using subkeys.

- - - - - - GPG keys -- The new web. - - - - - - -