BACKSCATTERER - does your list verify the SMTP return code before listing IP addresses?

[Mark]

I see a possible issue with the Backscatterer DNSRBL.

We have a server that is configured to reject messages with invalid
recipients during the SMTP conversation. This is working properly and
we are not sending asynchronous NDRs or backscatter. However, there
is a sitution where some *valid* addresses are setup with permissions
so that only certain users or e-mail addresses can send mail to them.

So what happens is that an external user sends an e-mail to this
address, let's say ***@bar.com, the SMTP conversation returns a "250
OK" and the message is transferred to the system - at which point the
permissions are evaluated and an NDR is returned to the sender like
this:

#< #5.2.0 smtp;550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange
Information Store service reported an error. The following information
should help identify the cause of this error:
"MapiExceptionNotAuthorized:

This is NOT the same as an NDR for an invalid recipient or "550 5.1.1
User unknown". Does the Backscatterer list note this difference, or is
there a way to "allow" the former situation and not the latter?

Responses appreciated.

[DevilsPGD]

In message

Post by Mark
I see a possible issue with the Backscatterer DNSRBL.
We have a server that is configured to reject messages with invalid
recipients during the SMTP conversation. This is working properly and
we are not sending asynchronous NDRs or backscatter. However, there
is a sitution where some *valid* addresses are setup with permissions
so that only certain users or e-mail addresses can send mail to them.
So what happens is that an external user sends an e-mail to this
OK" and the message is transferred to the system - at which point the
permissions are evaluated and an NDR is returned to the sender like
#< #5.2.0 smtp;550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange
Information Store service reported an error. The following information
This is NOT the same as an NDR for an invalid recipient or "550 5.1.1
User unknown". Does the Backscatterer list note this difference, or is
there a way to "allow" the former situation and not the latter?

No. Backscatter is backscatter, the reason isn't particularly
significant to the recipient who receives the bounce for the message
didn't send.

Post by Mark
Responses appreciated.

On my own server, I configure these restrictions to take effect at the
SMTP level, there's no particular need to accept these and later refuse
them.

Some infrastructures make that harder then others, admittedly, but it's
well within the range of possible.

[E-Mail Sent to this address will be added to the BlackLists]

Post by Mark
#< #5.2.0 smtp;550 5.2.0 STOREDRV.Deliver: The Microsoft
Exchange Information Store service reported an error.
The following information should help identify the cause
This is NOT the same as an NDR for an invalid recipient
or "550 5.1.1 User unknown".
Does the Backscatterer list note this difference, or is
there a way to "allow" the former situation and not the
latter?

I imagine that UCEprotect SpamTrap hits result in either
a UCEprtotect listing for Spam,
or a Backscatterer listing for backscatter Spam.

[Shmuel (Seymour J.) Metz]

In <45782e0f-6aac-4405-b966-***@p33g2000vbn.googlegroups.com>, on
11/17/2009

Post by Mark
We have a server that is configured to reject messages with invalid
recipients during the SMTP conversation. This is working properly and we
are not sending asynchronous NDRs or backscatter.

Yet you then write

Post by Mark
So what happens is that an external user sends an e-mail to this
and the message is transferred to the system - at which point the
permissions are evaluated and an NDR is returned to the sender

So you *are* sending asynchronous NDRs or backscatter.

Post by Mark
This is NOT the same as an NDR for an invalid recipient or "550 5.1.1
User unknown".

Backscatter is defined a a response sent to a forged address; that
definition does not depend on the specific status code used.

Post by Mark
Does the Backscatterer list note this difference,

I hope not.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>

I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to ***@library.lspace.org

[Mark]

Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.
I have a feeling that all Exchange 2003/2007 servers are vulnerable to
this type of situation then - where a public folder with a valid e-
mail address + permissions could result in an accepted message and an
asynchronous NDR.

I don't know that there's much more to say on this. You've said that
all NDRs of this type of backscatter for the purposes of your DNSBL,
so we'll just have to work with that.

Thanks.

[LP]

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.
I have a feeling that all Exchange 2003/2007 servers are vulnerable to
this type of situation then - where a public folder with a valid e-
mail address + permissions could result in an accepted message and an
asynchronous NDR.
I don't know that there's much more to say on this. You've said that
all NDRs of this type of backscatter for the purposes of your DNSBL,
so we'll just have to work with that.

