Should ISP"s send bounceback on mail to non-existent address?

My ISP is Sympatico.ca, one of Canada's major ones. Recently I deleted
an email address I had there, but then found that messages sent to that
obsolete address don't produce a bounceback message telling the sender
the address doesn't exist.

Now Sympatico is telling me that that's the way it's supposed to be --
it's an anti-spam measure. Their message is shown below.

Could anyone comment?
--
http://urielw.com

----- Original Message -----
From: "Executive Office of Customer Relations" <...@sympatico.ca>
To: [uriel]
Sent: Tuesday, June 28, 2005 11:18 AM
Subject: Re: Sympatico bouce messages

Mr. Wittenberg,

We were informed that all Sympatico customers on the MSN enhanced email
platform will experience this issue. Microsoft has implemented this
feature as a spam prevention method. This way spammers cannot update
their spam lists as they cannot know which email address are valid and
which are not.

We thank you for your understanding in this matter

Regards

Executive Office of Customer Relations
Bell Sympatico Internet Services

Re: Should ISP"s send bounceback on mail to non-existent address?

Uriel Wittenberg wrote:

> My ISP is Sympatico.ca, one of Canada's major ones. Recently I deleted
> an email address I had there, but then found that messages sent to that
> obsolete address don't produce a bounceback message telling the sender
> the address doesn't exist.

Sympatico, as usual, is full of sh*t.

> Now Sympatico is telling me that that's the way it's supposed to be --
> it's an anti-spam measure. Their message is shown below.

It's a clear violation of RFC 2821. You have only three choices if
someone sends e-mail to a nonexistent address:

1) You fail the RCPT command with a 5xx failure code.
2) You fail the final "." with a 5xx failure code (if there was only one recipient)
3) You accept the final "." and then generate a delivery failure notification.

Sympatico has allied itself with Microsoft, which cares little for
Internet standards or even polite network behaviour. I would
copy this posting to Sympatico tech support, and then switch
to a decent ISP.

Regards,

David.

Re: Should ISP"s send bounceback on mail to non-existent address?

On comp.mail.misc, in , "David
F. Skoll" wrote:


> Uriel Wittenberg wrote:
>
>> My ISP is Sympatico.ca, one of Canada's major ones. Recently
>> I deleted an email address I had there, but then found that
>> messages sent to that obsolete address don't produce a
>> bounceback message telling the sender the address doesn't
>> exist.
>
> Sympatico, as usual, is full of sh*t.
>
>> Now Sympatico is telling me that that's the way it's supposed
>> to be -- it's an anti-spam measure. Their message is shown
>> below.
>
> It's a clear violation of RFC 2821. You have only three
> choices if someone sends e-mail to a nonexistent address:
>
> 1) You fail the RCPT command with a 5xx failure code. 2) You
> fail the final "." with a 5xx failure code (if there was only
> one recipient) 3) You accept the final "." and then generate a
> delivery failure notification.
>
> Sympatico has allied itself with Microsoft, which cares little
> for Internet standards or even polite network behaviour. I
> would copy this posting to Sympatico tech support, and then
> switch to a decent ISP.
>
> Regards,
>
> David.
>

RFC2821 is _clearly_ out-of-date and needs to be subjected
to a major overhaul. Although it was published in 2001,
it contained no revisions that gave mailadmins any help
at all with the UBE plague, which even then was significant.

Now, it has reached epidemic proportions, and it is obvious
to almost everyone that a mail protocol that has not fundamentally
changed since 1982 is a DINOSAUR.

I notice that you scream bloody murder when someone violates
an RFC that facilitates spam, but utterly ignore the RFC
that _authorizes_ Challenge-Responses (RFC3834).

Challenge-Responses being the bain of spammers.

AC

--
alanconnor AT earthlink DOT net http://tinyurl.com/2t5kp
Please visit my home page:
http://angel.1jh.com./nanae/kooks/alanconnor.html

Re: Should ISP"s send bounceback on mail to non-existent address?

>My ISP is Sympatico.ca, one of Canada's major ones. Recently I deleted
>an email address I had there, but then found that messages sent to that
>obsolete address don't produce a bounceback message telling the sender
>the address doesn't exist.
>
>Now Sympatico is telling me that that's the way it's supposed to be --
>it's an anti-spam measure. Their message is shown below.
>
>Could anyone comment?

As the other poster mentioned, the best way is that sympatico.ca
should genereate a 5xx error after the RCPT TO. A quick check reveals
that what they write in their reply is true in that they obviousely
don't do this. It definately is the propper and most resource
conserving way though. If a server responds with 5xx to an RCPT TO,
it's then the sending mailservers job to generate the bounce towards
the original sender of the message. That way it's not possible that
the bounce goes out to inocent people whose address was just forged in
a spam or worm mail.

Especially this latter aspect is the main reason why bounces should
not be generated where possible at all. The only half way valid
argument against generateing the 5xx after the RCPT TO that I heard of
so far is the fear that a spammer could guess mailadresses using a
rumpelstilz attack. This seems also to be the case to which sympatico
refers to.

Well, by measureing the ratio between valid versus non valid recipient
adresses during an SMPT session it's a side walk to detect such
attempts. I.e. when we detect a configurable number of such attempts
in a row from the same sending IP, we ignore the sending IP for a
complete week. Problem solved without generating a bounce. Moreover
the problem is solved in a much better way. The aproach used by
sympatico is quite silly because of yet another important fact:

Let's asume you would write a really agressiv worm. How long do you
think that such a worm after infecting a PC will need to propagate
itself to all e-mail adresses found on an average PC? A hour? Probably
two? What should the worm do thereafter? Well, some worm writers
aparently realized this and came to the idea that the worm could visit
all domains found on the infected PC and try to guess mail adresses.
At least one of them does it in a round robin fashion running an SMTP
session per single guess.

To give you a real world example of what can (and will) happen if you
configure your mailserver "the sympatico" way. One of our customers
runs an Exchange 5.5. This SMTP wise poor software aparently can't be
configured not to accept mail for non existing users (hence we have
the sympatico effect). While it is a very fast machine with very much
ram etc, the customer experienced an almost saturated link to the
internet and the Exchange server running at peak CPU load.

We then simply added one of our $560 Embedded E-Mail Servers in front
of the Exchange which a) is able to validate the user accounts and
respond with 5xx messages when needed and b) is able to detect
rumpelstilz attacks and block the sending IP for a week and c) filters
spam better than 99%. Problem solved. The Exchange is now really bored
with dealing with the few valid messages that arrive there, the
internet link is down to normal levels. It turned out that 99% of the
Exchange servers capacity was used up by many many paralell worms
constantly propagate themselves towards this machine!

Now, perform a very simple test. Open a telnet session and telnet to
port 25 into any of the several sympatico.ca mailservers.

toip#.bellnexxia.net -> replace # with any digit between 1 - 8

Oh, what a surprise! It takes close to ONE MINUTE! up until the server
even sends a prompt! Hmmmmm, I don't really want to know how many
NetSky's are propagating themselves towards these servers. Nice job
sympatico, really, nice job.

Markus

