backscatter and mailing lists

[Steven Roberts]

To start off, I am quite familiar with the concept of backscatter. I
also have confirmed all e-mail targets of the list in question. It is
not a matter of an invalid recipient.

The problem is this. Some of the recipients have a stricter SPAM
blocking policy than my server does. They are fine with more false
positives than I can administratively The result of course is that
then for some SPAM messages sent to the list my server does not block
them as it does not detect them as SPAM. it then tries to send the e-
mail on to the end-user. their mail server spits out a 554. this
then cause my mail server to generate a bounce.

To the purist parts of the anti-backscatter camp that is viewed as
backscatter. my question is then how would one go about not sending
those? I am running postfix so some concrete pointers would be great.

[MrD]

Post by Steven Roberts
To start off, I am quite familiar with the concept of backscatter. I
also have confirmed all e-mail targets of the list in question. It
is not a matter of an invalid recipient.
The problem is this. Some of the recipients have a stricter SPAM
blocking policy than my server does. They are fine with more false
positives than I can administratively The result of course is that
then for some SPAM messages sent to the list my server does not block
them as it does not detect them as SPAM. it then tries to send the
e- mail on to the end-user. their mail server spits out a 554. this
then cause my mail server to generate a bounce.

Have I understood your configuration correctly?

1. Spammer submits mail to your server, addressed to a list.
2. Your server accepts the spam as good mail. Fair enough.
3. Your server 'explodes' the list-address, and relays the spam to all
the subscribers.
4. Some subscribers reject the spam with a 554.
5. Your server then generates a bounce message to somebody or other - I
presume the OP (surely not the whole list?).

Post by Steven Roberts
To the purist parts of the anti-backscatter camp that is viewed as
backscatter.

So you send a bounce message "to the spammer", but he forged the
sender-address. That's backscatter. It has nothing to do with purity
(and it doesn't matter whether you are against backscatter or not; it's
just a description of the phenomenon).

Post by Steven Roberts
my question is then how would one go about not sending those? I am
running postfix so some concrete pointers would be great.

Postfix has support for aliases, which *can* be used to make poor-man's
mailing lists. But if you do it that way, then the OP effectively sends
the mail to all of the subscribers himself, using the Postfix server as
a relay. I believe the only way to prevent Postfix (configured as a
relay server) to not send backscatter in such circumstances is to
authenticate all relay senders.

Have you considered using proper mailing list software, such as Mailman?

N.B. I've used Mailman, but I'm not so well-acquainted with its
operation that I can definitely confirm it would solve your problem. But
it *is* the case that a Mailman envelope sender-address can be of the
form <listname-***@lists.example.org>. With such a sender-address,
any bounce generated by Postfix would go to the list server, not to the
poster. How Mailman deals with such bounces is configurable.

[Fallout]

Post by MrD
5. Your server then generates a bounce message to somebody or other - I
    presume the OP (surely not the whole list?).

Just a funny story, a couple of weeks ago this gardening-greenhouse
list I never heard about got so misconfigured that it sent a bunch of
e-mails to people that never signed up for it, then when they were
replying shouting for them to stop the whole list would get the e-mail
(list of people who never signed up for it)
So every poor recepient was getting very confused, saying they didn't
send anything, then the whole list would get that reply and they
replied back shouting to get taken of it, then everyone would get
*that* reply and would reply they didn't send anything and take them
off the list *or else* then the innocent recipients would reply again
to the whole list, then....

Can you imagine the fun for a whole boring Friday?

[g***@guscreek.com]

Post by MrD

To start off, I am quite familiar with the concept of backscatter.  I
 also have confirmed all e-mail targets of the list in question.  It
is not a matter of an invalid recipient.
The problem is this.  Some of the recipients have a stricter SPAM
blocking policy than my server does.  They are fine with more false
positives than I can administratively The result of course is that
then for some SPAM messages sent to the list my server does not block
 them as it does not detect them as SPAM.  it then tries to send the
e- mail on to the end-user.   their mail server spits out a 554. this
then cause my mail server to generate a bounce.

Have I understood your configuration correctly?
1. Spammer submits mail to your server, addressed to a list.

No. He didn't say that the mail was necessarily actual spam. In fact
he specifically mentioned the likelihood that it was ham that was
falsely identified as spam by the remote server.

Post by MrD
2. Your server accepts the spam as good mail. Fair enough.

