[Greylist-users] Possible Enhancements

[Bob Beck]

> Yeah..  But the general rule of thumb is that you don't trust the From: 
> address..  So..  The only way to accomplish this would be to use the IP 
> address of the incoming connection.  Reverse lookup, MX, and callback..  
> 
	Which proves exactly nothing, if you don't trust the FROM: address,
because of course, it's probably forged, either a Joe Job or a nice
throwaway domain, either of which can have an MX record because
spammers aren't stupid.  Look, it costs me nothing to register a
throwaway domain, put some pudwanking linux box up with a mailserver
that will answer to port 25 delivering everything to /dev/null,
register a nice liberal SPF record for the domain for all the people
still dumb believe that spam <-> forgery, and then buy me a nice
bot-net of compomised broadband connected virus run time environments
from which to fling spam at the masses faster than a poop fight in a
marmoset cage. The box which is MX'ed to never sends one piece of spam
- the compromised PC's do. It just sits there looking like an innocous
mailserver, recieving all your "callbacks", (and /dev/null'ing all the
bounces from morons with idiotically configured bounce-after-recieve
SMTP DDOS multipliers :) At least, it does that until a different
spammer hacks into it through linux-hole-of-week and makes it part of
his bot-net, but that's another story :) 

	There's also of course, the case where I legitimately
use a different host for outbound deliveries than inbounx MX. Happens
all the time.

	The only thing callback can concievably help you for is deciding "Am
I talking to a real mail server" - you could connect back to the
connecting IP, and try to issue a few simply smtp commands. However
the problem with this is that if it works, ok, but if it doesn't, the
lack of a connection doesnt' tell you enoug. It may simply be that the
the outbound mailserver is firewalled inbound, etc. etc. 

	So really, you've gained not too much. Wait for the message to retry
by conventional greylisting and you know you have at least something 
vaguely resembling a standards compliant MTA talking to you, and in the
meantime hopefully you've considered what else he was trying to deliver
from the same address, allowed the blacklists to catch up, etc. etc. 
etc.

	Greylisting buys you exactly two things:

	1) Is the sender a real queueing MTA - most virii don't currently
retry. At least if they do, it costs them more resources on the host
they've compromised. Remember that this only works well now because
the majority of the world isn't greylisting, so it isn't worth a
spammer's while to retry from a bot (yet). 

	2) Time. time to check out what else will be attempted to be
delivered from the same host in the next 30 minutes and blackist him
yourself, Time for him to trip over one of your spamtrap addresses in
the next 30 minutes so you blacklist him yourself, or time for someone
else of eminent authority to decide he's up to no good and shove him
in your favorite blacklist... Once there, into the tarpit he goes...

	-Bob

	P.S. Actually, for me I get a third thing. Because my greylister *is*
my tarpit talking fast, and I *make* it look like a spamtrap - many
spammers programs give up when they see the banner, rather than retry
and come through. Doesn't break my heart, they go and bother someone 
else with their hijacked bandwidth.
 
--
Bob Beck                                   Computing and Network Services
beck at bofh.ucs.ualberta.ca                           University of Alberta
True Evil hides its real intentions in its street address.