Beavis to rewrite RFC 2821 (was Re: Should ISP"s send bounceback on mail to non-existent addr

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-25425-1120005754-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Usenet Beavis writes:

> RFC2821 is _clearly_ out-of-date and needs to be subjected
> to a major overhaul. Although it was published in 2001,
> it contained no revisions that gave mailadmins any help
> at all with the UBE plague, which even then was significant.
>
> Now, it has reached epidemic proportions, and it is obvious
> to almost everyone that a mail protocol that has not fundamentally
> changed since 1982 is a DINOSAUR.

Beavis, if it's not too much trouble, it would be great if you went ahead
and revised RFC 2821 to address all these woes.

Please post the results to comp.mail.misc. I'm very interested in reading
what you come up with.

> I notice that you scream bloody murder when someone violates
> an RFC that facilitates spam, but utterly ignore the RFC
> that _authorizes_ Challenge-Responses (RFC3834).
>
> Challenge-Responses being the bain of spammers.

Beavis, would you mind highlighting what part of RFC 3834 recommends using
autoresponses as spam filters?

Stupid Beavis, can't even read the document he uses as a reference.



--=_mimegpg-commodore.email-scan.com-25425-1120005754-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCwe56x9p3GYHlUOIRAs1yAJ4vJbPdB5f8Empd8HNehyzQtKexaQCb Bth7
Ly/8OvX7NTKvLmMJ8l2cLa8=
=0aYl
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-25425-1120005754-0002--

Re: Should ISP"s send bounceback on mail to non-existent address?

Thanks to all for responses!

OK, I'm sorry, I realize now my subject line -- "Should ISP's send
bounceback...." was inappropriate. Please note I'm just an email *user*,
ignorant of technicalities. What I meant was: Should sympatico.ca be
doing something, anything, different, so that a person sending mail to

non-existent-address@sympatico.ca

eventually, through whatever mechanism, gets *some* notification that
his message won't reach anyone? I don't care who's supposed to generate
the actual bounce message.

I understand this:

>If a server responds with 5xx to an RCPT TO ... it's not possible that
>the bounce goes out to inocent people whose address was just forged in
>a spam or worm mail.

But I'm afraid I got lost in the part leading up to:

>Nice job sympatico, really, nice job.

Anyway, are you basically saying that the approach in use by sympatico
is a misguided way to prevent spammers from learning valid addresses?
And is this same approach indeed the one prescribed by Microsoft
software?

If sympatico did produce a response to indicate an invalid address, then
why couldn't a spammer indeed send to a@sympatico.ca, b@sympatico.ca,
c@sympatico.ca, etc., and use the responses to figure out which are
valid and which invalid?

P.S. In case you're in the mood for a laugh (of the black humor
variety), you may want to see sympatico's initial responses to my
inquiry before I escalated to the "Executive Office," at
http://urielw.com/custsvc.htm .

Re: Should ISP"s send bounceback on mail to non-existent address?

Hi Uriel

>Thanks to all for responses!
>
>OK, I'm sorry, I realize now my subject line -- "Should ISP's send
>bounceback...." was inappropriate. Please note I'm just an email *user*,
>ignorant of technicalities. What I meant was: Should sympatico.ca be
>doing something, anything, different, so that a person sending mail to
>
>non-existent-address@sympatico.ca

Yes, definately. The server should reply with a 5xx error message in
the RCPT TO. With less technical words, at that point in time the
sending mail server (your outgoing one in your case) should get a
reply that the user does not exist. Because of the SMTP protocol this
reply comes BEVORE the mail data is transmitted hence there is no
waste in bandwitdh and processing time. Your server then terminates
the session without transmiting the mail and generates a failure
message which informs you about the fact, and as a valid user you will
check the target for typos and resend.

>eventually, through whatever mechanism, gets *some* notification that
>his message won't reach anyone? I don't care who's supposed to generate
>the actual bounce message.

You should care WHO is generateing the bounce. If it's sympatico, then
every one whoes mail adress was forged will get a bounce and this
bounce is then simply SPAM. That's not possible if the sending server
must generate the bounce. Another huge problem with such bounces is
that they are extremly hard to filter. It's also in sympaticos
interest in the long run cause if everyone would do it this way, you
could read as much about this in the news as you can about spam.

>I understand this:
>
>>If a server responds with 5xx to an RCPT TO ... it's not possible that
>>the bounce goes out to inocent people whose address was just forged in
>>a spam or worm mail.
>
>But I'm afraid I got lost in the part leading up to:
>
>>Nice job sympatico, really, nice job.
>
>Anyway, are you basically saying that the approach in use by sympatico
>is a misguided way to prevent spammers from learning valid addresses?
>And is this same approach indeed the one prescribed by Microsoft
>software?

It's not misguided in the sence that spammers in fact can't guess mail
adresses. It's VERY misguided in general though because bounces are
sent to inocent victims and also because it will lead to very busy
mailservers.

Microsoft is not the holy grail. The aproach IS having the serious
problem with bounces generated to inocents. With regard to the server
itself the aproach IS having the problem with those worms autmatically
guessing adresses and propagate themselves for every guess. The former
is important to the internet comunity, the latter is important to the
owner of the mailserver.

>If sympatico did produce a response to indicate an invalid address, then
>why couldn't a spammer indeed send to a@sympatico.ca, b@sympatico.ca,
>c@sympatico.ca, etc., and use the responses to figure out which are
>valid and which invalid?

Well, "a" does not exist, so does "b" and "c" etc.

By monitoring the number of good and bad recipients per sending IP for
those IP's which go above a certain theresold of bad versus good it's
very easy to detect such attacks. I.e. we ignore such IP's at the TCP
level for a complete week if the firmware triggers that it's enough
from a given IP.

The advantages of this aproach:

a) the original sending server must generate the bounce hence we do
not have victims of forgery. Legit useres which make a typo still get
their failrue message.

b) Mail in such cases must not be accepted. That's fine because in the
vast majority it's not mail because of typos but worms trying to
propagate themselves.

c) the server does not carry the burden to deliver the bounces. Fact
is that many of those forged addresses then also lead to problems in
this area. They might be dead, the domain is not reacheable etc

HTH

Markus

>P.S. In case you're in the mood for a laugh (of the black humor
>variety), you may want to see sympatico's initial responses to my
>inquiry before I escalated to the "Executive Office," at
>http://urielw.com/custsvc.htm .

Uhhh, my thoughts are with you....

Re: Should ISP"s send bounceback on mail to non-existent address?

>By monitoring the number of good and bad recipients per sending IP for
>those IP's which go above a certain theresold of bad versus good it's
>very easy to detect such attacks. I.e. we ignore such IP's at the TCP
>level for a complete week if the firmware triggers that it's enough
>from a given IP.

Ahh! That's what I was looking for.

So, to reiterate:

-------------------------
- Sympatico has told me that it simply DISCARDS AND IGNORES any incoming
email addressed to non-existent-address@sympatico.ca.

- Its justification: If it somehow indicated to a sender when a
recipient didn't exist, a spammer could use that to guess valid
addresses. The spammer would do that by sending to a@sympatico.ca,
b@sympatico.ca, c@sympatico.ca, etc. Whenever there was no notice of
non-existence, he'd know he'd guessed a valid address.

- The above justification is nonsense since, as above, the proper way
for sympatico to prevent this kind of spammer action is to monitor
sending IP's and ignore those with excess bad/good ratios.
-------------------------

However, I'm still not clear about sympatico's claim that "Microsoft has
implemented this feature [in the MSN enhanced email platform] as a spam
prevention method."

(I gather the "MSN enhanced email platform" is MS software that
sympatico uses for processing email.)

Sympatico's claim suggests that the reason sympatico's systems
discard/ignore incoming email addressed to
non-existent-address@sympatico.ca is that that's the way the "MSN
enhanced email platform" is designed to work. Is that right?

If so -- why is MS taking this obviously wrong approach, rather than the
correct one you've outlined above?

>>Anyway, are you basically saying that the approach in use by sympatico
>>is a misguided way to prevent spammers from learning valid addresses?

>It's not misguided in the sence that spammers in fact can't guess mail
>adresses.

Uhhh -- not sure you understood/remembered: What sympatico is doing is
discarding/ignoring incoming email addressed to
non-existent-address@sympatico.ca. So I think the answer to my question
is: "yes, sympatico's approach (discarding/ignoring) is misguided
because it's unnecessary for foiling the spammer attack referred to."

Re: Should ISP"s send bounceback on mail to non-existent address?

> My ISP is Sympatico.ca, one of Canada's major ones. Recently I deleted
> an email address I had there, but then found that messages sent to that
> obsolete address don't produce a bounceback message telling the sender
> the address doesn't exist.
>
> Now Sympatico is telling me that that's the way it's supposed to be --
> it's an anti-spam measure. Their message is shown below.

Generally, the MX (host that receives mail) for a domain can immediately
determine whether a recipient address is valid, perhaps by a site-wide
database lookup. With that immediate determination, the MX can then return
an error to the peer (spammer?) and not even allow an email transfer. This
is the best, and proper, configuration. The sender will then receive an
informative and relevant bounce message generated by their own mail server.

However some sites can not succeed in doing this, meaning they are
configured to accept all incoming mail because they can not immediately
determine whether the RCPT TO address is valid. If the address is then
found to be invalid, the site might bounce the email back to the "sender's
address" (which may be forged) and this is an ugly situation that leads to
abuse and annoying bounces to forged addresses.