Except it's not what he said.

[MrD]

Post by g***@guscreek.com

Post by MrD

Post by Steven Roberts
To start off, I am quite familiar with the concept of
backscatter. I also have confirmed all e-mail targets of the
list in question. It is not a matter of an invalid recipient.
The problem is this. Some of the recipients have a stricter SPAM
blocking policy than my server does. They are fine with more
false positives than I can administratively The result of course
is that then for some SPAM messages sent to the list my server
does not block them as it does not detect them as SPAM. it then
tries to send the e- mail on to the end-user. their mail server
spits out a 554. this then cause my mail server to generate a
bounce.

Have I understood your configuration correctly?
1. Spammer submits mail to your server, addressed to a list.

No. He didn't say that the mail was necessarily actual spam. In
fact he specifically mentioned the likelihood that it was ham that
was falsely identified as spam by the remote server.

Did I misread this?

"The result of course is that then for some SPAM messages sent to the
list my server does not block them as it does not detect them as SPAM."

Post by g***@guscreek.com

Post by MrD
2. Your server accepts the spam as good mail. Fair enough.

Except it's not what he said.

Oh, well. Guess I just got it wrong. Just asking.

[Rob]

Post by Steven Roberts
To the purist parts of the anti-backscatter camp that is viewed as
backscatter. my question is then how would one go about not sending
those? I am running postfix so some concrete pointers would be great.

The anti-backscatter camp want you to drop functionality to be
able to keep within their lines.

They say you should not send any bounce to their addresses.

When you ask "how do I know it is their address" they will send
you in the woods suggesting that you should never send any bounce.

Even though the standards say you should.

So it is a problem that really cannot be solved. It can only
be ignored.

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

Post by Rob
suggesting that you should never send any bounce.
Even though the standards say you should.

RFC 5321
_dropping_ mail _without_ _notification_ of the sender
_is_ _permitted_ in practice."


RFC 3834:
Recommendations for Automatic Responses to Electronic Mail
When (not) to send automatic responses
...
In practice there are always reasons to refuse to respond
to some kinds of received messages
...
In general, care should be taken to avoid sending useless
or redundant responses, and to avoid contributing to
mail loops or facilitating denial-of-service attacks
...
In order to avoid responding to spam and to certain kinds
of attacks, automatic responses from Service Responders
SHOULD NOT be sent for extremely malformed requests.
This may include checking that the subject message has
a content-type and content appropriate to that service.
...
Return addresses are easily forged, in order to avoid
being used as a means of denial-of-service attacks
(i.e., to flood mailboxes with unwanted content)
Service Responders
...

Post by Rob
So it is a problem that really cannot be solved.

Except for those that _Reject_ messages,
instead of accepting, then bouncing.

Post by Rob
It can only be ignored.

Yes, sources of abuse (like backscatter spam),
can be ignored, Backscatterer is one way to do that,
although I would think most could do it without third party
opinions (DNSbls) if they made the effort.

[Shmuel (Seymour J.) Metz]

In <hdpl9o$fhp$***@news.eternal-september.org>, on 11/15/2009
at 05:42 PM, E-Mail Sent to this address will be added to the

Post by E-Mail Sent to this address will be added to the BlackLists
Yes, sources of abuse (like backscatter spam),
can be ignored, Backscatterer is one way to do that,
although I would think most could do it without third party
opinions (DNSbls) if they made the effort.

The difference is that most of those using a DNSBL to block backscatter
sources will automatically remove the block when the DNSBL removes the
listing. Those using a local list are more likely to do list and forget.
--
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

[Michael Deutschmann]

Post by Rob
The anti-backscatter camp want you to drop functionality to be
able to keep within their lines.
They say you should not send any bounce to their addresses.

Actually, it's "not send a bounce to *any* address", unless you are sure
it is genuine. It's universally agreed that a bounce within your own
bailiwick, such as from your own smarthost to a local sender, is fine.

Likely most think bounces to SPF-pass mail are OK, but this hasn't come
up in practice. (Note: this is quite different from D.Stussy's position,
which claims that all but SPF-fail mail is bounceable.)

Post by Rob
When you ask "how do I know it is their address" they will send
you in the woods suggesting that you should never send any bounce.
Even though the standards say you should.

"We" do indeed want you to drop functionality, but not that specific
functunality. The "functionality" that we do not care that we are killing
is: you being able to retroactively declare a message undeliverable after
replying 200 to CR LF '.' CR LF.

