spamc, spamd and spamassassin

[Steve Freegard]

Hugo van der Kooij wrote:
> On 10/15/09 17:39, Steve Freegard wrote:
> 
>> The implementation of the test is so flawed that it trips my own servers
>> pipelining checks (e.g. it sends all the SMTP commands without waiting
>> for a response - which is illegal if using SMTP (e.g. HELO vs EHLO):
>>
>> 220-mta11.safeguardmail.net SMTP Welcome to smtpf #633 
>> (l9EBY0201453145500)
>> HELO www.declude.com
>> 220 Copyright 2006, 2009 by SnertSoft. All rights reserved.
>> MAIL FROM:<webmaster-vir at declude.com>
>> 250 Hello declude.com [216.144.195.82] #256 (l9EBY0201453145500)
>> RCPT TO:<steve.freegard at fsl.com>
>> 250 2.1.0 sender  accepted #283 (l9EBY0201453145500)
>> DATA
>> 550-5.3.3 pipelining not allowed #643 (l9EBY0201453145500) White list
>> via
>> http://mta11.safeguardmail.net/barricademx/click.php?h=l9EBY25a6134e025c9b82a9daaf928997922b2&c=click:declude.com,webmaster-vir@declude.com 
>>
>>
>>
>> Sorry, an error occurred!
> 
> I must say the output shown does not look like a pipeline at first 
> glance. It resembles a normal SMTP session but they have a problem with 
> multiple line responses.
> 

We use multi-line banners and responses deliberately to trip up poorly 
written software like this intentionally but they would have hit a 
syncronisation error if it were due to the multi-line responses (as they 
would have read the second line of the banner instead of the HELO 
response); which tells me that they are not reading the responses until 
DATA (which is the sync point if you are pipelining).

Pipelining is supposed to wait until after EHLO returns 'PIPELINING' as 
an extension - the client then sends everything else and finishes with 
'DATA' and then reads the responses from the server.  In this case; 
they're skipping the EHLO bit entirely.

> RFC 5321 indicates that the use of HELO is now deprecated. But even RFC 
> 821 specifies that multiline responses are allowed for each valid command.

Support for HELO is required even though it's deprecated see section 
2.2.1.  It's not going away any time soon.

One of the tricks we use extensively is to *disable* ESMTP for unknown 
hosts (e.g. hosts we've never spoken to before or that are not 
whitelisted) by rejecting the EHLO command and making them fall-back to 
HELO.   Many bots simply do not fall-back correctly and quit the 
connection instead:

l9L48f044650594100 #721 end i=189.3.185.101 p="" 
f="forged,black,no_ptr,ehlo_no_helo,ipv6,quit" h="[189.3.185.101]" m=0/0 
b=28 R=1 t=2 l="502 5.5.1 EHLO not supported #253 (l9L48f044650594100)" 
p0f="(unknown) hops 0"

This also allows us to compare the arguments sent on the EHLO to the 
HELO and reject if they differ (quite sneaky):

l9H9Z5088273824400 #721 end i=114.217.156.246 p="" 
f="forged,black,no_ptr,schizo,ipv6" h="QAPVBYXA" m=0/0 b=29 R=2 t=5 
l="550 5.7.1 client [114.217.156.246] is schizophrenic #255 
(l9H9Z5088273824400)" p0f="(unknown) hops 0"

Both of these hit a considerable amount of junk:

214-2.0.0 age=4562 (00 01:16:02)
214-2.0.0 030 ehlo-no-helo=6946 63.50%; 3436 58.49%; 4658 59.32%
214-2.0.0 031 helo-schizophrenic=874 7.99%; 456 7.75%; 647 8.23%

> Perhaps someone ought to print out those RFCs, roll them up real stiff 
> and whack these guys over the head with it?

Yeah; but this isn't the worst I've seen by a long way unfortunately. 
Typically web-apps such as this are the worst, followed by 
Printer/Fax/Scanner SMTP engines, then Windows web mail SMTP 'servers' 
(I use the term lightly).

Cheers,
Steve.