In general, I think an ISP that accepts all mail transfers and passes up
the opportunity to give a meaningful failure message is creating
unnecessary problems. Invalid email addresses should bounce, and the only
way to safely bounce is if the initial mail transfer is rejected by MX.

--
Jem Berkes
Software design for Windows and Linux/Unix-like systems
http://www.sysdesign.ca/

Re: Should ISP"s send bounceback on mail to non-existent address?

On Wed, 29 Jun 2005 09:01:41 -0400, "Uriel Wittenberg"
wrote:

>>By monitoring the number of good and bad recipients per sending IP for
>>those IP's which go above a certain theresold of bad versus good it's
>>very easy to detect such attacks. I.e. we ignore such IP's at the TCP
>>level for a complete week if the firmware triggers that it's enough
>>from a given IP.
>
>Ahh! That's what I was looking for.
>
>So, to reiterate:
>
>-------------------------
>- Sympatico has told me that it simply DISCARDS AND IGNORES any incoming
>email addressed to non-existent-address@sympatico.ca.
>
>- Its justification: If it somehow indicated to a sender when a
>recipient didn't exist, a spammer could use that to guess valid
>addresses. The spammer would do that by sending to a@sympatico.ca,
>b@sympatico.ca, c@sympatico.ca, etc. Whenever there was no notice of
>non-existence, he'd know he'd guessed a valid address.
>
>- The above justification is nonsense since, as above, the proper way
>for sympatico to prevent this kind of spammer action is to monitor
>sending IP's and ignore those with excess bad/good ratios.

Well, "the propper way" is of course a matter of one's view. It's
surely "propper" in that this aproach does not create any problematic
cases. That said, valid senders get their propper bounce, attackers
get blocked.

The downside of this is that probably many mail server software does
not implement such a feature. On the other hand, ISP's as big as
sympatico should be able to buy/hire/get this functionality quite
easily. So from this perspective yes the justification IS nonsense.

>-------------------------
>
>However, I'm still not clear about sympatico's claim that "Microsoft has
>implemented this feature [in the MSN enhanced email platform] as a spam
>prevention method."
>
>(I gather the "MSN enhanced email platform" is MS software that
>sympatico uses for processing email.)

I figure they use MS Internet Information Service probably along with
Exchange Server 5.5 or older. The newer Exchange servers (surprize
surprize) finally CAN validate the recipient during the SMTP
transaction. To my knownleadge, they do not implement rumpelstilz
attack detection though. So, if cou call the lack of a feature
"enhenced" technology then this statement is probably right :-)

IMHO that's just marketing fuzz to obfuscate the embarassing fact that
their first incarnations of mailserver software is utterly broken in
many places. Note, don't ge me wrong, I don't think that the GROUPWARE
part of Exchange is that bad. Their SMTP implementation - especially
the older ones - are seriousely broken though.

>Sympatico's claim suggests that the reason sympatico's systems
>discard/ignore incoming email addressed to
>non-existent-address@sympatico.ca is that that's the way the "MSN
>enhanced email platform" is designed to work. Is that right?