Once you surrender that, it is easy to avoid violations of both the RFC
"never discard without bouncing" and the Lumber Cartel's (TINLC) "never
bounce without *affirmative* knowledge the sender is real", because you
*never discard*. You always deliver forwards.

This does mean, if the quota interlocking amoung your mailservers, or
even between different processes on one server, is inadequate, you may end
with denied service to other users if a user on vacation gets mailbombed.
But, *that's not our problem*. You just have to get better interlocking.

---- Michael Deutschmann <***@talamasca.ocis.net>

[Shmuel (Seymour J.) Metz]

Post by Michael Deutschmann
Once you surrender that, it is easy to avoid violations of both the RFC
"never discard without bouncing"

Actually, RFC 5321 says something quite different from what Rob claims,
and he has been told numerous times:

Conversely, if a message is rejected because it is found to
contain hostile content (a decision that is outside the scope of
an SMTP server as defined in this document), rejection
("bounce") messages SHOULD NOT be sent unless the receiving site
is confident that those messages will be usefully delivered.
The preference and default in these cases is to avoid sending
non-delivery messages when the incoming message is determined to
contain hostile content.
--
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

[D. Stussy]

Post by Michael Deutschmann

Post by Rob
The anti-backscatter camp want you to drop functionality to be
able to keep within their lines.
They say you should not send any bounce to their addresses.

Actually, it's "not send a bounce to *any* address", unless you are sure
it is genuine. It's universally agreed that a bounce within your own
bailiwick, such as from your own smarthost to a local sender, is fine.
Likely most think bounces to SPF-pass mail are OK, but this hasn't come
up in practice. (Note: this is quite different from D.Stussy's position,
which claims that all but SPF-fail mail is bounceable.)

However, I am not the only one who claims such. This is what the standards
actually say and require in order to be backwards compatible with those who
have not yet implemented such technology (e.g. SPF). Also note that my
comments are not SPF specific; I equally addressed DK/DKIM and any similar
method.

What it comes down to is this: The standards say that unless we are TOLD
that a message is forged, it is NOT forged. They also say that if we can
determine that a message should not be delivered before we reach the point
of acceptance, we MUST reject it before that point. However, there are
some conditions that can cause non-delivery that cannot be determined
before message acceptance that cannot be mitigated, and therefore, a
non-delivery-report will be generated (and once generated, it MUST be
sent). These conditions that cannot be mitigated are usually operating
system errors and hardware failures.

Some people don't seem to understand that the primary responsibility for
preventing spam is their OWN responsibility to prevent their mailbox(es)
from being abused by spammers. They'd rather blame everyone else first.
"They" includes the operators of the backscatterer DNSBL, but is not
limited to them.

Post by Michael Deutschmann

Post by Rob
When you ask "how do I know it is their address" they will send
you in the woods suggesting that you should never send any bounce.
Even though the standards say you should.

"We" do indeed want you to drop functionality, but not that specific
functunality. The "functionality" that we do not care that we are killing
is: you being able to retroactively declare a message undeliverable after
replying 200 to CR LF '.' CR LF.

That requires a standards change. Where's your RFC proposing such?

Post by Michael Deutschmann
Once you surrender that, it is easy to avoid violations of both the RFC
"never discard without bouncing" and the Lumber Cartel's (TINLC) "never
bounce without *affirmative* knowledge the sender is real", because you
*never discard*. You always deliver forwards.
This does mean, if the quota interlocking amoung your mailservers, or
even between different processes on one server, is inadequate, you may end
with denied service to other users if a user on vacation gets mailbombed.
But, *that's not our problem*. You just have to get better interlocking.

Not all problems can be mitigated by a redesign.

[Michael Deutschmann]

Post by Michael Deutschmann

Post by Michael Deutschmann
"We" do indeed want you to drop functionality, but not that specific
functunality. The "functionality" that we do not care that we are

killing

Post by Michael Deutschmann
is: you being able to retroactively declare a message undeliverable after
replying 200 to CR LF '.' CR LF.

That requires a standards change. Where's your RFC proposing such?

It doesn't require a "standards change", for the same reason that
SBL-like blacklisting and LART mails do not require any goverments to
declare spamming to be criminal.

Open relaying is punished quickly today, but is not forbidden by the
standards.