You seem to be operating under a misconception when you say "your
inflexibility" and especially "your DNSBL". What "you" do you think
you are talking to? As far as I can see, nobody from the outfit that
maintains the BACKSCATTERER list has participated in this thread.
Instead, you have gotten some advice on how to avoid backscattering
(like doing your check during the SMTP session so you can send your
55x from there) from a few people who purport to have some experience
dealing with the issue. How you respond to these people who are
trying to help you is up to you.

Maybe at some point Claus or somebody from the group that maintains
BACKSCATTERER will chime in with their advice for avoiding being
listed. I suspect it would be about the same advice, perhaps also
with a comment about how that list is not meant to be used for
blocking email except in a very limited set of circumstances (have you
actually seen any of your emails rejected due to this listing?).

[AntiSpam]

The scribbles of

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.

How does the *cause* of the asynchronous NDR in any way change or mitigate
the fact that it's backscatter?

Backscatter is backscatter.

What might have caused the server to send that NDR to an uninvoled third
party is irrelevant.
--
Current Peeve: The mindset that the Internet is some sort of school for
novice sysadmins and that everyone -not- doing stupid dangerous things
should act like patient teachers with the ones who are. -- Bill Cole, NANAE

[Seth]

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.

Not all of them are backscatter; rather, those sent *to me* in
response to *email I had nothing to do with* are backscatter.

Post by Mark
I have a feeling that all Exchange 2003/2007 servers are vulnerable to
this type of situation then

"Microsoft follows standards the way fish follow migrating caribou."

Post by Mark
I don't know that there's much more to say on this.

You can't depend on broken software to do the right thing.

Seth

[E-Mail Sent to this address will be added to the BlackLists]

all asynchronous NDRs are backscatter,

Thats not true, if they are sent to the _actual_ sender.

As opposed to being sent to someone who did not originate
the message the NDR is in response to (which is BackScatter).

[g***@guscreek.com]

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.
I have a feeling that all Exchange 2003/2007 servers are vulnerable to
this type of situation then - where a public folder with a valid e-
mail address + permissions could result in an accepted message and an
asynchronous NDR.
I don't know that there's much more to say on this. You've said that
all NDRs of this type of backscatter for the purposes of your DNSBL,
so we'll just have to work with that.
Thanks.

for what it's worth, one of my servers has been on this DNSBL for
months with absolutely no impact. I've never seen a message rejected
because of it. Practically no one uses this DNSBL - for obvious
reasons.

[Fred Mobach]

Post by g***@guscreek.com

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.
I have a feeling that all Exchange 2003/2007 servers are vulnerable
to this type of situation then - where a public folder with a valid
e- mail address + permissions could result in an accepted message and
an asynchronous NDR.
I don't know that there's much more to say on this. You've said that
all NDRs of this type of backscatter for the purposes of your DNSBL,
so we'll just have to work with that.

for what it's worth, one of my servers has been on this DNSBL for
months with absolutely no impact. I've never seen a message rejected
because of it. Practically no one uses this DNSBL - for obvious
reasons.

I've seen this DNSBL in use, however in an not advised way : to block
e-mail instead of backscatter.
--
Fred Mobach - ***@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..

[MrD]

Post by g***@guscreek.com

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or
not. I have a feeling that all Exchange 2003/2007 servers are
vulnerable to this type of situation then - where a public folder
with a valid e- mail address + permissions could result in an
accepted message and an asynchronous NDR.
I don't know that there's much more to say on this. You've said
that all NDRs of this type of backscatter for the purposes of your
DNSBL, so we'll just have to work with that.
Thanks.

for what it's worth, one of my servers has been on this DNSBL for
months with absolutely no impact. I've never seen a message rejected
because of it.

That would be the expected outcome, if your server doesn't send
backscatter (although that begs the question of how you got listed). In
the general case, only NDRs, vacation messages and the like should be
affected by a Backscatterer listing.

Post by g***@guscreek.com
Practically no one uses this DNSBL - for obvious reasons.

Heh. I wonder where you get that information from.

As it happens, my router is listed, because I connected to the
backscatterer.org MX a couple of weeks ago to inspect its banner. My
mail to a certain Linux mailing list promptly started getting dropped.
My suggestion to the list-admin that he might want to reconsider the
policy (and use the list only for null-sender mail) has so far remained
unanswered.