Yes, it's designed to work this way because they are using a layered
aproach. The original Internet informatoin Service which deals with
SMTP has no knownleadge about users hence MUST accept all mail.
Exchange server then reads the mails in a seperate step and then
generates the bounces (or as in the case of sympatico and in clear
violation of the RFC's drops such mail). Again, newer incarnations of
the internet information service are aparently able to verify the
recipients address during the SMTP phase hence can genreate those 5xx
responses. Since this still leaves the possibility of rumpelstilz
attacks, it remains unclear if sympatico would also "drop" mails to
unknown recipients if their servers were able (or maybe even are able)
to verify the recipients during the SMTP phase or if they just use
this argumentation due to the pure lack of the recipeint verification
feature.

>If so -- why is MS taking this obviously wrong approach, rather than the
>correct one you've outlined above?

Again, "correct" is a matter of point of view, but I figure they had
the problem because they were splitting the task between "internet
information service" and Exchange server. It's beond me why they did
it this way, but I figure if you take enough software developpers to
design a system this is what happens...

[snip]
>Uhhh -- not sure you understood/remembered: What sympatico is doing is
>discarding/ignoring incoming email addressed to
>non-existent-address@sympatico.ca. So I think the answer to my question
>is: "yes, sympatico's approach (discarding/ignoring) is misguided
>because it's unnecessary for foiling the spammer attack referred to."

Yes, it IS misguided if they silently drop the mail cause this is a
violation of the RFC which clearly states that once a server accepts a
mail by returning a 220 code after the data phase it takes
responsability for it's delivery. If it cant be delivered, it takes
the responsability to inform the sender with a propper bounce. However
this part is questionable these days. It's clear that the RFC by
itself is a bit outdated by the reality with regard to spam and worm
mails. My previousely sugested way of dealing with the problem (i.e.
recongnizing rumpelstilz attacks and deal with them) is of course not
based on any RFC - it's just a good way to deal with the problems
faced these days. I admit though that if one is not having the
possibilities to detect rumpelstilz attacks and expericnes such
attacks might revert to the way sympatico is dealing with it. It's
just embarassing that an ISP of that size does not implement counter
measures. Even if it should turn out that they are using Micrsoft
servers they could either hook up some security apliance in front of
them or use different e-mail server software or switch to Linux based
servers. Since I'm not a sympatico customer, I don't know if they
probably offer groupware functionaltiy to their customers. If they do,
transition to another mailserver software would be difficult. It still
would leave the option of hooking up propper security appliances in
front of their servers.

HTH

Markus

Re: Should ISP"s send bounceback on mail to non-existent address?

>The downside of this is that probably many mail server software does
>not implement such a feature.

Hi Markus,

Again I'm having trouble understanding your meaning. I *think* you're
saying there is NO downside (to the approach of ignoring sending IP's
with excess bad/good ratios).

What do those "many" server software systems do? Is it common for ISP's
to simply ignore/discard incoming mail to nonexistent addresses, with no
indication to sender?

>I figure they use MS Internet Information Service probably along with
>Exchange Server 5.5 or older. The newer Exchange servers ... To my
>knownleadge ... do not implement rumpelstilz attack detection.

I'm totally confused. You're guessing, on the basis that sympatico
doesn't detect rumpelstilz attacks, that sympatico uses old Exchange
Server software. But then you say the newer versions of the software
don't detect rumpelstilz attacks either.

(I'm assuming "rumpelstilz attacks" are those in which a spammer sends
to addresses a, b, c, etc., and infers from server responses which are
valid and which aren't.)

>Again, newer incarnations of [MS Internet Information Service] are
>aparently able to verify the recipients address during the SMTP phase
>hence can genreate those 5xx responses. Since this still leaves the
>possibility of rumpelstilz attacks

So sympatico is RIGHT: Sympatico ignores/discards incoming mail to
nonexistent addresses because they're using MS software, and the only
alternative that software gives them is to expose themselves to
rumpelstilz attacks.

>I figure [sympatico] had the problem because they were splitting the
>task between "internet information service" and Exchange server. It's
>beond me why they did it this way

You've already said MS Internet Information Service does not offer the
capability of detecting rumpelstilz attacks. So I don't see what it has
to do with "splitting."

>Even if it should turn out that they are using Micrsoft servers they
>could either hook up some security apliance in front of them or use
>different e-mail server software or switch to Linux based servers.

I'm guessing alternatives 2 and 3 would be non-trivial. Maybe #1 is
easy?

What I'm not getting out of this discussion is clarity in terms of a
viable counter-argument to sympatico. They're apparently not in breach
of any formal internet standard or protocol. I can still argue it's
stupid to ignore/discard incoming mail to nonexistent addresses (sent by
legit senders). But only if there's a not-huge means of operating more
intelligently.

Re: Should ISP"s send bounceback on mail to non-existent address?

>the MX can then return an error to the peer (spammer?) and not even
>allow an email transfer. This is the best, and proper, configuration.

But you haven't addressed sympatico's justification for not doing this:
It helps spammers build their databases of valid addresses.

Re: Should ISP"s send bounceback on mail to non-existent address?

> But you haven't addressed sympatico's justification for not doing this:
> It helps spammers build their databases of valid addresses.

In my experience, the majority of spammers do not clean up their lists any
way. In my server logs I always see attempts to deliver to the same non
existent addresses; obviously spammers are not cleaning up their lists or I
wouldn't see spam attempts to these 5 year old addresses. Once I even re-
enabled an address that had been inactive for nearly 10 years. Immediately,
spam started flooding through.

Spammers do however use dictionary attacks in which they will try to
deliver to a large number of guessed addresses. But I don't see how
Sympatico's behaviour thwarts that, since they will accept all of that spam
and of course deliver to the valid addresses any way.

The ISP should weigh the convenience and expected behaviour of letting
people see real bounces ("sorry, this address doesn't exist") against the
chance that they are helping spammers build their lists.

--
Jem Berkes
Software design for Windows and Linux/Unix-like systems
http://www.sysdesign.ca/

Re: Should ISP"s send bounceback on mail to non-existent address?

>> But you haven't addressed sympatico's justification for not doing
>> this: It helps spammers build their databases of valid addresses.

Another way of saying my point from my last post is that spammers do not
seem to care what is a valid versus invalid address. They will try as many
addresses as they can.

--
Jem Berkes
Software design for Windows and Linux/Unix-like systems
http://www.sysdesign.ca/

Re: Should ISP"s send bounceback on mail to non-existent address?

Hi Uriel

I'm truly sorry that I'm not clear enough. English is not my native
language (as you probably found out anyway). I this time will provide
less explanations and very clear answers/statemets. Please ask
thereafter if you don't understand something.

>>The downside of this is that probably many mail server software does
>>not implement such a feature.
>
>Hi Markus,
>
>Again I'm having trouble understanding your meaning. I *think* you're
>saying there is NO downside (to the approach of ignoring sending IP's
>with excess bad/good ratios).

Yes, there is NO downside.

>What do those "many" server software systems do? Is it common for ISP's
>to simply ignore/discard incoming mail to nonexistent addresses, with no
>indication to sender?

The feature to DETECT rumpelstilz attacks (= e-mail address guessing)
is not widely available. For an ISP as big as sympatico it should be
easy to get. We would be more than happy to implement it for them no
matter what kind of e-Mail infrastructure they currently use.

>>I figure they use MS Internet Information Service probably along with
>>Exchange Server 5.5 or older. The newer Exchange servers ... To my
>>knownleadge ... do not implement rumpelstilz attack detection.
>
>I'm totally confused. You're guessing, on the basis that sympatico
>doesn't detect rumpelstilz attacks, that sympatico uses old Exchange
>Server software. But then you say the newer versions of the software
>don't detect rumpelstilz attacks either.

My guessing is because you mentioned MS technologies. The only MS
technology with regard to mail is internet information service on top
of which Exchange is running. Informing the sender about an non
existing mail address is ONE feature, detecting rumpelstilz attacks
(that said detecting the abusie of the former feature) is yet another
feature. Both features are lacking in older MS internet infromation
service whereas the first one is now finally present but the second
one is still missing.

>(I'm assuming "rumpelstilz attacks" are those in which a spammer sends
>to addresses a, b, c, etc., and infers from server responses which are
>valid and which aren't.)

yes

>>Again, newer incarnations of [MS Internet Information Service] are
>>aparently able to verify the recipients address during the SMTP phase
>>hence can genreate those 5xx responses. Since this still leaves the
>>possibility of rumpelstilz attacks
>
>So sympatico is RIGHT: Sympatico ignores/discards incoming mail to
>nonexistent addresses because they're using MS software, and the only
>alternative that software gives them is to expose themselves to
>rumpelstilz attacks.

yes, with that software, but there is no law that would bind them to
not either add modules/technology to this software implementing this
feature, replace the software or hook up some appliances in front of
their existing servers to get rid of the problem.

>>I figure [sympatico] had the problem because they were splitting the
>>task between "internet information service" and Exchange server. It's
>>beond me why they did it this way
>
>You've already said MS Internet Information Service does not offer the
>capability of detecting rumpelstilz attacks. So I don't see what it has
>to do with "splitting."

Usually a mailserver is monolytic in that it handles SMTP transactions
but also manages useres and domains in one functinal unit. In the MS
world these things are splitted up into two functinal units. The MS
internet information service is the one that handles SMTP transations
but (in older incarnations) did not know abuout the local e-mail
acounts. Exchange then used the mails that were recived by the
internet information server and deliverd to local acounts, detecting
non existing users and act by either dropping the mail (sympaticos way
to deal with this) or by generating a bounce to the original sender.

The spliting of the functinal units is the thing that is not
inteligent in that the reciveing module is not in the position to
validate user accounts. Again, this got changed by the time Windows
server 2003 became available where those two functinal units now
finally are interacting more closely.

>>Even if it should turn out that they are using Micrsoft servers they
>>could either hook up some security apliance in front of them or use
>>different e-mail server software or switch to Linux based servers.
>
>I'm guessing alternatives 2 and 3 would be non-trivial. Maybe #1 is
>easy?

#1 is as easy as ordering the propper device. There are at least 5
different suppliers of such appliances which can do this that come to
mind.

>What I'm not getting out of this discussion is clarity in terms of a
>viable counter-argument to sympatico. They're apparently not in breach
>of any formal internet standard or protocol.

That's not true. They are actually breaking the SMTP protocol
specification which clearly states that once a server accepts a mail
it takes responsibility over it to deliver it or then must inform the
sender about the failure.

>I can still argue it's
>stupid to ignore/discard incoming mail to nonexistent addresses (sent by
>legit senders). But only if there's a not-huge means of operating more
>intelligently.

Again, as I outlined already, the more inteligent way of dealing with
this is:

a) do not accept mail for non existing users by immediately informing
the sender about a non existing account.

b) implement technology which is able to detect rumpelstilz attacks
and block or ignore the attackers.


I hope things are more clear now.

Markus

Re: Should ISP"s send bounceback on mail to non-existent address?

Markus,

That's ok! Yes, I could see you're not a native English speaker. But
thanks to your perseverance and patience, you've really made most of
this quite clear for me. I appreciate your help!

The following remain unclear:

#1: You didn't directly answer my question:

>What do those "many" server software systems do? Is it common for ISP's
>to simply ignore/discard incoming mail to nonexistent addresses, with
>no
>indication to sender?

I *think* the answer is that it's rather unusual for ISP's to do what
sympatico is doing. (But I'm not sure.)

You said "The feature to DETECT rumpelstilz attacks (= e-mail address
guessing) is not widely available." My guess is that, for most ISP's, if
they don't have the feature, then they don't attempt to defend against
rumpelstilz attacks. (I.e. if they want to defend against rumpelstilz
attacks, they do it by getting software to detect them, rather than
adopting sympatico's dumb approach.)


#2:
You write that alternative solution #1 for sympatico ("if they are using
Micrsoft servers, hook up some security apliance in front of them") "is
as easy as ordering the propper device. There are at least 5 different
suppliers of such appliances which can do this that come to mind."

Sympatico told me they're stuck with their approach because they use MS
software. If they can indeed add some device/system in front of the
MS-ware to block rumpelstilz attacks, then their position is wrong. If
you would NAME a few of those suppliers, along with the relevant
product, then that's something I could present to sympatico in response.


#3:
>They are actually breaking the SMTP protocol specification which
>clearly states that once a server accepts a mail it takes
>responsibility over it to deliver it or then must inform the sender
>about the failure.

I misspoke in my earlier post (saying sympatico apparently not in breach
of any formal internet standard). I had in mind what you'd written, that
the applicable part of the RFC "is questionable" and "a bit outdated by
the reality with regard to spam and worm mails."

Again, my question in #1 above arises. OK, RFC dictates that a server is
responsible for informing a sender if mail can't be delivered. Is this
requirement generally accepted, or is it not unusual for serious ISP's
to ignore it?

If this RFC requirement is generally accepted, how is it formally
referred to? (RFC 2821? Subsection? Clause number? Whatever.) Again, for
purposes of responding to sympatico.

Re: Should ISP"s send bounceback on mail to non-existent address?

>I don't see how Sympatico's behaviour thwarts [dictionary attacks],
>since they will accept all of that spam and of course deliver to the
>valid addresses any way.

I'd guess it depends on the spammer. Some, as you're saying, will ignore
server responses. But others, I'd expect, would avail themselves of
responses that indicate which addresses are good and which are bad.
Presumably they send spam repeatedly, many times, to addresses on their
lists. Why continue to send to the >99% of addresses that are invalid?
It's inefficient.

Re: Should ISP"s send bounceback on mail to non-existent address?

Hi Uriel

Ok, here we go

>Markus,
>
>That's ok! Yes, I could see you're not a native English speaker. But
>thanks to your perseverance and patience, you've really made most of
>this quite clear for me. I appreciate your help!
>
>The following remain unclear:
>
>#1: You didn't directly answer my question:
>
>>What do those "many" server software systems do? Is it common for ISP's
>>to simply ignore/discard incoming mail to nonexistent addresses, with
>>no
>>indication to sender?
>
>I *think* the answer is that it's rather unusual for ISP's to do what
>sympatico is doing. (But I'm not sure.)

Yes, it's unusual.

>You said "The feature to DETECT rumpelstilz attacks (= e-mail address
>guessing) is not widely available." My guess is that, for most ISP's, if
>they don't have the feature, then they don't attempt to defend against
>rumpelstilz attacks. (I.e. if they want to defend against rumpelstilz
>attacks, they do it by getting software to detect them, rather than
>adopting sympatico's dumb approach.)

Yes, most of them probably don't attempt to defend rumpelstilz
attacks.

I don't know why though and think it's a bad idea not to take care of
this problem. We observed a significant number of connections which
were coming and going all times. Our investigations clearly showed
that all of those cases we looked at were viruses and not spammers
tryign to guess mail adresses. The proof is simple, if we accepted the
mail after a couple of attemps, the payload always was a worm, hence
we decided to do something against it in our product. I know for sure
that we are not the only ones doing so. I also know for sure that the
SMTP server service available from MS does not have this feature.

>#2:
>You write that alternative solution #1 for sympatico ("if they are using
>Micrsoft servers, hook up some security apliance in front of them") "is
>as easy as ordering the propper device. There are at least 5 different
>suppliers of such appliances which can do this that come to mind."
>
>Sympatico told me they're stuck with their approach because they use MS
>software. If they can indeed add some device/system in front of the
>MS-ware to block rumpelstilz attacks, then their position is wrong. If
>you would NAME a few of those suppliers, along with the relevant
>product, then that's something I could present to sympatico in response.

We are a manufacturer of such apliances but so far we only target the
SOHO market (up to 200 e-mail user accounts which is obviousely way
out of the scope of what sympatico must deal with). I therefore have
to list competitors. Anyways,. I do so in the order I think I would
use them, but limit myself to two of them - I hope you understand.

a) PineApp Mail-SeCure -> www.pineapp.com
b) Barracuda Spam Firewall -> www.barracudanetworks.com

We will offer a solution to this and other problems in the near future
though.

>#3:
>>They are actually breaking the SMTP protocol specification which
>>clearly states that once a server accepts a mail it takes
>>responsibility over it to deliver it or then must inform the sender
>>about the failure.
>
>I misspoke in my earlier post (saying sympatico apparently not in breach
>of any formal internet standard). I had in mind what you'd written, that
>the applicable part of the RFC "is questionable" and "a bit outdated by
>the reality with regard to spam and worm mails."
>
>Again, my question in #1 above arises. OK, RFC dictates that a server is
>responsible for informing a sender if mail can't be delivered. Is this
>requirement generally accepted, or is it not unusual for serious ISP's
>to ignore it?

It's surely genreally accepted. Sympaticos way to deal with this is
something I would not accept for myself. Typos are not so unusual and
loosing a customer because of this is not funny. It's probably not the
same with friends, but in a business envireonement clearly not
acceptable to me.

>If this RFC requirement is generally accepted, how is it formally
>referred to? (RFC 2821? Subsection? Clause number? Whatever.) Again, for
>purposes of responding to sympatico.

RFC 2821 Section 3.3 Mail Transactions on page 17. I quote here the
relevant part:

"If the recipient is known not to be a deliverable address, the SMTP
server returns a 550 reply"

There is no "may" or something. Not sending a 550 reply in this
situation is in clear violation of the RFC. The only point of
discussion is the text "is KNOWN not to be". From the point of view of
stupid internet informatoin service the user is in fact generally
"unknown" but IMHO this is stressing it quite a bit.

Then the complete section "6.1 Reliable Delivery and Replies by Email"
applies here. It's a bit too long to reproduce it here. Since you
mention the propper RFC I figure you have it already hence can read it
by yourself.

It's section 6.1 which I had in mind when I said "it's questionable".
The point is however that if the RCPT TO is handled propperly, there
is no dilemma in 6.1. A (rumpelstilz) attacker never would reach the
stage anyways (unless he is lucky enough to guess a real mail address
which is likely to be rare and impossible if rumpelstilz counter
measures are in place).

So let me once more summarize:

1) It's a fact that there are worms out there performing rumpelstilz
attacks. It's a fact that there are sites which are heavily targeted
by this.

