El grupo al cual envías entradas es un grupo Usenet. Si envías mensajes a este grupo, cualquier usuario de Internet podrá ver tu dirección de correo electrónico
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.
-- 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.
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. 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-boun...@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.
-- 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.
In message <1983c11b-286c-4fa6-a159-b65d7b832...@h14g2000pri.googlegroups.com> Steven Roberts <strobert.postt...@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)
-- 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.
Steven Roberts <strobert.postt...@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.
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.
-- 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.
On Nov 14, 6:18 am, MrD <mrdemean...@jackpot.invalid> wrote:
> 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?
-- 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.
Rob wrote: > 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 <BlackL...@Anitech-Systems.com> will be added to the BlackLists.
-- 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.
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.)
> 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 <mich...@talamasca.ocis.net>
-- 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.
In <hdpl9o$fh...@news.eternal-september.org>, on 11/15/2009 at 05:42 PM, E-Mail Sent to this address will be added to the BlackLists <N...@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.
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 spamt...@library.lspace.org
-- 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.
In <%MGHALR...@khar-pern.talamasca.ocis.net>, on 11/15/2009 at 09:49 PM, Michael Deutschmann <mich...@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.
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 spamt...@library.lspace.org
-- 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.
In article <1983c11b-286c-4fa6-a159-b65d7b832...@h14g2000pri.googlegroups.com>, Steven Roberts <strobert.postt...@gmail.com> writes:
>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.
-- 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.
> 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.
-- 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.
> 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.
-- 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.
On Mon, 16 Nov 2009, D. Stussy wrote: > "Michael Deutschmann" <mich...@talamasca.ocis.net> wrote in message > > "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?
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 <%MGHALR...@khar-pern.talamasca.ocis.net>, on 11/15/2009 ) at 09:49 PM, Michael Deutschmann <mich...@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 <mich...@talamasca.ocis.net>
-- 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.
goo...@guscreek.com wrote: > 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.
-- 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.
D. Stussy <repl...@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
-- 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.
In article <%vciALB...@khar-pern.talamasca.ocis.net>, Michael Deutschmann <mich...@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
-- 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.
In article <hdqb33$g2...@snarked.org>, D.Stussy spam+newsgro...@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.
-- 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.
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.
M4
-- 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.
> 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.
-- 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.
> In article <hdqb33$g2...@snarked.org>, D.Stussy > spam+newsgro...@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."
-- 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.
In article <slrnhfqqr5.1dae.nom...@xs7.xs4all.nl>,
Rob <nom...@example.com> wrote: >Steven Roberts <strobert.postt...@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
-- 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.
D. Stussy <repl...@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
-- 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.
I wrote a response to this earlier, but it seems to have gotten lost. (I received an initial acknowlegement, but no approval/disapproval message.)
On Tue, 17 Nov 2009, Seth wrote: > In article <%vciALB...@khar-pern.talamasca.ocis.net>, > Michael Deutschmann <mich...@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 <mich...@talamasca.ocis.net>
-- 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.
In <%5AQCLR...@khar-pern.talamasca.ocis.net>, on 11/22/2009 at 11:19 PM, Michael Deutschmann <mich...@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.
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 spamt...@library.lspace.org
-- 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.
D. Stussy <repl...@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
-- 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.
|
