BACKSCATTERER "There should be no need to contact us"
goo...@guscreek.com
unknown local recipients is rejected during the smtp connection.
My server isn't doing sender callouts.
(Of course, I could be mistaken, but I've diligently tested the
server, double-checked the configuration, and examined my logs.
Absent any specific info from backscatterer, e.g. a message id or
other identifying headers, that's all I can do.)
However I'm not interested in having my server removed from the
list. That would be pointless, since it was put on the list
erroneously in
the first place, it's highly likely it would just get listed again.
Rather, I'm writing you to inform you that the system you believe to
be
so perfect is a piece of crap.
One way it could be improved is to actually provide some headers of
the
allegedly offending email, rather than simply lecturing people about
backscatter.
I see from the discussions on new.admin.net-abuse.blocklisting that
I
am not the only victim of your poorly designed and implemented system.
Since you are lecturing people on 'good netizenship', that must mean
mail sent to postm...@backscatterer.org will be read by a human.
However, I doubt it.
This message was sent to postm...@backscatterer.org.
this was the result.
Nov 10 14:47:47 s2 postfix/smtp[31840]: 6D6A9ADC050:
to=<postm...@backscatterer.org>,
relay=unimatrix.admins.ws[213.200.254.243]:25,
delay=5.1, delays=0.38/0/1.2/3.5, dsn=5.0.0,
status=bounced
(host unimatrix.admins.ws[213.200.254.243] said:
550 Access denied: 550 (V4.1-RULE-0615)
We have no user postm...@backscatterer.org,
please call your recipient if you are in doubt of the correct
spelling.
(in reply to RCPT TO command))
I'm sure the readers of this newsgroup realize that the RfC for smtp
requires that mail to postmaster@domain be deliverable to a mailbox
read by a human.
BACKSCATTERER: forget about the mote in my eye, remove the beam from
your own.
--
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.
Martijn Lievaart
> Nov 10 14:47:47 s2 postfix/smtp[31840]: 6D6A9ADC050:
> to=<postm...@backscatterer.org>,
> relay=unimatrix.admins.ws[213.200.254.243]:25, delay=5.1,
> delays=0.38/0/1.2/3.5, dsn=5.0.0,
> status=bounced
> (host unimatrix.admins.ws[213.200.254.243] said: 550 Access denied: 550
> (V4.1-RULE-0615) We have no user postm...@backscatterer.org, please
> call your recipient if you are in doubt of the correct spelling.
> (in reply to RCPT TO command))
>
>
> I'm sure the readers of this newsgroup realize that the RfC for smtp
> requires that mail to postmaster@domain be deliverable to a mailbox read
> by a human.
Only if the domain actually sends mail....
M4
Rob
> One way it could be improved is to actually provide some headers of
> the
> allegedly offending email, rather than simply lecturing people about
> backscatter.
Remember that this silly system does not even collect the offending
mail. It gets the MAIL FROM, sees it is <> or <postmaster@*>, gets
the RCPT TO and then it returns the "error" that you have been reported
as a backscatterer.
So their system has not even a way of knowing if you intended to send
a real backscatter message. Our system does source address validation
and it gets listed the same way.
(of course we have now changed the MAIL FROM for this operation so it
cannot happen again)
THey could improve their system so much... they could capture the
messages and make them available in the report, they could sync their
clocks using NTP and return the event time in milliseconds instead of
"10 minute intervals" (wristwatch time??), they could use UTC instead
of "german time", they could separate the listings for true backscatter
and other things the operator doesn't like but isn't backscatter
(like source address verification).
The list goes on and on and on. But Claus is not interested in
improvements. He has built himself a toy and he is proud, and he likes
to send others away with blunt "go looking in your logfiles" messages,
so nothing will change.
> Nov 10 14:47:47 s2 postfix/smtp[31840]: 6D6A9ADC050:
> to=<postm...@backscatterer.org>,
> relay=unimatrix.admins.ws[213.200.254.243]:25,
> delay=5.1, delays=0.38/0/1.2/3.5, dsn=5.0.0,
> status=bounced
> (host unimatrix.admins.ws[213.200.254.243] said:
> 550 Access denied: 550 (V4.1-RULE-0615)
> We have no user postm...@backscatterer.org,
> please call your recipient if you are in doubt of the correct
> spelling.
> (in reply to RCPT TO command))
HAHAHA!! I like that!
I wonder what Claus will reply to this...
Fallout
> My server isn't sending backscatter, mail sent to
> unknown local recipients is rejected during the smtp connection.
>
> My server isn't doing sender callouts.
There are other things you can get listed for, and I'm sure you know
it.
> One way it could be improved is to actually provide some headers of
> the
> allegedly offending email, rather than simply lecturing people about
> backscatter.
I guess they don't want to make it very easy for people to find their
spam traps.
> I see from the discussions on new.admin.net-abuse.blocklisting that
> I
> am not the only victim of your poorly designed and implemented system.
I have yet to see anyone prove they were wrongly listed, a false
positive. Have you? Maybe the victims are the ones that receive the
backscatter...
> Since you are lecturing people on 'good netizenship', that must mean
> mail sent to postmas...@backscatterer.org will be read by a human.
> However, I doubt it.
>
> This message was sent to postmas...@backscatterer.org.
>
> this was the result.
>
> Nov 10 14:47:47 s2 postfix/smtp[31840]: 6D6A9ADC050:
> to=<postmas...@backscatterer.org>,
> relay=unimatrix.admins.ws[213.200.254.243]:25,
> delay=5.1, delays=0.38/0/1.2/3.5, dsn=5.0.0,
> status=bounced
> (host unimatrix.admins.ws[213.200.254.243] said:
> 550 Access denied: 550 (V4.1-RULE-0615)
> We have no user postmas...@backscatterer.org,
> please call your recipient if you are in doubt of the correct
> spelling.
> (in reply to RCPT TO command))
>
> I'm sure the readers of this newsgroup realize that the RfC for smtp
> requires that mail to postmaster@domain be deliverable to a mailbox
> read by a human.
>
> BACKSCATTERER: forget about the mote in my eye, remove the beam from
> your own.
Hmmm. I can't seem to be able to contact their mail server...
Fred Mobach
> My server isn't sending backscatter, mail sent to
> unknown local recipients is rejected during the smtp connection.
That seems to be OK.
> My server isn't doing sender callouts.
Very good.
> (Of course, I could be mistaken, but I've diligently tested the
> server, double-checked the configuration, and examined my logs.
> Absent any specific info from backscatterer, e.g. a message id or
> other identifying headers, that's all I can do.)
To be sure that you didn't oversee anything you might publish the
hostname or IP address of your server so I can send a mail to
this-user-do...@yourdomain.invalid and see the error after
RCPT and not in a separate message.
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
Seth
Rob <nom...@example.com> wrote:
>goo...@guscreek.com <goo...@guscreek.com> wrote:
>> One way it could be improved is to actually provide some headers of
>> the
>> allegedly offending email, rather than simply lecturing people about
>> backscatter.
>
>Remember that this silly system does not even collect the offending
>mail. It gets the MAIL FROM, sees it is <> or <postmaster@*>, gets
>the RCPT TO and then it returns the "error" that you have been reported
>as a backscatterer.
>
>So their system has not even a way of knowing if you intended to send
>a real backscatter message. Our system does source address validation
>and it gets listed the same way.
They turned off VRFY because they intentionally chose not to provide
that information.
By attempt to use RCPT TO to bypass their decision, your action is
arguably a felony (access to a computer system in excess of
authorization).
Seth
Shmuel (Seymour J.) Metz
at 03:57 PM, Rob <nom...@example.com> said:
>Remember that this silly system does not even collect the offending
>mail.
Nor is there any reason that it should.
>So their system has not even a way of knowing if you intended to send a
>real backscatter message.
You're listed for your behavior, not for your intent. What matters is that
the DSN is not a response to an e-mail that UCEPROTECT sent.
>So their system has not even a way of knowing if you intended to send a
>real backscatter message. Our system does source address validation
So you're a spammer.
>THey could improve their system so much...
They could remove the express delisting option. They could use a longer
TTL on their listings.
--
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
David W. Hodgins
> My server isn't sending backscatter, mail sent to
If it's listed, then it is.
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Michelle Sullivan
> On Wed, 11 Nov 2009 03:45:44 +0000, google wrote:
>
>> I'm sure the readers of this newsgroup realize that the RfC for smtp
>> requires that mail to postmaster@domain be deliverable to a mailbox read
>> by a human.
>
> Only if the domain actually sends mail....
Sure about that?
Michelle
MrD
> My server isn't sending backscatter, mail sent to unknown local
> recipients is rejected during the smtp connection.
Non-sequitur.
>
> My server isn't doing sender callouts.
Super.
>
> (Of course, I could be mistaken,
Noted.
> but I've diligently tested the server, double-checked the
> configuration, and examined my logs. Absent any specific info from
> backscatterer, e.g. a message id or other identifying headers, that's
> all I can do.)
>
> However I'm not interested in having my server removed from the
> list. That would be pointless, since it was put on the list
> erroneously in the first place, it's highly likely it would just get
> listed again.
But "Of course, [you] could be mistaken".
>
> Rather, I'm writing you to inform you that the system you believe to
> be so perfect is a piece of crap.
You mean you don't like it? Don't use it.
>
> One way it could be improved is to actually provide some headers of
> the allegedly offending email, rather than simply lecturing people
> about backscatter.
That would be the sort of header that would enable backscatterers to
identify the spamtrap IP and blacklist it?
But then anyone who was determined to backscatter could do so without
getting listed, despite that their recipients may have decided they
don't want such messages (and filtered them using BACKSCATTERER). That
would kinda defeat the object, wouldn't it?
--
MrD.
http://ipquery.org
Shmuel (Seymour J.) Metz
11/11/2009
at 03:45 AM, goo...@guscreek.com said:
>My server isn't sending backscatter,
Perhaps, but the smart money says thaat you are.
>mail sent to unknown local recipients is rejected during the
>smtp connection.
What do you do with e-mail that is undeliverable for other reasons?
>(Of course, I could be mistaken,
In which case your rant is BS.
>However I'm not interested in having my server removed from the list.
>That would be pointless, since it was put on the list erroneously in
>the first place, it's highly likely it would just get listed again.
ITYM that since you haven't corrected the misconfiguration that got you
listed the directions on the web site tell you to not ask for express
delisting. You've alluded to the possibility that you might be mistaken;
if you are[1], then you weren't listed erroneously and there is a point to
getting removed by fixing your server.
>Rather, I'm writing you to inform you
TINY. This is just a news group where blocking issues can be discussed.
>that the system you believe to be so perfect is a piece of crap.
You can present your prejudices as facts all that you want; that doesn't
make them true or even plausible. Since you started out with a
demonstrably false description of your target audience, your claim has
even less credibility than it would otherwise.
>One way it could be improved is to
Extend the timeout to 6 months. But since it's not my list, Claus has no
obligation to take my advice. The list isn't there to educate inept
admins, it's there to protect systems using it.
>I see from the discussions on new.admin.net-abuse.blocklisting that I
>am not the only victim of your poorly designed and implemented system.
What you see is that many people whine about being outed when they mess
up, and are heavily into denial. What I also see is ignorant posters
ranting at the readership of this news group as if they controlled the
DNSBL's that are discussed here.
>Since you are lecturing
You who? This is not UCEPROTECT.
>that must mean mail sent to postm...@backscatterer.org will be
>read by a human.
It does not mean that the human will agree with whatever drivel is in the
e-mail, or that the human will respond to complaints that have nothing to
do with UCEPROTECT e-mail. The postmaster mail box has a much narrower
scope than, e.g., abuse, does.
>However, I doubt it.
Your guesses are irrelevant. Only facts matter.
>This message was sent to postm...@backscatterer.org.
Is there a mail client or mail server in that domain?
>I'm sure the readers of this newsgroup realize that the RfC for smtp
>requires that mail to postmaster@domain be deliverable to a mailbox read
>by a human.
Some of those readers remember that the text doesn't say quite whate you
want it to say; does UCEPROTECT have "an SMTP server supporting mail
relaying or delivery" for backscatterer.org?
[1] Which is almost certain.
--
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
--
Claus v. Wolfhausen
>
>goo...@guscreek.com <goo...@guscreek.com> wrote:
>> One way it could be improved is to actually provide some headers of
>> the
>> allegedly offending email, rather than simply lecturing people about
>> backscatter.
>
>Remember that this silly system does not even collect the offending
>mail. It gets the MAIL FROM, sees it is <> or <postmaster@*>, gets
>the RCPT TO and then it returns the "error" that you have been reported
>as a backscatterer.
>
>So their system has not even a way of knowing if you intended to send
>a real backscatter message. Our system does source address validation
>and it gets listed the same way.
>(of course we have now changed the MAIL FROM for this operation so it
>cannot happen again)
And you really believe you can get away with that?
You are playing a more dangerous dangerous game and i hope you know it, do you?
You qualify for listings in both Lists (UCEPROTECT L1 and BACKSCATTERER) that
way.
In case you hit an invalid RCPT TO:
Using a different MAIL FROM for Sender verify you are at risk to end up in
UCEPROTECT-Level 1 if you hit enough traps or in case you break your DNS...
If that happens you will get a feeling how much more people are using Level 1
for blocking compared to Backscatterer :-)
In case you hit a valid RCPT TO:
If you disconnect or drop without sending a real mail after you did go up to
RCPT TO: you will of course get listed in Backcatterer again...
Different to an invalid address you will not find in the log what got you
listed that way.
If you would have read some of my earlier articles in nanabl instead of wasting
your time to search for ways to circumvent our listings you would have known
that.
>THey could improve their system so much... they could capture the
>messages and make them available in the report, they could sync their
>clocks using NTP and return the event time in milliseconds instead of
>"10 minute intervals" (wristwatch time??), they could use UTC instead
>of "german time", they could separate the listings for true backscatter
>and other things the operator doesn't like but isn't backscatter
>(like source address verification).
Oh the system is perfect for those that are using it.
Why should we waste resources to accept crap we exactly know we don't want?
Why should we give exact timestamps and tell people like you which server did
list them for probing a valid address at RCPT TO?
>The list goes on and on and on. But Claus is not interested in
>improvements. He has built himself a toy and he is proud, and he likes
>to send others away with blunt "go looking in your logfiles" messages,
>so nothing will change.
No our users are happy with the results, that is what we are proud of.
It was never our intention to make abusers happy, so why should we help them to
circumvent our listings while not stopping the abuse generated by their
systems?
>> please call your recipient if you are in doubt of the correct
>> spelling.
>> (in reply to RCPT TO command))
>
>HAHAHA!! I like that!
>I wonder what Claus will reply to this...
>
Why should a domain that is not used for email have a postmaster account?
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
Rob
> And you really believe you can get away with that?
> You are playing a more dangerous dangerous game and i hope you know it, do you?
> You qualify for listings in both Lists (UCEPROTECT L1 and BACKSCATTERER) that
> way.
Is this a threat?
Is it an official threat from UCEPROTECT or is it only from you personally?
Of couse we send our sender address verifications from another IP than
we use for our incoming our outgoing mail, so getting listed is not a
real problem.
What will be your reply to that? Another clever one?
> Oh the system is perfect for those that are using it.
> Why should we waste resources to accept crap we exactly know we don't want?
Waste resources?
Maybe you should finally accept that your Commodore 64 is no longer able
to run your business and you need to upgrade to an Amiga!
>>The list goes on and on and on. But Claus is not interested in
>>improvements. He has built himself a toy and he is proud, and he likes
>>to send others away with blunt "go looking in your logfiles" messages,
>>so nothing will change.
>
> No our users are happy with the results, that is what we are proud of.
> It was never our intention to make abusers happy, so why should we help them to
> circumvent our listings while not stopping the abuse generated by their
> systems?
Here you confirm what I think about you.
MrD
>
>> This message was sent to postm...@backscatterer.org.
>
> Is there a mail client or mail server in that domain?
There's an MX, ergo it's a mail realm. In theory, it's capable of
producing internet mail nuisances such as mail loops, that would be a
proper matter for the postmaster to deal with; so I'd say it should have
a human postmaster.
>
> Some of those readers remember that the text doesn't say quite whate
> you want it to say; does UCEPROTECT have "an SMTP server supporting
> mail relaying or delivery" for backscatterer.org?
It does appear to.
--
MrD.
http://ipquery.org
DevilsPGD
<nom...@example.com> was claimed to have wrote:
>Of couse we send our sender address verifications from another IP than
>we use for our incoming our outgoing mail, so getting listed is not a
>real problem.
You know what you're doing is abusive so you segregate it from your
normal sending space so that blocklisting doesn't impact you, but yet
you continue to operate in a method you know to be abusive.
That seems like a pretty reasonable justification for listing your
corporate servers too, at least in blocklists that list more then actual
abusive IPs.
Rob
> In message <slrnhfqbh0....@xs7.xs4all.nl> Rob
> <nom...@example.com> was claimed to have wrote:
>
>>Of couse we send our sender address verifications from another IP than
>>we use for our incoming our outgoing mail, so getting listed is not a
>>real problem.
>
> You know what you're doing is abusive so you segregate it from your
> normal sending space so that blocklisting doesn't impact you, but yet
> you continue to operate in a method you know to be abusive.
I do not agree it is abusive. It filters a lot of spam, and I consider
the impact on others to be neglible.
Everyone can call a method of operation abusive, but that does not
mean that all others will agree.
We also do greylisting. You'll probably call it abusive because it
"wastes" mailserver sending queue resources. Too bad for you.
Seth
MrD <mrdem...@jackpot.invalid> wrote:
>Shmuel (Seymour J.) Metz wrote:
>>
>>> This message was sent to postm...@backscatterer.org.
>>
>> Is there a mail client or mail server in that domain?
>
>There's an MX, ergo it's a mail realm. In theory, it's capable of
>producing internet mail nuisances such as mail loops,
Only if it's capable of _emitting_ mail. We don't know that it is,
and the person who should know says that it isn't.
Seth
Claus v. Wolfhausen
>
>DevilsPGD <Death...@crazyhat.net> wrote:
>> In message <slrnhfqbh0....@xs7.xs4all.nl> Rob
>> <nom...@example.com> was claimed to have wrote:
>>
>>>Of couse we send our sender address verifications from another IP than
>>>we use for our incoming our outgoing mail, so getting listed is not a
>>>real problem.
>>
>> You know what you're doing is abusive so you segregate it from your
>> normal sending space so that blocklisting doesn't impact you, but yet
>> you continue to operate in a method you know to be abusive.
>
>I do not agree it is abusive. It filters a lot of spam, and I consider
>the impact on others to be neglible.
>Everyone can call a method of operation abusive, but that does not
>mean that all others will agree.
It is abusive because you are trying to circumvent other peoples policies at
their servers.
My server will not contact you because i do not know you.
If i do not allow VRFY because i do not want that spammers are able to do
dictionary attacks, then it *IS ABUSIVE* if you contact my server and you are
going up to RCPT TO for address probing.
The case is very similar to: I have secured a server with a password.
If you connect there and probe passwords it is similar abusive.
>We also do greylisting. You'll probably call it abusive because it
>"wastes" mailserver sending queue resources. Too bad for you.
That is a complete different thing.
If you are greylisting, you are wasting resources at your customers.
They have freely chosen to be in contact with you. I have not.
I'm not your customer and i don't want to be contacted by you.
Therfore it is abusive that you connect to my server and play around there.
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
--
Fallout
> DevilsPGD <DeathToS...@crazyhat.net> wrote:
> > In message <slrnhfqbh0.17cr.nom...@xs7.xs4all.nl> Rob
> > <nom...@example.com> was claimed to have wrote:
>
> >>Of couse we send our sender address verifications from another IP than
> >>we use for our incoming our outgoing mail, so getting listed is not a
> >>real problem.
>
> > You know what you're doing is abusive so you segregate it from your
> > normal sending space so that blocklisting doesn't impact you, but yet
> > you continue to operate in a method you know to be abusive.
>
> I do not agree it is abusive. It filters a lot of spam, and I consider
> the impact on others to be neglible.
> Everyone can call a method of operation abusive, but that does not
> mean that all others will agree.
>
> We also do greylisting. You'll probably call it abusive because it
> "wastes" mailserver sending queue resources. Too bad for you.
Spammers can use your mail server as part of a DDos attack against
some system then. It is not about the resources taken *by you* but by
thousands of other servers doing the same. Do you at least rate limit
your SAVs? My bet is you don't :)
Seth
Rob <nom...@example.com> wrote:
>I do not agree it is abusive.
Your opinion is not relevant here.
> It filters a lot of spam, and I consider the impact on others to be neglible.
There is one person whose opinion about its impact on me matters. You
are not that person.
Repeat umpteen billion times. Your opinion about impact matters only
when it's about the impact on you.
>Everyone can call a method of operation abusive, but that does not
>mean that all others will agree.
If _one_ of the victims of your pseudo-sending considers the impact on
him unaccceptable, then it _is_ abusive.
>We also do greylisting. You'll probably call it abusive because it
>"wastes" mailserver sending queue resources. Too bad for you.
Greylisting is not abusive, because it doesn't involves the resources
of innocent third parties. The sender can retry or not at his option.
Seth
MrD
> In article <hdj73c$pu8$1...@news.eternal-september.org>, MrD
> <mrdem...@jackpot.invalid> wrote:
>> Shmuel (Seymour J.) Metz wrote:
>>>> This message was sent to postm...@backscatterer.org.
>>> Is there a mail client or mail server in that domain?
>> There's an MX, ergo it's a mail realm. In theory, it's capable of
>> producing internet mail nuisances such as mail loops,
>
> Only if it's capable of _emitting_ mail. We don't know that it is,
> and the person who should know says that it isn't.
*We* know he said that, because he said so here, and we happen to read
this froup. But the generic mail-admin who knows nothing of that list or
this froup might reasonably inquire at postmaster@.
"Any system that includes an SMTP server supporting mail relaying or
delivery MUST support the reserved mailbox "postmaster" as a case-
insensitive local name."
~RFC 2821.
I'm having a little trouble imagining why one might create an MX record
for an SMTP server that will never either relay or deliver. Note that
the prose I quoted doesn't say anything about _emitting_ (for which one
doesn't need an MX anyway).
--
MrD.
http://ipquery.org
Shmuel (Seymour J.) Metz
at 03:20 PM, Rob <nom...@example.com> said:
>Everyone can call a method of operation abusive, but that does not mean
>that all others will agree.
Some opinions have more impact on deliverability than others. You seem to
be wearing a big "block me" sign on your back.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--
Seth
Rob <nom...@example.com> wrote:
>Claus v. Wolfhausen <use-reply-...@remove-this.com> wrote:
>> And you really believe you can get away with that?
>> You are playing a more dangerous dangerous game and i hope you know it, do you?
>> You qualify for listings in both Lists (UCEPROTECT L1 and BACKSCATTERER) that
>> way.
>
>Is this a threat?
It looks more like a prediction and description of the way those lists
work.
>> Oh the system is perfect for those that are using it.
>> Why should we waste resources to accept crap we exactly know we don't want?
>
>Waste resources?
It takes resources to accept mail.
>Maybe you should finally accept that your Commodore 64 is no longer able
>to run your business and you need to upgrade to an Amiga!
Or maybe you shouldn't tell him how to use his resources. I don't see
you offering to buy him hardware sufficient for him to do what you
want rather than what he wants.
Seth
Rob
> On Nov 13, 5:20 pm, Rob <nom...@example.com> wrote:
>> DevilsPGD <DeathToS...@crazyhat.net> wrote:
>> > In message <slrnhfqbh0.17cr.nom...@xs7.xs4all.nl> Rob
>> > <nom...@example.com> was claimed to have wrote:
>>
>> >>Of couse we send our sender address verifications from another IP than
>> >>we use for our incoming our outgoing mail, so getting listed is not a
>> >>real problem.
>>
>> > You know what you're doing is abusive so you segregate it from your
>> > normal sending space so that blocklisting doesn't impact you, but yet
>> > you continue to operate in a method you know to be abusive.
>>
>> I do not agree it is abusive. It filters a lot of spam, and I consider
>> the impact on others to be neglible.
>> Everyone can call a method of operation abusive, but that does not
>> mean that all others will agree.
>>
>> We also do greylisting. You'll probably call it abusive because it
>> "wastes" mailserver sending queue resources. Too bad for you.
>
> Spammers can use your mail server as part of a DDos attack against
> some system then. It is not about the resources taken *by you* but by
I don't see a simple connect and three commands as a DDOS attack.
> thousands of other servers doing the same. Do you at least rate limit
> your SAVs? My bet is you don't :)
Your bet was wrong. We do cache the results.
DevilsPGD
<nom...@example.com> was claimed to have wrote:
>Fallout <ad...@ascomex.ro> wrote:
>> On Nov 13, 5:20 pm, Rob <nom...@example.com> wrote:
>>> DevilsPGD <DeathToS...@crazyhat.net> wrote:
>>> > In message <slrnhfqbh0.17cr.nom...@xs7.xs4all.nl> Rob
>>> > <nom...@example.com> was claimed to have wrote:
>>>
>>> >>Of couse we send our sender address verifications from another IP than
>>> >>we use for our incoming our outgoing mail, so getting listed is not a
>>> >>real problem.
>>>
>>> > You know what you're doing is abusive so you segregate it from your
>>> > normal sending space so that blocklisting doesn't impact you, but yet
>>> > you continue to operate in a method you know to be abusive.
>>>
>>> I do not agree it is abusive. It filters a lot of spam, and I consider
>>> the impact on others to be neglible.
>>> Everyone can call a method of operation abusive, but that does not
>>> mean that all others will agree.
>>>
>>> We also do greylisting. You'll probably call it abusive because it
>>> "wastes" mailserver sending queue resources. Too bad for you.
>>
>> Spammers can use your mail server as part of a DDos attack against
>> some system then. It is not about the resources taken *by you* but by
>
>I don't see a simple connect and three commands as a DDOS attack.
Multiply that by a few thousand simultaneous sessions and imagine what
happens?
It's not so much that your server itself causes a DDoS, but rather, your
server is used to anonymize the abuse since the victim will see he's
being attacked by yourself and other SAV users rather then the attacker.
More importantly though, it's still not up to you to decide how much of
*my* resources you can "borrow" to prop up your otherwise ineffective
spam filtering.
>> thousands of other servers doing the same. Do you at least rate limit
>> your SAVs? My bet is you don't :)
>
>Your bet was wrong. We do cache the results.
Caching != Rate Limiting.
An attacker might send "from" bo...@victim.example then bob2@, rinse,
repeat. A cache won't be useful here.
Fallout
> I don't see a simple connect and three commands as a DDOS attack.
And when 10,000 servers including yours send "a simple connect and
three commands" at the same time to someone who never sent them
anything, will it be a DDOS then? Or one where noone would be guilty,
because all each of them did was send 3 commands...
> Your bet was wrong. We do cache the results.
How can a bet be wrong? It can be won or lost, or tie even :))
siversoncan
> On Nov 15, 11:45 pm, Rob <nom...@example.com> wrote:
>
> > I don't see a simple connect and three commands as a DDOS attack.
>
> And when 10,000 servers including yours send "a simple connect and
> three commands" at the same time to someone who never sent them
> anything, will it be a DDOS then? Or one where noone would be guilty,
> because all each of them did was send 3 commands...
>
backscatter.
Has anyone heard of DDOS attack caused by backscatter. Surely if a
spammer wanted to comit a DDOS attack against an email server he would
just email from his botnet a zillion messages to that server, because
if the spammer used backscatter to do it the number of messages
hitting that server would only be a fraction of the number of emails
sent out.
Also, why are you whining about a small addittion of a few commands to
verify if the sending email is legitimate. SPAM is more than a mere
nuisance, it can cause the unwary to lose very significant resources,
compared to the minor resources the whiners can't seem to tolerate.
Lets put it this way, Most spam filters use scoring to decide if an
email is SPAM. If an email scores a high enough score it is most
defeinately SPAM and if it scores low enough it is very likely not
SPAM. In between those scores there is a small percentage that we are
unsure about. If we configury our servers to check first SPF DKIM and
SPAM probabilities before sending a short request to the server to
verify if he is who he says he is then the check is using very few
resources and should cut SPAM by another large factor.
If there is a SPAM filter out there that is correct 99.9% then the
additional server requests would be negligible.
And if we eliminate a high enough percentage of SPAM from getting into
mailboxes then we would make spamming economically not viable. I would
love to see the day when spammers give up because they can't get their
SPAM through to end users and any progress towards that day is
benficial for all of us.
We are at war with spammers and we should pool our resources to stop
them instead of saying "stop putting up your wall because I'm getting
some backscatter from your defenses."
Claus v. Wolfhausen
>
>Fallout <ad...@ascomex.ro> wrote:
>> On Nov 13, 5:20 pm, Rob <nom...@example.com> wrote:
>>> DevilsPGD <DeathToS...@crazyhat.net> wrote:
>>> > In message <slrnhfqbh0.17cr.nom...@xs7.xs4all.nl> Rob
>>> > <nom...@example.com> was claimed to have wrote:
>>>
>>> >>Of couse we send our sender address verifications from another IP than
>>> >>we use for our incoming our outgoing mail, so getting listed is not a
>>> >>real problem.
>>>
>>> > You know what you're doing is abusive so you segregate it from your
>>> > normal sending space so that blocklisting doesn't impact you, but yet
>>> > you continue to operate in a method you know to be abusive.
>>>
>>> I do not agree it is abusive. It filters a lot of spam, and I consider
>>> the impact on others to be neglible.
>>> Everyone can call a method of operation abusive, but that does not
>>> mean that all others will agree.
>>>
>>> We also do greylisting. You'll probably call it abusive because it
>>> "wastes" mailserver sending queue resources. Too bad for you.
>>
>> Spammers can use your mail server as part of a DDos attack against
>> some system then. It is not about the resources taken *by you* but by
>
>I don't see a simple connect and three commands as a DDOS attack.
You can not imagine that you are not the only person getting spam.
If a spammer fakes to be victim@example com the he sends not just one mail to
you which triggers your 1 connection with 3 abusive commands.
That is what you abusers will not get in your heads:
Spam claiming to be vic...@example.com comes not just to you, it comes also to
some Million other systems.
Lets assume that 100000 will do sender verify....
So now 100000 systems will each connect example.coms mx and each will try your
stupid 3 steps ...
In reality this are much more and you know it.
I would say that results in a nice DDOS, because you have not enough
tcp-sockets to handle that, if the connections are tried at the same time.
Chances that all will try it the same time are excellent, because the spammer
does not send with 1 machine any longer, the typical spammer is using a botnet,
so his spam will arrive at your system and some hundrettausand other sav
abusers the same time.
>> thousands of other servers doing the same. Do you at least rate limit
>> your SAVs? My bet is you don't :)
>
>Your bet was wrong. We do cache the results.
Nothing to be proud of it is still abusive.
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
--
Seth
siversoncan <greed...@hotmail.com> wrote:
>On Nov 16, 4:11 am, Fallout <ad...@ascomex.ro> wrote:
>> On Nov 15, 11:45 pm, Rob <nom...@example.com> wrote:
>>
>> > I don't see a simple connect and three commands as a DDOS attack.
>>
>> And when 10,000 servers including yours send "a simple connect and
>> three commands" at the same time to someone who never sent them
>> anything, will it be a DDOS then? Or one where noone would be guilty,
>> because all each of them did was send 3 commands...
>>
>I'm not quite sure I understand why people are so concerned with
>backscatter.
>Has anyone heard of DDOS attack caused by backscatter.
It's been done to me.
> Surely if a spammer wanted to comit a DDOS attack against an email
>server he would just email from his botnet a zillion messages to that
>server,
If he had a large botnet that wasn't in any DNSBL.
> because if the spammer used backscatter to do it the number of
>messages hitting that server would only be a fraction of the number
>of emails sent out.
But the backscatter is coming from mostly-legitimate real mail
servers, so it's harder to auto-block.
>Also, why are you whining about a small addittion of a few commands to
>verify if the sending email is legitimate.
First, it does no such thing.
Second, if I choose not to implement VRFY then for you to bypass my
access control mechanism by faking a RCPT TO instead is just wrong
(and arguably quite illegal, in the US).
> SPAM is more than a mere nuisance, it can cause the unwary to lose
>very significant resources, compared to the minor resources the
>whiners can't seem to tolerate. Lets put it this way,
When the discussion is about _my_ resources, then the only person
whose opinion as to whether something is significant, important, or
minor, is _me_.
> Most spam filters use scoring to decide if an
>email is SPAM.
Where's the RFC for meat product transfer protocol?
>If there is a SPAM filter out there that is correct 99.9% then the
>additional server requests would be negligible.
You don't get to decide what's negligible when it involves stealing my
resources.
>We are at war with spammers and we should pool our resources to stop
>them instead of saying "stop putting up your wall because I'm getting
>some backscatter from your defenses."
You don't get to decide to pool my resources for your benefit. That's
what spammers do.
Seth
DevilsPGD
<b0e40558-8be2-4ba3...@f20g2000prn.googlegroups.com>
siversoncan <greed...@hotmail.com> was claimed to have wrote:
>On Nov 16, 4:11 am, Fallout <ad...@ascomex.ro> wrote:
>> On Nov 15, 11:45 pm, Rob <nom...@example.com> wrote:
>>
>> > I don't see a simple connect and three commands as a DDOS attack.
>>
>> And when 10,000 servers including yours send "a simple connect and
>> three commands" at the same time to someone who never sent them
>> anything, will it be a DDOS then? Or one where noone would be guilty,
>> because all each of them did was send 3 commands...
>>
>I'm not quite sure I understand why people are so concerned with
>backscatter.
>Has anyone heard of DDOS attack caused by backscatter.
Yes. Maybe once you've been on the receiving end of one, you'll
understand the issue. I'm sure I'm not the only one here who has been
on the receiving end of a backscatter based DDOS flood.
Then again, maybe you could learn from those who have, without having to
be on the receiving end yourself?
>Surely if a
>spammer wanted to comit a DDOS attack against an email server he would
>just email from his botnet a zillion messages to that server, because
>if the spammer used backscatter to do it the number of messages
>hitting that server would only be a fraction of the number of emails
>sent out.
It's generally not an intentional attack as much as a side effect of
being unlucky enough to have one's address stuck in a spammer's MAIL
FROM command for a while.
>Also, why are you whining about a small addittion of a few commands to
>verify if the sending email is legitimate. SPAM is more than a mere
>nuisance, it can cause the unwary to lose very significant resources,
>compared to the minor resources the whiners can't seem to tolerate.
You're welcome to allocate *your* resources any way you and your clients
desire. You don't get use *my* resources to filter *your* spam.
That being said, if you need assistance filtering your spam, there are
likely many on this list who would be thrilled to sell you filtering
services.
>Lets put it this way, Most spam filters use scoring to decide if an
>email is SPAM. If an email scores a high enough score it is most
>defeinately SPAM and if it scores low enough it is very likely not
>SPAM.
Great, so refuse the spam, accept the rest?
>In between those scores there is a small percentage that we are
>unsure about. If we configury our servers to check first SPF DKIM and
>SPAM probabilities before sending a short request to the server to
>verify if he is who he says he is then the check is using very few
>resources and should cut SPAM by another large factor.
Excellent, so you've got very little mail left over, right?
>If there is a SPAM filter out there that is correct 99.9% then the
>additional server requests would be negligible.
So if you have so little messages hitting verification anyway, then why
not give it up and be a good net neighbour?
>And if we eliminate a high enough percentage of SPAM from getting into
>mailboxes then we would make spamming economically not viable. I would
>love to see the day when spammers give up because they can't get their
>SPAM through to end users and any progress towards that day is
>benficial for all of us.
That sounds remarkable like the ends justifying the means.
>We are at war with spammers and we should pool our resources to stop
>them instead of saying "stop putting up your wall because I'm getting
>some backscatter from your defenses."
You pool your resources, I'll pool mine and we'll do alright. You don't
get to pool my resources, that's still theft.
Rob
>>I don't see a simple connect and three commands as a DDOS attack.
>
> Multiply that by a few thousand simultaneous sessions and imagine what
> happens?
For being involved in a DDOS attack, IMHO, threre must be some
multiplication going on. The controller does something simple and
as a result the involved systems do more than that.
(e.g. send more requests, send larger requests)
This is not going on here.
Seth
MrD <mrdem...@jackpot.invalid> wrote:
>I'm having a little trouble imagining why one might create an MX record
>for an SMTP server that will never either relay or deliver.
Perhaps there are no actual valid email addresses in a domain, but its
owner wants to see who's trying to send to it anyways (e.g. for
reputational purposes).
Seth
Martijn Lievaart
> On Nov 16, 4:11 am, Fallout <ad...@ascomex.ro> wrote:
>> On Nov 15, 11:45 pm, Rob <nom...@example.com> wrote:
>>
>> > I don't see a simple connect and three commands as a DDOS attack.
>>
>> And when 10,000 servers including yours send "a simple connect and
>> three commands" at the same time to someone who never sent them
>> anything, will it be a DDOS then? Or one where noone would be guilty,
>> because all each of them did was send 3 commands...
>>
> I'm not quite sure I understand why people are so concerned with
> backscatter.
> Has anyone heard of DDOS attack caused by backscatter. Surely if a
Yes, it happens often. Not even intentional, just huge spamruns with a
fixed spoofed from address.
> spammer wanted to comit a DDOS attack against an email server he would
> just email from his botnet a zillion messages to that server, because if
> the spammer used backscatter to do it the number of messages hitting
> that server would only be a fraction of the number of emails sent out.
If your aim is to DDOS, sending a million emails will get the sending IPs
listed in no time. Using a botnet to DDOS makes it very hard to stop the
DDOS. Using a botnet to DDOS by backscatter makes it very, very hard to
stop,
> Also, why are you whining about a small addittion of a few commands to
> verify if the sending email is legitimate. SPAM is more than a mere
> nuisance, it can cause the unwary to lose very significant resources,
> compared to the minor resources the whiners can't seem to tolerate. Lets
So because you cannot stop spam, you transfer part of your problem to me?
I agree that I'ls rather recieve a million callouts than a million
backscatters, but still I prefer to receive nothing.
> put it this way, Most spam filters use scoring to decide if an email is
> SPAM. If an email scores a high enough score it is most defeinately SPAM
> and if it scores low enough it is very likely not SPAM. In between those
> scores there is a small percentage that we are unsure about. If we
> configury our servers to check first SPF DKIM and SPAM probabilities
> before sending a short request to the server to verify if he is who he
> says he is then the check is using very few resources and should cut
> SPAM by another large factor. If there is a SPAM filter out there that
So do you advocate doing callouts when SPF/DKIM passes or fails? And how
are you going to solve the SPF forwarding problem?
> is correct 99.9% then the additional server requests would be
> negligible. And if we eliminate a high enough percentage of SPAM from
> getting into mailboxes then we would make spamming economically not
> viable. I would love to see the day when spammers give up because they
If we make spamming harder, history shows that spammers send more spam.
Although I would love to see spam economically not viable, that day is
still far away.
> can't get their SPAM through to end users and any progress towards that
> day is benficial for all of us.
Agree.
> We are at war with spammers and we should pool our resources to stop
Agree.
> them instead of saying "stop putting up your wall because I'm getting
> some backscatter from your defenses."
Disagree. No one is telling you to tear down your wall. But please use a
wall that does not involve me.
M4
MrD
> If we configury our servers to check first SPF DKIM and SPAM
> probabilities before sending a short request to the server to verify
> if he is who he says he is then the check is using very few resources
> and should cut SPAM by another large factor.
However the "short message" you refer to is actually an attempt at
deception: "RCPT TO: I am going to submit a message for $recipient. Oops
- no I'm not! Fooled you!". Put less facetiously, it is an attempt to
circumvent the admin's legitimate decision to disable VRFY, and is
therefore abusive. If you do this, don't be surprised (and don't whinge)
when you end up on a list of abusive hosts.
> If there is a SPAM filter out there that is correct 99.9% then the
> additional server requests would be negligible.
However they amount to an attempt to gather information about which
mailboxes at the victim's server do and don't accept mail. This is
information that spammers want to collect, and that many admins want to
keep private.
> And if we eliminate a high enough percentage of SPAM from getting
> into mailboxes then we would make spamming economically not viable.
The evidence of the last ten years doesn't jibe with that view. The
higher the percentage of spam blocked (so the evidence shows), the more
messages the spammers send.
FWIW, I'd argue that a final end to spam is about as likely as an end to
any other attempt to send a "valuable message" to someone who doesn't
want to receive it.
> I would love to see the day when spammers give up because they can't
> get their SPAM through to end users and any progress towards that day
> is benficial for all of us. We are at war with spammers and we
> should pool our resources to stop them instead of saying "stop
> putting up your wall because I'm getting some backscatter from your
> defenses."
Whoah! those are two very confused sentences.
1. Sending backscatter is not a necessary component of defending against
spam.
2. Rejecting backscatter isn't the same as demanding that the sending
party drop their spam defences.
3. "The day when spammers give up" is such a remote concept that it has
no significant bearing on how mail admins should conduct themselves
in practice.
--
MrD.
http://ipquery.org
E-Mail Sent to this address will be added to the BlackLists
> I'm having a little trouble imagining why one might
> create an MX record for an SMTP server that will never
> either relay or deliver.
SpamTrap domains.
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
DevilsPGD
<nom...@example.com> was claimed to have wrote:
>DevilsPGD <Death...@crazyhat.net> wrote:
>>>I don't see a simple connect and three commands as a DDOS attack.
>>
>> Multiply that by a few thousand simultaneous sessions and imagine what
>> happens?
>
>For being involved in a DDOS attack, IMHO, threre must be some
>multiplication going on. The controller does something simple and
>as a result the involved systems do more than that.
>(e.g. send more requests, send larger requests)
>
>This is not going on here.
No, there is no multiplication requirement in DDoS. DDoS means,
literally "Distributed Denial of Service" (note the lack of "M" in
DDoS?)
An attacker doesn't need a botnet worth of unique IPs to launch a DDoS
attack against me, he just needs a bunch of patzies who will happily
relay the attack from their own IPs.
siversoncan
> On Mon, 16 Nov 2009 19:25:26 +0000, siversoncan wrote:
>>I would love to see the day when spammers give up because they
> > day is benficial for all of us.
>
> Agree.
>
> > We are at war with spammers and we should pool our resources to stop
>
> Agree.
>
> > them instead of saying "stop putting up your wall because I'm getting
> > some backscatter from your defenses."
>
> Disagree. No one is telling you to tear down your wall. But please use a
> wall that does not involve me.
>
> M4
>
won't lend me a small portion of your resources to very significantly
reduce the amount of SPAM I get. That sounds contradictory to me. I
would allow a small amount of my resources to help you.
Try to imagine 1000 emails coming my way. 950 of them are easily
detectable as SPAM. 20 of them are easily detectable as HAM. I only
have 30 left to deal with that I need someone else's help with. So I
run SPF and DKIM checks and I am thankful to the ones that haad enough
community spirit to set up those records because I able to pass or
fail 15 of them. That leaves 15 out of 1000 that I am not quite sure
of. That's 1.5%. Let's say out of those 15 one of them said it came
from you and it tells me to click on a link or open an attachment or
something similar. Now, I am not sure if it's safe because I don't
really know if it came from you because you didn't set up SPF or DKIM
on your server. Would you rather I pass the email on to a user who may
open it without thinking or perhaps phone you and take your time up to
find out if you really sent the messsage, or would you allow me to
make a small server query to see if your server really sent that
email.
Actually you have already told me. You think everyone should just
leave you alone because you are too selfish and short sighted to see
this as a potential solution to your problem.
It does cost spammers to send SPAM. The cost is not insignificant. It
might cost them $10 to send a million SPAM. But lets say they get $.05
every time someone clicks on a link in the SPAM email. If we can
reduce the number of clicks to less than 200 for a million SPAM sent
then the spammer will stop spamming. I don't know what the economies
are but there is a cost for everything and there is a limit to what
can be gained. To stop SPAM we need to reduce the gain to less than
the cost. The solution is economics.
I am not advocating stealing resources, I am asking you to share a
small portion.
If we only do sender callouts on the portion of mail we can't be sure
about otherwise then we are only requesting a small portion of your
resources, and we are willing to allow an equivalent portion of our
resources to be shared. That is more of an arm in arm solution to SPAM
rather than an every man for himself solution. History teaches us that
those who act together as a team are more successful than those who
stand alone.
If you have a better solution to eliminate SPAM then by all means, let
us hear it.
Seth
Rob <nom...@example.com> wrote:
>DevilsPGD <Death...@crazyhat.net> wrote:
>>>I don't see a simple connect and three commands as a DDOS attack.
>>
>> Multiply that by a few thousand simultaneous sessions and imagine what
>> happens?
>
>For being involved in a DDOS attack, IMHO, threre must be some
>multiplication going on.
That's not a requirement for a Distributed Denial of Service.
Suppose BadGuy has one server with a lot of bandwidth. If he attacks
me directly, I'll block him at the router, end of problem. If he
sends to 50,000 sites that backscatter at me, I can't do anything
effective nearly that simply.
Seth
Rob
> some Million other systems.
> Lets assume that 100000 will do sender verify....
>
> So now 100000 systems will each connect example.coms mx and each will try your
> stupid 3 steps ...
>
> In reality this are much more and you know it.
>
> I would say that results in a nice DDOS, because you have not enough
> tcp-sockets to handle that, if the connections are tried at the same time.
>
> Chances that all will try it the same time are excellent, because the spammer
> does not send with 1 machine any longer, the typical spammer is using a botnet,
> so his spam will arrive at your system and some hundrettausand other sav
> abusers the same time.
This will normally not happen.
The spammer will not use the same sender address, or sender addresses
from the same domain, on all his spam messages. This would be a high
risk to the spammer because the sending domain is an easy identification
for the mail to be spam.
So a spammer will normally use many different sender addresses and there
will be no attack on your server.
Unless of course you have done something to the spammer that makes him
retaliate against you.
That is something you should blame yourself for, not the people that use
source address verification.
Rob
> On Nov 16, 4:11 am, Fallout <ad...@ascomex.ro> wrote:
>> On Nov 15, 11:45 pm, Rob <nom...@example.com> wrote:
>>
>> > I don't see a simple connect and three commands as a DDOS attack.
>>
>> And when 10,000 servers including yours send "a simple connect and
>> three commands" at the same time to someone who never sent them
>> anything, will it be a DDOS then? Or one where noone would be guilty,
>> because all each of them did was send 3 commands...
>>
> I'm not quite sure I understand why people are so concerned with
> backscatter.
> Has anyone heard of DDOS attack caused by backscatter. Surely if a
> spammer wanted to comit a DDOS attack against an email server he would
> just email from his botnet a zillion messages to that server, because
> if the spammer used backscatter to do it the number of messages
> hitting that server would only be a fraction of the number of emails
> sent out.
I completely agree with you.
I can understand that it is a problem when your mail address is used
as source address in spam (although I think it is one's own fault;
spammers do this to retaliate against reporting their actions to abuse
desks so you should not do that from a mail address that cannot handle
some load).
The bounces from the spam (backscatter) can be high in volume and can
be a problem for a small server on a slow connection.
However, I cannot understand that this is true for source address
verification. The resources consumed by it are tiny. When it is a
problem for a server, the server should not be on the internet.
Host your mail at a suitable ISP when you are in this position.
Claus v. Wolfhausen
>
>Claus v. Wolfhausen <use-reply-...@remove-this.com> wrote:
>> Spam claiming to be vic...@example.com comes not just to you, it comes also
to
>
>> some Million other systems.
>> Lets assume that 100000 will do sender verify....
>>
>> So now 100000 systems will each connect example.coms mx and each will try
your
>
>> stupid 3 steps ...
>>
>> In reality this are much more and you know it.
>>
>> I would say that results in a nice DDOS, because you have not enough
>> tcp-sockets to handle that, if the connections are tried at the same time.
>>
>> Chances that all will try it the same time are excellent, because the
spammer
>> does not send with 1 machine any longer, the typical spammer is using a
botnet
>,
>> so his spam will arrive at your system and some hundrettausand other sav
>> abusers the same time.
>
>This will normally not happen.
It happens often enough and not only to spamfighters.
If you would not just run a mailsystem for you, mom, dad and 2 dogs then you
would of course know that.
>The spammer will not use the same sender address, or sender addresses
>from the same domain, on all his spam messages. This would be a high
>risk to the spammer because the sending domain is an easy identification
>for the mail to be spam.
It is not, because the spamrun using a botnet is over before the first
blocklist has the domain listed.
>So a spammer will normally use many different sender addresses and there
>will be no attack on your server.
The fact that you have never seen spammers abusing *ONE* of your valid
emailaddresses in a spamrun does not make your claims true.
>Unless of course you have done something to the spammer that makes him
>retaliate against you.
>That is something you should blame yourself for, not the people that use
>source address verification.
It is not a verification, it is an abusive waste of third parties resources.
Even if you get a 250 after RCPT TO that is no proof for that emailaddress did
send you anything, it is just proof that it would accept a bounce from you at
that time, nothing more.
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
--
David Bolt
siversoncan painted this mural:
> Has anyone heard of DDOS attack caused by backscatter.
Yes. I've been on the receiving end of one, as have other users of my
ISP. Here's a couple of links to threads about it:
http://groups.google.com/group/demon.service/browse_thread/thread/1f78fdc608b10aa7
http://groups.google.com/group/demon.service/browse_thread/thread/3a9f7fc392d463ba
http://groups.google.com/group/demon.service/msg/50d96c0cf1e468ee?dmode=source
And, before you point it out, yes they are from a few years ago. That
doesn't alter the fact that people have been DDOSed as a result of
backscatter.
Then there's this one, which was posted at the beginning of last year:
http://groups.google.com/group/news.admin.net-abuse.email/browse_thread/thread/5244ca2e196c8221
I'm sure that a quick search with Google thought the newsgroups will
turn up other, though maybe not quite so extreme, bounce floods.
> Surely if a
> spammer wanted to comit a DDOS attack against an email server he would
> just email from his botnet a zillion messages to that server, because
> if the spammer used backscatter to do it the number of messages
> hitting that server would only be a fraction of the number of emails
> sent out.
Who says they're intentionally DDOSing someone? It may be that they are
viewing it as a positive side-effect of getting their spams out, a sort
of "Ha! Got through to some suckers and you can have some of the crap
that didn't get through"
Regards,
David Bolt
--
Team Acorn: www.distributed.net OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s
openSUSE 10.3 32b | openSUSE 11.0 32b | | openSUSE 11.2 32b
openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b |
RISC OS 4.02 | RISC OS 3.11 | openSUSE 11.1 PPC | TOS 4.02
Claus v. Wolfhausen
>The bounces from the spam (backscatter) can be high in volume and can
>be a problem for a small server on a slow connection.
It is not a question of server speed and internet access.
It is a question of tcp-sockets. No free sockets -> No connections.
>However, I cannot understand that this is true for source address
>verification. The resources consumed by it are tiny. When it is a
>problem for a server, the server should not be on the internet.
>Host your mail at a suitable ISP when you are in this position.
The resources wasted are not even close to be tiny.
Same problem as above:
It is a question of tcp-sockets. No free sockets -> No connections.
With your logic i should therefore declare:
When it is a problem for a server to accept email without "verifications" then
the server should be not on the internet.
Host you mail at a suitable ISP wich offers professional spam filtering when
you are in this position.
You see your logic can easy be used against yourself :-)
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
--
Fallout
>On Nov 15, 11:45 pm, Rob <nom...@example.com> wrote:
> I completely agree with you.
> I can understand that it is a problem when your mail address is used
> as source address in spam (although I think it is one's own fault;
> spammers do this to retaliate against reporting their actions to abuse
> desks so you should not do that from a mail address that cannot handle
> some load).
You guys should read the links posted by David Bolt above. Spammers
put your address in the <mail from> because they have to put an
address. And they won't choose theirs...saying that every fake <mail
from> address sent out (which make probably 80% of all e-mail) is the
result of a row with the spammer is ridiculous beyond belief.
> The bounces from the spam (backscatter) can be high in volume and can
> be a problem for a small server on a slow connection.
So you could handle 10,000 connections per second over 5 days, like
that poor guy?
> However, I cannot understand that this is true for source address
> verification. The resources consumed by it are tiny. When it is a
> problem for a server, the server should not be on the internet.
> Host your mail at a suitable ISP when you are in this position.
Claus pointed out the number of available sockets problem. Besides
that, there is the privacy issue - maybe I don't want you to know the
e-mail addresses I have on my server, you could easily cache a list
and sell it to spammers (not *you* in particular, but anyone doing
SAV)
Dave Platt
>>
>> Multiply that by a few thousand simultaneous sessions and imagine what
>> happens?
>
>For being involved in a DDOS attack, IMHO, threre must be some
>multiplication going on. The controller does something simple and
>as a result the involved systems do more than that.
>(e.g. send more requests, send larger requests)
>
>This is not going on here.
Spam bot-net controller sends out one command to each of 10,000
infected computer: "Send phish message #1 to each address on your
list. Use made-u...@victimdomain.com as the alleged sender."
Each of 10,000 infected bots starts sending out hundreds of spam
emails, to numerous domains, using various addresses in
victimdomain.com as the alleged sender.
It only takes a relatively small number of target domain mail servers,
which implement SAV or which bounce backscatter, to hammer the mail
server at victimdomain.com pretty badly.
In this scenarios, amplification *is* taking place - it occurs at each
infected system in the botnet.
My own mailserver at home has been clobbered in this way on numerous
occasions. I *really* dislike SAV and backscatter... the former more
than the latter, actually, because it results from a deliberate
decision by target domains to "offload" their spam-processing burden,
and because they don't bother to check SPF first.
--
Dave Platt <dpl...@radagast.org> AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
DevilsPGD
<mrdem...@jackpot.invalid> was claimed to have wrote:
>I'm having a little trouble imagining why one might create an MX record
>for an SMTP server that will never either relay or deliver.
I have a fairly default set of DNS records for my hosting customers, I
don't add or remove MX records based on whether or not they create
mailboxes, nor can I think of any particular need to add this level of
complexity to my DNS management code.
Martijn Lievaart
> Claus v. Wolfhausen <use-reply-...@remove-this.com> wrote:
>> Chances that all will try it the same time are excellent, because the
>> spammer does not send with 1 machine any longer, the typical spammer is
>> using a botnet, so his spam will arrive at your system and some
>> hundrettausand other sav abusers the same time.
>
> This will normally not happen.
> The spammer will not use the same sender address, or sender addresses
> from the same domain, on all his spam messages. This would be a high
> risk to the spammer because the sending domain is an easy identification
> for the mail to be spam.
> So a spammer will normally use many different sender addresses and there
> will be no attack on your server.
Although most spam uses randomised from addresses, not all spam does.
With 95% of all email spam, even a small portion that does not use
randomised from addresses can (and does!) add up to a nice DDOS for the
alleged sender. Your assumption just does not hold up in the real world.
> Unless of course you have done something to the spammer that makes him
> retaliate against you.
> That is something you should blame yourself for, not the people that use
> source address verification.
If I fight spam, I must open myself to retaliation? What are you smoking?
Can I have some?
Please reread what you just wrote and tell me again you mean it, I think
(hope!) you will retract that.
M4
Rob
>
>>The bounces from the spam (backscatter) can be high in volume and can
>>be a problem for a small server on a slow connection.
>
> It is not a question of server speed and internet access.
> It is a question of tcp-sockets. No free sockets -> No connections.
Get a better OS then.
Why should your problem of sockets be made into my problem?
You always are the first to point out that practical problems in
mailservers are not to be made the problems of others, yet now you
are doing exactly the same thing!
Get behind your keyboard and fix the problem with sockets in your OS,
instead of claiming it to be a problem that others have to live with.
Martijn Lievaart
[ Please, use that return key. Your mails are very hard to read without
some whitespace. ]
> So you agree that we should pool our resources to end SPAM, but you
> won't lend me a small portion of your resources to very significantly
> reduce the amount of SPAM I get. That sounds contradictory to me. I
> would allow a small amount of my resources to help you. Try to imagine
> 1000 emails coming my way. 950 of them are easily detectable as SPAM. 20
> of them are easily detectable as HAM. I only have 30 left to deal with
> that I need someone else's help with. So I run SPF and DKIM checks and I
> am thankful to the ones that haad enough community spirit to set up
> those records because I able to pass or fail 15 of them. That leaves 15
> out of 1000 that I am not quite sure of. That's 1.5%. Let's say out of
> those 15 one of them said it came from you and it tells me to click on a
> link or open an attachment or something similar. Now, I am not sure if
> it's safe because I don't really know if it came from you because you
> didn't set up SPF or DKIM on your server. Would you rather I pass the
> email on to a user who may open it without thinking or perhaps phone you
> and take your time up to find out if you really sent the messsage, or
> would you allow me to make a small server query to see if your server
> really sent that email.
First, you CANNOT determine if my server sent that mail. That is just BS.
Second, if a spammer has forged my from address, it's not just you but
thousands of others as well that probe my mailserver. It may just keel
over under that bombardment[1]. That is unacceptable. I'm perfectly
willing to lend you some small resource to better the world as a whole.
I'm not prepared to let myself be bombarded because some spammer forged
an email address on my server.
You may be idealistic -- I am too, to some extend --, but this is just
practical. Your solution does not scale.
Actually my mailserver will handle such a bombardment, most people may
not be able to connect. So now you really contributed to a DDOS on my
server. Worse, because callouts now probably will fail, others that do
also use callouts will start rejecting my legitimate mail, because they
cannot connect to my mailserver. Hopefully with a temporary (4xx) error,
but that means my mailserver will have to queue and retry that message
later, when it is already busy with that bombardment of callouts.
So while it seems at the serface to be a good solution, it is actually a
very selfish solution for you as you transfer a small problem on your
side to make it a big problem on my side.
> Actually you have already told me. You think everyone should just leave
> you alone because you are too selfish and short sighted to see this as a
> potential solution to your problem. It does cost spammers to send SPAM.
> The cost is not insignificant. It might cost them $10 to send a million
> SPAM. But lets say they get $.05 every time someone clicks on a link in
> the SPAM email. If we can reduce the number of clicks to less than 200
> for a million SPAM sent then the spammer will stop spamming. I don't
> know what the economies are but there is a cost for everything and there
> is a limit to what can be gained. To stop SPAM we need to reduce the
> gain to less than the cost. The solution is economics.
Spammers will just send out more spam, leading to even more callouts,
worsening the situation outlined above.
> I am not advocating stealing resources, I am asking you to share a small
> portion.
No you are not, you are asking much more than your thinking.
> If we only do sender callouts on the portion of mail we can't be sure
> about otherwise then we are only requesting a small portion of your
> resources, and we are willing to allow an equivalent portion of our
> resources to be shared. That is more of an arm in arm solution to SPAM
> rather than an every man for himself solution. History teaches us that
> those who act together as a team are more successful than those who
> stand alone.
I agree with the sentiment, and I don';t have another solution, but
callouts is not a good solution.
> If you have a better solution to eliminate SPAM then by all means, let
> us hear it.
Working on it. At least some solutions to lessen spam. But I have to
think them through very carefully first. Many solutions that have been
advocated in the past either weren't thought out enough (SPF), would
actually make spamming easier instead of harder (IM2000), required
incompatible changes to SMTP (IM2000 again), didn't scale (callouts, some
crypto solutions). Most even didn't actually work or had unacceptable
side effects (all of the above).
M4
Shmuel (Seymour J.) Metz
11/16/2009
at 07:25 PM, siversoncan <greed...@hotmail.com> said:
>We are at war with spammers
Those who use SAV and send backscatter *are* spammers.
--
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
MrD
> On Nov 17, 4:04 am, Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
>> On Mon, 16 Nov 2009 19:25:26 +0000, siversoncan wrote:
>>> I would love to see the day when spammers give up because they
>>> can't get their SPAM through to end users and any progress
>>> towards that day is benficial for all of us.
>> Agree.
>>
>>> We are at war with spammers and we should pool our resources to
>>> stop
>> Agree.
>>
>>> them instead of saying "stop putting up your wall because I'm
>>> getting some backscatter from your defenses."
>> Disagree. No one is telling you to tear down your wall. But please
>> use a wall that does not involve me.
>>
>> M4
>>
> So you agree that we should pool our resources to end SPAM, but you
> won't lend me a small portion of your resources to very significantly
> reduce the amount of SPAM I get.
If you want to borrow something of mine, you have to arrange it with me
first. Otherwise it's called "stealing".
> or would you allow me to make a small server query to see if your
> server really sent that email.
My server is not configured to support such queries.
> I am not advocating stealing resources, I am asking you to share a
> small portion.
That's not true. Or rather, you may be "asking" here; but if I say no, I
presume you're going to go on doing it. And in general, servers that
make these queries do not have a prior arrangement.
> If you have a better solution to eliminate SPAM then by all means,
> let us hear it.
I don't believe your "solution" is a solution. I don't believe there is
one, at this time. I will not be drafted into a project whose methods I
consider questionable. All your gentle talk about sharing and
cooperation is just that - talk. Your practice is to take without first
getting permission - stealing, in other words.
--
MrD.
http://ipquery.org
Seth
siversoncan <greed...@hotmail.com> wrote:
>So you agree that we should pool our resources to end SPAM,
There's a kind of person who claims to believe that "we" should pool
"our" resources, but somehow it ends up with them not doing any of the
providing, only the use of other people's.
> but you won't lend me a small portion of your resources to very
>significantly reduce the amount of SPAM I get. That sounds
>contradictory to me.
How much of your resources are you providing to others to help them,
with no benefit (only cost) to you?
Since you're the one who wants it, you go first.
> I would allow a small amount of my resources to help you.
Easy to say. Not so easy to do with 50 million "you"s out there.
>Try to imagine 1000 emails coming my way. 950 of them are easily
>detectable as SPAM. 20 of them are easily detectable as HAM. I only
>have 30 left to deal with that I need someone else's help with.
So pay someone to help you. It won't cost much, because you don't
need much help.
> So I run SPF and DKIM checks and I am thankful to the ones that haad
>enough community spirit to set up those records because I able to
>pass or fail 15 of them. That leaves 15 out of 1000 that I am not quite sure
>of. That's 1.5%.
The percentage of your email is intensely uninteresting to me.
> Let's say out of those 15 one of them said it came
>from you and it tells me to click on a link or open an attachment or
>something similar. Now, I am not sure if it's safe because I don't
>really know if it came from you because you didn't set up SPF or DKIM
>on your server.
And if a it passed SPF because a spammer set up SPF (and pointed to
its current zombie pool) that would somehow make it safe?
> Would you rather I pass the email on to a user who may
>open it without thinking or perhaps phone you and take your time up to
>find out if you really sent the messsage, or would you allow me to
>make a small server query to see if your server really sent that
>email.
And for what it's worth, there's no way my server will tell you that.
You aren't even asking that; you're asking the server if my email
address exists. Yes, it does. That says nothing about whether or not
I send any particular email.
>Actually you have already told me. You think everyone should just
>leave you alone because you are too selfish and short sighted to see
>this as a potential solution to your problem.
It isn't a solution to _my_ problem.
>It does cost spammers to send SPAM. The cost is not insignificant.
They have to steal it from Hormel.
> It might cost them $10 to send a million SPAM. But lets say they get
>$.05 every time someone clicks on a link in the SPAM email. If we can
>reduce the number of clicks to less than 200 for a million SPAM sent
>then the spammer will stop spamming.
You're assuming economic rationality of spammers. That assumption
doesn't even work for humans.
>I am not advocating stealing resources, I am asking you to share a
>small portion.
You're taking, with or without permission.
>If we only do sender callouts on the portion of mail we can't be sure
>about otherwise then we are only requesting a small portion of your
>resources,
YM "taking".
> and we are willing to allow an equivalent portion of our
>resources to be shared. That is more of an arm in arm solution to SPAM
>rather than an every man for himself solution.
That is no sort of solution whatsoever. What good does it do for you
to determine that my mailbox exists? How does that help you determine
if mail claiming to be from me is actually forged by a spammer?
What happens when my mailbox fills and I try to send out mail saying
"my mailbox is full so I can't receive mail until further notice"?
You ask if I can receive mail, my mailserver says "no", so you decide
that message is spam. Wrong again.
>If you have a better solution to eliminate SPAM then by all means, let
>us hear it.
Start by learning to spell it correctly.
A bogus non-solution isn't improved by challenging others to do
better.
I do have a better solution: penalize those who spam, and those who
support them. Follow the money and take it back. Pass a law that
anything purchased from spam can be kept, but the money paid can be
recaptured from the credit card company.
Seth
Fallout
> On Nov 17, 4:04 am, Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
>
> > On Mon, 16 Nov 2009 19:25:26 +0000, siversoncan wrote:
> >>I would love to see the day when spammers give up because they
> > > can't get their SPAM through to end users and any progress towards that
> > > day is benficial for all of us.
>
> > Agree.
>
> > > We are at war with spammers and we should pool our resources to stop
>
> > Agree.
>
> > > them instead of saying "stop putting up your wall because I'm getting
> > > some backscatter from your defenses."
>
> > Disagree. No one is telling you to tear down your wall. But please use a
> > wall that does not involve me.
>
> > M4
>
> So you agree that we should pool our resources to end SPAM, but you
> won't lend me a small portion of your resources to very significantly
> reduce the amount of SPAM I get. That sounds contradictory to me. I
> would allow a small amount of my resources to help you.
You are making that decision for someone else. Plus like I said to
Rob, I don't know you're a trustworthy person and won't for instance
sell the list of valid e-mails from my domain gathered from SAV to
third parties. If I wanted you to verify an address, I'd enable VRFY.
Would you rather I pass the email on to a user who may
> open it without thinking or perhaps phone you and take your time up to
> find out if you really sent the messsage, or would you allow me to
> make a small server query to see if your server really sent that
> email.
You're really not finding out anything. If you do your SAV and find
the address exists, it doesn't mean my server really sent it, more
likely it means some spammer forged an address that really exists.
Which is what happens all the time. You seem to be confused thinking
SAV will let you know my server sent that mail.
Why not check the sending IP for the MX record of the sending domain?
If they match, then you'll know. Sure many times the sending IP is
different from any MX IP but at least you won't be invading
> It does cost spammers to send SPAM. The cost is not insignificant. It
> might cost them $10 to send a million SPAM. But lets say they get $.05
> every time someone clicks on a link in the SPAM email. If we can
> reduce the number of clicks to less than 200 for a million SPAM sent
> then the spammer will stop spamming.
If I already have a botnet of 1 million zombie PCs, it will cost me
nothing to send that spam. Ok, maybe a few $ / month to pay for
hosting somewhere. There are many kinds of spam too, for instance a
411 scammer needs to make only 1 good hit out of 100 million spam sent
to make the cost worth it.
>I don't know what the economies are
Obviously.
> If we only do sender callouts on the portion of mail we can't be sure
> about otherwise then we are only requesting a small portion of your
> resources, and we are willing to allow an equivalent portion of our
> resources to be shared.
Meanwhile you can compile a list of existing and used e-mail addresses
that can bring you a profit. Maybe your principles will stop you from
doing it, but it won't stop everybody else...
> That is more of an arm in arm solution to SPAM
> rather than an every man for himself solution. History teaches us that
> those who act together as a team are more successful than those who
> stand alone.
If you could guarantee everyone doing your SAVS will not do anything
with the data collected, I'm sure many would join your rainbow
coalition. Your assumption that every mail server operator is honest
is highly naive IMHO...
> If you have a better solution to eliminate SPAM then by all means, let
> us hear it.
I'd say create laws that force ISP's to care.
Fred Mobach
> Claus v. Wolfhausen <use-reply-...@remove-this.com> wrote:
>> In article <slrnhg4o2r....@xs7.xs4all.nl>, nom...@example.com
>> says...
>>
>>>The bounces from the spam (backscatter) can be high in volume and can
>>>be a problem for a small server on a slow connection.
>>
>> It is not a question of server speed and internet access.
>> It is a question of tcp-sockets. No free sockets -> No connections.
>
> Get a better OS then.
> Why should your problem of sockets be made into my problem?
Which OS can offer more than 65535 IP connections at a time ?
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
Shmuel (Seymour J.) Metz
at 08:57 PM, Rob <nom...@example.com> said:
>Why should your problem of sockets be made into my problem?
Because you want to use his resources. Why should your problems of
laziness and incompetence be made into his problems?
>You always are the first to point out that practical problems in
>mailservers are not to be made the problems of others, yet now you are
>doing exactly the same thing!
He's not trying to use your resources; you're trying to use his. That puts
the onus on you.
--
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
--
Rob
>>>>I don't see a simple connect and three commands as a DDOS attack.
>>>
>>> Multiply that by a few thousand simultaneous sessions and imagine what
>>> happens?
>>
>>For being involved in a DDOS attack, IMHO, threre must be some
>>multiplication going on. The controller does something simple and
>>as a result the involved systems do more than that.
>>(e.g. send more requests, send larger requests)
>>
>>This is not going on here.
>
> Spam bot-net controller sends out one command to each of 10,000
> infected computer: "Send phish message #1 to each address on your
> list. Use made-u...@victimdomain.com as the alleged sender."
>
> Each of 10,000 infected bots starts sending out hundreds of spam
> emails, to numerous domains, using various addresses in
> victimdomain.com as the alleged sender.
>
> It only takes a relatively small number of target domain mail servers,
> which implement SAV or which bounce backscatter, to hammer the mail
> server at victimdomain.com pretty badly.
This is an imaginary situation that is not happening on a large enough
scale in the real world to warrant avoiding it.
It would be much, much easier for the DDOSer to instruct all 10,000
infected computers to connect to the mailserver of victimdomain.com
directly. This would not require the involvement of systems doing
source address verification so it would be much more "effective".
E-Mail Sent to this address will be added to the BlackLists
> Which OS can offer more than 65535 IP connections at a time ?
I heard rumors, that theoretically Solaris can.
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
--
Rob
> On Tue, 17 Nov 2009 18:44:54 +0000, Rob wrote:
>
>> Claus v. Wolfhausen <use-reply-...@remove-this.com> wrote:
>
>>> Chances that all will try it the same time are excellent, because the
>>> spammer does not send with 1 machine any longer, the typical spammer is
>>> using a botnet, so his spam will arrive at your system and some
>>> hundrettausand other sav abusers the same time.
>>
>> This will normally not happen.
>> The spammer will not use the same sender address, or sender addresses
>> from the same domain, on all his spam messages. This would be a high
>> risk to the spammer because the sending domain is an easy identification
>> for the mail to be spam.
>> So a spammer will normally use many different sender addresses and there
>> will be no attack on your server.
>
> Although most spam uses randomised from addresses, not all spam does.
> With 95% of all email spam, even a small portion that does not use
> randomised from addresses can (and does!) add up to a nice DDOS for the
> alleged sender. Your assumption just does not hold up in the real world.
It does. It is not important "what could happen in theory", it is important
what is happening all the time in practice. And that is:
1. spammers don't use the same from address for an entire spam run
just for fun, in fact they avoid doing that. because they know it will
lower their success rate.
2. when spammers use the same address a lot of times, it is called a
joe-job and it is done to retaliate for something the owner of that address
has done.
You may not like it, but it is true.
>> Unless of course you have done something to the spammer that makes him
>> retaliate against you.
>> That is something you should blame yourself for, not the people that use
>> source address verification.
>
> If I fight spam, I must open myself to retaliation? What are you smoking?
> Can I have some?
>
> Please reread what you just wrote and tell me again you mean it, I think
> (hope!) you will retract that.
You may not like it, but it is the factual truth.
When you go out on the street and tell everyone dropping beer cans
that they are a litterer, at some time you will be beaten. Because the
person does not like it when you call upon their responsibility.
Same thing when you fight spam.
That is the way it is, whether you like it or not.
Seth
Rob <nom...@example.com> wrote:
>Get a better OS then.
>Why should your problem of sockets be made into my problem?
You're the one who's using his resources, thereby causing the problem.
Seth
Scott Iverson
> > So you agree that we should pool our resources to end SPAM, but you
> > won't lend me a small portion of your resources to very significantly
> > reduce the amount of SPAM I get.
>
> If you want to borrow something of mine, you have to arrange it with me
> first. Otherwise it's called "stealing".
>
> > or would you allow me to make a small server query to see if your
> > server really sent that email.
>
> My server is not configured to support such queries.
>
> > I am not advocating stealing resources, I am asking you to share a
> > small portion.
>
> That's not true. Or rather, you may be "asking" here; but if I say no, I
> presume you're going to go on doing it. And in general, servers that
> make these queries do not have a prior arrangement.
>
> > If you have a better solution to eliminate SPAM then by all means,
> > let us hear it.
>
> I don't believe your "solution" is a solution. I don't believe there is
> one, at this time. I will not be drafted into a project whose methods I
> consider questionable. All your gentle talk about sharing and
> cooperation is just that - talk. Your practice is to take without first
> getting permission - stealing, in other words.
I don't know how you reached that conclusion. I haven't implemented
SAV and I have stopped my system from emitting backscatter.
Yet you called me a thief based on what? Your logical deduction? With
that kind of logic you better leave the planning to someone else.
Oh, by the way. I have spent quite a bit of time going through my
logs. We get about 10,000 items of SPAM each day. Not huge, but enough
to get a statistical picture. We get SPAM runs of about 100 all the
same (or similar enough that I know they are all from one SPAM run)
quite often and the From: address is not duplicated over the run. It
seems to be either random (generated or picked from a data pool) or
quite often has senders with the same domain as the recipients. It may
be that the spammers that have our addresses all act that way, and
other spammers do not, but based on the information I have DDOS seems
an unlikely result of using SAV.
Besides, if you register an SPF record for your server you would not
get any SAV requests from my server even if I did implement SAV.
However, I am open to a well reasoned argument why SPF or DKIM won't
work. Because if a large enough portion of servers registered and
implemented these forgery detection schemes then there would be no
need to verify addresses with SAV.
I believe that it is possible to cut down the amount of SPAM getting
through to a very tiny amount using a combination of filtering and
verification methods. And if we only use SAV when all other techniques
have failed to determine the value of an individual email then an
unintentional DDOS would not be the result. The result would be that
spammers would find it uneconomical to SPAM.
10 million SPAM emails costs 10 times as much to send as 1 million.
The only way SPAM will stop coming is if we can stop a high enough
percentage of it from getting through so that it costs spammers more
to send their emails than they get from sending them.
Rob
> Rob wrote:
>
>> Claus v. Wolfhausen <use-reply-...@remove-this.com> wrote:
>>> In article <slrnhg4o2r....@xs7.xs4all.nl>, nom...@example.com
>>> says...
>>>
>>>>The bounces from the spam (backscatter) can be high in volume and can
>>>>be a problem for a small server on a slow connection.
>>>
>>> It is not a question of server speed and internet access.
>>> It is a question of tcp-sockets. No free sockets -> No connections.
>>
>> Get a better OS then.
>> Why should your problem of sockets be made into my problem?
>
> Which OS can offer more than 65535 IP connections at a time ?
I think there is no OS that offers IP connections.
When you are talking about TCP connections, there is no global limit to
65535 other than limits in the OS design or implementation.
DevilsPGD
The point is that you don't need 10,000 bots, you only need one bot to
cause hundreds or thousands of servers to harass your victim by way of
verifications.
It's not a DDoS amplifier (well, not unless your server makes multiple
connection attempts of it's met with a 4xx instead of a greeting), but
it does add the "D" to "DoS"
Possibly more important, if the victim blocks zombie'd bot IP addresses,
they lose nothing but spam and abuse. If the attacker relays their
attack through your IP, it's your IP that will get blocked.
E-Mail Sent to this address will be added to the BlackLists
> 2. when spammers use the same address a lot of times,
> it is called a joe-job
joe-job != Forged
Forged != joe-job
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
--
Fred Mobach
> Fred Mobach wrote:
>> Which OS can offer more than 65535 IP connections at a time ?
>
> I heard rumors, that theoretically Solaris can.
Great. How do they do that (I have Solaris boxes running here) ?
As far as I know (but that's not so much) a IP connection is identified
with an IP address and a port number. OK, when multiple IP addresses
are available I see a possibility for more than 65535 IP connections at
a time. :-)
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
--
Dave Platt
Rob <nom...@example.com> wrote:
>> It only takes a relatively small number of target domain mail servers,
>> which implement SAV or which bounce backscatter, to hammer the mail
>> server at victimdomain.com pretty badly.
>
>This is an imaginary situation that is not happening on a large enough
>scale in the real world to warrant avoiding it.
I guess you didn't bother to read the next paragraph in my posting, in
which I said that this *has* happened to my system, repeatedly.
Other people have stated publicly that it *has* happened to their
servers, sometimes repeatedly.
It is by no means an "imaginary" scenario. Even if the bot spamware
is changing forged usernames periodically, the large number of
infected bots in a big net, and the rate at which they send out spam,
means trouble. Even if there are a thousand domain names in a bot's
forged-sender domain list, the odd one-in-a-thousand forgery of a
domain, when multiplied by the large number of bots, adds up to a very
large number of attempted SAV or backscatter connections to each
forged domain.
--
Dave Platt <dpl...@radagast.org> AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
--
AntiSpam
Rob <nom...@example.com> looked something like:
> Dave Platt <dpl...@radagast.org> wrote:
>> It only takes a relatively small number of target domain mail servers,
>> which implement SAV or which bounce backscatter, to hammer the mail
>> server at victimdomain.com pretty badly.
>
> This is an imaginary situation that is not happening on a large enough
> scale in the real world to warrant avoiding it.
>
>
> It would be much, much easier for the DDOSer to instruct all 10,000
That's just it - the DDoS is not deliberate. It is a secondary or side
effect of the spam run. The spammer isn't trying to DDoS anyone - they're
just trying to get their spam out.
It's the servers that use SAV and similar ilk that *result* in a DDoS style
effect on the victimdomain.
--
Current Peeve: The mindset that the Internet is some sort of school for
novice sysadmins and that everyone -not- doing stupid dangerous things
should act like patient teachers with the ones who are. -- Bill Cole, NANAE
MrD
Based on your utterances.
Of course, I don't know if you _really_ try to "share" other peoples'
resources without their permission; perhaps you are speaking
hypothetically. In that case, you would seem to be a hypothetical thief.
> With that kind of logic you better leave the planning to someone
> else.
What planning?
>
> Oh, by the way. I have spent quite a bit of time going through my
> logs. We get about 10,000 items of SPAM each day. Not huge, but
> enough to get a statistical picture. We get SPAM runs of about 100
> all the same (or similar enough that I know they are all from one
> SPAM run) quite often and the From: address is not duplicated over
> the run. It seems to be either random (generated or picked from a
> data pool) or quite often has senders with the same domain as the
> recipients. It may be that the spammers that have our addresses all
> act that way, and other spammers do not, but based on the information
> I have DDOS seems an unlikely result of using SAV.
>
> Besides, if you register an SPF record for your server you would not
> get any SAV requests from my server even if I did implement SAV.
> However, I am open to a well reasoned argument why SPF or DKIM won't
> work.
SPF has intrinsic problems working with forwarders. If you don't know
about this, ask Google.
> Because if a large enough portion of servers registered and
> implemented these forgery detection schemes then there would be no
> need to verify addresses with SAV.
Even without these schemes, there is no need for SAV. It's sufficient to
know who your authenticated users are, and restrict NDRs to those users.
>
> I believe that it is possible to cut down the amount of SPAM getting
> through to a very tiny amount using a combination of filtering and
> verification methods. And if we only use SAV when all other
> techniques have failed to determine the value of an individual email
> then an unintentional DDOS would not be the result. The result would
> be that spammers would find it uneconomical to SPAM.
SPAM is a kind of cheap meat. As such it's always "economical". Perhaps
you mean "spam".
The point you seem to be missing about SAV is this: it's a method for
determining whether a mailbox might exist at a certain mailserver.
That's information that spammers place a premium on, and therefore that
mail admins often want to restrict. Typically they will disable VRFY. If
you then come along and use a bogus RCPT TO to get around the disabled
VRFY, you are attempting to circumvent their policy. Expect to meet
countermeasures (such as blocklists) if you do that.
>
> 10 million SPAM emails costs 10 times as much to send as 1 million.
> The only way SPAM will stop coming is if we can stop a high enough
> percentage of it from getting through so that it costs spammers more
> to send their emails than they get from sending them.
That may or may not be true; but it's not obviously true, and you saying
it doesn't make it so.
--
MrD.
http://ipquery.org
E-Mail Sent to this address will be added to the BlackLists
> We get about 10,000 items of SPAM each day.
> Not huge, but enough to get a statistical picture.
Unless that is per account, you must have a small number of users.
> 10 million SPAM emails costs 10 times as much to send as 1 million.
That could not be much more wrong.
10 million SPAM emails typically costs _the_ _spammer_
some minuscule amount more than sending 1 million.
10 million SPAM emails might costs recipients 10 times
as much to _receive_ as 1 million.
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Shmuel (Seymour J.) Metz
at 03:54 PM, Rob <nom...@example.com> said:
>This is an imaginary situation that is not happening on a large enough
>scale in the real world to warrant avoiding it.
The people claiming to have experienced it have far more credibility than
you do. You keep presenting uninformed guesses as though they were facts.
--
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
--
AntiSpam
Rob <nom...@example.com> looked something like:
> It does. It is not important "what could happen in theory", it is important
> what is happening all the time in practice. And that is:
>
> 1. spammers don't use the same from address for an entire spam run
> just for fun, in fact they avoid doing that.
Some do, some don't. Some use crappy spam software that tries to randomize
>From addresses and fail.
The point remains that this is hardly an imaginary scenario as it happens
every single day to someone.
> 2. when spammers use the same address a lot of times, it is called a
> joe-job and it is done to retaliate for something the owner of that address
> has done.
More likely it's caused by Rule #3: Spammer's are stupid.
Remember - do not attribute to malice that which can be explained by
stupidity.
> You may not like it, but it is true.
Dittos.
>>> That is something you should blame yourself for, not the people that use
>>> source address verification.
I think more rationally than this. I blame the spammer for attacking *and*
the idiots that use SAV.
--
Current Peeve: The mindset that the Internet is some sort of school for
novice sysadmins and that everyone -not- doing stupid dangerous things
should act like patient teachers with the ones who are. -- Bill Cole, NANAE
--
Fred Mobach
> Dave Platt <dpl...@radagast.org> wrote:
>>>>>I don't see a simple connect and three commands as a DDOS attack.
>>>>
>>>> Multiply that by a few thousand simultaneous sessions and imagine
>>>> what happens?
>>>
>>>For being involved in a DDOS attack, IMHO, threre must be some
>>>multiplication going on. The controller does something simple and
>>>as a result the involved systems do more than that.
>>>(e.g. send more requests, send larger requests)
>>>
>>>This is not going on here.
>>
>> Spam bot-net controller sends out one command to each of 10,000
>> infected computer: "Send phish message #1 to each address on your
>> list. Use made-u...@victimdomain.com as the alleged sender."
>>
>> Each of 10,000 infected bots starts sending out hundreds of spam
>> emails, to numerous domains, using various addresses in
>> victimdomain.com as the alleged sender.
>>
>> It only takes a relatively small number of target domain mail
>> servers, which implement SAV or which bounce backscatter, to hammer
>> the mail server at victimdomain.com pretty badly.
>
> This is an imaginary situation that is not happening on a large enough
> scale in the real world to warrant avoiding it.
But to me it happens sometimes. And that's enough for me to not bother
with the culprits and just to block them until the sun stops shining.
And, while you're at it, when my users ask questions I will often
require that they state positive that they need mail from such mail
servers.
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
--
Rob
> But to me it happens sometimes. And that's enough for me to not bother
> with the culprits and just to block them until the sun stops shining.
>
> And, while you're at it, when my users ask questions I will often
> require that they state positive that they need mail from such mail
> servers.
I'm sure you know that this includes the mailservers from almost all
major providers in the Netherlands.
Not allowing those tells a lot about your attitude against users.
Fortunately I am not a user of your services.
MrD
> E-Mail Sent to this address will be added to the BlackLists wrote:
>
>> Fred Mobach wrote:
>>> Which OS can offer more than 65535 IP connections at a time ?
>> I heard rumors, that theoretically Solaris can.
>
> Great. How do they do that (I have Solaris boxes running here) ?
>
> As far as I know (but that's not so much) a IP connection is
> identified with an IP address and a port number. OK, when multiple IP
> addresses are available I see a possibility for more than 65535 IP
> connections at a time. :-)
Setting aside that IP doesn't use ports (I assume you mean TCP), are you
saying that one IP address, one port => one connection?
--
MrD.
http://ipquery.org
D. Stussy
news:he8vm0$qn6$1...@news.eternal-september.org...
> Scott Iverson wrote:
> > ...
> > Besides, if you register an SPF record for your server you would not
> > get any SAV requests from my server even if I did implement SAV.
> > However, I am open to a well reasoned argument why SPF or DKIM won't
> > work.
>
> SPF has intrinsic problems working with forwarders. If you don't know
> about this, ask Google.
That's why one works this out with one's forwarders ahead of time. Make
them get a password and AUTH them, and when they succeed, skip the SPF
check. This way, only the forwarders you trust can forward. If they break
the trust and pass spam that you reject, guess what: They generate an NDR
which may (or may not) cause them to end up on the [defective]
backscatterer list! ;-)
That's NOT rocket science.
Rob
> E-Mail Sent to this address will be added to the BlackLists wrote:
>
>> Fred Mobach wrote:
>>> Which OS can offer more than 65535 IP connections at a time ?
>>
>> I heard rumors, that theoretically Solaris can.
>
> Great. How do they do that (I have Solaris boxes running here) ?
>
> As far as I know (but that's not so much) a IP connection is identified
> with an IP address and a port number. OK, when multiple IP addresses
> are available I see a possibility for more than 65535 IP connections at
> a time. :-)
IP is a connectionless protocol. IP does not have port numbers.
Connections are handled by TCP, a protocol on top of IP.
After you have read up a bit on this, you probably will see that there
is no global limit on the number of connections of 65535.
Fred Mobach
> Fred Mobach <fr...@mobach.nl> wrote:
>> But to me it happens sometimes. And that's enough for me to not
>> bother with the culprits and just to block them until the sun stops
>> shining.
>>
>> And, while you're at it, when my users ask questions I will often
>> require that they state positive that they need mail from such mail
>> servers.
>
> I'm sure you know that this includes the mailservers from almost all
> major providers in the Netherlands.
Sorry, but I don't receive backscatter from those servers.
> Not allowing those tells a lot about your attitude against users.
Your presumptions let you jump to unfounded conclusions.
> Fortunately I am not a user of your services.
And that situation will not change fortunately, for you as for me.
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
--
Fred Mobach
> Fred Mobach <fr...@mobach.nl> wrote:
>> Rob wrote:
>>
>>> Claus v. Wolfhausen <use-reply-...@remove-this.com> wrote:
>>>> In article <slrnhg4o2r....@xs7.xs4all.nl>,
>>>> nom...@example.com says...
>>>>
>>>>>The bounces from the spam (backscatter) can be high in volume and
>>>>>can be a problem for a small server on a slow connection.
>>>>
>>>> It is not a question of server speed and internet access.
>>>> It is a question of tcp-sockets. No free sockets -> No connections.
>>>
>>> Get a better OS then.
>>> Why should your problem of sockets be made into my problem?
>>
>> Which OS can offer more than 65535 IP connections at a time ?
>
> I think there is no OS that offers IP connections.
> When you are talking about TCP connections, there is no global limit
> to 65535 other than limits in the OS design or implementation.
Please tell how TCP connections are identified in an OS. Perhaps by IP
address and port number ? Is it then theoretically possible to have
more than 65535 TCP connections per IP address at a time ?
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
--
Fred Mobach
> Fred Mobach wrote:
>> E-Mail Sent to this address will be added to the BlackLists wrote:
>>
>>> Fred Mobach wrote:
>>>> Which OS can offer more than 65535 IP connections at a time ?
>>> I heard rumors, that theoretically Solaris can.
>>
>> Great. How do they do that (I have Solaris boxes running here) ?
>>
>> As far as I know (but that's not so much) a IP connection is
>> identified with an IP address and a port number. OK, when multiple IP
>> addresses are available I see a possibility for more than 65535 IP
>> connections at a time. :-)
>
> Setting aside that IP doesn't use ports (I assume you mean TCP), are
> you saying that one IP address, one port => one connection?
Sorry to have been unclear, but one local IP address, one port plus one
remote IP address, one port => one connection.
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
--
Shmuel (Seymour J.) Metz
at 11:11 AM, Fred Mobach <fr...@mobach.nl> said:
>Please tell how TCP connections are identified in an OS.
The same as in any other TCP implementation: source IP, source port,
destination IP and destination port.
>Is it then theoretically possible to have
>more than 65535 TCP connections per IP address at a time ?
Il va sans dire. It's even theoretically possible to have more than 64Ki
connections per source IP - destination IP pair, although I wouldn't
expect to see it in practice.
--
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
--
Rob
> Rob wrote:
>
>> Fred Mobach <fr...@mobach.nl> wrote:
>>> But to me it happens sometimes. And that's enough for me to not
>>> bother with the culprits and just to block them until the sun stops
>>> shining.
>>>
>>> And, while you're at it, when my users ask questions I will often
>>> require that they state positive that they need mail from such mail
>>> servers.
>>
>> I'm sure you know that this includes the mailservers from almost all
>> major providers in the Netherlands.
>
> Sorry, but I don't receive backscatter from those servers.
Apparently backscatter is a non-problem.
(after all, the fact that they are listed must mean they are backscattering)
E-Mail Sent to this address will be added to the BlackLists
> Fred Mobach <fr...@mobach.nl> said:
>> Please tell how TCP connections are identified in an OS.
>
> The same as in any other TCP implementation: source IP,
> source port, destination IP and destination port.
>
>> Is it then theoretically possible to have
>> more than 65535 TCP connections per IP address at a time ?
>
> Il va sans dire. It's even theoretically possible to have
> more than 64Ki connections per source IP - destination
> IP pair, although I wouldn't expect to see it in practice.
This is straying kind of from from BlackListing, unless
someone is going to start (or there already is)
e.g. a blacklist of IP address that create excessive
TCP connections (or something like that).
It is going to depend on the performance of the application,
available memory (at least 64 KB per connection), and the
configured limits of the OS; In most unix something like
tcp_conn_request_max (1024).
e.g. in Linux several things can affect the number of TCP
connections:
tcp_max_orphans (typical default is 1024,
number of TCP sockets not attached to any user file handle)
tcp_max_tw_buckets (typical default is 2048,
number of sockets in TIME_WAIT
tcp_max_syn_backlog (typical default is 1024
number of half-open connections,
or 128 or 256 when less than 128 MB of memory)
tcp_synack_retries (typical default is 5)
{usually the above several tcp_max(es) default to multiples
of NR_FILE, as each TCP socket uses a file descriptor}
/proc/sys/kernel/file-max (typical default is 1024)
... so with defaults, likely not more than 1k connections
above those already accepted by your application?
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Rob
> Rob wrote:
>
>> Fred Mobach <fr...@mobach.nl> wrote:
>>> Rob wrote:
>>>
>>>> Claus v. Wolfhausen <use-reply-...@remove-this.com> wrote:
>>>>> In article <slrnhg4o2r....@xs7.xs4all.nl>,
>>>>> nom...@example.com says...
>>>>>
>>>>>>The bounces from the spam (backscatter) can be high in volume and
>>>>>>can be a problem for a small server on a slow connection.
>>>>>
>>>>> It is not a question of server speed and internet access.
>>>>> It is a question of tcp-sockets. No free sockets -> No connections.
>>>>
>>>> Get a better OS then.
>>>> Why should your problem of sockets be made into my problem?
>>>
>>> Which OS can offer more than 65535 IP connections at a time ?
>>
>> I think there is no OS that offers IP connections.
>> When you are talking about TCP connections, there is no global limit
>> to 65535 other than limits in the OS design or implementation.
>
> Please tell how TCP connections are identified in an OS. Perhaps by IP
> address and port number ? Is it then theoretically possible to have
> more than 65535 TCP connections per IP address at a time ?
It seems you do not understand "global limit".
This of course means the limit on TCP connections in the system.
Not from one address. No system would connect you 65535 times at the
same time to verify a source address.
Seth
Rob <nom...@example.com> wrote:
>2. when spammers use the same address a lot of times, it is called a
>joe-job
Sometimes it is, usually it isn't (at least not by people who use the
term correctly).
> and it is done to retaliate for something the owner of that address
>has done.
Such as reporting their earlier spam.
>You may not like it, but it is the factual truth.
>When you go out on the street and tell everyone dropping beer cans
>that they are a litterer, at some time you will be beaten.
And the person attempting to do that raises the level of his crime
from violation to felony.
> Because the
>person does not like it when you call upon their responsibility.
The fact that evil people (such as spammers) do things does not put
any responsibility on the non-evil people fighting them.
Seth
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"MrD" <mrdem...@jackpot.invalid> wrote in message
>news:he8vm0$qn6$1...@news.eternal-september.org...
>> SPF has intrinsic problems working with forwarders. If you don't know
>> about this, ask Google.
>
>That's why one works this out with one's forwarders ahead of time.
How can an ISP know who is going to forward messages to its users? A
new user shows up every few minutes, and some fraction of them get
email forwarded from college alumni accounts, ieee, acm, and lots of
places I've never heard of so couldn't arrange anything with.
Seth
Seth
>> It only takes a relatively small number of target domain mail servers,
>> which implement SAV or which bounce backscatter, to hammer the mail
>> server at victimdomain.com pretty badly.
>
>This is an imaginary situation that is not happening on a large enough
>scale in the real world to warrant avoiding it.
Where do you get definitive information about what's happening to
other people's mailswervers?
>It would be much, much easier for the DDOSer to instruct all 10,000
>infected computers to connect to the mailserver of victimdomain.com
>directly. This would not require the involvement of systems doing
>source address verification so it would be much more "effective".
What if the attacker doesn't have 10,000 zombies, but one computer on
a rogue site with a fast connection? If he sends me 1,000,000
messages, I just block him at the router and stop worrying. If he
sends 1,000,000 messages to 100,000 different backscattering servers,
I get hit by all of them and it isn't nearly so easy or inexpensive to
block.
E-Mail Sent to this address will be added to the BlackLists
> D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>>> SPF has intrinsic problems working with forwarders.
>>> If you don't know about this, ask Google.
>> That's why one works this out with one's forwarders
>> ahead of time.
The typical enduser could not work their way out of a wet
paper bag, much less wrap their mind around how e-mail
happens to work.
Which is why some ISPs do things like disable enduser
email accounts when issues related to forwarding happen.
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
--
miketothep
what I find most disturbing is that the methods used by this list to
"check" servers are abusive in their own right.
You admit that you forge the headers in an attempt to "test" a mail
server, which by definition is abuse. You are abusing the mail servers
of those to whom you send these falsified messages. You yourself are
spamming. You say it's for the greater good, but then you
automatically blacklist a server, and offer to "expedite" its removal
from your list for a fee.
I believe that is the textbook definition of extortion.
If you really were trying to do your duty as a "netizen" there are all
sorts of ways you could actually help the problem by informing the
system administrator and working with them to correct it (at no
charge, of course, since we're all just doing our duty, right?).
But, no, instead you choose to act in the same manner as organized
crime. Your "system" is akin to paying protection money to the mob. Of
course your "justification" is that the IP's are removed after 4
weeks, but what's stopping you from simply listing it again? And
again? and again? You don't even offer to actually help anyone fix
their so-called problem.
I hope I'm wrong, but it's difficult to believe that your motivation
is altruistic in the face of your own questionable methods. It seems
to me, that if you were really trying to help, you certainly wouldn't
be trying to extort money form the so-called abusers, you would
instead be working with mail server operators to educate them of the
issue and to correct it.
Steve Watt
In article <5f9ad9b2-a756-46a4...@j24g2000yqa.googlegroups.com>,
miketothep <miket...@gmail.com> wrote:
>While I suppose the notion of eliminating backscatter is a good one,
>what I find most disturbing is that the methods used by this list to
>"check" servers are abusive in their own right.
Where are you getting the impression that backscatterer.org does active
testing?
>You admit that you forge the headers in an attempt to "test" a mail
>server, which by definition is abuse. You are abusing the mail servers
>of those to whom you send these falsified messages. You yourself are
>spamming. You say it's for the greater good, but then you
>automatically blacklist a server, and offer to "expedite" its removal
>from your list for a fee.
Nothing on the backscatterer.org web site implies that they do this
sort of testing. They have spamtraps that they have seeded however,
and the spammers send the messages. Those misconfigured servers that
generate asynchronous NDRs then get listed.
>I believe that is the textbook definition of extortion.
Quite arguable.
[ removing much based on faulty assumptions. ]
>I hope I'm wrong, but it's difficult to believe that your motivation
>is altruistic in the face of your own questionable methods. It seems
>to me, that if you were really trying to help, you certainly wouldn't
>be trying to extort money form the so-called abusers, you would
>instead be working with mail server operators to educate them of the
>issue and to correct it.
You are wrong. While UCEPROTECT is not especially well operated in
my opinion (it's quite easy for humans to hit spamtraps because they
have put spamtraps on accounts like "webm...@uceprotect.net"), I
don't think they're outright malicious.
No, I don't use UCEPROTECT. But they have a right to publish
whatever they want. If you are attempting to send email to
correspondents that want your mail, and it's somehow being blocked
by the site for a listing on backscatterer, either you need to
stop sending as envelope sender <>, or that site needs to be
notified that their mailer configuration is very broken, and
that using backscatterer as a general DNSBL is a bad idea.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3"
Internet: steve @ Watt.COM Whois: SW32-ARIN
Free time? There's no such thing. It just comes in varying prices...
MrD
> While I suppose the notion of eliminating backscatter is a good one,
> what I find most disturbing is that the methods used by this list to
> "check" servers are abusive in their own right.
Hmmm! I wonder what methods might you be referring to? A far as I'm
aware, the backscatterer list only uses one method: it waits for abusers
to contact it, then lists them. I see nothing abusive in that.
>
> You admit that you
Who does? Your post quotes no context.
> [...] forge the headers in an attempt to "test" a mail server, which
> by definition is abuse.
You seem to be replying to DevilsPGD, Message-ID:
<lmc1g5tn2gidhi36a...@4ax.com>, 17/11/2009; but he
admitted nothing of the sort.
> You are abusing the mail servers of those to whom you send these
> falsified messages. You yourself are spamming. You say it's for the
> greater good, but then you automatically blacklist a server, and
> offer to "expedite" its removal from your list for a fee.
On the other hand, those remarks imply that you're replying to Claus;
but I'm not aware that he has said here (or anywhere) that his server
sends out falsified messages (or any messages at all).
I think you've muddled up remarks from Rob about his policy of fakery,
with a post from Claus saying specifically that his server will *not*
contact you.
The rest of your remarks are therefore moot.
--
MrD.
http://ipquery.org
Shmuel (Seymour J.) Metz
12/05/2009
at 01:25 PM, miketothep <miket...@gmail.com> said:
>You
Whom are you addressing?
>admit that you forge the headers in an attempt to "test" a mail server,
Who admitted that? Is it even true?
>and offer to "expedite" its removal from your list for a fee.
I agree that if you are listed you should not be trusted to have cleaned
up your network before paying the expedited delisting fee. Please click on
the button that says you do not want to be eligible for express delisting.
>If you really were trying to do your duty as a "netizen" there are all
>sorts of ways you could actually help the problem by informing the
>system administrator
Why would they want to be treated as spammers?
>But, no, instead you choose to act in the same manner as organized
>crime.
ROTF,LMAO! When did UCEPROTECT start hiring kneecappers et al?
>Your "system" is akin to paying protection money to the mob.
That's ludicrous. At worst it's analogous to paying CU to stop publishing
an adverse review.
>but what's stopping you from simply listing it again?
Only the integrity of whoever made the first payment. If he didn't
actually fix the problem, then he will and should be listed again. Whether
UCEPROTECT will allow him to continue gaming the system is a separate
question.
>You don't even offer to actually help anyone fix
>their so-called problem.
Why should he? Have you offered him a grant to cover his expenses? Why
aren't *you* helping them, if you really believe that there is such an
obligation?
--
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
--
Claus v. Wolfhausen
> While I suppose the notion of eliminating backscatter is a good one,
> what I find most disturbing is that the methods used by this list to
> "check" servers are abusive in their own right.
What i find most disturbing is that many listees have no clue what
backscatter is but they believe they must blame the backscatterer list
instead of themself.
> You admit that you forge the headers in an attempt to "test" a mail
> server, which by definition is abuse. You are abusing the mail servers
> of those to whom you send these falsified messages. You yourself are
> spamming.
That is one of the most infamous lies i have ever heard about us.
> You say it's for the greater good, but then you
> automatically blacklist a server, and offer to "expedite" its removal
> from your list for a fee.
Since you did not offer to work 24/7 at our hotline free of charge, you
should not expect other people to do that work free of charge.
> I believe that is the textbook definition of extortion.
Tell me the IP you are talking about and i will give you proof that it
is not extortion.
> If you really were trying to do your duty as a "netizen" there are all
> sorts of ways you could actually help the problem by informing the
> system administrator and working with them to correct it (at no
> charge, of course, since we're all just doing our duty, right?).
Hey, you are responsible for your system. You are also not our customer.
Why do you expect us to hold your hand?
> But, no, instead you choose to act in the same manner as organized
> crime. Your "system" is akin to paying protection money to the mob.
If you had similar skills to prevent abuse originating from your system
instead of insulting others, then you wouldn't be listed.
> Of course your "justification" is that the IP's are removed after 4
> weeks, but what's stopping you from simply listing it again? And
> again? and again? You don't even offer to actually help anyone fix
> their so-called problem.
The only thing that stops our system from listing you is if you stop the
abuse originating from your system.
> I hope I'm wrong, but it's difficult to believe that your motivation
> is altruistic in the face of your own questionable methods. It seems
> to me, that if you were really trying to help, you certainly wouldn't
> be trying to extort money form the so-called abusers, you would
> instead be working with mail server operators to educate them of the
> issue and to correct it.
Hey why didn't you visit the backscatterer website from the listed ip?
Then you will find a button called "I do not like expressdelistings"
below the expedited expressdelisting option.
If you click it, you will get immediate proof for that we really don't
want your money.
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
E-Mail Sent to this address will be added to the BlackLists
> While I suppose the notion of eliminating backscatter is
> a good one, what I find most disturbing is that the methods
> used by this list to "check" servers are abusive in their
> own right.
> You admit that you forge the headers in an attempt to
> "test" a mail server, which by definition is abuse.
> You are abusing the mail servers of those to whom you send
> these falsified messages.
References?
It seems likely you are confused,
or otherwise have a perception problem.
As far as I can tell, neither the spamtraps, nor the maintainers
or the DNSbls they feed, are sending out any messages with
forged headers. {The spammers do enough of that themselves.}
--
E-Mail Sent to this address <Blac...@Griffin-Technologies.net>
will be added to the BlackLists.
--
AntiSpam
miketothep <miket...@gmail.com> looked something like:
> spamming. You say it's for the greater good, but then you
> automatically blacklist a server, and offer to "expedite" its removal
> from your list for a fee.
>
> I believe that is the textbook definition of extortion.
"Don't pay us and we'll remove it from our list for free" is extortion?
That and Backscatter (when used properly of course) does not block
legitimate mail, so being listed on it should have no negative affect on
legitimate messages.
So what seems to be the problem?
--
Current Peeve: The mindset that the Internet is some sort of school for
novice sysadmins and that everyone -not- doing stupid dangerous things
should act like patient teachers with the ones who are. -- Bill Cole, NANAE
--
Shmuel (Seymour J.) Metz
at 02:38 PM, Steve Watt <steve.re...@Watt.COM> said:
>If you are attempting to send email to
>correspondents that want your mail, and it's somehow being blocked by the
>site for a listing on backscatterer, either you need to stop sending as
>envelope sender <>, or that site needs to be notified that their mailer
>configuration is very broken, and that using backscatterer as a general
>DNSBL is a bad idea.
Unless you have access to their statistics, you can't know that it is a
bad idea. The best that he could legitimately tell them is that UCEPROTECT
advises against it.
What *is* a bad idea is for a sender to tell an admin that his blocking
decisions are ill informed. An admin who has already thought through the
issues is liable to reach his own conclusions about such claims, and they
may not be conclusions you want.
--
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
--
siversoncan
BlackLists <N...@BlackList.Griffin-Technologies.invalid> wrote:
> miketothep wrote:
>
> > While I suppose the notion of eliminating backscatter is
> > a good one, what I find most disturbing is that the methods
> > used by this list to "check" servers are abusive in their
> > own right.
> > You admit that you forge the headers in an attempt to
> > "test" a mail server, which by definition is abuse.
> > You are abusing the mail servers of those to whom you send
> > these falsified messages.
>
> References?
>
> It seems likely you are confused,
> or otherwise have a perception problem.
>
> As far as I can tell, neither the spamtraps, nor the maintainers
> or the DNSbls they feed, are sending out any messages with
> forged headers. {The spammers do enough of that themselves.}
>
Backscatterer.org is complicit in the forging of spammed email headers
because they are intentionally providing their spamtrap email
addresses to spammers intending the spammers to use those email
addresses in their headers. The intent is to test servers by examining
the results of these spam messages which they have contributed to.
Tha'ts aiding and abetting.
Now I agree that Backscatterer.org does serve a useful purpose, but I
also agree that their motives are not clearly altruistic.
They could certailnly do more to pinpoint an exact time of the
backscatter.
They could also provide a portion of the email without giving away too
much information to help administrators debug their systems.
They pretty much just say don't do it or you will be listed.
E-Mail Sent to this address will be added to the BlackLists
> The word that is missing here is complicit.
> Backscatterer.org is complicit in the forging of spammed
> email headers because they are intentionally providing
> their spamtrap email addresses to spammers
Where, When?
>From all I have seen so far, no more than some others
who reject messages with an explanation in the reject.
e.g. 550 UCEPROTECT-Policy Server decided: 550 (V#.#-EXPO-####)
...
You hit a Spamtrap.
Counter to blacklisting increase for your IP.
421 Service not available, closing transmission channel
...
We have no user with that account here.
No PTR (Reverse-DNS) is assigned to your IP.
Welcome to UCEPROTECT-Level 1.
...
We have no user with that account here.
Your IP was detected to be a Dialup.
Welcome to UCEPROTECT-Level 1.
Are those what you are complaining about?
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
MrD
> On Dec 6, 10:35 am, E-Mail Sent to this address will be added to the
> BlackLists <N...@BlackList.Griffin-Technologies.invalid> wrote:
>> miketothep wrote:
>>
>>> While I suppose the notion of eliminating backscatter is a good
>>> one, what I find most disturbing is that the methods used by this
>>> list to "check" servers are abusive in their own right. You admit
>>> that you forge the headers in an attempt to "test" a mail server,
>>> which by definition is abuse. You are abusing the mail servers of
>>> those to whom you send these falsified messages.
>>
>> References?
>>
>> It seems likely you are confused, or otherwise have a perception
>> problem.
>>
>> As far as I can tell, neither the spamtraps, nor the maintainers or
>> the DNSbls they feed, are sending out any messages with forged
>> headers. {The spammers do enough of that themselves.}
>>
> The word that is missing here is complicit. Backscatterer.org is
> complicit in the forging of spammed email headers because they are
> intentionally providing their spamtrap email addresses to spammers
> intending the spammers to use those email addresses in their headers.
> The intent is to test servers by examining the results of these spam
> messages which they have contributed to.
>
> Tha'ts aiding and abetting.
Rubbish. That's how spamtraps work.
>
> Now I agree that Backscatterer.org does serve a useful purpose, but I
> also agree that their motives are not clearly altruistic.
Altruism? Never trust a hippie, said some punk.
> They could certailnly do more to pinpoint an exact time of the
> backscatter.
Thus exposing their spamtrap. Bad idea.
> They could also provide a portion of the email without giving away
> too much information to help administrators debug their systems.
"Debug their systems" -> frig them so they can continue to backscatter
without hitting spamtraps. Bad idea.
> They pretty much just say don't do it or you will be listed.
Correct.
--
MrD.
http://ipquery.org
D. Stussy
news:970a3fdd-b7ae-4178...@d21g2000yqn.googlegroups.com...
> On Dec 6, 10:35 am, E-Mail Sent to this address will be added to the
> BlackLists <N...@BlackList.Griffin-Technologies.invalid> wrote:
> > miketothep wrote:
> > > While I suppose the notion of eliminating backscatter is
> > > a good one, what I find most disturbing is that the methods
> > > used by this list to "check" servers are abusive in their
> > > own right.
> > > You admit that you forge the headers in an attempt to
> > > "test" a mail server, which by definition is abuse.
> > > You are abusing the mail servers of those to whom you send
> > > these falsified messages.
> >
> > References?
> >
> > It seems likely you are confused,
> > or otherwise have a perception problem.
> >
> > As far as I can tell, neither the spamtraps, nor the maintainers
> > or the DNSbls they feed, are sending out any messages with
> > forged headers. {The spammers do enough of that themselves.}
> >
> The word that is missing here is complicit.
> Backscatterer.org is complicit in the forging of spammed email headers
> because they are intentionally providing their spamtrap email
> addresses to spammers intending the spammers to use those email
> addresses in their headers. The intent is to test servers by examining
> the results of these spam messages which they have contributed to.
>
> Tha'ts aiding and abetting.
That's been my point for the past year. If they protected their trap
mailboxes with SPF, DK/DKIM, or their successors, such that "properly
behaving systems" would recognize the forgeries up front and reject them,
they wouldn't have FALSE POSITIVE listings. By FAILING to do so, they
cannot determine if the receiver is misbehaving because they, as the
mailbox owners, are misbehaving. Forged message status cannot be
determined by the receiver - only the mailbox owner can declare the
appropriate criteria with which to determine it. NDRs in response to
non-spam are appropriate (and required under STD 10), but not all forged
messages are spam. If they don't want NDRs to non-spammy forgeries, that's
what SPF and DK prevent. Forgery has nothing to do with [hostile] content,
and one cannot be substituted for the other.
By choosing NOT to protect their trap mailboxes, they are collaborating
with the spammers; thus, they ARE themselves spammers.
> Now I agree that Backscatterer.org does serve a useful purpose, but I
> also agree that their motives are not clearly altruistic.
As long as it can be contaminated by false positives (by design defect), it
will never be useful. However, they refuse to fix it (despite being told
how) because they would have to admit that I was correct after all. "They
refuse to eat crow."
> They could certailnly do more to pinpoint an exact time of the
> backscatter.
Not if they want to keep their trap addresses secret. However, they could
use UTC, not their local time, and identify that they TRUNCATE to 10 minute
intervals, not ROUND to them. (These operations differ when applying to
the upper-half of the range value.)
> They could also provide a portion of the email without giving away too
> much information to help administrators debug their systems.
Since they won't provide precise times, what makes you think they'd even
consider this?
The time for debugging systems is BEFORE one goes live on the Internet.
> They pretty much just say don't do it or you will be listed.
Including FALSE POSITIVE LISTINGS for servers which would reject the
spammers' forgeries if the DNSBL operators had an SPF or DK/DKIM record
protecting their mailboxes.
AntiSpam
D. Stussy <spam+ne...@bde-arc.ampr.org> looked something like:
> That's been my point for the past year. If they protected their trap
> mailboxes with SPF, DK/DKIM, or their successors, such that "properly
> behaving systems" would recognize the forgeries up front and reject them
Properly behaving systems don't ACCEPT an email and then decide sometime
later to REJECT.
Period.
--
Current Peeve: The mindset that the Internet is some sort of school for
novice sysadmins and that everyone -not- doing stupid dangerous things
should act like patient teachers with the ones who are. -- Bill Cole, NANAE
--
Shmuel (Seymour J.) Metz
12/09/2009
at 08:21 PM, siversoncan <greed...@hotmail.com> said:
>Tha'ts aiding and abetting.
You might have a case for entrapment; claiming aiding and abetting is
stark raving bonkers.
>Now I agree that Backscatterer.org does serve a useful purpose, but I
>also agree that their motives are not clearly altruistic.
Agree with whom? What percentage of the readers of this froup share your
prejudice, and how did you ascertain that percentage?
>They could certailnly do more to pinpoint an exact time of the
>backscatter.
They could. Could they do so without compromising their sources?
>They could also provide a portion of the email without giving away too
>much information
Could they? How do you know that they could? Is your idea of "too much"
the same as theirs?
>to help administrators debug their systems.
I'd like to see them help administers to debug their system; why don't you
give them a grant to fund the effort?
>They pretty much just say don't do it or you will be listed.
Sound much like Consumers Union, which also rates products without helping
the manufacturers to correct design defects, or restaurant reviewers who
don't offer free retraining for poor chefs.
--
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
--