2) It's very stupid to accept all mails not verifying the recipient
because of the following reasons:

2a) the worms will not go away. They will CUMULATE over time to a
degeree I'm sure will hog down any mailserver and consume lot's of
bandwidth.

2b) Because the e-mail address guessing so far seems to be widespread
only with worms where it's questionable if the result of a positive
guess really can be comunicated to a spammer or only serves the
purpose of self propagation.

2c) the argumentation sympatico uses seems to be weak since the target
it should reach (prevent spammers from e-mail address guessing aka.
run a rumpelstilz attack) is not reached because such attacks are NOT
widespread outside of the worm context.

2d) worms are genreally bigger than average mail. Hence accepting them
even though it would be easy to detect (no such user) is stupid for
the obivious waste of resources.

- It's wrong that e-mail address guessing (rumpelstilz attack) could
not be safely detected.

- It's wrong not to reply with 550 to an RCPT TO denoting a non
existing user

- It's a fact that the fewest resources are used (in terms of
bandwidth processing power and storeage) if RCPT TO is dealth with
properly and a rumpelstilz attack detection technology is in place.
It's also a fact that this at the same time solves your original
problem - your friends get a feedback if the mail address you used in
the past is no longer operated. This at the same time also solves the
problem symtapico is claming to have - not disclosing valid mail
addresses

- I can't tell wether sympatico uses their argumentation because they
use the MS software which is having this limitation. I can't tell
wether they are clueless with regard to potential solutions (very hard
to belive though) or if they are simply unwilling. Might be they don't
want to spend the money to upgrade their older MS servers and or get
security apliances/solutions. Might be they hide behind this Microsoft
advice thing only. I think I now have shown clear enough why this MS
advice is wrong or at least totally outdated.

HTH

Markus

Re: Should ISP"s send bounceback on mail to non-existent address?

In article , Markus Zingg wrote:
> You should care WHO is generateing the bounce. If it's sympatico, then
> every one whoes mail adress was forged will get a bounce and this bounce
> is then simply SPAM. That's not possible if the sending server

Sympatico could check for an SPF record first, and only bounce if the
address is not forged.

--
--Tim Smith

Re: Should ISP"s send bounceback on mail to non-existent address?

Uriel Wittenberg wrote:

> I'd guess it depends on the spammer. Some, as you're saying, will ignore
> server responses. But others, I'd expect, would avail themselves of
> responses that indicate which addresses are good and which are bad.
> Presumably they send spam repeatedly, many times, to addresses on their
> lists. Why continue to send to the >99% of addresses that are invalid?

In my experience, spammers seldom clean their lists. We still get
lots of spam to an address at roaringpenguin.com that is not valid
and has _never_ been valid.

Spamware ignores return codes (success or failure)

> It's inefficient.

Actually, no. It's more efficient to blast blindly that to use any
kind of finesse.

Regards,

David.

Re: Should ISP"s send bounceback on mail to non-existent address?

Hi Markus,

