incorrect spam setups cause spool messes on forwarders

Tue Dec 2 19:05:47 UTC 2003

Hi,

...on Tue, Dec 02, 2003 at 07:23:41PM +0800, Suresh Ramasubramanian wrote:

 > What they are trying to do is to connect back 
 > to email.com's MXs and ensure that the user 
 > <sgswretyshsdhtest at email.com> who is trying to 
 > send them mail really does exist, [..]
 > It does tend to cut down on the amount of spam, 
 > but fails in several ways which have been discussed 
 > upthread (the most common being: the MX has an smtpd 
 > listener with no view of the userdb, 

While sender address verification puts additional 
load on (more or less) innocent bystanders, it's 
right to exist is, as you said, based on the fact 
that it eases the spam load to the recipient - like 
many other intrusive anti-spam techniques.

I agree that much of the anti-spam stuff out there 
is kludgy at best, and often harmful to other users, 
but let's not forget that it's the spammers who make 
all this necessary... At the edge of the net, where 
traffic can still be a major cost factor despite the 
limited bandwidth, having to transport 20% to 50% 
spam is a real burden that fuels many desperate 
decisions.

If some of the large Email providers like Outblaze, 
Hotmail, Yahoo, AOL, etc. could agree on a more 
integrated approach to implement at least some form 
of sender authorization - possibly in the line of the 
RMX RR draft[1] - as a service to the public, the 
aggressive MX callbacks would perhaps be made 
redundant... 

While RMX and similar ideas certainly are no perfect 
solution, it's a cheap way to attach some trust level 
to a message, and gives the email providers the chance 
to solve the problem at their end as they gain control 
over the users of their domain name(s) by hampering 
unauthorized usage. 

Alex.

[1] http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt

-- 
AB54-RIPE