On Mon, 16 Nov 2009, Shmuel (Seymour J.) Metz wrote:
) In <%***@khar-pern.talamasca.ocis.net>, on 11/15/2009
) at 09:49 PM, Michael Deutschmann <***@talamasca.ocis.net> said:
)
) >Once you surrender that, it is easy to avoid violations of both the RFC
) >"never discard without bouncing"
)
) Actually, RFC 5321 says something quite different from what Rob claims,
) and he has been told numerous times:

I'm aware of that. But messages that are so obviously hostile as to
invoke that exception are only part of the problem -- and would be the
easier bit to solve even without said exception.

The real problem here is mailservers that overcommit queue space, get
wedged by a mailbomb to someone on vacation, and then want freedom to
shed messages they have already acknowledged, so that they have room to
accept other messages to other mailboxes that are actually being read.

In that situation, the mailserver can't tell the difference between the
mailbomb messages and the legitimate traffic to that user, so it cannot
invoke the exception.

---- Michael Deutschmann <***@talamasca.ocis.net>

[Seth]

Post by Michael Deutschmann
The real problem here is mailservers that overcommit queue space,

That's the (solvable) problem right there. Don't Do That.

Post by Michael Deutschmann
In that situation, the mailserver

is already broken. Fix it, don't impose backscatter on third parties
who aren't responsible for your use of broken software.

Seth

[Michael Deutschmann]

I wrote a response to this earlier, but it seems to have gotten lost. (I
received an initial acknowlegement, but no approval/disapproval message.)

Post by Seth

Post by Michael Deutschmann
The real problem here is mailservers that overcommit queue space,

That's the (solvable) problem right there. Don't Do That.

No disagreement there. My point in writing that was not to support the
backscatter apologists, but merely to explain that the "hostile mail"
exception (RFC 5321, section 6.2) Shmuel is fixated on is a distraction in
this debate.

---- Michael Deutschmann <***@talamasca.ocis.net>

[Shmuel (Seymour J.) Metz]

Post by Michael Deutschmann
No disagreement there. My point in writing that was not to support the
backscatter apologists, but merely to explain that the "hostile mail"
exception (RFC 5321, section 6.2) Shmuel is fixated on is a distraction
in this debate.

No, it's a rebuttal of a false contention. Pointing out that a poster has
his facts wrong is not a distraction, because it has bearing on the
poster's credibility, especially when he's already on notice that his
statements are incorrect.
--
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

[Seth]

Post by D. Stussy
What it comes down to is this: The standards say that unless we are TOLD
that a message is forged, it is NOT forged.

Once again, I'll challenge you to quote that from a standard, with
citation.

Go on, we're waiting.

Post by D. Stussy
However, there are some conditions that can cause non-delivery that
cannot be determined before message acceptance that cannot be
mitigated,

Such as what? A lightning strike taking out the computer during
delivery?

Post by D. Stussy
and therefore, a non-delivery-report will be generated

I'm not aware of any such conditions. If bad software is in use, it
can't do the right thing, but that doesn't make doing the wrong thing
necessary.

Post by D. Stussy
(and once generated, it MUST be
sent). These conditions that cannot be mitigated are usually operating
system errors and hardware failures.

And such things will never prevent the generation of the NDN, oh, no.

Post by D. Stussy
Some people don't seem to understand that the primary responsibility for
preventing spam is their OWN responsibility to prevent their mailbox(es)
from being abused by spammers.

One way I protect mine is by getting the spammers removed from the
Internet.

Post by D. Stussy
They'd rather blame everyone else first.

Primary blame belongs to those who emit spam, just like primary blame
for robbery belong to the robbers, not the victims who didn't have
strong enough locks.

Post by D. Stussy

Post by Michael Deutschmann
"We" do indeed want you to drop functionality, but not that specific
functunality. The "functionality" that we do not care that we are

killing

Post by Michael Deutschmann
is: you being able to retroactively declare a message undeliverable after
replying 200 to CR LF '.' CR LF.

That requires a standards change. Where's your RFC proposing such?

Where's your RFC claiming that failing to use your current FUSSP
authorizes any message and makes forgery impossible?

Seth

[Martijn Lievaart]

Post by Seth

Post by D. Stussy
However, there are some conditions that can cause non-delivery that
cannot be determined before message acceptance that cannot be mitigated,

Such as what? A lightning strike taking out the computer during
delivery?