Indeed, RFC 2821 (http://www.faqs.org/rfcs/rfc2821.html ) doesn't seem
very ambiguous on this point.

Section 3.3: "If the recipient is known not to be a deliverable address,
the SMTP server returns a 550 reply"

Section 6.1: "If there is a delivery failure after acceptance of a
message, the receiver-SMTP MUST formulate and mail a notification
message."

Unfortunately you've lost me again with this:

>It's very stupid to accept all mails not verifying the recipient
>because ... the e-mail address guessing so far seems to be widespread
>only with worms where it's questionable if the result of a positive
>guess really can be comunicated to a spammer or only serves the purpose
>of self propagation.

??

I guess "positive guess" means a guess that produces a valid email
address. So what do you mean by "it's questionable [whether] the result
of a positive guess really can be comunicated to a spammer"?

>the argumentation sympatico uses seems to be weak since the target it
>should reach (prevent spammers from e-mail address guessing aka. run a
>rumpelstilz attack) is not reached because such attacks are NOT
>widespread outside of the worm context.

Why is sympatico's argument any weaker when worms rather than spam are
involved? In both cases, the sender benefits by being able to prune his
address list. Is it because worms work independently of each other, and
collectively don't have the intelligence that a single spammer might?
Could worms not coordinate?

>I can't tell wether sympatico uses their argumentation because they use
>the MS software which is having this limitation.

I thought you DID tell: Even if they're using MS software, they can
*supplement* it with a separate device/system to block out rumpelstilz
attacks.

>Might be they don't want to spend the money to upgrade their older MS
>servers

And couldn't that separate device/system block rumpelstilz attacks even
if older MS systems are in use?

Re: Should ISP"s send bounceback on mail to non-existent address?

>> It's inefficient.

>Actually, no. It's more efficient to blast blindly that to use any
>kind of finesse.

Hmm. Maybe you're right, I don't know.

Re: Should ISP"s send bounceback on mail to non-existent address?

On Fri, 1 Jul 2005 23:29:05 -0400, "Uriel Wittenberg"
wrote:

>>> It's inefficient.
>
>>Actually, no. It's more efficient to blast blindly that to use any
>>kind of finesse.
>
>Hmm. Maybe you're right, I don't know.

He's wrong. ISPs do use counter measures. For example, Comcast delays
the SMTP response to an invalid address. Others *do* do checks on the
ratio of valid vs. invalid addresses and react. A list of valid
addresses at a large domain is valuable. Developing such a list is good
business for an address seller. Buying such a list rather than blindly
blasting to guessed addresses makes sense for a spammer.
On one hand Sympatico is protecting their customers, but on the other
hand they are delivering crippled email service. From the point of view
of Sympatico customers in general, I'm not sure that the bad outweighs
the good. Some ISPs have used an "accept, then bounce" strategy to
prevent easy harvesting of valid addresses. But then they send bounces
to forged addresses in spam and get themselves blocked as "backscatter"
spammers. Spam has really fucked things up, no matter how you deal with
it there's going to be a downside.

Steve Baker

Re: Should ISP"s send bounceback on mail to non-existent address?

>Unfortunately you've lost me again with this:
>
>>It's very stupid to accept all mails not verifying the recipient
>>because ... the e-mail address guessing so far seems to be widespread
>>only with worms where it's questionable if the result of a positive
>>guess really can be comunicated to a spammer or only serves the purpose
>>of self propagation.
>
>??
>I guess "positive guess" means a guess that produces a valid email
>address. So what do you mean by "it's questionable [whether] the result
>of a positive guess really can be comunicated to a spammer"?

Yes, your guess is right.

Most worms are written so as they can spread themselfes as fast as
possible. So, the rumpelstilz tactic is for sure choosen to reach this
target. It's known that some wormes USED TO comunicate the found
adresses back to spammers, but it's also clear that the comunication
channel back to the spammer gets more and more dangerous/flakey as
time goes by. Remember, spamming unfortunately seems to be tolerated
here and there while being responsible/involved in the creation of a
worm seems to be treated differently. Since with all those trojanized
PC's around it became much easier for spammers to collect mail
adresses I figure they do not very often reallly insist (care) in
getting mail adresses found by worms in rumpestilz attacks (since the
sucess rate will be very low) if the alternative to visit trojanized
PCs and download databases/contact lists is so much easier.

So, provided above conclusion is true (which evidence seems to show)
rumpelstilz attacks made do in the vast majority of all cases not
serve the purpose of comunicating the found addresses back to
spammers, but serve the purpose of the worms propagating themselfes.

As a result, replying 550 at the RCPT TO phase IS in fact enough for
these cases where one can live with the waste of resources/payload
created by those worms connecting over and over again. IMHO this
aproach (replying 550 to non existing adresses but not having
rumpestilz counter measures in place) is the most widely used
"configuration". Having aditional rumpelstilz countermeasures in place
at the same time is of course better because it at the same times
saves resources and secondly also prevents a real spammer rumpestilz
attack should it really ever happen.

>>the argumentation sympatico uses seems to be weak since the target it
>>should reach (prevent spammers from e-mail address guessing aka. run a
>>rumpelstilz attack) is not reached because such attacks are NOT
>>widespread outside of the worm context.
>
>Why is sympatico's argument any weaker when worms rather than spam are
>involved? In both cases, the sender benefits by being able to prune his
>address list. Is it because worms work independently of each other, and
>collectively don't have the intelligence that a single spammer might?
>Could worms not coordinate?

See above, because it SEEMS that worms only very rarlely comunicate
back to the spammers.

>>I can't tell wether sympatico uses their argumentation because they use
>>the MS software which is having this limitation.
>
>I thought you DID tell: Even if they're using MS software, they can
>*supplement* it with a separate device/system to block out rumpelstilz
>attacks.

There is no rumpelstilz counter measures available with MS software.
There IS the possiblity to validate recipients with Windows server
2003 and up based installations. Previous incarnations don't have any
of the two.

>>Might be they don't want to spend the money to upgrade their older MS
>>servers
>
>And couldn't that separate device/system block rumpelstilz attacks even
>if older MS systems are in use?

Yes, the devices listed (I'm sure with at least the first one) does
have the capability.

Markus

Re: Should ISP"s send bounceback on mail to non-existent address?

Ohhhhhhh.....

You're saying rumpelstilz attacks usually involve worms; and worms are
more dicey, legally, for their originators; so worms don't tend to
report back which addresses are valid; so ISP's don't have to worry much
about issuing a response saying which addresses are valid and which
aren't, even during a rumpelstilz attack, because that information won't
reach the attack's originator.

>>>I can't tell wether sympatico uses their argumentation because they
>>>use
>>>the MS software which is having this limitation.

>>I thought you DID tell: Even if they're using MS software, they can
>>*supplement* it with a separate device/system to block out rumpelstilz
>>attacks.

>There is no rumpelstilz counter measures available with MS software.

No, it *is* available as a separate, non-MS add-on ("supplement").

>>>Might be they don't want to spend the money to upgrade their older MS
>>>servers

>>And couldn't that separate device/system block rumpelstilz attacks
>>even
>>if older MS systems are in use?

>Yes, the devices listed (I'm sure with at least the first one) does
>have the capability.

So, in other words, your "might be" above would not explain why
sympatico doesn't detect rumpelstilz attacks. Upgrading their older MS
servers would not be required. (I assume that even with the older MS
servers, they could somehow load the list of their valid addresses into
the front-end attack detection device, perhaps on a weekly basis.)

Re: Should ISP"s send bounceback on mail to non-existent address?

>Spam has really fucked things up, no matter how you deal with it
>there's going to be a downside.

What's the downside of Markus's solution (detecting and thwarting
rumpelstilz attacks)?

Re: Should ISP"s send bounceback on mail to non-existent address?

Steve Baker wrote:

> On Fri, 1 Jul 2005 23:29:05 -0400, "Uriel Wittenberg"
> wrote:

>>>> It's inefficient.

>>>Actually, no. It's more efficient to blast blindly that to use any
>>>kind of finesse.

>>Hmm. Maybe you're right, I don't know.

> He's wrong. ISPs do use counter measures.

Those countermeasures are useless.

> For example, Comcast delays
> the SMTP response to an invalid address.

Sendmail has that option. It's useless.

Do you know how modern spamware works? Modern ratware programs can
run tens of thousands of simultaneous sending threads. (Remember, a
ratware program can be designed radically differently from a
legitimate SMTP server, which needs to worry about reliable delivery.)

The fact that the 5,000 threads talking to Comcast's servers are each
delayed by (say) 10 seconds means the entire spam run takes an
extra 10 seconds. Big deal.

> Others *do* do checks on the ratio of valid vs. invalid addresses
> and react. A list of valid addresses at a large domain is valuable.

True. See above. Invalid recipient delays are useless unless they can
somehow detect a coordinated attack, and make a coordinated response.
Given that serious spammers commandeer thousands of compromised PC's to
do their spam runs, recognition of a coordinated attack is extremely
difficuly.

> On one hand Sympatico is protecting their customers, but on the other
> hand they are delivering crippled email service.

I used to be a Sympatico customer. Trust me when I say they're clueless. :-)

Regards,

David.

Re: Should ISP"s send bounceback on mail to non-existent address?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-17222-1120349841-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

David F. Skoll writes:

> Do you know how modern spamware works? Modern ratware programs can
> run tens of thousands of simultaneous sending threads. (Remember, a
> ratware program can be designed radically differently from a
> legitimate SMTP server, which needs to worry about reliable delivery.)
>
> The fact that the 5,000 threads talking to Comcast's servers are each
> delayed by (say) 10 seconds means the entire spam run takes an
> extra 10 seconds. Big deal.

Limit incoming connections to a max four or five from the same IP address or
netblock (this also has a nice side effect of throttling constipated Qmail
senders, that just had a major bowel movement).

Zombied trojans you say? There are a couple of blacklists that do a fairly
good job of maintaining a comprehensive trojan shitlist.



--=_mimegpg-commodore.email-scan.com-17222-1120349841-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCxy6Rx9p3GYHlUOIRAlqBAJwJ0PqgZTJAewMHK+dbDzwlfp9Z/ACc DYAn
2bYGsszZlMC+6xacE9TyPUo=
=0DgP
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-17222-1120349841-0002--

Re: Should ISP"s send bounceback on mail to non-existent address?

Sam wrote:

> Limit incoming connections to a max four or five from the same IP address
> or netblock (this also has a nice side effect of throttling constipated
> Qmail senders, that just had a major bowel movement).

That can be effective. Or it can hurt if you're a large domain with
lots of users who expect mail from hotmail.

> Zombied trojans you say? There are a couple of blacklists that do a
> fairly good job of maintaining a comprehensive trojan shitlist.

Unfortunately, the RBL's are necessarily a step behind.

By the way, I have pretty solid evidence that spammers don't clean
their lists. I met a guy who runs Nortel's internal anti-spam system.
The old BNR domain ("bnr.ca") had been dormant for a year. In other words,
there were _no_ MX records for bnr.ca and _no_ machines were configured
to accept mail for that domain.

Just out of curiosity, he switched bnr.ca back on to see what would
happen. What happened was 100K messages/day, all spam.

--
David.

Re: Should ISP"s send bounceback on mail to non-existent address?

>I used to be a Sympatico customer. Trust me when I say they're
>clueless. :-)

It's certainly plausible. But from what you're saying --

>Given that serious spammers commandeer thousands of compromised PC's to
>do their spam runs, recognition of a coordinated attack is extremely
>difficuly.

--it sounds like there's really nothing Sympatico could do to thwart
dictionary attacks.

So what should they do? Not attempt to do so? Are you saying Markus's
suggested detection strategy is pointless? Or worthwhile since it'll
prevent *some* of the attacks?

Re: Should ISP"s send bounceback on mail to non-existent address?

Uriel Wittenberg wrote:

> --it sounds like there's really nothing Sympatico could do to thwart
> dictionary attacks.

That is correct.

> So what should they do? Not attempt to do so?

Yup. It's a waste of resources.

> Are you saying Markus's
> suggested detection strategy is pointless? Or worthwhile since it'll
> prevent *some* of the attacks?

Detecting dictionary attacks from a small number of machines is worthwhile,
because you can block their traffic. Simple countermeasures like terminating
connections after N bad RCPT commands (and possibly firewalling off the
offending machine for a few minutes) are worthwhile, because they're
easy to do and don't bother legitimate senders.

Attempting to *prevent* dictionary attacks by violating RFCs is not
good practice, because the "cure" is worse than the disease.

By the way, I've heard rumours that the *real* reason MSFT didn't validate
RCPT commands was that their Active Directory server would fall over under
the load of a dictionary attack. :-) Sounds possible to me!

Regards,

David.

Re: Should ISP"s send bounceback on mail to non-existent address?

Thanks for your advice, David.

Re: Should ISP"s send bounceback on mail to non-existent address?

On Sat, 02 Jul 2005 19:30:22 -0400, "David F. Skoll"
wrote:

>> For example, Comcast delays
>> the SMTP response to an invalid address.
>
>Sendmail has that option. It's useless.
>
>Do you know how modern spamware works? Modern ratware programs can
>run tens of thousands of simultaneous sending threads. (Remember, a
>ratware program can be designed radically differently from a
>legitimate SMTP server, which needs to worry about reliable delivery.)
>
>The fact that the 5,000 threads talking to Comcast's servers are each
>delayed by (say) 10 seconds means the entire spam run takes an
>extra 10 seconds. Big deal.

Hmm. But a "spam run" isn't about sending to 5,000 addresses, is it?
How many Rcpt Tos to real addresses could be done during the 10 second
delay that a Rcpt To to a bogus address generates? I'm not sure if
we're talking about spam blocking measures, or address harvesting
measures now.
Maybe "the spammers" have, in effect, unlimited resources so that it
doesn't matter? Is that what you're saying? That still isn't quite
right, though, because zombies get "burned" (listed by CBL, etc.), and
although the spammers are always using zillions of new ones, they don't
have enough to prevent the CBL from tagging most of the spam I get as
being from a zombie. They wouldn't want to "waste time" using a zombie
to try to send to invalid addresses, they'd want to have a clean list
and try to get the spam out before the zombie of the hour made it to
the blocklists.

Steve Baker

Re: Should ISP"s send bounceback on mail to non-existent address?

Steve Baker wrote:

> Hmm. But a "spam run" isn't about sending to 5,000 addresses, is it?
> How many Rcpt Tos to real addresses could be done during the 10 second
> delay that a Rcpt To to a bogus address generates?

Just open parallel sessions. Sendmail does not coordinate the
BadRecipientThrottle between different processes.


> Maybe "the spammers" have, in effect, unlimited resources so that it
> doesn't matter? Is that what you're saying?

Pretty much. Spammers have the advantage for two reasons:

1) Ratware is concernted with mass-mailing the same (or an
algorithmically-mutated) message to millions of people. This goal is
quite different from a normal mail server, and therefore different
optimizations can be performed. The result is that unless you do
your throttling at a very low level (eg, in the operating system
network stack), the spammer can make you use up a lot more resources than
you can make him use up.

