Re: Loopholes in a proxy and smtp server

[MaddHatter <maddhatt+securitybasics () cat pdx edu>]

Niranjan Patil <niranjan.patil () gmail com> said (on 2006/12/12):
> 2. The SMTP servers ...
> mean when we respond to its RCPT command with an email id, it checks
> and throws out a message as
> '[250 recipient <name () company com> ok]' for a valid id and
> '[Could not connect: Got an unknown RCPT TO response: 501 #5.1.1 bad
> address  nonexistingname () company com]' for non existing email id and
> closes the connection.
> Using this anyone can get address book of all valid email ids of that
> firm, he/she may use a simple script too. I don't think this is
> normal, and need to address this soon. I checked out the popular free
> email providers like gmail, yahoo or hotmail, they accept connections
> for all email ids and then sends back a mailer daemon for invalid ids.


It's fairly normal to disable SMTP EXPN and VRFY commands. It's not 
unheard-of to ignore the NOTIFY keyword to the RCPT command. It is not 
normal -- in fact it's a Bad Idea (tm) -- to accept mail that (to the 
best of your knowledge) you cannot deliver. 

If you believe the figures thrown around the media -- that 75+% of 
email is spam -- then most of the envelope senders* seen by your 
server are forged. Sending a mailer daemon notification to those 
(forged) addresses is, at best, amplifying the effect of the spam. 
It's probably annoying some poor user who doesn't know why s/he's 
getting bounces for emails s/he never sent. At worst, it can be used 
as a denial-of-service attack against someone else's mail server(s). 

Alternatively, you can return a 5xx error after the DATA, but you've 
wasted a bunch of time and bandwidth listening to a message you know 
you won't accept. It makes sense to send the 5xx after the RCPT, as 
soon as you know the recipient is bogus.

The last alternative, if you insist on pretending to accept mail for 
any address, is to silently drop emails sent to invalid addresses. 
However this approach isn't very user-friendly for the cases where 
someone mistypes johndoe () company com as jonhdoe () company com.

There are other remedies to limit the effectiveness of brute-force 
email address guessing. My personal favorite is pseudo-exponential 
back-off: After the first RCPT command to an invalid address, delay 
the SMTP conversation by 1 second; after the next "invalid" RCPT, wait 
2 seconds; after the third, wait 4 seconds, and so on up to a 
reasonable upper limit. It's easy to implement that within a single 
SMTP session, and with a little work you can extend it across SMTP 
sessions on a number-of-wrong-RCPTs-per-IP-address basis. 



(*) Envelope sender: Roughly, the "from" address, or more accurately, 
the place you would send a "this message can't be delivered" notice 
(called a DSN), if you had to send one.


---------------------------------------------------------------------------
This list is sponsored by: ByteCrusher

Detect Malicious Web Content and Exploits in Real-Time.
Anti-Virus engines can't detect unknown or new threats.
LinkScanner can. Web surfing just became a whole lot safer.

http://www.explabs.com/staging/promotions/xern_lspro.asp?loc=sfmaildetect
---------------------------------------------------------------------------