Domino greylistingYou may recall that some while ago I stumbled upon the idea of announcing a high preference number MX, but not listening on it. This did lead directly to a substantial reduction in spam with no undesirable side effects. But I got to thinking - "I wonder how many attempts to deliver email at the high preference MX I am missing by just not listening there". It is possible to see this by looking at the firewall logs as they show inbound connections being built to port 25 of that high preference MX, but that is not very user friendly. So I derived a means of counting them directly.
If you use the option "Load Internet configurations from Server\Internet Sites documents:" for your inbound SMTP servers in the Domino Directory, then you must also define an inbound SMTP site in the Internet Sites view. One of the fields in this document says which Domino servers offer that service. Simply omit the high preference MX server from that list, but start the SMTP service on it anyway and clients connecting to it to attempt to deliver mail will see:
421 mx100.example.com SMTP service not available, closing transmission channel
Now you can see exactly how many clients are attempting to connect to deliver email at the high preference MX and who they are, without either accepting the email or causing a permanent failure. 4xx is a transient failure meaning "please try again" and any well behaved SMTP client will do so, probably at another MX, so real email is still delivered. From this we can clearly see that despite the transient nature of failures, a very high proportion of attempts to deliver email at the high preference MX do not subsequently retry at the preferred MX (yes, they are all spam). This is similar to a technique called "greylisting" and it got me thinking (yes, there's more).
Why not do the same thing at a preferred MX? Not the real preferred MX of course. But announce a new, lowest preference number MX (lower than the real inbound server) and do the same thing. Listen on port 25 but tell the SMTP inbound site document that this server does not offer the SMTP inbound service. This has the effect of making virtually every inbound email re-queue and try again once because each one encounters first a transient failure at the lowest preference number MX before it hits the original preferred MX and is accepted. This is closer to true greylisting, though still not exactly that, but here's the thing. It works.
We changed the MX records here to announce a lowest preference number MX on our production domains and set that new MX (a handy Domino server that already exists but was not doing any mail routing) to listen on port 25 but send a 421 transient failure when remote SMTP clients connect. All inbound email here now tries that MX first and, usually a matter of seconds later, the original preferred MX (now being only the second in the list). So real email continues to be delivered without a great deal of delay, but we can already see spammers connecting to the new preferred MX and not coming back again when that connection is refused.
Sometimes I scare myself.
Category: Domino: Administration
Technorati: Domino: Administration
1. Eric Parsons24/11/2004 18:06:02
Homepage: http://www.startingblockcomputing.com
One small caveat -- Using the Internet sites will break default page settings.
Putting an "Index.HTML" into a folder, then hitting www.somewhere/folder, with Internet Sites enabled, and you're in for a surprise. (What was IBM thinking on that one????)
The work around is to create redirects for each folder (folder ->folder/index.html)
2. Chris Linfoot24/11/2004 20:14:15
I've not tried that but do you get a 403 not authorised type page (attempting to browse a folder)? That's actually exactly what I would expect.
Also, how often are Domino SMTP servers also web servers.
And how many Domino servers are used to serve up static HTML?
And there are some significant advantages in using Internet sites (that's how this site is served for a start).
3. Nathan T. Freeman25/11/2004 06:31:40
You're right. I do like this one. :)
Would you be interested in working together on putting together some kind of wizard app that would configure these things for you automatically? It shouldn't be difficult, and at this point, you've done so much tuning to your directory, it should probably be enshrined. :)
It's going to be a slow couple of days for me any, since everyone I know back in the States will be on holiday. I'll need some distractions from real work!
AIM me at: caveatemptor27
4. Eric Parsons29/11/2004 16:50:07
Homepage: http://www.startingblockcomputing.com
As to the 403, no. I believe it's a 404, not found.
I just recall we converted to put a virtual server up, and broke a number of links due to the reliance on index.html in the folder.
We serve up a number of static pages. We also serve a number of static pages through Domino databases. Of course, portal will make the site much more dynamic by virtue of it's portalness (tongue firmly planted in cheek)
I agree, the Internet sites seem much more straight forward (sans the folder thingy).
Unable to post a comment? Please read this for a possible explanation...
-