One aspect of the latest VeriSign nonsense that I stumbled upon through Haiko Hebig is mail delivery for non-existent domains. Here's an analysis of what happens with a non-existent domain:

 muenster:~# exim -bt gb@blubberfaselblubb.com gb@blubberfaselblubb.com deliver to gb@blubberfaselblubb.com router = lookuphost, transport = remote_smtp host blubberfaselblubb.com [64.94.110.11]

So an email is sent normally to the A-record (the one with the wildcard). What happens there? You can see it here:

 telnet blubberfaselblubb.com smtp Trying 64.94.110.11... Connected to sitefinder-idn.verisign.com. Escape character is '^]'. 220 snubby3-wceast Snubby Mail Rejector Daemon v1.3 ready HELO blubberfaselblubb.com 250 OK MAIL FROM: blah@blubberfaselblubb.com 250 OK RCPT TO: blah@blubberfaselblubb.com 550 User domain does not exist. DATA 250 OK quit 221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel Connection closed by foreign host.

So there's a mail rejector running at that address that rejects every mail delivery with 550 - User domain doesn't exist. Want some paranoia? Sure? OK: it's trivial to modify the mail rejector so that it collects and archives the sender addresses provided at MAIL FROM: of the misdirected emails. I'm not saying VeriSign does that - but wildcard A-records at such a central location are an abuse waiting to happen ...

Here's the original article.