Multiple recipients where:
1) One user is over quota or
2) One user is currently undeliverable, so locally spooled and later
found to be definately undeliverable or
3) User defined filtering accepts for one user, but not for another.

With the current state of RFCs the above is impossible to do correctly
without NDRs (unless you count dropping legitimate mail as correct).

1) Can be avoided by reserving for the largest possible message.
Unfriendly, but possible workable.
3) Can be avoided by just not doing user defined filtering.
2) Cannot be avoided.

M4

[D. Stussy]

Post by Martijn Lievaart

Post by Seth

Post by D. Stussy
However, there are some conditions that can cause non-delivery that
cannot be determined before message acceptance that cannot be mitigated,

Such as what? A lightning strike taking out the computer during
delivery?

1) One user is over quota or
2) One user is currently undeliverable, so locally spooled and later
found to be definately undeliverable or
3) User defined filtering accepts for one user, but not for another.
With the current state of RFCs the above is impossible to do correctly
without NDRs (unless you count dropping legitimate mail as correct).
1) Can be avoided by reserving for the largest possible message.
Unfriendly, but possible workable.
3) Can be avoided by just not doing user defined filtering.
2) Cannot be avoided.

If a hardware or OS failure is the cause of the non-delivery, an NDR cannot
be universally avoided. An NDR can occur even when all possible checks
performed during SMTP indicate that the message will be deliverable.

Unanticipated errors can always turn up.

[Seth]

Post by D. Stussy
If a hardware or OS failure is the cause of the non-delivery, an NDR
cannot be

guaranteed. Or do you expect a computer where lightning has just let
all the magic smoke out to still be able to generate an NDR?

Post by D. Stussy
Unanticipated errors can always turn up.

But somehow, they don't stop NDRs?

Seth

[Claus v. Wolfhausen]

Post by D. Stussy
Some people don't seem to understand that the primary responsibility for
preventing spam is their OWN responsibility to prevent their mailbox(es)
from being abused by spammers.

True words, but i guess you do not understand their real meaning.
Since we (tinw) and our users did understand that it is our responsibility to
prevent our mailboxes being abused by spammers, we (tinw) are blocking those
who try to spam our inboxes with backscatter.

Post by D. Stussy
They'd rather blame everyone else first.
"They" includes the operators of the backscatterer DNSBL, but is not
limited to them.

Hey we don't blame those that are sending backscatter, we just list them.
After that the problem is fixed for us and our users.

It's the listees that seem to have a problem, otherwise they wouldn't come here
and whine about our listings.

Since they have a problem and not we (tinw), it is logically up to them to fix
it.
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net

[D. Stussy]

Post by Claus v. Wolfhausen

Post by D. Stussy
Some people don't seem to understand that the primary responsibility for
preventing spam is their OWN responsibility to prevent their mailbox(es)
from being abused by spammers.

True words, but i guess you do not understand their real meaning.
Since we (tinw) and our users did understand that it is our

responsibility to

Post by Claus v. Wolfhausen
prevent our mailboxes being abused by spammers, we (tinw) are blocking those
who try to spam our inboxes with backscatter.

Yes, but you ALSO block those who wouldn't be sending you an NDR if you had
an SPF or DK record in place to tell them that the message they tried to
deliver, having passed their spam filter, was also forged. Those servers
aren't misbehaving but following the standards in a manner consistent with
backwards compatibility for those who still haven't heard of these tools.

It's YOUR responsibility as the mailbox owner to declare what is and isn't
a legitimate message from your mailbox. By NOT doing so, you are telling
the rest of us that you WANT NDRs even for messages you claim you never
sent nor authorized - and therefore such NDRs are NOT backscatter, because
you wanted them.

Post by Claus v. Wolfhausen

Post by D. Stussy
They'd rather blame everyone else first.
"They" includes the operators of the backscatterer DNSBL, but is not
limited to them.

Hey we don't blame those that are sending backscatter, we just list them.

Same thing. Same result.

Post by Claus v. Wolfhausen
After that the problem is fixed for us and our users.

...Without recognizing that YOU are the cause of the problem by letting the
spammers abuse and forge your mailbox as the sender in the first place.

Post by Claus v. Wolfhausen
It's the listees that seem to have a problem, otherwise they wouldn't come here
and whine about our listings.