[E-Mail Sent to this address will be added to the BlackLists]

Post by g***@guscreek.com
for what it's worth, one of my servers has been on this
DNSBL for months with absolutely no impact.
I've never seen a message rejected because of it.
Practically no one uses this DNSBL - for obvious reasons.

Since it is intended to be used to reject messages from null
senders <> or Postmaster@ (not all envelope senders), there
should be few rejects; Unless you are a significant source
of backscatter.

[Fallout]

Post by g***@guscreek.com
for what it's worth, one of my servers has been on this DNSBL for
months with absolutely no impact.  I've never seen a message rejected
because of it.  

That's because it's not supposed to be used for rejecting e-mails, as
their web page states. But it's easier to talk about things you don't
understand, than trying to understand them.

Post by g***@guscreek.com
Practically no one uses this DNSBL - for obvious
reasons.

Right, I'm sure that is why I guess 80% or more of threads in this
group are about it.

[DevilsPGD]

In message

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.
I have a feeling that all Exchange 2003/2007 servers are vulnerable to
this type of situation then - where a public folder with a valid e-
mail address + permissions could result in an accepted message and an
asynchronous NDR.

I think you're missing the point. Look at this from the victim's point
of view, not from the point of view of your technical limitations.

If I receive a bounce to a message I didn't send, I don't really care
why you sent it, I just want you to stop wasting my time and resources.

[D. Stussy]

Post by DevilsPGD
In message

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.
I have a feeling that all Exchange 2003/2007 servers are vulnerable to
this type of situation then - where a public folder with a valid e-
mail address + permissions could result in an accepted message and an
asynchronous NDR.

I think you're missing the point. Look at this from the victim's point
of view, not from the point of view of your technical limitations.
If I receive a bounce to a message I didn't send, I don't really care
why you sent it, I just want you to stop wasting my time and resources.

...And the counterargument is: Why did you leave your mailbox open to be a
forged source in the first place? That's what SPF and DK/DKIM aid in
preventing (within the limitations of each method).

You got the bounce flood because you FAILED to prevent spammers from
abusing your resource. The flood is YOUR FAULT for not protecting your
mailbox.

[AntiSpam]

The scribbles of

Post by D. Stussy
...And the counterargument is: Why did you leave your mailbox open to be a
forged source in the first place? That's what SPF and DK/DKIM aid in
preventing (within the limitations of each method).

SPF and DK/DKIM will do little if anything to mitigate this problem.

Logic suggests that an administrator too lazy to prevent backscatter is
also going to be too lazy to bother with things like SPF, DK, DKIM or any
other Magic-Bullet-Whizbang-of-the-week.

Post by D. Stussy
You got the bounce flood because you FAILED to prevent spammers from
abusing your resource. The flood is YOUR FAULT for not protecting your
mailbox.

I get hit with a bounce flood because someone else has a misconfigured mail
server and that's *my* fault?

No.
--
Current Peeve: The mindset that the Internet is some sort of school for
novice sysadmins and that everyone -not- doing stupid dangerous things
should act like patient teachers with the ones who are. -- Bill Cole, NANAE

[DevilsPGD]

Post by D. Stussy

Post by DevilsPGD
In message

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.
I have a feeling that all Exchange 2003/2007 servers are vulnerable to
this type of situation then - where a public folder with a valid e-
mail address + permissions could result in an accepted message and an
asynchronous NDR.

I think you're missing the point. Look at this from the victim's point
of view, not from the point of view of your technical limitations.
If I receive a bounce to a message I didn't send, I don't really care
why you sent it, I just want you to stop wasting my time and resources.

...And the counterargument is: Why did you leave your mailbox open to be a
forged source in the first place? That's what SPF and DK/DKIM aid in
preventing (within the limitations of each method).

Who says I didn't? If the message passed SPF or DKIM then any bounce
wouldn't be backscatter and we wouldn't be having this discussion.

[DevilsPGD]

"Who says I didn't?" I say you didn't - because if you had the SPF or DK
record, you wouldn't be getting an NDR from a properly behaving recipient
server.

A properly behaving server wouldn't send backscatter with or without SPF
or DK, so their existence is moot.

[D. Stussy]

Post by DevilsPGD

