Weblog entry #2 for medwayman
See all weblog entries made by medwayman.
#2
Nolisting - another anti-spam method?
Posted by medwayman on Mon 29 Jan 2007 at 21:34
Stumbled on the Nolisting idea this weekend, and thought I would give it a try. There is a full document here:-
http://www.joreybump.com/code/howto/nolisting.html
In a nutshell by making your primary MX always unavailable, real MTA's will just move on to the secondary, but the fire-and-forget Spam aimed at your primary will never even get a connection, let alone get rejected or needing to be filtered.
So I've firewalled my primary to only accept connections on port 25 from the secondary, and so far I'm seeing only about 10% of the connections that my primary would have rejected re-appearing on the secondary. That's a straw poll rather than a proper analysis.
I'm small-scale here, and I've done this out of interest rather than necessity, but it looks promising.
http://www.joreybump.com/code/howto/nolisting.html
In a nutshell by making your primary MX always unavailable, real MTA's will just move on to the secondary, but the fire-and-forget Spam aimed at your primary will never even get a connection, let alone get rejected or needing to be filtered.
So I've firewalled my primary to only accept connections on port 25 from the secondary, and so far I'm seeing only about 10% of the connections that my primary would have rejected re-appearing on the secondary. That's a straw poll rather than a proper analysis.
I'm small-scale here, and I've done this out of interest rather than necessity, but it looks promising.
Comments on this Entry
Posted by Anonymous (85.98.xx.xx) on Mon 29 Jan 2007 at 22:12
Spammers try the MX record with higher priority numbers usually, because they assume there are less spam protections in the secondary(or ternary) server.
Now if you enter three MX records (say, 5 10 15) for one server, and place the server in the middle (number 10) that may be good ;)
but legitimate servers will have hard time finding the real one and mails will be delayed a bit.
Now if you enter three MX records (say, 5 10 15) for one server, and place the server in the middle (number 10) that may be good ;)
but legitimate servers will have hard time finding the real one and mails will be delayed a bit.
[ Parent | Reply to this comment ]
Posted by Anonymous (213.164.xx.xx) on Tue 30 Jan 2007 at 10:04
This is a very bad idea. It promotes the arm race between the spammers and the mail server admins.
[ Parent | Reply to this comment ]
Any technique that relies on predicting the behaviour of 'non-spammer' SMTP software by reading the RFCs is broken. While the big, free, Unix daemons are predicable in their out-of-the box behaviour - there is a lot that can be configured. And much commercial mail software (from the point of a non-user, I admit) has been extremely lax in RFC compliance.
A client has a mailing list in the thousands and only sends out a mail once a month. In those weeks, plenty can change in the status of the addresses mail is being sent to. However, with the different anti-spam techniques out there - it seems almost impossible to identify *actual* delivery issues, since there's a significant number of servers just pretending to have technical problems.
Therefore new methods need to be developed, outside of the assumptions of the RFCs, to control delivery.
Some backup MX servers don't issue DSNs for failed deliveries. The assumption is that, if there's been no issues with the primary, you might only expect spammers to be delivering to a backup MX first. Thus DSNs are not generated in the event of rejection from the primary since the return address is likely to have been forged (blowback).
In this situation, if we consider that mail delivered to backup MXes is not likely to result in a DSN, persistant failure to connect to a primary MX (in the absence of other feedback) *might* be considered evidence of a dead address.
A client has a mailing list in the thousands and only sends out a mail once a month. In those weeks, plenty can change in the status of the addresses mail is being sent to. However, with the different anti-spam techniques out there - it seems almost impossible to identify *actual* delivery issues, since there's a significant number of servers just pretending to have technical problems.
Therefore new methods need to be developed, outside of the assumptions of the RFCs, to control delivery.
Some backup MX servers don't issue DSNs for failed deliveries. The assumption is that, if there's been no issues with the primary, you might only expect spammers to be delivering to a backup MX first. Thus DSNs are not generated in the event of rejection from the primary since the return address is likely to have been forged (blowback).
In this situation, if we consider that mail delivered to backup MXes is not likely to result in a DSN, persistant failure to connect to a primary MX (in the absence of other feedback) *might* be considered evidence of a dead address.
[ Parent | Reply to this comment ]
The comments seem rather harsh.
I'd be interested in knowing the results.
Since we provide greylisting when we register/hold a domain for a client, I don't see much need for a "poor mans" greylisting. Greylisting implementations are free software, and available gratis and nicely packaged in Debian, so one doesn't need to give up cash, or liberty, to deploy greylisting.
The gotchas I see with nolisting;
You need to make sure the first MX is a valid IP (rfc-ignorant will list badly configured primary MX records).
You need to make sure the first MX is never listening on port 25.
Since spambots exist that try secondary MXes in preference, so I doubt it is a big win.
I'm also very surprised they claim zero false positives, as even greylisting that merely simulates a server being busy, results in wanted emails not being delivered due to servers that don't retry if the primary MX is busy. I'd be stunned if everything out there follows the RFCs as regards secondary MXes.
I also still see email (and spam) sent to the A record for domains that have an MX record listed. I suspect some blacklists, use this broken fail-over behaviour to identify some spambots. But it hints at a lot of brokenness in this area of SMTP.
I'd be interested in knowing the results.
Since we provide greylisting when we register/hold a domain for a client, I don't see much need for a "poor mans" greylisting. Greylisting implementations are free software, and available gratis and nicely packaged in Debian, so one doesn't need to give up cash, or liberty, to deploy greylisting.
The gotchas I see with nolisting;
You need to make sure the first MX is a valid IP (rfc-ignorant will list badly configured primary MX records).
You need to make sure the first MX is never listening on port 25.
Since spambots exist that try secondary MXes in preference, so I doubt it is a big win.
I'm also very surprised they claim zero false positives, as even greylisting that merely simulates a server being busy, results in wanted emails not being delivered due to servers that don't retry if the primary MX is busy. I'd be stunned if everything out there follows the RFCs as regards secondary MXes.
I also still see email (and spam) sent to the A record for domains that have an MX record listed. I suspect some blacklists, use this broken fail-over behaviour to identify some spambots. But it hints at a lot of brokenness in this area of SMTP.
[ Parent | Reply to this comment ]