They complain about your listings because you claim that their servers are
misbehaving, which may in fact be INCORRECT. Their servers may very well
be checking for SPF and DK/DKIM signatures, and would have not sent any NDR
had the mailbox owner (that means you w/r to your spamtraps) implemented
these tools so that these complainants' servers could tell that the
messages were forged.

Your failure to implement SPF and/or DK directly leads to the possibility
of these systems to generate an NDR. The fault is YOURS, not theirs. By
not using these tools, you have told them that ALL messages from your
mailbox are legitimate.

Only when a mailbox that is protected by SPF and/or DK (or other, future
method) receives an NDR with respect to a message that is a forgery does
the NDR become backscatter - i.e. backscatter can be sent ONLY by servers
that don't check for (or don't act on, by rejecting a message with) a
positive forgery status. Those are the ONLY misbehavers that should be
listed.

Post by Claus v. Wolfhausen
Since they have a problem and not we (tinw), it is logically up to them to fix
it.

Garbage-in, garbage-out.

It is YOUR responsibility to tell them the criteria by which they can
determine the message isn't from you so that they have a reason not to
generate the NDR. Without such, they are REQUIRED to generate the NDR for
message non-delivery (assuming it wasn't rejected for some other reason).
If you don't want the possibility of backscatter, YOU need to tell them
(and do so with the tools already mentioned) what may be a legitimate
mesage and what isn't.


You have continuously LIED about what is going on here. You claim that
your spamtrap mailboxes receive NDRs but that no message is ever sent using
any of them as sender. As an NDR can come only as a reply, this means that
your spamtraps were in fact used as senders by SOMEONE (presumedly, a
spammer). That is a direct contradiction of your claim. I note that you
did not say that "you never send using them...." You said that "mail is
never sent with [them] as sender." Those statements don't mean the same
thing. Obviously, someone does send messages using your spamtraps as
source - and if these messages are not legitimate, you need to tell us so
via your SPF record or a DK/DKIM record which says "always signed."

[CSA Evangelist]

Post by D. Stussy
Your failure to implement SPF and/or DK directly leads to the possibility
of these systems to generate an NDR. The fault is YOURS, not theirs.

I implement CSA instead of SPF or DK. Do you check CSA? If not, is it MY
fault for using a different silver bullet than you do?

Post by D. Stussy
Only when a mailbox that is protected by SPF and/or DK (or other, future
method)

s/future/alternative/

Post by D. Stussy
receives an NDR with respect to a message that is a forgery does
the NDR become backscatter

So, if I protect my domains with ASDF records (Almighty & Secure Detection
of Forgeries, the Next Big Thing, just read My Blog) and receive NDRs from
your server - it's backscatter, right?

Post by D. Stussy
i.e. backscatter can be sent ONLY by servers that don't check for (or
don't act on, by rejecting a message with) a positive forgery status.

.. using *all* known and unknown methods to detect forgeries deployed on
the Internet today. I don't think my server could handle the number of
database lookups required to process a single mail.

Post by D. Stussy
It is YOUR responsibility to tell them the criteria by which they can
determine the message isn't from you so that they have a reason not to
generate the NDR.

So, by your standards, it's ok if I post my criteria on a shed in Timbuktu.
Any NDR received with respect to a message that is a forgery is clearly
backscatter.

I think we (tiaw) can live with that.

Post by D. Stussy
You have continuously LIED about what is going on here. You claim that
your spamtrap mailboxes receive NDRs but that no message is ever sent using
any of them as sender.

There is no such guarantee.

http://www.uceprotect.net/en/index.php?m=2&s=0

| Q7: I own a domain that I am actually not using so can I do anything to
| help the project?
|
| A7: Yes and you are very welcome to do so.
..
| Simply ask your ISP to change your MX-Record to: nirvana.admins.ws in the
| DNS.
..
| All email sent to your domain will then be routed to nirvana.admins.ws,
| which blacklists (if conditions from our policy match) every IP address
| sending mail to it :-)

[Seth]

Post by D. Stussy
Yes, but you ALSO block those who wouldn't be sending you an NDR if

they had a properly configured mailserver.

Post by D. Stussy
It's YOUR responsibility as the mailbox owner to declare what is and isn't
a legitimate message from your mailbox.

According to which RFC? Is that at the level of MUST, SHOULD, or This
is an Experiment you Might want to Try?

Post by D. Stussy
By NOT doing so, you are telling the rest of us

