BACKSCATTERER - does your list verify the SMTP return code before listing IP addresses?
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. 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 f...@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.
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
DevilsPGD
<45782e0f-6aac-4405...@p33g2000vbn.googlegroups.com> Mark
<lanmas...@gmail.com> was claimed to have wrote:
>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 f...@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?
No. Backscatter is backscatter, the reason isn't particularly
significant to the recipient who receives the bounce for the message
didn't send.
>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
> #< #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?
I imagine that UCEprotect SpamTrap hits result in either
a UCEprtotect listing for Spam,
or a Backscatterer listing for backscatter Spam.
--
E-Mail Sent to this address <Blac...@Griffin-Technologies.net>
will be added to the BlackLists.
Shmuel (Seymour J.) Metz
11/17/2009
at 06:41 PM, Mark <lanmas...@gmail.com> said:
>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
>So what happens is that an external user sends an e-mail to this
>address, let's say f...@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
So you *are* sending asynchronous NDRs or backscatter.
>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.
>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 spam...@library.lspace.org
Mark
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
> 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
Mark <lanmas...@gmail.com> looked something like:
> 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
Mark <lanmas...@gmail.com> wrote:
>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.
>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."
>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).
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
--
DevilsPGD
<e48e60e8-ae8c-41ac...@p28g2000vbi.googlegroups.com> Mark
<lanmas...@gmail.com> was claimed to have wrote:
>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.
goo...@guscreek.com
> 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.
Shmuel (Seymour J.) Metz
11/20/2009
at 03:52 PM, Mark <lanmas...@gmail.com> said:
>Your inflexibility is convenient..
PKB. f course, *your* inflexibility exists.
>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.
>I don't know that there's much more to say on this.
Try the truth.
>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 spam...@library.lspace.org
--
Fred Mobach
> 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 - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
Fred Mobach
> On Nov 20, 8:52 am, Mark <lanmasterm...@gmail.com> wrote:
>> 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 - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
--
D. Stussy
news:ksudg519vm55ilvdo...@4ax.com...
> In message
> <e48e60e8-ae8c-41ac...@p28g2000vbi.googlegroups.com> Mark
> <lanmas...@gmail.com> was claimed to have wrote:
> >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.
MrD
> On Nov 20, 8:52 am, Mark <lanmasterm...@gmail.com> wrote:
>> 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.
> 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.
--
MrD.
http://ipquery.org
E-Mail Sent to this address will be added to the BlackLists
> 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.
--
E-Mail Sent to this address <Blac...@Griffin-Technologies.net>
will be added to the BlackLists.
--
Fallout
> 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.
>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.
AntiSpam
D. Stussy <spam+ne...@bde-arc.ampr.org> looked something like:
> ...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.
> 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
<spam+ne...@bde-arc.ampr.org> was claimed to have wrote:
>"DevilsPGD" <Death...@crazyhat.net> wrote in message
>news:ksudg519vm55ilvdo...@4ax.com...
>> In message
>> <e48e60e8-ae8c-41ac...@p28g2000vbi.googlegroups.com> Mark
>> <lanmas...@gmail.com> was claimed to have wrote:
>> >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.
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. 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.
DevilsPGD
<spam+ne...@bde-arc.ampr.org> was claimed to have wrote:
>"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.
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"DevilsPGD" <Death...@crazyhat.net> wrote in message
>news:0otlg5hgp3qu80msg...@4ax.com...
>> In message <heastv$tul$1...@snarked.org> "D. Stussy"
>> <spam+ne...@bde-arc.ampr.org> was claimed to have wrote:
>> >...And the counterargument is: Why did you leave your mailbox open to
>be a
>> >forged source in the first place?
Because it's impossible not to. Anybody who has a telnet client can
forge any email address.
>> > 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.
>> 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.
>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.
> 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.
>"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