BACKSCATTERER - constantly listed after first payment and not being listed on any other list
Gaj Capuder
how could someone get more info about the listing, not just time
+-10mins?
It is frustrating to see our IP (195.88.82.2) being listed every week
or 2 becouse of a single new impact.
In 20mins range there can be quite some emails sent so it is basicly
imposible to find "the one".
We are not listed on anyother blacklist and we surely do not want to
be listed on this one which costs us 50eur per week now.
Can we get more info to solve our problem? Listing without any real
feedback wont solve the problem, it will just make Backscatterer's
bank account look nicer.
Best Regards,
Gaj Capuder
--
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.
Claus v. Wolfhausen
gaj.c...@gmail.com ranted...
>
>Hi,
>
>how could someone get more info about the listing, not just time
>+-10mins?
>It is frustrating to see our IP (195.88.82.2) being listed every week
>or 2 becouse of a single new impact.
>In 20mins range there can be quite some emails sent so it is basicly
>imposible to find "the one".
Hey the time and date is there to give you an idea in which logfile to search
only. The more interesting questinon is why you are trying to find "the one"
instead of solving the backscatter problem complete?
Just make sure that no NULL SENDER nor postmaster is claimed as sender on mails
that leave your networks and you are done.
>We are not listed on anyother blacklist and we surely do not want to
>be listed on this one which costs us 50eur per week now.
You should not pay before you fixed the problem ...
>Can we get more info to solve our problem? Listing without any real
>feedback wont solve the problem, it will just make Backscatterer's
>bank account look nicer.
We are not there to hold your hand.
As i said before search your maillogs for outgoing mails that are claiming to
be a NULL SENDER or POSTMASTER in MAIL FROM: and which got rejected at the
remote side. READ those rejection texts ...
Just in case you are claiming that would be new for you:
This information is also found at the lookup page of every active listing...
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
E-Mail Sent to this address will be added to the BlackLists
> It is frustrating to see our IP (195.88.82.2) being listed
> every week or 2 becouse of a single new impact.
> In 20mins range there can be quite some emails sent so it
> is basicly imposible to find "the one".
Just how many null sender messages do you have in 20 minutes?
{It should be close to none, or it is easy to believe
you are a source of backscatter.}
At risk of an ever increasing BI;
If you have access to the server logs, UCEprotect spamtrap
hits are usually very unique and blatantly obvious.
If you are sending messages to UCEprotect's SpamTraps,
that are getting listed as backscatter, (As opposed to SAV)
then the sender is likely postmaster@ or null sender <>.
Most of their spam trap rejects contain something like
V#.##-RULE-#### or V#.##-EXPO-#### .
Most also contain "uceprotect", however not all seem to;
{Perhaps some of the appliance reject messages are modified
by end customer admins?}
I have seen I've seen "backscatter" in some of their
spamtrap rejects, with no reference to "backscatterer".
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Gaj Capuder
of null sender emails and reconfigure our mail server.
Still i do not understand why does this makes us a spamer.
Best Regards,
Gaj Capuder
Shmuel (Seymour J.) Metz
10/26/2009
at 03:54 PM, Gaj Capuder <gaj.c...@gmail.com> said:
>It is frustrating to see our IP (195.88.82.2) being listed every week or
>2 becouse of a single new impact.
Why do you believe that it is only a single impact? It's dollars to donuts
that you're sending more than you believe.
>In 20mins range there can be quite some emails sent so it is basicly
>imposible to find "the one".
There is no reason for you to find the one that hit the spam trap; you
should be finding and fixing whatever is causing the backscatter.
>We are not listed on anyother blacklist
How do you know?
>which costs us 50eur per week n
Their web site tells you to fix the problem before requesting express
delisting. If you're paying Õ50/week then it's clear that you ignored
that.
>Can we get more info to solve our problem? Listing without any real
>feedback wont solve the problem, it will just make Backscatterer's bank
>account look nicer.
I imagine that Claus will eventually solve the problem by not accepting
any more express delisting payments once you pass whatever his threshold
is. He doesn't want the payments, he wants the MTA fixed.
BTW, I would like to see the supporting data more complete and in a
friendlier format, but I'm not sure how much Claus can do without
compromising his spam traps.
--
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
Winston
> Still i do not understand why does this makes us a spamer.
It doesn't, per se. The problem is that mail systems that backscatter can
easily be used by spammers to deliver spam.
Similarly, with a compromised machine, it doesn't matter whether the owner
is the one originating the spam, just whether spam is coming from it.
-WBE
Shmuel (Seymour J.) Metz
10/26/2009
at 08:58 PM, Gaj Capuder <gaj.c...@gmail.com> said:
>Still i do not understand why does this makes us a spamer.
Because when you get a forged reverse path you send a DSN to it, and those
DSN's are unsolicited bulk e-mail.
--
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
--
Michelle Sullivan
> In <c557a647-7e6a-4c93...@o21g2000vbl.googlegroups.com>, on
> 10/26/2009
> at 03:54 PM, Gaj Capuder <gaj.c...@gmail.com> said:
>
>> It is frustrating to see our IP (195.88.82.2) being listed every week or
>> 2 becouse of a single new impact.
>
> Why do you believe that it is only a single impact? It's dollars to donuts
> that you're sending more than you believe.
>
>> In 20mins range there can be quite some emails sent so it is basicly
>> imposible to find "the one".
>
> There is no reason for you to find the one that hit the spam trap; you
> should be finding and fixing whatever is causing the backscatter.
...and in my case there was one (and still is one) and only 1 piece of
backscatter that hits their traps every seven days. There is no other
back scatter... So maybe the OP should be looking for "The One"... Of
course the OP might be sending 100's therefore he should fix the
problem, but if he isn't well he'll need to find the one.
Shells
Fallout
wrote:
> Shmuel (Seymour J.) Metz wrote:
>
> > 10/26/2009
> > at 03:54 PM, Gaj Capuder <gaj.capu...@gmail.com> said:
>
> >> It is frustrating to see our IP (195.88.82.2) being listed every week or
> >> 2 becouse of a single new impact.
>
> > Why do you believe that it is only a single impact? It's dollars to donuts
> > that you're sending more than you believe.
>
> >> In 20mins range there can be quite some emails sent so it is basicly
> >> imposible to find "the one".
>
> > There is no reason for you to find the one that hit the spam trap; you
> > should be finding and fixing whatever is causing the backscatter.
>
> ...and in my case there was one (and still is one) and only 1 piece of
> backscatter that hits their traps every seven days. There is no other
> back scatter... So maybe the OP should be looking for "The One"... Of
> course the OP might be sending 100's therefore he should fix the
> problem, but if he isn't well he'll need to find the one.
>
> Shells
>
> --
> 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.htmlbefore posting.
But still Michelle, it is backscatter since they're not sending you
that badly formatted data, are they? Do you have any kind of proof /
suspicion they sent it? What about the sending IP?
Of course, there is no way of knowing for them how many other
thousands of backscatter e-mail a system sends before/after it hit
their spamtrap...
Michelle Sullivan
>
> But still Michelle, it is backscatter since they're not sending you
> that badly formatted data, are they? Do you have any kind of proof /
> suspicion they sent it? What about the sending IP?
I can suspect all I like, and I have good reason to suspect based on the
timing and frequency, but that's all I have and I am way over it.
> Of course, there is no way of knowing for them how many other
> thousands of backscatter e-mail a system sends before/after it hit
> their spamtrap...
Yeah there is ;-) That I can tell you. In my case there is zero for
the last 12 months. Before that.. well I can't tell you because I don't
have logs going back that far.
(hint: UCEProtect/Backscatter.org servers are very easily identified in
my logs)
D. Stussy
message news:4ae70779$4$fuzhry+tra$mr2...@news.patriot.net...
> In <50462ccb-de7c-4c64...@b25g2000prb.googlegroups.com>,
on
> 10/26/2009
> at 08:58 PM, Gaj Capuder <gaj.c...@gmail.com> said:
>
> >Still i do not understand why does this makes us a spamer.
>
> Because when you get a forged reverse path you send a DSN to it, and
those
> DSN's are unsolicited bulk e-mail.
I have yet to see a real answer to this question:
How is he supposed to know that the reverse path was forged if the owner of
that mailbox or domain has not published an SPF or DK/DKIM record?
Shmuel (Seymour J.) Metz
at 05:41 AM, Michelle Sullivan <michell...@sorbs.net> said:
>(hint: UCEProtect/Backscatter.org servers are very easily identified in
>my logs)
If you have received e-mail from one of their mail servers, why have you
not notified them of the messages and timestamps? OTOH, if their domains
are appearing in HELO/EHLO or reverse paths, that doesn't mean it came
from their servers.
--
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
--
DevilsPGD
<spam+ne...@bde-arc.ampr.org> was claimed to have wrote:
>"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in
>message news:4ae70779$4$fuzhry+tra$mr2...@news.patriot.net...
>> In <50462ccb-de7c-4c64...@b25g2000prb.googlegroups.com>,
>on
>> 10/26/2009
>> at 08:58 PM, Gaj Capuder <gaj.c...@gmail.com> said:
>>
>> >Still i do not understand why does this makes us a spamer.
>>
>> Because when you get a forged reverse path you send a DSN to it, and
>those
>> DSN's are unsolicited bulk e-mail.
>
>I have yet to see a real answer to this question:
>
>How is he supposed to know that the reverse path was forged if the owner of
>that mailbox or domain has not published an SPF or DK/DKIM record?
You *don't* know. That's the whole point, if you did know then you'd
know whether you could send a response or not, but since you don't know,
you must assume the worst.
Claus v. Wolfhausen
>
>Fallout wrote:
>>
>> But still Michelle, it is backscatter since they're not sending you
>> that badly formatted data, are they? Do you have any kind of proof /
>> suspicion they sent it? What about the sending IP?
>
>
>I can suspect all I like, and I have good reason to suspect based on the
>timing and frequency, but that's all I have and I am way over it.
>
>
>> Of course, there is no way of knowing for them how many other
>> thousands of backscatter e-mail a system sends before/after it hit
>> their spamtrap...
>
>Yeah there is ;-) That I can tell you. In my case there is zero for
>the last 12 months. Before that.. well I can't tell you because I don't
>have logs going back that far.
>
>(hint: UCEProtect/Backscatter.org servers are very easily identified in
>my logs)
That is intentional. I really have to wonder why you still hit traps ....
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
--
Winston
>>> Still i do not understand why does this makes us a spamer.
"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> replied:
>> Because when you get a forged reverse path you send a DSN to it, and
>> those DSN's are unsolicited bulk e-mail.
"D. Stussy" <spam+ne...@bde-arc.ampr.org> then replied:
> How is he supposed to know that the reverse path was forged if the owner of
> that mailbox or domain has not published an SPF or DK/DKIM record?
Obviously he doesn't, so the policy for sending DFNs should be one that
works when "maybe it's forged; maybe it's not".
The new policy seems to be: if mail comes from "inside" (users, customers,
and IP addresses "we" own and can verify because we know our own SPF
criteria whether or not it's exported to the world), DFNs are fine; mail
from "outside" must be SMTP accepted or rejected at the entrance/border,
and DFNs are not sent if there's any chance the MAIL FROM is forged.
Even the user-based "vacation" notifications are a risk.
-WBE
Jonathan Knight
>> that mailbox or domain has not published an SPF or DK/DKIM record?
>
> You *don't* know. That's the whole point, if you did know then you'd
> know whether you could send a response or not, but since you don't know,
> you must assume the worst.
Or do you assume that if there's no SPF or DKIM then the domain is
prepared to accept backscatter?
Surely as SPF and DKIM become widely implemented that will become the
case. The whole argument around backscatter will become moot as the
method of stopping it for your domain becomes easier to deploy.
So the effort to reduce backscatter should move away from RBL's and
complaining about mail admins who return NDR's for over quota inboxes
and out of office messages and towards wider use of SPF and DKIM as that
looks to be the future.
Jon.
Claus v. Wolfhausen
spam+ne...@bde-arc.ampr.org says...
>
>"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in
>message news:4ae70779$4$fuzhry+tra$mr2...@news.patriot.net...
>> In <50462ccb-de7c-4c64...@b25g2000prb.googlegroups.com>,
>on
>> 10/26/2009
>> at 08:58 PM, Gaj Capuder <gaj.c...@gmail.com> said:
>>
>> >Still i do not understand why does this makes us a spamer.
>>
>> Because when you get a forged reverse path you send a DSN to it, and
>those
>> DSN's are unsolicited bulk e-mail.
>
>I have yet to see a real answer to this question:
>
>How is he supposed to know that the reverse path was forged if the owner of
>that mailbox or domain has not published an SPF or DK/DKIM record?
It was told to you several times, but you still did not get it?
It is not necessary to know if the reverse path is forged...
It is necessary to know the reverse path is authentic before sending a bounce.
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
======================================= MODERATOR'S COMMENT:
my apologies for the tardiness; i was traveling and i misfiled some mail.
DevilsPGD
<j.kn...@kis.keele.ac.uk> was claimed to have wrote:
>DevilsPGD wrote:
>> In message <hc7mk4$94g$1...@snarked.org> "D. Stussy"
>>> How is he supposed to know that the reverse path was forged if the owner of
>>> that mailbox or domain has not published an SPF or DK/DKIM record?
>>
>> You *don't* know. That's the whole point, if you did know then you'd
>> know whether you could send a response or not, but since you don't know,
>> you must assume the worst.
>
>Or do you assume that if there's no SPF or DKIM then the domain is
>prepared to accept backscatter?
No, that would be silly.
>Surely as SPF and DKIM become widely implemented that will become the
>case. The whole argument around backscatter will become moot as the
>method of stopping it for your domain becomes easier to deploy.
So if you don't wear a "please don't punch me in the face" sign, I'm
free to take a shot?
I'm a proponent of both SPF and DKIM and use both on both inbound and
outbound mail, but I don't accept blaming the victim.
I'd be willing to support discarding bounces by default and only ever
sending a bounce when the sender can be reliably identified.
siversoncan
>
> So if you don't wear a "please don't punch me in the face" sign, I'm
> free to take a shot?
>
> I'm a proponent of both SPF and DKIM and use both on both inbound and
> outbound mail, but I don't accept blaming the victim.
If you don't accept blaming the victim, then why do you suppose it
would be "silly" to accept that users that don't employ SPF or DKIM
are willing to receive backscatter. Surely their servers are
misconfigured to not provide a method of forgery detection. In the
fight against SPAM we are all victims as we all have to take elaborate
and costly steps to keep SPAM out of our mailboxes. No one is more
deserving of that title than anyone else.
So if you don't want to blame the victim, then you shouldn't blame the
server operator that doesn't completely eliminate all forms of
backscatter if you are also not going to blame the server operator
that gets hit by backscatter because they didn't employ a method of
forgery detection.
At least the server operator who employs SPF or DKIM detection is
doing his bit to reduce SPAM.
SPAM is a menace and anyone who is fighting SPAM should be applauded.
Those who do nothing to stop it should not be given an elevated status
compared to those that are fighting it.
D. Stussy
news:hcedhq$l7j$1...@north.jnrs.ja.net...
> DevilsPGD wrote:
> > In message <hc7mk4$94g$1...@snarked.org> "D. Stussy"
> >> How is he supposed to know that the reverse path was forged if the
owner of
> >> that mailbox or domain has not published an SPF or DK/DKIM record?
> >
> > You *don't* know. That's the whole point, if you did know then you'd
> > know whether you could send a response or not, but since you don't
know,
> > you must assume the worst.
I agree that's the point: We are NOT told that these are forged, so the
current standards tell us to treat them as NOT FORGED so as to be backwards
compatible with the status-quo that existed before these methods existed
thus allowing legitimate mail from domains that haven't implemented them to
be delivered without hinderance.
Assuming the worst is contrary to the standards. Even RFCs 5321 & 5322 say
we "need a reason" to refuse mail, not the lack of one.
A change to the standards or public policies (including "Best Current
Practices") requires an RFC to propose the change. There have been none.
> Or do you assume that if there's no SPF or DKIM then the domain is
> prepared to accept backscatter?
If there's no SPF or DK record, that tells me that there are NO forgeries
and all mail was authorized from whatever source it came from.
Remember that this says NOTHING about its spam status or other content
issues (e.g. viruses) which can lead to legitimate reasons to reject any
message.
> Surely as SPF and DKIM become widely implemented that will become the
> case. The whole argument around backscatter will become moot as the
> method of stopping it for your domain becomes easier to deploy.
What's so difficult about deploying SPF (as a mail sender)? One identifes
all the sending points and lists them in a DNS-RR. There are several tools
out there that will even generate the required record and test it.
Copy-and-paste is within the capabilities of most administrators.
As a mail receiver, all one needs to do is install any one of several
available plugins for various MTAs that check for SPF and DK records.
I see that by saying the backscatterer list "will become moot" acknowledges
that the list is used to enforce the behavior that mail recipients check
for these records and reject forged mail during SMTP. It also requires
that senders implement SPF or DK. However, remember that such hasn't even
been proposed as a standards requirement (BCP or otherwise), despite my
suggestion that the list adminstrator do so.
> So the effort to reduce backscatter should move away from RBL's and
> complaining about mail admins who return NDR's for over quota inboxes
> and out of office messages and towards wider use of SPF and DKIM as that
> looks to be the future.
Not possible. As I have previously demonstrated, a full mailbox and other
such errors can be minimized but NOT eliminated.
Also, what does "vacation" responses have to do with this? If their
generators only see mail that has been through the checks (i.e. not forged
and not spam), these autoreplies will be going to legitimate senders who
actually originated the inbound mail, so how would they ever be considered
backscatter?
Jonathan Knight
> In message <hcedhq$l7j$1...@north.jnrs.ja.net> Jonathan Knight
> <j.kn...@kis.keele.ac.uk> was claimed to have wrote:
>
>> DevilsPGD wrote:
>> Or do you assume that if there's no SPF or DKIM then the domain is
>> prepared to accept backscatter?
>
> No, that would be silly.
>
>> Surely as SPF and DKIM become widely implemented that will become the
>> case. The whole argument around backscatter will become moot as the
>> method of stopping it for your domain becomes easier to deploy.
>
> So if you don't wear a "please don't punch me in the face" sign, I'm
> free to take a shot?
Hmmmm... Now who's being silly.
What you can assume has to be put in context. Punching someone in the
face is unacceptable in the street but fairly compulsory in a boxing
ring. Neither case needs a notice as the convention is well understood
by those taking part. (Okay - there are exceptions, usually found in
city centres when the pubs/night clubs/bars close)
Much like the "abuse@" email address started out as a good idea, became
a convention and was then enshrined as a requirement in the standards
there is every possibility that DKIM/SPF will evolve in a similar way.
Today, you cannot assume that a lack of SPF/DKIM means that the domain
accepts backscatter because the implementations of SPF/DKIM are not yet
widely available enough. At some point in the future we can hope that
SPF/DKIM is available in all the main mail systems. When such a time
exists the decision to not have SPF/DKIM enabled will be the choice of
the mail administrator and we can then assume that backscatter is
acceptable if SPF/DKIM is not deployed.
At that point we will be able to generate NDR's without fear of creating
unwanted backscatter.
I was being a bit provocative towards the members of this newsgroup who
argue that no NDR's should ever be sent because you cannot verify the
sender. It seems that the technology has been invented to solve the
problem so should we berate the mail admins who generate backscatter or
encourage them to deploy SPF/DKIM?
Unfortunately UCE Protect don't seem to have SPF on their trap domains.
Perhaps they could lead by example.
Jon.
Steve Baker
wrote:
>If you don't accept blaming the victim, then why do you suppose it
>would be "silly" to accept that users that don't employ SPF or DKIM
>are willing to receive backscatter.
Maybe users don't want backscatter and still don't deploy SPF
because it breaks forwarding?
--
Steve Baker
DevilsPGD
<cd76ea7d-f252-4b61...@m7g2000prd.googlegroups.com>
siversoncan <greed...@hotmail.com> was claimed to have wrote:
>On Nov 4, 9:52 am, DevilsPGD <DeathToS...@crazyhat.net> wrote:
>>
>> So if you don't wear a "please don't punch me in the face" sign, I'm
>> free to take a shot?
>>
>> I'm a proponent of both SPF and DKIM and use both on both inbound and
>> outbound mail, but I don't accept blaming the victim.
>
>If you don't accept blaming the victim, then why do you suppose it
>would be "silly" to accept that users that don't employ SPF or DKIM
>are willing to receive backscatter. Surely their servers are
>misconfigured to not provide a method of forgery detection.
If SPF or DKIM were mandatory, then I'd agree. They're not required
parts of the SMTP spec.
Backscatter isn't explicitly prohibited, but it does seem to get you
blocklisted, otherwise this discussion wouldn't be happening.
>In the
>fight against SPAM we are all victims as we all have to take elaborate
>and costly steps to keep SPAM out of our mailboxes.
Agreed.
Are you suggesting it's acceptable to make your spam problem into my
backscatter problem?
>No one is more deserving of that title than anyone else.
It's all about who becomes who's victim here I suppose. Spammers abuse
you and spammers abuse me, we both do what we can to mitigate that,
we're both victims of spammers.
If your mitigation causes uninvolved third parties harm, they become
victims of you. Spammers may have contributed to the harm, and aren't
off the hook for forgery, but you're the one who passed the abuse on to
someone else.
To try an analogy, someone keeps throwing bricks through your window
that say "from crazyhat.net", does that make it right for you to throw
those bricks through my window? -- Sure, if the spammer stopped putting
my name on bricks you might stop throwing them at me, but I'm still your
victim.
siversoncan
> It's all about who becomes who's victim here I suppose. Spammers abuse
> you and spammers abuse me, we both do what we can to mitigate that,
> we're both victims of spammers.
>
> If your mitigation causes uninvolved third parties harm, they become
> victims of you. Spammers may have contributed to the harm, and aren't
> off the hook for forgery, but you're the one who passed the abuse on to
> someone else.
>
> To try an analogy, someone keeps throwing bricks through your window
> that say "from crazyhat.net", does that make it right for you to throw
> those bricks through my window? -- Sure, if the spammer stopped putting
> my name on bricks you might stop throwing them at me, but I'm still your
> victim.
>
I disagree. It is better to do something than to do nothing.
If I configure my server to accept all mail then there will be no
misdirected bounces, but the spammers will be encouraged to keep
sending their crap my way.
I realize that not everyone is going to put an antispam plan in place,
but the more people that do, the worse off the spammers are.
If my attempt to reduce SPAM causes some people to receive unsolicited
bounces, then I am not doing a great job combatting SPAM. However the
internet community is in better shape with less SPAM and more bounces
than it is with more SPAM and less bounces because SPAM that gets
through generates income for the SPAMMERS and if there is no income
for SPAMMERS there is no SPAM.
Bounces can be controlled with enough effort, but there are never
unlimited resources and in principle I would rather get unsolicited
bounces than hear stories about people losing their money to some
internet scam artist.
I took the time and effort to stop my system from emitting
backscatter, but not everyone is as clever.
If a stray bounce can get someone to configure SPF on their server
then that is a positive result.
Frankly, if it wasn't for the odd admin who configures their server to
block my mail based on a listing on backscatterer.org then I would
consider allowing backscatter to non SPF protected servers just as way
to influence them into getting SPF set up. Just think how much better
off we would be if everyone added SPF records to their servers.
Backscatter could be used as a public service message, especially if
there was a text attached like "if this is an unsolicited message, it
means you did not configure SPF on your mail server."
Shmuel (Seymour J.) Metz
at 09:30 PM, Jonathan Knight <j.kn...@kis.keele.ac.uk> said:
>What you can assume has to be put in context.
In the context of e-mail, UBE is unacceptable.
>there is every possibility that DKIM/SPF will evolve in a similar way.
K3wl. If it does then there will be RFC's on the standards track. As long
as the relevant RFC's are designated as experimental, there is no
justification for demanding deployment. Even the networks publishing,
e.g., SPF, are not consistently checking the data. My best guess is that
some validation protocol will become a standard but that it will be new
and that it won't be soon.
>we can then assume that backscatter is
>acceptable if SPF/DKIM is not deployed.
You can assume what you want, but unless use of the standard becomes
mandatory backscatter will still be treated like any other spam.
>It seems that the technology has been invented to solve the problem
No, SPF does not validate that the owner of the mailbox authorized its
use.
>Unfortunately UCE Protect don't seem to have SPF on their trap domains.
It might be unfortunate for spammers; it's not unfortunate for their
users.
> Perhaps they could lead by example.
They do. If you want a list that excludes certaion types of backscatter,
start your own.
--
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
--
Fallout
> Bounces can be controlled with enough effort, but there are never
> unlimited resources and in principle I would rather get unsolicited
> bounces than hear stories about people losing their money to some
> internet scam artist.
>
> I took the time and effort to stop my system from emitting
> backscatter, but not everyone is as clever.
Why would anyone need to use a mail server if they didn't have the
'resources' or 'cleverness' to stop bounces? It's *free*, just as
stopping spam. But corporations backscatter too :) the problem is they
don't care, not that they can't stop it...
> If a stray bounce can get someone to configure SPF on their server
> then that is a positive result.
> Frankly, if it wasn't for the odd admin who configures their server to
> block my mail based on a listing on backscatterer.org then I would
> consider allowing backscatter to non SPF protected servers just as way
> to influence them into getting SPF set up.
Yeah, that will work. About as well as SPEWS :-) People don't respond
to 'forcing' like this. Besides, read your sentence again, it breaks
logically. Why would those admins want to set up SPF records, since
you backscatter them *without* checking SPF records - in order to
convince them to set up SPF records, of course. It's like, a wonderful
catch 22!
> Just think how much better
> off we would be if everyone added SPF records to their servers.
> Backscatter could be used as a public service message, especially if
> there was a text attached like "if this is an unsolicited message, it
> means you did not configure SPF on your mail server."
You are confused about what SPF can do, I was too at first. The thing
is, if we both have an yahoo.com account, I log on with my user and
send out 1 million spam with *your* user as MAIL FROM: , how is SPF
going to help when backscatter comes to you?
I think SPF is just great for small and/or in-house mail servers when
you don't need some extra functionality, but it has its unsurpasable
limits so it makes no sense to make it mandatory or universally deploy
it.
DevilsPGD
<e2c3d6ab-79ea-4188...@y28g2000prd.googlegroups.com>
siversoncan <greed...@hotmail.com> was claimed to have wrote:
>On Nov 6, 2:51 pm, DevilsPGD <DeathToS...@crazyhat.net> wrote:
>
>> It's all about who becomes who's victim here I suppose. Spammers abuse
>> you and spammers abuse me, we both do what we can to mitigate that,
>> we're both victims of spammers.
>>
>> If your mitigation causes uninvolved third parties harm, they become
>> victims of you. Spammers may have contributed to the harm, and aren't
>> off the hook for forgery, but you're the one who passed the abuse on to
>> someone else.
>>
>> To try an analogy, someone keeps throwing bricks through your window
>> that say "from crazyhat.net", does that make it right for you to throw
>> those bricks through my window? -- Sure, if the spammer stopped putting
>> my name on bricks you might stop throwing them at me, but I'm still your
>> victim.
>>
>I disagree. It is better to do something than to do nothing.
So you would throw bricks through my window because someone other then
me threw rocks through your window with a "from crazyhat.net" note on
the bricks?
I realize I'm overusing the analogy, but it seems to fit.
If you honestly consider this progress, then all I can ask is for a list
of your IPs, I'd like to preemptively block them before I become your
victim.
>If I configure my server to accept all mail then there will be no
>misdirected bounces, but the spammers will be encouraged to keep
>sending their crap my way.
That's one way to avoid generating backscatter. It's not the approach
I'd recommend, or the approach I take on my clients' servers...
>I realize that not everyone is going to put an antispam plan in place,
>but the more people that do, the worse off the spammers are.
>If my attempt to reduce SPAM causes some people to receive unsolicited
>bounces, then I am not doing a great job combatting SPAM.
huh? There is a difference between "my attempt to reduce spam causes a
spammer to do 'x'..." and "I configure my server 'x'..."
>However the
>internet community is in better shape with less SPAM and more bounces
>than it is with more SPAM and less bounces because SPAM that gets
>through generates income for the SPAMMERS and if there is no income
>for SPAMMERS there is no SPAM.
Unless your server is particularly poorly configured you should never
ever be bouncing something you think might be spam, so this whole spam
vs bounces argument is, at best, a straw man. It doesn't exist.
Block all the spam you can, you have no argument with me, just don't
start forwarding your spam to me.
>I took the time and effort to stop my system from emitting
>backscatter, but not everyone is as clever.
If someone isn't competent to handle basic mail server configuration and
administration, they should either hire these necessary skills,
outsource, or limit themselves to other communication methods.
siversoncan
> On Nov 9, 11:50 pm, siversoncan <greedysn...@hotmail.com> wrote:
>
> Why would anyone need to use a mail server if they didn't have the
> 'resources' or 'cleverness' to stop bounces? It's *free*, just as
> stopping spam. But corporations backscatter too :) the problem is they
> don't care, not that they can't stop it...
>
Not *all* emailers are mail server admins. Not *all* emailers have
enough influence to get the server admins to make the proper changes.
Here are a couple example of people that may not have the resources.
Elementary school student. Junior office clerk.
> > If a stray bounce can get someone to configure SPF on their server
> > then that is a positive result.
> > Frankly, if it wasn't for the odd admin who configures their server to
> > block my mail based on a listing on backscatterer.org then I would
> > consider allowing backscatter to non SPF protected servers just as way
> > to influence them into getting SPF set up.
>
> Yeah, that will work. About as well as SPEWS :-) People don't respond
> to 'forcing' like this.
Sure they do. Plenty of people have purchased personal SPAM filters to
get rid of SPAM or signed up with service providers that provide built
in SPAM filters, because they are anoyed with the SPAM they get. That
should work just as well with backscatter.
> Besides, read your sentence again, it breaks
> logically. Why would those admins want to set up SPF records, since
> you backscatter them *without* checking SPF records
I never said I backscattered without checking SPF. You should check
*your* logic.
If I only return NDRs to people that don't fail SPF checking (ie the
sender either matches the SPF record or there is no SPF record) then
only those that sent messages from non-forged accounts and those that
don't use SPF would get a bounce message. Therefore if you get a
bounce from me for a message you did not send then I can assume that
you did not set up SPF records for your server.
>
> You are confused about what SPF can do, I was too at first. The thing
> is, if we both have an yahoo.com account, I log on with my user and
> send out 1 million spam with *your* user as MAIL FROM: , how is SPF
> going to help when backscatter comes to you?
>
I would think that Yahoo.com would be able to detect a person sending
1 milion forged emails from their domain.
And I'm sure that person would be prosecuted and likely convicted. If
you sent those emails from an IP address that does not belong to Yahoo
and said it came from a Yahoo address I'm sure that servers with SPF
configured would reject them for failing SPF checking.
MrD
>>
>> To try an analogy, someone keeps throwing bricks through your
>> window that say "from crazyhat.net", does that make it right for
>> you to throw those bricks through my window? -- Sure, if the
>> spammer stopped putting my name on bricks you might stop throwing
>> them at me, but I'm still your victim.
>>
> I disagree. It is better to do something than to do nothing. If I
> configure my server to accept all mail then there will be no
> misdirected bounces, but the spammers will be encouraged to keep
> sending their crap my way.
As a response to the claim that you're dumping your spam on someone
else, making them a victim of your spam, that's an incoherent response.
> I realize that not everyone is going to put an antispam plan in
> place, but the more people that do, the worse off the spammers are.
Trite, and yet not obviously true.
> If my attempt to reduce SPAM causes some people to receive
> unsolicited bounces, then I am not doing a great job combatting SPAM.
> However the internet community is in better shape with less SPAM and
> more bounces than it is with more SPAM and less bounces because SPAM
> that gets through generates income for the SPAMMERS and if there is
> no income for SPAMMERS there is no SPAM.
Arguments of the form "If X then there is no spam" are rightly treated
with extreme suspicion nowadays. Google FUSSP.
> Bounces can be controlled with enough effort, but there are never
> unlimited resources and in principle I would rather get unsolicited
> bounces than hear stories about people losing their money to some
> internet scam artist.
But it's not you that's getting these bogus bounces.
>
> I took the time and effort to stop my system from emitting
> backscatter, but not everyone is as clever.
So they should have their system configured by someone that is (a) as
clever as you, and (b) cognizant of the nuisance that is bogus bounces.
> If a stray bounce can get someone to configure SPF on their server
> then that is a positive result.
Not necessarily. SPF is not a FUSSP. And it doesn't work in certain
common circumstances.
> Frankly, if it wasn't for the odd admin who configures their server
> to block my mail based on a listing on backscatterer.org then I would
> consider allowing backscatter to non SPF protected servers just as
> way to influence them into getting SPF set up. Just think how much
> better off we would be if everyone added SPF records to their
> servers.
OK, I considered that (just a little, perhaps, was the conclusion I came
to).
> Backscatter could be used as a public service message, especially if
> there was a text attached like "if this is an unsolicited message, it
> means you did not configure SPF on your mail server."
>
Are you saying you're actually in favour of backscatter? If so, you're
swimming against the stream.
--
MrD.
http://ipquery.org
E-Mail Sent to this address will be added to the BlackLists
> I would think that Yahoo.com would be able to detect a
> person sending 1 milion forged emails from their domain.
> And I'm sure that person would be prosecuted and likely
> convicted.
Really?
I didn't realize doing so would be against the law
everywhere in the world, and that if it was those laws
were actually aggressively enforced (anywhere).
{Seems extremely unlikely to me.}
e.g. I doubt it is against the law in Somalia
or Afghanistan, and almost certainly not enforced
in the former, and fairly unlikely to be enforced
in the later, except perhaps as something like
enforcement against generally using technology at all .
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Shmuel (Seymour J.) Metz
11/09/2009
at 09:50 PM, siversoncan <greed...@hotmail.com> said:
>I disagree. It is better to do something than to do nothing.
Blocking your server is doing something.
>If I configure my server to accept all mail then there will be no
>misdirected bounces, but the spammers will be encouraged to keep sending
>their crap my way.
How will spamming a 3rd party discourage the spammers?
>However the internet community is in better shape with less SPAM
The issue is your spam (lc), not the registered trademark of a lunch meat.
>and more bounces than it is with more SPAM and less bounces
If your grandmother had wheels she'd be a wagon. Your bounces are
increasing the spam, not reducing it.
>If a stray bounce can get someone to configure SPF on their server then
>that is a positive result.
The snake oil might make them feel better, but it won't noticably decrease
their spam load.
>Just think how much better
>off we would be if everyone added SPF records to their servers.
Perhaps in some alternate universe where the 800 lb gorillas are actually
requiring appropriate[1] SPF records.
[1] E.g., not Neutral or SoftFail.
--
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
--
Fallout
> Not *all* emailers are mail server admins. Not *all* emailers have
> enough influence to get the server admins to make the proper changes.
> Here are a couple example of people that may not have the resources.
> Elementary school student. Junior office clerk.
So they send through their ISP, school's, company's mail server. Then
the backscatter is those entities' problem.
> Sure they do. Plenty of people have purchased personal SPAM filters to
> get rid of SPAM or signed up with service providers that provide built
> in SPAM filters, because they are anoyed with the SPAM they get. That
> should work just as well with backscatter.
People paid/used spam filters because they understand what it does and
how it can help them - reduce spam. But how many average email users
do you think know what backscatter is and how to stop it? Because
backscatter goes to the average user, not the admin.
Your scenario: you send Average Joe a NDR. Joe sees that a message he
never sent bounced back because the recepient he never heard of
doesn't exist/has mailbox full/whatever and he will start searching
google, to find out what he received is called "backscatter" and can
be "stopped" by deploying this thing called SPF. So he immediately
forwards it to his admin demanding they deploy SPF right away!
Seems feasible enough for you?
> I never said I backscattered without checking SPF. You should check
> *your* logic.
> If I only return NDRs to people that don't fail SPF checking (ie the
> sender either matches the SPF record or there is no SPF record) then
> only those that sent messages from non-forged accounts and those that
> don't use SPF would get a bounce message. Therefore if you get a
> bounce from me for a message you did not send then I can assume that
> you did not set up SPF records for your server.
OK, but still see above for the result of your bounce :-)
> I would think that Yahoo.com would be able to detect a person sending
> 1 milion forged emails from their domain.
Detect when? After I sent the spam? What about 1000 emails from 1000
accounts? They're free to make, no hassle :-) So would you like it if
you were the recepient of the 1 million backscatters coming your way?
Yahoo.com was just an example, of course. Insert any server you want,
the point was SPF can't protect you from someone using the same
sending IP (for instance, a customer of your ISP, or webhost) forging
your e-mail at MAIL FROM: then happily spamming away...again, how
would you like it if that backscatter returned to you?
> And I'm sure that person would be prosecuted and likely convicted. If
> you sent those emails from an IP address that does not belong to Yahoo
> and said it came from a Yahoo address I'm sure that servers with SPF
> configured would reject them for failing SPF checking.
Oh right. Because in the real world, spammers get found, prosecuted
and convicted *all the time*. When a spammer is convicted it is not
the exception but the rule. How come I missed that? lol
Irony aside, for instance I know of no case where anyone was convicted
or even fined for spam in my country, and we just made the top10 of
spam-sending countries according to some reports (hurray!)
MrD
>
> Irony aside, for instance I know of no case where anyone was
> convicted or even fined for spam in my country, and we just made the
> top10 of spam-sending countries according to some reports (hurray!)
>
But that's pretty bad, when considered on a per-head-of-pop basis.
--
MrD.
http://ipquery.org
Fallout
> Romania? "Just made the top 10"? Sounds about right.
>
> But that's pretty bad, when considered on a per-head-of-pop basis.
Well internet scams are very popular here, a national sport in some
areas :) so I suspect most spams are phishing and scam related. I see
more than a dozen phishing/scam e-mails pretending to be from romanian
banks at work, on a very small mail server, but I'm sure the majority
of it is targeted at US/Canada ebay/paypal customers
Seth
siversoncan <greed...@hotmail.com> wrote:
>On Nov 10, 8:00 am, Fallout <ad...@ascomex.ro> wrote:
>> On Nov 9, 11:50 pm, siversoncan <greedysn...@hotmail.com> wrote:
>
>> Why would anyone need to use a mail server if they didn't have the
>> 'resources' or 'cleverness' to stop bounces? It's *free*, just as
>> stopping spam. But corporations backscatter too :) the problem is they
>> don't care, not that they can't stop it...
>>
>Not *all* emailers are mail server admins. Not *all* emailers have
>enough influence to get the server admins to make the proper changes.
>Here are a couple example of people that may not have the resources.
>Elementary school student. Junior office clerk.
It's the server that backscatters, not the second grader who happens
to use it for email.
>> Yeah, that will work. About as well as SPEWS :-) People don't respond
>> to 'forcing' like this.
>
>Sure they do. Plenty of people have purchased personal SPAM filters to
>get rid of SPAM or signed up with service providers that provide built
>in SPAM filters, because they are anoyed with the SPAM they get. That
>should work just as well with backscatter.
You mean, people will purchase filters to block Hormel products as a
result of backscatter?
You might notice that those spam filters or spam filtering services
have a tendency to block sites that emit spam. If the response to
backscatter is the same, people will buy backscatter filters or use
backscatter filtering services, which will have a tendency to block
sites that emit backscatter. I don't know why you think that would be
an improvement for those who emit backscatter.
>If I only return NDRs to people that don't fail SPF checking (ie the
>sender either matches the SPF record or there is no SPF record) then
>only those that sent messages from non-forged accounts and those that
>don't use SPF would get a bounce message. Therefore if you get a
>bounce from me for a message you did not send then I can assume that
>you did not set up SPF records for your server.
You can assume anything you want.
You might also assume that if you emit backscatter at me, I will
decide that you are an undesirable. What effect that might have on
such issues as the deliverability of your email is your problem.
Whining that since I didn't set up SPF I'm therefore willing to eat
your backscatter isn't going to get you anything except some laughs.
>I would think that Yahoo.com would be able to detect a person sending
>1 milion forged emails from their domain.
I haven't noticed that.
>And I'm sure that person would be prosecuted and likely convicted.
Reality doesn't agree with your certitude.
Has anybody here ever received a Yahoo Invite other than from a
spammer? (The last time I asked, one person had: he set it up to
invite himself as a reminder.) What about a Yahoo Change of Address
notice?
Yahoo apparently has several services that are close to 100%
spammers. I haven't heard of anyone being prosecuted or convicted as
a result.
> If you sent those emails from an IP address that does not belong to
>Yahoo and said it came from a Yahoo address I'm sure that servers
>with SPF configured would reject them for failing SPF checking.
And if you get your mail forwarded (e.g. an alumni account at a
college), you aren't going to get any SPF-protected mail at all.
Seth
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>I agree that's the point: We are NOT told that these are forged, so the
>current standards tell us to treat them as NOT FORGED
It doesn't matter to me how you treat incoming messages.
>Assuming the worst is contrary to the standards.
What do the standards say about what I'm allowed to assume? Please
quote and provide citations.
> Even RFCs 5321 & 5322 say
>we "need a reason" to refuse mail, not the lack of one.
RFC 5321 7.9. says
It is a well-established principle that an SMTP server may refuse
to accept mail for any operational or technical reason that makes
sense to the site providing the server.
Note carefully who gets to decide what constitutes a sufficient reason
to refuse mail. "any operation or technical reason" is an extremely
broad category.
>A change to the standards or public policies (including "Best Current
>Practices") requires an RFC to propose the change. There have been none.
Not sending sites mail they don't want and didn't do anything to
request is a very old policy.
>> Or do you assume that if there's no SPF or DKIM then the domain is
>> prepared to accept backscatter?
>
>If there's no SPF or DK record, that tells me that there are NO forgeries
Where is the RFC that redefines "forgery"? You want to change the
definition, you need RFC support. Or is RFC support only required
from those who disagree with you?
>and all mail was authorized from whatever source it came from.
Mail is not authorized by choosing not to implement this week's
FUSSP. Mail is authorized when the purported sender actually
authorizes it.
>Remember that this says NOTHING about its spam status or other content
>issues (e.g. viruses) which can lead to legitimate reasons to reject any
>message.
See above: a legitimate reason for site X to refuse any message is
whatever *site X* decides is a legitimate reason. RFC 5321
specifically states that, as I quoted and cited. If you wish to
redefine "legitimate reason to refuse mail" you need to propose an RFC
to do so.
>What's so difficult about deploying SPF (as a mail sender)?
I send to many people, a number of whom use forwarding services of
various types. Some of them are multi-hop, and I have no idea past
the first hop; therefore, I cannot create an SPF record that would
allow them to receive my mail (were they foolish enough to depend on
the result of SPF checks).
> One identifes all the sending points
"First, steal a chicken." That might not be possible (e.g. the
emission point is the mailswerver of whoever provides Internet access
to the hotel I'm staying at).
>As a mail receiver, all one needs to do is install any one of several
>available plugins for various MTAs that check for SPF and DK records.
And if one is using a different MTA?
>> So the effort to reduce backscatter should move away from RBL's and
>> complaining about mail admins who return NDR's for over quota inboxes
>> and out of office messages and towards wider use of SPF and DKIM as that
>> looks to be the future.
>
>Not possible. As I have previously demonstrated, a full mailbox and other
>such errors can be minimized but NOT eliminated.
As others (including me) have shown, mailbox full and other quota
issues can be handled so as to avoid any such problems. The method is
to reserve space before accepting ("250") the message. If you can't
reserve the space, assume a mailbox full.
>Also, what does "vacation" responses have to do with this? If their
>generators only see mail that has been through the checks (i.e. not forged
>and not spam),
The checks don't show "not forged", they can only show "the methods I
use did not determine the message to be forged". Likewise, there are
no perfect spam filters, else the whole problem would have gone away.
> these autoreplies will be going to legitimate senders who
>actually originated the inbound mail,
You aren't checking for that, because you can't.
> so how would they ever be considered backscatter?
They would be considered backscatter when they are.
Mail isn't magically "actually originated" by me when some spammer
forges my email address, no matter what protective technologies I
choose to implement or not implement. Mail is actually originated by
me when I, personally, perform the actual actions (^C^C) that cause it
to be sent.
Seth
Shmuel (Seymour J.) Metz
at 08:06 PM, se...@panix.com (Seth) said:
>In article <hct0gr$cqt$1...@snarked.org>,
>D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>>I agree that's the point: We are NOT told that these are forged, so the
>>current standards tell us to treat them as NOT FORGED
>It doesn't matter to me how you treat incoming messages.
Besides, Stussy is wrong about what the current standards say, and he's
been told multiple times.
>What do the standards say about what I'm allowed to assume?
Well, "3.3. Mail Transactions" says
These restrictions make a server useless as a relay for clients that
do not support full SMTP functionality. Consequently, restricted-
capability clients MUST NOT assume that any SMTP server on the
Internet can be used as their mail processing (relaying) site.
and "3.4. Forwarding for Address Correction or Updating" says
o Servers MAY forward messages when they are aware of an address
change. When they do so, they MAY either provide address-updating
information with a 251 code, or may forward "silently" and return
a 250 code. However, if a 251 code is used, they MUST NOT assume
that the client will actually update address information or even
return that information to the user.
o Servers MAY reject messages or return them as non-deliverable when
they cannot be delivered precisely as addressed. When they do so,
they MAY either provide address-updating information with a 551
code, or may reject the message as undeliverable with a 550 code
and no address-specific information. However, if a 551 code is
used, they MUST NOT assume that the client will actually update
address information or even return that information to the user.
In general, RFC 5321 allows a lot of leeway for "policy or other reasons."
It has nothing remotely similar to what stussy claims.
--
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
--