By not telling you anything, I'm not telling you anything. It's just
that simple.

Post by D. Stussy
that you WANT NDRs even for messages you claim you never
sent nor authorized

Do you want to be held to have agreed to everything you haven't
explicitly disclaimed according to every method that anybody else has
proposed?

Post by D. Stussy
- and therefore such NDRs are NOT backscatter, because
you wanted them.

False on several counts. (1) Backscatter isn't defined in terms of
"want". (2) I don't want them, and I've said so and posted that fact
here numerous times.

Post by D. Stussy

Post by Claus v. Wolfhausen
Hey we don't blame those that are sending backscatter, we just list them.

Same thing. Same result.

You have a problem with them telling the truth?

Post by D. Stussy

Post by Claus v. Wolfhausen
After that the problem is fixed for us and our users.

...Without recognizing that YOU are the cause of the problem by letting the
spammers abuse and forge your mailbox as the sender in the first place.

Please explain exactly how I can stop spammers from forging, keeping
in mind that it's illegal in most states to shoot them.

Post by D. Stussy

Post by Claus v. Wolfhausen
It's the listees that seem to have a problem, otherwise they wouldn't
come here and whine about our listings.

They complain about your listings because you claim that their servers are
misbehaving, which may in fact be INCORRECT.

I don't see any claim about "misbehaving". I see statements about
"sent NDRs to addresses that never send email".

Post by D. Stussy
Their servers may very well be checking for SPF and DK/DKIM
signatures, and would have not sent any NDR had the mailbox owner
(that means you w/r to your spamtraps) implemented these tools so
that these complainants' servers could tell that the messages were
forged.

So what? Backscatterer doesn't claim that the NDR-sender would or
would not have sent NDRs in some alternate universe. It claims that
the server actually sent something.

Post by D. Stussy
Your failure to implement SPF and/or DK directly leads to the possibility
of these systems to generate an NDR.

Those systems do what _they_ are programmed to do by _their
administrators_. I'm not one of their administrators. I have no
control over what they do.

Post by D. Stussy
The fault is YOURS, not theirs.

Backscatterer isn't about fault. It's about specific email messages.
What they send is their responsibility.

Post by D. Stussy
By not using these tools, you have told them that

I am not using those tools. That's all I say by not using those
tools. I am not responsible for any incorrect conclusions drawn by
anybody else.

Post by D. Stussy
ALL messages from your mailbox are legitimate.

All the messages that are actually from it are legitimate. Messages
forged by spammers are not legitimate, and I'm not saying they are.
If you say they are, then you're lying (or at least wrong).

Post by D. Stussy
Only when a mailbox that is protected by SPF and/or DK (or other, future
method)

No problem then: my mailbox is protected by Uncle Guido's Osteofractic
Mailbox Protection Service.

Post by D. Stussy
receives an NDR with respect to a message that is a forgery does
the NDR become backscatter

You may define terms however you wish. When you use terms in
non-standard ways, your ability to communicate ideas suffers and
instead of people saying "so what?" they say "You're wrong."

Post by D. Stussy
- i.e. backscatter can be sent ONLY by servers
that don't check for (or don't act on, by rejecting a message with) a
positive forgery status.

YM "Stussy-defined-backscatter" can be sent only by such servers. I
don't care about that; I want to stop Seth-defined backscatter (which
happens to match backscatterer-defined backscatter, and probably the
definitions of most other entities posting here).

Post by D. Stussy
Those are the ONLY misbehavers that should be listed.

Your opinion as to how others should behave is noted. How many users
does your list of sites that backscatter by your definition have?

Post by D. Stussy
It is YOUR responsibility

You don't get to invent and place responsibilities on others.

Post by D. Stussy
to tell them the criteria by which they can determine the message
isn't from you so that they have a reason not to generate the NDR.

OK: "If I didn't send it, then it isn't from me."