2) Serious spammers break the law, so they care nothing for taking
over thousands of compromised machines, or stealing credit card
numbers to register fake domains to get around SURBL for a few hours.

> That still isn't quite
> right, though, because zombies get "burned" (listed by CBL, etc.), and
> although the spammers are always using zillions of new ones, they don't
> have enough to prevent the CBL from tagging most of the spam I get as
> being from a zombie.

I use sbl-xbl.spamhaus.org and it catches nowhere near "most" of my spam.
Perhaps there are more aggressive or up-to-date RBLs that I'm not
aware of.

> They wouldn't want to "waste time" using a zombie
> to try to send to invalid addresses, they'd want to have a clean list
> and try to get the spam out before the zombie of the hour made it to
> the blocklists.

Perhaps, but that's not my experience. Empirical evidence (see the
BNR.CA story on another branch of the thread) seems to point to spammers
not caring much about clean lists. I bet that it's cheaper to send out
spam to 100 invalid addresses than to actually clean your list to find
the 1 in 100 that's valid.

Regards,

David.

Re: Should ISP"s send bounceback on mail to non-existent address?

On Wed, 06 Jul 2005 00:55:32 -0400, "David F. Skoll"
wrote:

>> That still isn't quite
>> right, though, because zombies get "burned" (listed by CBL, etc.), and
>> although the spammers are always using zillions of new ones, they don't
>> have enough to prevent the CBL from tagging most of the spam I get as
>> being from a zombie.
>
>I use sbl-xbl.spamhaus.org and it catches nowhere near "most" of my spam.
>Perhaps there are more aggressive or up-to-date RBLs that I'm not
>aware of.

SBL-XBL is what I use, the CBL is a subset of that, and is the most
reactive of what's a part of the SBL-XBL. "Most" is around 60-70% for
me. But I'm just an end user, I don't check in real time, I check my
email maybe a few times per day. I've been told that the "churn" for
the CBL is 200,000 - 300,000 addresses per day. I've noticed that the
CBL seems to be very time sensitive. In a days's worth of email, there
seems to be a trend; the older the spam, the more likely it was tagged
as spam by the CBL (SBL-XBL). Once I came across a period of a day or
two where the SBL-XBL was hardly catching any spam. Turned out the CBL
had taken a little vacation
The point is that zombies do get "burned".

