Spam to this list

[Shachar Shemesh]

John E. Malmberg wrote:

> The essential SMTP NACK is not what is the problem as long as it is 
> done during the SMTP connection using reject codes.  Issuing a SMTP 
> reject code for undeliverable messages will never cause a spamcop.net 
> listing.

Reject codes were very common once. Then they were recommended against. 
They were recommended against for a reason, that reason being that they 
expose the user base to password and other guessing.

When Spamcop was confronted with spammers harvesting email using 
rejection codes, Julian responded with the laughable "I don't know of 
spammers who do that". What?

Not to mention the fact that secondary MXes are impossible to reject 
during SMTP, as are virtual domains (for all practical purposes), later 
filters, and many many many other cases.

Julian's solution is either "don't provide NACK" or "hold the original 
SMTP until you know what to reply". I'm sorry, but both answers are 
laughably sad, and effectively mean the end of SMTP.

I know, it's bad to be bombarded with bounces. I've been there myself. 
Destroying the reliability of SMTP for this high cause, however, is 
something I cannot abide by. I have heard of enough cases where 
important emails vanished without leaving a trace to consider this a 
trivial or unimportant problem.

> The SMTP bounce is an artifact from the time when third party open 
> relays where also in common use.  At that time, it was needed by the 
> third party open relay to return the non-delivery message.

No. See above. I won't mention "qmail" again, because Julian seems to 
not mind the fact that it's the only safe MTA around, but the simple 
fact is that any time you need to perform processing in order to accept 
or reject an email, you need to accept the mail and then decide. Keeping 
a TCP connection open just so you can put in a reject code in the 
protocol opens you up for DoS, as well as threaten the very delivery due 
to timeouts.

And, you have not mentioned secondary MXes and downed networks yet.

> Now, almost no mail servers will accept e-mail from known open relays, 
> so when they can not deliver an e-mail, if they use an SMTP reject 
> code, then the sender's mail server, which should trust the sender 
> will generate the bounce message.

It's a great theory. Too bad it doesn't cover all cases.

> If these bounces from the sender's mail server are going to forged 
> addresses, then there is a security problem on the sending network 
> that needs to be fixed.

No, there is a bandwidth problem. I agree that it's a problem, but I 
totally disagree with the "solution".

> And since medium to large networks pay a metered rate for their 
> internet connection, bouncing instead of using SMTP rejects will 
> significantly increase their operating costs as it will cause them to 
> pay for the bandwidth for 6 spam/virus e-mails for every 1 real e-mail 
> that they receive.  Using SMTP rejects and DNSbls eliminates almost 
> all of that cost from their operation.

I don't see the difference. One way or the other, SMTP is shot. If 
someone shoots down a protocol I need, I call him "the enemy of the 
public". So far it has been spammers. Now it's spammers and Spamcop.

My mail server doesn't bounce viruses. The reason is that I can detect 
viruses with close to 0% false positives, so I feel fairly confident in 
sending them to /dev/null. Unfortunately, spam does not enjoy this rate 
of false positives. What's more, even if it did, the occasional false 
negative would mean that I would still get blacklisted.

Look, I chose a difficult to understand name for my company (Lingnu). As 
a result, many times, if I'm telling someone my email address over the 
phone, they'll get it wrong. It didn't used to be a problem. If one in 
four got it wrong, they would get a bounce and call me. Not any more. 
One of the domains around mine sends all incoming email to /dev/null, 
and people are mad at me for not responding to my emails. Do tell me 
that this is ok with you, or that you don't think that SMTP loses a lot 
from it's functionality (even more so than because of Spam) as a result.

Again, this is without bringing qmail into the picture. Qmail, as a 
direct result of a design that keeps security in mind, cannot send 
rejections inline. The daemon accepting the mail simply doesn't know 
what's behind it. It's an unprivileged drown that take the emails and 
queue them, not having any idea what will happen to them afterwards. In 
an environment where spammers exploit security holes to infect computers 
with spam sending zombies, telling an MTA admin to switch to something 
less secure because you don't like something defined by the RFC is 
counter-productive and does more to hurt spam fighting than to help it.

Now, this is getting off topic for rsync, so please do feel free to send 
me your reply privately.

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html