Post by D. Stussy
Without such, they are REQUIRED to generate the NDR for
message non-delivery (assuming it wasn't rejected for some other reason).

You can say they're required to do something. It doesn't matter; they
get listed for what they do, whether or not you claim (correctly or
not doesn't matter) that it's required.

Post by D. Stussy
If you don't want the possibility of backscatter, YOU need to tell them

I've told them.

Post by D. Stussy
(and do so with the tools already mentioned)

Oh, so now you get to list all the possible ways?

Post by D. Stussy
what may be a legitimate mesage and what isn't.

A message that I didn't send but which claims to come from me is not
legitimate. It's just that simple.

Post by D. Stussy
You have continuously LIED about what is going on here.

No, they haven't. You have continuously used incorrect definitions of
terms in order to support your claims.

Post by D. Stussy
You claim that your spamtrap mailboxes receive NDRs but that no
message is ever sent using any of them as sender.

No message is _legitimately_ sent (that is, by anyone authorized by
the mailbox owner to send it) from any of those mailboxes.

Post by D. Stussy
As an NDR can come only as a reply, this means that your spamtraps
were in fact used as senders by SOMEONE (presumedly, a spammer).

That's right.

Post by D. Stussy
That is a direct contradiction of your claim. I note that you
did not say that "you never send using them...." You said that "mail is
never sent with [them] as sender."

They aren't the sender. Some spammer is the sender.

Post by D. Stussy
Those statements don't mean the same thing.

In this case, they're both true.

Post by D. Stussy
Obviously, someone does send messages using your spamtraps as
source - and if these messages are not legitimate, you need to tell
us

As before, you don't get to create needs for others.

Seth

[Seth]

Post by Rob

Post by Steven Roberts
To the purist parts of the anti-backscatter camp that is viewed as
backscatter. my question is then how would one go about not sending
those? I am running postfix so some concrete pointers would be great.

The anti-backscatter camp want you to drop functionality to be
able to keep within their lines.
They say you should not send any bounce to their addresses.

You shouldn't send any bounce *for mail I didn't send* to *my email
address*. Any such bounce is *spam*.

Post by Rob
When you ask "how do I know it is their address" they will send
you in the woods suggesting that you should never send any bounce.

I don't care if you ever send bounces or not. Just don't send them to
me for forged email.

Post by Rob
Even though the standards say you should.

What standard requires you to spam the victim of forgery?

Post by Rob
So it is a problem that really cannot be solved.

Yes, it can. Configure your system correctly.

Post by Rob
It can only be ignored.

If you choose to ignore the "don't emit spam" part of the problem, you
deserve the consequences of emitting spam. Claiming you're required
to do so doesn't matter. If whoever requires you to (e.g. your boss)
has sufficient power, then you'll do what he requires and live with
the resulting blockage. If whoever requires you to (e.g. your own
misinterpretation of the RFCs) has no such power, then you make your
choice and the rest of us [tinrou] will make ours.

Seth

[DevilsPGD]

In message

Post by Steven Roberts
To start off, I am quite familiar with the concept of backscatter. I
also have confirmed all e-mail targets of the list in question. It is
not a matter of an invalid recipient.
The problem is this. Some of the recipients have a stricter SPAM
blocking policy than my server does. They are fine with more false
positives than I can administratively The result of course is that
then for some SPAM messages sent to the list my server does not block
them as it does not detect them as SPAM. it then tries to send the e-
mail on to the end-user. their mail server spits out a 554. this
then cause my mail server to generate a bounce.

A bounce to who? If you're sending bounces for mailing lists back to
posters of the mailing list, you've probably got bigger management
problems already festering.

If the mailing list is well run then there wouldn't be a bounce at all
(or at least not one that leaves your server), your server would detect
the 554 on outbound delivery and log it, hopefully flagging their
address as possibly not being active anymore (pending further
undeliverables)

[Hal Murray]

Post by Steven Roberts
To start off, I am quite familiar with the concept of backscatter. I
also have confirmed all e-mail targets of the list in question. It is
not a matter of an invalid recipient.
The problem is this. Some of the recipients have a stricter SPAM
blocking policy than my server does. They are fine with more false
positives than I can administratively The result of course is that
then for some SPAM messages sent to the list my server does not block
them as it does not detect them as SPAM. it then tries to send the e-
mail on to the end-user. their mail server spits out a 554. this
then cause my mail server to generate a bounce.
To the purist parts of the anti-backscatter camp that is viewed as
backscatter. my question is then how would one go about not sending
those? I am running postfix so some concrete pointers would be great.

You need to patch the return info on the mail that is getting sent
to the list so that bounces go to the list owner.

You may not be able to do that directly in the MTA you are using.

I expect most mailing list programs can do it. You probably want
to be using one of them anyway (rather than just letting your MTA
expand a list) to handle things like members of your list deleting
their accounts without telling you or having their quota fill up
while they are on vacation...