Spam to this list
rsync at shemesh.biz
Mon Apr 18 21:25:23 GMT 2005
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
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
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.
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
More information about the rsync