Re: Why SRS really sucks

> Which means: if you detect SRS signatures in the local part
> and drop mail, then you are violating RFC. 
 
You are right and we know that.
 
Trust me, we normally act RFC compliant whereever this makes sense.
 
But if we find something which is contraproductive, and there is no other
way to circumvent the problem, we are (from time to time) violating RFCs.
 
Example:
 
A Server connects to us and tries to deliver mail to multiple recipients.
S = Sending server
R = Recipient System
 
As soon as S hits a Spamtrap on R  we simply drop him, we are also violation
RFCs
by acting as follows:
 
Connection to UCEPROTECT-Server established.
R: 220 recipientdomain SMTP ready.
S: HELO anything :-)
R: 250 Ok
S: mail from: anything@faked
R: 250 Maybe OK
S: rcpt to: validuser1@recipeientsystem
R: 250 OK (by Policy)
S: rcpt to: spamtrap@recipientsystem
R: 571 Game over. Your IP is now blacklisted
R: 421 Hasta la vista ...
Connection dropped by UCEROTECT-Server
 
This really makes sense.
 
Beeing RFC conform would mean to act like this:
 
Connection established.
R: 220 recipientdomain SMTP ready.
S: HELO anything :-)
R: 250 Ok
S: mail from: anything@faked
R: 250 Maybe OK
S: rcpt to: validuser1@recipeientsystem
R: 250 OK (by Policy)
S: rcpt to: spamtrap@recipientsystem
R: 550 I know you are a Spammer but RFCs force me to be fooled by you ...
S: rcpt to: nextvalidrecipient@recipientsystem
R: 250 OK (i dont like it but im conform to RFCs)
S: DATA
 and so on ... resulting the Spam will be delivered to your valid recipients
..
 
This makes no sense, but is conform to RFCs :-)
 
So you see it is not always good to follow RFCs ...
 
--
 
Johann Steigenberger 
Blacklistmaster at UCEPROTECT-Network 
http://www.uceprotect.net