DUMBER: Now there's no such thing as a non-existent .com or .net domain...
A nameless domain registrar (I choose not to name them here but Google is your friend) now "owns" every non-existent .com and .net domain.Of course, they do not actually own them. But they have kindly listed a DNS A record for all hosts named "www.absolutely-anything-you-care-to-make-up.com" and "absolutely-anything-you-care-to-make-up.com". And the same for .net.
Try it. Go to Sam Spade, enter a random collection of characters ending in .com or .net and hit the button marked "do stuff". Or just click this (stolen from here). All of these non-existent names resolve to hosts in CIDR 64.94.110.0/24.
Spammy will think Christmas has come early.
"Why is this a problem?", you ask. "All we need to do is set up a local block to deny any mail from 64.94.110.0/24".
Well, no. No actual spam will originate from that block, now will it? But when a spammer decides to spoof a sender address in a non-existent .com or .net domain, we will no longer be able to block it, because "Verify sender's domain in DNS" will now succeed for every possible .com or .net domain.
Want proof?
First, a bad .co.uk domain to show what should happen when "verify sender's domain in DNS" is enabled.
telnet mail.example.com 25
220 Ready at Tue, 16 Sep 2003 15:52:09 +0100
helo example.com
250 mail.example.com Hello example.com ([192.168.0.1]), pleased to meet you
mail from:<no-one@gjhgsjhgjhgss.co.uk>
554 Mail from no-one@gjhgsjhgjhgss.co.uk rejected for policy reasons.
And now a random .com domain
rset
250 Reset state
mail from:<no-one@gjhgjsghjgssgjhgs.com>
250 no-one@gjhgjsghjgssgjhgs.com... Sender OK
Bugger it.
rset
250 Reset state
quit
221 mail.example.com SMTP Service closing transmission channel
How very thoughtful, to disable one of the most basic and (till now) fail safe mechanisms for blocking email abuse.
NOT!
Category: Dumb and Dumber
Technorati: Dumb and Dumber
1. Wolfgang Flamme17/09/2003 17:16:37
Homepage: http://www.sns1.de/partner/flamme/wflamme.nsf/
18:13, Mainz, Germany
Looked like they've learned a lesson or two. 404-popup finally. However: Never, ever...
2. Chris Linfoot17/09/2003 19:44:00
Really? Still happening here (20:43 your time, 17th September).
3. Stew the Yax...02/10/2003 19:01:10
Now that I understand the issue...what a pain in the ass! There's not even any advertisement on the site! What would the commercial interest be in setting this up? (I assume that is the prime mover behind this setup... otherwise, somebody fill me in.)
4. Graham Miller10/01/2007 04:09:11
I do not think this is an issue any more. As I understand it, this awful practice has been discontinued.
I tried the sam spade and dnsstuff.com and they both gave a negative answer to some foolish domain name in the dotcom space.
So verify the sender domain to help stamp out spam.
5. Chris Linfoot10/01/2007 08:46:07
Thanks Graham.
Yes, we know this is no longer an issue and hasn't been for over three years - see date on this original post and all comments prior to yours... 
6. Martijn de Jong08/02/2007 16:36:47
Hmm, when I was configuring my (home) mailserver way back I looked at the option, saw your remarks on it and did not switch it on as it apparently didn't work and, as IBM puts it, "Using 'Verify Sender's Domain' in DNS can affect performance of SMTP task" (that was a bug back then). As I'm configuring my new mailserver, I was passing this setting again and saw the new remarks. Is this a setting you have switched on in your production environment?
7. Chris Linfoot08/02/2007 20:37:17
Yes.
You should always verify sender's domain and I have never recommended otherwise (perhaps you are thinking of Verify Connecting Hostname in DNS - an altogether more contentious issue).
All this does is ensure that there is a domain to which a reply can be addressed. It is reasonable to assume that a real person sending email will do so from a live domain. Only spam and malware uses bogus domains.
8. Greg Bussey10/07/2007 04:45:19
Do you know of a way to "whitelist" this setting? I have it set to 'yes' but my local workstations' antivirus tries to send in admin messages and they are getting rejected. They come from Administrator@TrendMicroCSM.Local, which of course is not in DNS.
9. Chris Linfoot10/07/2007 08:24:00
1. Can you configure the sender address so that Administrator@TrendMicroCSM.Local becomes something meaningful?
2. Do you have a Domino host inside the DMZ somewhere which could accept SMTP from trusted systems without any onerous policy checks?
3. If you have your own DNS servers, create an A record for TrendMicroCSM.Local (anything will do - use loopback) - or try this in the hosts file on the Domino server.
Unable to post a comment? Please read this for a possible explanation...
-