>> They wouldn't want to "waste time" using a zombie
>> to try to send to invalid addresses, they'd want to have a clean list
>> and try to get the spam out before the zombie of the hour made it to
>> the blocklists.
>
>Perhaps, but that's not my experience. Empirical evidence (see the
>BNR.CA story on another branch of the thread) seems to point to spammers
>not caring much about clean lists. I bet that it's cheaper to send out
>spam to 100 invalid addresses than to actually clean your list to find
>the 1 in 100 that's valid.

But what does "cheaper" mean if spammers have essentially unlimited
resources? I think you're generally wrong, I think spammers would pay
for a list that was populated with mostly valid addresses rather than
send to a generated list that had a validity rate of 1% even though the
generated list was "free".
I think a "dictionary attack" is probably done by someone trying to
generate a list of addresses to sell rather that by a spammer who is
just trying to get some spam through.

Steve Baker

Re: Should ISP"s send bounceback on mail to non-existent address?

Steve Baker wrote:

>>Perhaps, but that's not my experience. Empirical evidence (see the
>>BNR.CA story on another branch of the thread) seems to point to spammers
>>not caring much about clean lists. I bet that it's cheaper to send out
>>spam to 100 invalid addresses than to actually clean your list to find
>>the 1 in 100 that's valid.

> But what does "cheaper" mean if spammers have essentially unlimited
> resources?

Spammers have essentially unlimited resources to do dumb things like
blast out e-mails. Cleaning lists requires closed-loop feedback, because
you have to know about rejections or non-delivery notifications. That's
a lot harder to do in an untraceable way.

> I think you're generally wrong, I think spammers would pay
> for a list that was populated with mostly valid addresses rather than
> send to a generated list that had a validity rate of 1% even though the
> generated list was "free".

Perhaps, but again, empirical evidence shows that many (most?) spam
runs are to very dirty lists. My small domain has about 20 valid
e-mail addresses. In just one day's spam run (July 5th), we received
752 bad RCPT commands to 192 unique bad addresses. This number has
stayed about constant for years.

> I think a "dictionary attack" is probably done by someone trying to
> generate a list of addresses to sell rather that by a spammer who is
> just trying to get some spam through.

You're probably right, but trying to thwart dictionary attacks really
doesn't make much difference to the volume of spam. And doing it in a
way that violates RFCs is just wrong.

Regards,

David.

Re: Should ISP"s send bounceback on mail to non-existent address?

>You're probably right, but trying to thwart dictionary attacks really
>doesn't make much difference to the volume of spam. And doing it in a
>way that violates RFCs is just wrong.

IMHO there is no RFC that would define how to defend a dictionary
attack, so I asume you refer to the standard SMTP defining RFC's. In
this sense, fitlering spam alone could also be seen as a violation of
RFCs in that delivery to the recipients is obviousely not granted in
all cases. IMHO this "strict" aproach is no longer possible if you
want to run mail in a useable manner these days. To put it
differently, a firewall also violates many RFC's i.e. by not letting
IP traffic trhough etc.

Keping state of sender IP's who denote invalid recipients above a
certain trigger over a certain time and then keep track of the number
of good and bad recipients, igonring / blocking such IPs if they go
above a certain limit is not risiky at all. In the above outlined
sense it is violating the RFCs, but I look more at it as some sort of
firewall which is autmatically "configured".

In the real world, we did not had any single incidence yet about a
falsely blocked sender the way we do it and we do have lot's of
servers out there.

That's of course just my opinion and well, probably the opinion of
those users whoes dictionary attack problems now are solved this way.

Markus

Re: Should ISP"s send bounceback on mail to non-existent address?

Markus Zingg wrote:

>>You're probably right, but trying to thwart dictionary attacks really
>>doesn't make much difference to the volume of spam. And doing it in a
>>way that violates RFCs is just wrong.

> IMHO there is no RFC that would define how to defend a dictionary
> attack, so I asume you refer to the standard SMTP defining RFC's.

Yes.

> In this sense, fitlering spam alone could also be seen as a
> violation of RFCs in that delivery to the recipients is obviousely
> not granted in all cases.

Our anti-spam product always returns either a 5xx status code or a
delivery-failure notification if something is blocked.

> IMHO this "strict" aproach is no longer possible if you
> want to run mail in a useable manner these days.

I disagree.

> To put it differently, a firewall also violates many RFC's i.e. by
> not letting IP traffic trhough etc.

I'm unaware of an RFC that says you MUST NOT block certain traffic.
I *am* aware of an RFC that says you MUST NOT silently discard e-mail
for a trivial reason (and I consider blackholing mail to avoid dictionary
attacks a "trivial" reason.)

> Keping state of sender IP's who denote invalid recipients above a
> certain trigger over a certain time and then keep track of the number
> of good and bad recipients, igonring / blocking such IPs if they go
> above a certain limit is not risiky at all.

Indeed. But the OP describes an ISP that silently discards *all* mail
sent to nonexistent recipients. That's highly risky; it's very easy
to make a typo. If your recipient is at Sympatico, you'll never know
if the mail made it or not.

Regards,

David.

Re: Should ISP"s send bounceback on mail to non-existent address?

>Our anti-spam product always returns either a 5xx status code or a

That's what it should. What I described (not sure if you ever read it)
does fully comply here - at least to the point where the sending host
as a whole get's blocked. I'm not sure if you are aware about this,
but in our implementation this is after quite a long period of
"patience". We shape our countermeasures so as they fit the ongoing
abuse - not always some heroic teoretical targets, but just those
things that happen all day long. With regard to dictionary attacks our
observations clearly indicate that the vast majority of them are
caused by worms trying to propagate themselves. While the pattern of
counter measures used most likely also will catch other cases, they
cause those worm sending machines to move on to other targets and this
is a huge gain in many cases bandwidth and machine resources wise.

>delivery-failure notification if something is blocked.

delivery-failure notices are a big problem these days because of
forged sender adresses. They should be avoided at almost all costs.
Configurations where mail first is acepted to then later on generate a
bounce are a huge problem. Most of the anoying backscatter these days
originate here. We therefore deliver products which allow to validate
the recipients during the SMTP session and reply with 5xx codes.
Delivery failures to external sources are only generated if the
customer intentionally configures the device not to validate the
recipients. All other delivery failures are generated towards local
users unsucessfully sending mail to remote nodes.

>> IMHO this "strict" aproach is no longer possible if you
>> want to run mail in a useable manner these days.
>
>I disagree.

That's your right. I'm expressing my opinion and experience - so do
you. You did not elaborate how you interpret the RFCs. I.e. I have a
hard time to belive though that intercepting a worm will cause your
anti spam solution to generate a bounce. If so, then I'm glad we are
not interpreting the RFC so strictly and I'm also sure the majority of
fellows over in NANAE would not like your point of view too. Again, I
have a hard time to belive that you meant it this way but maybe you
opt to clarify your opinon.

>> To put it differently, a firewall also violates many RFC's i.e. by
>> not letting IP traffic trhough etc.
>
>I'm unaware of an RFC that says you MUST NOT block certain traffic.

That depends to what you refer to and what cases you have in mind etc.
Since I'm not even sure wether you were reading my replies to the OP
in full, there is probably not too much sense in further insisting
here. However the RFC says that once a host accepts mail it takes
responsibilty for it.

>I *am* aware of an RFC that says you MUST NOT silently discard e-mail
>for a trivial reason (and I consider blackholing mail to avoid dictionary
>attacks a "trivial" reason.)

I fully agree here.

>> Keping state of sender IP's who denote invalid recipients above a
>> certain trigger over a certain time and then keep track of the number
>> of good and bad recipients, igonring / blocking such IPs if they go
>> above a certain limit is not risiky at all.
>
>Indeed. But the OP describes an ISP that silently discards *all* mail
>sent to nonexistent recipients. That's highly risky; it's very easy
>to make a typo. If your recipient is at Sympatico, you'll never know
>if the mail made it or not.

Again, I figure you were not following my comunication with the OP in
the other branch of this thread cause otherwise you would know my
opinion of what Sympatico is doing. In short, is just plain wrong and
stupid to put it mildly. In other words, I fully agree here with you
too.

Markus