Post by D. Stussy

Post by DevilsPGD
In message

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.
I have a feeling that all Exchange 2003/2007 servers are vulnerable to
this type of situation then - where a public folder with a valid e-
mail address + permissions could result in an accepted message and an
asynchronous NDR.

I think you're missing the point. Look at this from the victim's point
of view, not from the point of view of your technical limitations.
If I receive a bounce to a message I didn't send, I don't really care
why you sent it, I just want you to stop wasting my time and resources.

...And the counterargument is: Why did you leave your mailbox open to be a
forged source in the first place? That's what SPF and DK/DKIM aid in
preventing (within the limitations of each method).

Who says I didn't? If the message passed SPF or DKIM then any bounce
wouldn't be backscatter and we wouldn't be having this discussion.

If you had protected your mailbox with SPF or DK/DKIM, and the message
wasn't from you, your message would be rejected during SMTP and no NDR
would be generated. By the fact that you got an NDR means that either the
message really was from you (thus not backscatter) or you failed to protect
your mailbox, which means no SPF or DK record.

"Who says I didn't?" I say you didn't - because if you had the SPF or DK
record, you wouldn't be getting an NDR from a properly behaving recipient
server.

[Seth]

Post by D. Stussy

Post by DevilsPGD

Post by D. Stussy
...And the counterargument is: Why did you leave your mailbox open to

be a

Post by DevilsPGD

Post by D. Stussy
forged source in the first place?

Because it's impossible not to. Anybody who has a telnet client can
forge any email address.

Post by D. Stussy

Post by DevilsPGD

Post by D. Stussy
That's what SPF and DK/DKIM aid in
preventing (within the limitations of each method).

They don't prevent any spammer from forging anything.

They might help the recipient determine that the message is forged, or
maybe forwarded.

Post by D. Stussy

Post by DevilsPGD
Who says I didn't? If the message passed SPF or DKIM then any bounce
wouldn't be backscatter and we wouldn't be having this discussion.

A bounce is backscatter if it goes to someone who didn't send the
original message, no matter what SPF or DKIM say.

Post by D. Stussy
If you had protected your mailbox with SPF or DK/DKIM, and the message
wasn't from you, your message would be rejected during SMTP and no NDR
would be generated.

You left out a few other criteria there: if the protection were
accurate, if the message wasn't from someone else using the same email
emitter (e.g. another customer of the same ISP), the recipient checked
whatever the backscatter victim used, and the code all ran correctly.

Post by D. Stussy
By the fact that you got an NDR means that either the
message really was from you (thus not backscatter) or you failed to protect
your mailbox, which means no SPF or DK record.

There is no _requirement_ to use SPF or DK.

Post by D. Stussy
"Who says I didn't?" I say you didn't - because if you had the SPF or DK
record, you wouldn't be getting an NDR from a properly behaving recipient
server.

A properly behaving recipient server doesn't backscatter, period,
completely independend of whether or not someone uses SPF or DK.

Seth

[Shmuel (Seymour J.) Metz]

In <e48e60e8-ae8c-41ac-96e3-***@p28g2000vbi.googlegroups.com>, on
11/20/2009

Post by Mark
Your inflexibility is convenient..

PKB. f course, *your* inflexibility exists.

Post by Mark
for you, that all asynchronous
NDRs are backscatter,

That, of course is untrue; NDR's sent to the proper addresses are not
backscatter. But I suppose that it's easier to rebut straw dummies than
what people actually state.

Post by Mark
I don't know that there's much more to say on this.

Try the truth.

Post by Mark
You've said that
all NDRs of this type of backscatter for the purposes of your DNSBL,

No, he said that the ones to forged addresses are backscatter.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>

I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to ***@library.lspace.org

[Fred Mobach]

Post by Mark
Your inflexibility is convenient... for you, that all asynchronous
NDRs are backscatter, no matter if they're a 550 User Unknown or not.
I have a feeling that all Exchange 2003/2007 servers are vulnerable to
this type of situation then - where a public folder with a valid e-
mail address + permissions could result in an accepted message and an
asynchronous NDR.

And you just didn't notice why some admins are still known to block any
MS-Windows server directly connected to the Internet ? FYI, I don't
like spam, even from admins who don't know how to configure their
servers appropriately.
--
Fred Mobach - ***@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..