backscatter and mailing lists
Steven Roberts
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.
--
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.
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.
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?).
> 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).
> 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.
--
MrD.
http://ipquery.org
DevilsPGD
<1983c11b-286c-4fa6...@h14g2000pri.googlegroups.com>
Steven Roberts <strobert...@gmail.com> was claimed to have wrote:
>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)
Rob
> 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.
Fallout
> 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?
E-Mail Sent to this address will be added to the BlackLists
> 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
...
> So it is a problem that really cannot be solved.
Except for those that _Reject_ messages,
instead of accepting, then bouncing.
> 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.
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Michael Deutschmann
> 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.)
> 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 <mic...@talamasca.ocis.net>
Shmuel (Seymour J.) Metz
at 05:42 PM, E-Mail Sent to this address will be added to the
BlackLists <Nu...@BlackList.Anitech-Systems.invalid> said:
>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 spam...@library.lspace.org
Shmuel (Seymour J.) Metz
at 09:49 PM, Michael Deutschmann <mic...@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:
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 spam...@library.lspace.org
--
Hal Murray
>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...
--
These are my opinions, not necessarily my employer's. I hate spam.
D. Stussy
news:%MGHA...@khar-pern.talamasca.ocis.net...
> On Sun, 15 Nov 2009, Rob wrote:
> > 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.
> > 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?
> 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.
goo...@guscreek.com
> Steven Roberts wrote:
> > 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.
>2. Your server accepts the spam as good mail. Fair enough.
Except it's not what he said.
Michael Deutschmann
> "Michael Deutschmann" <mic...@talamasca.ocis.net> wrote in message
> > 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?
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 <%MGHA...@khar-pern.talamasca.ocis.net>, on 11/15/2009
) at 09:49 PM, Michael Deutschmann <mic...@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 <mic...@talamasca.ocis.net>
MrD
> On Nov 13, 9:18 pm, MrD <mrdemean...@jackpot.invalid> wrote:
>> Steven Roberts wrote:
>>> 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."
>
>> 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.
--
MrD.
http://ipquery.org
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>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.
> 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?
> 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.
> (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.
>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.
> 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.
>> "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?
Where's your RFC claiming that failing to use your current FUSSP
authorizes any message and makes forgery impossible?
Seth
Seth
Michael Deutschmann <mic...@talamasca.ocis.net> wrote:
>The real problem here is mailservers that overcommit queue space,
That's the (solvable) problem right there. Don't Do That.
>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
Claus v. Wolfhausen
spam+ne...@bde-arc.ampr.org says...
>
>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.
>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
Martijn Lievaart
>> 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
news:miebt6-...@news.rtij.nl...
> On Tue, 17 Nov 2009 11:06:32 +0000, Seth wrote:
> >> 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.
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.
D. Stussy
message news:hdtv0o$8fs$1...@news.eternal-september.org...
> In article <hdqb33$g2i$1...@snarked.org>, D.Stussy
> spam+ne...@bde-arc.ampr.org says...
> >
> >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.
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.
> >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.
> 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.
> 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.
> 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."
Seth
Rob <nom...@example.com> wrote:
>Steven Roberts <strobert...@gmail.com> wrote:
>> 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*.
>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.
>Even though the standards say you should.
What standard requires you to spam the victim of forgery?
>So it is a problem that really cannot be solved.
Yes, it can. Configure your system correctly.
> 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
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>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?
>Unanticipated errors can always turn up.
But somehow, they don't stop NDRs?
Seth
Michael Deutschmann
received an initial acknowlegement, but no approval/disapproval message.)
On Tue, 17 Nov 2009, Seth wrote:
> In article <%vciA...@khar-pern.talamasca.ocis.net>,
> Michael Deutschmann <mic...@talamasca.ocis.net> wrote:
>
> >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 <mic...@talamasca.ocis.net>
Shmuel (Seymour J.) Metz
at 11:19 PM, Michael Deutschmann <mic...@talamasca.ocis.net> said:
>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 spam...@library.lspace.org
--
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>Yes, but you ALSO block those who wouldn't be sending you an NDR if
they had a properly configured mailserver.
>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?
> 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.
> 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?
> - 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.
>> 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?
>> 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.
>> 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".
> 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.
>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.
> The fault is YOURS, not theirs.
Backscatterer isn't about fault. It's about specific email messages.
What they send is their responsibility.
> 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.
> 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).
>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.
> 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."
> - 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).
> 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?
>It is YOUR responsibility
You don't get to invent and place responsibilities on others.
> 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."
> 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.
>If you don't want the possibility of backscatter, YOU need to tell them
I've told them.
>(and do so with the tools already mentioned)
Oh, so now you get to list all the possible ways?
> 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.
>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.
> 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.
> 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.
> 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.
> Those statements don't mean the same thing.
In this case, they're both true.
> 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