From: "william(at)elan.net" <william(_at_)elan(_dot_)net>
As far as anti-spam techniques what happens is that some percent of
messages come directly from spammer controlled PCs and it appears some
spam software indeed was designed to mimic those badly written MUAs
and also do not work properly (or its possible that some spam software
in fact directly tries to interface with those bad MUAs to send email
out). So its exactly those MUA->MDA spam attempts that would be caught
by such anti-spam technique.
Good observation. I need to study the percentages here.
As much as I am a stickler for standards (and of course, that include my own
software complying), we need to seriously deal with backward compatibility.
So I would suggest that authorized sessions could be used as a way to deal
with non-compliant exemptions *specifically* in regards to the no-space
syntax.
At this moment, purely because of legacy issues, this one, needs to be less
strict.
But if the numbers at very high, I agree with Arnt, that this would be very
good tag for a Bayesian weight.
It might be a good idea to outline all the SMTP x821 compliancy issues (red
flags) that one may face and discuss what is possible or not.
x821 level
1.0: HELO/EHLO domain literal - no brackets
1.1. HELO/EHLO [domain literal] - ip mismatch
1.2: HELO/EHLO FQDN - nxdomain
1.3: HELO/EHLO FQDN - ip mismatch
2.0: MAIL FROM:sp<address> - illegal syntax
2.1. MAIL FROM:<address> - valid return path
3.0 RCPT TO:sp<address> - illegal syntax
3.1 RCPT TO:<multiple addresses> - limits per NULL return path
3.2 RCPT TO:<remote_address> - non-authorized sessions
x822 level
4.0 DATA - 822 server, 2822 header
4.1 DATA - 822 server, no headers
4.2 DATA - 822 server, partial headers
4.4 DATA - 2822 server, no headers
4.5 DATA - 2822 server, partial headers
4.6 DATA - SenderID/PRA (2822) server, no PRA
Others?
We can look at all the issues, whether ort not it is applicable,
recommendations for handling, etc.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com