[UseNet] Spam problem with abuse@ ... role address
K. A. Cannon
I figure this is as good as any place to discuss this issue.
Our various role addresses (as are yours) are getting inundated with
spam. Huge amounts of spam. So much spam that using spam assassin and
various other filters doesn't completely alleviate the problem.
I know that some people have a tremendous issue with the "jump through
hoops to get to a person" technique to solve some of the spam issues.
That being said would it be considered improper to auto-ack every
incoming e-mail with something like:
hello...thank you for contacting abuse@ whatever dot com.
In order to expedite your abuse issue please re-send it with
[ABUSE] in the subject line so that we can get to your problem right
away. Thank you for your cooperation.
Anything without [ABUSE] gets dev/null'ed.
This offers two advantages.
One...solves the spam problem.
Two...makes sure that you are getting a real person with a valid
concern.
So...is this worth considering?
And...is it that much against RFC?
--
K. A. Cannon
kevin.a.cannon at gmail dot com
Obviously I'm dealing with inferior mentalities.
-Daffy Duck
COOSN-266-06-02374
Hammer of Thor, April 2005
PIERRE SALINGER MEMORIAL HOOK, LINE & SINKER June 2007
Barbara Woodhouse Memorial Dog Whistle X 2
#9 People ruining UseNet lits.
#6 Top Assholes on the Net lits.
#5 Most hated Usenetizens of all time
#15 AUK psychos and felons lits
#5 Cog in the AUK Hate Machine
http://www.themonastery.org/dev/cert/ulc_certificate_view.swf?id=10010810040
414
Tim Skirvin
> I know that some people have a tremendous issue with the "jump through
> hoops to get to a person" technique to solve some of the spam issues.
> That being said would it be considered improper to auto-ack every
> incoming e-mail with something like:
[snip suggestion of 'ABUSE' subject tag as required for abuse@site mail]
It seems perfectly reasonable to me, given that the alternative is
just to ignore the feed entirely. I'm not really sure that it would work
at scale; the spammers would just start adding that tag. But it's worth a
shot.
- Tim Skirvin (tski...@killfile.org)
--
http://wiki.killfile.org/ Skirv's Homepage <FISH>< <*>
http://wiki.killfile.org/projects/software/ Skirv's Software
Xavier Roche
> That being said would it be considered improper to auto-ack every
> incoming e-mail with something like:
How do you know that the incoming email address is valid ?
Ie. if you get 95% of spam, I assume that 95% of all incoming addresses
will be either (1) invalid or (2) valid but forged (by spammers)
Hence, you are about to send to 90% of all incoming addresses a fake
reply, which is probably going to annoy many people. And a lot of
bounces will probably be sent back to you, too.
Suggestion: what about a 550 error during the SMTP transaction, with the
same message ? You'll never have to send any mail, and won't do any harm
that way.
DATA
..mail
.
550 In order to expedite your abuse issue please re-send it with
K. A. Cannon
<gt7cdk$9kk$1...@news.httrack.net> in news.admin.net-abuse.policy on Tue,
28 Apr 2009 09:55:07 -0700:
That is an idea that I didn't even begin to consider.
You are right...it would cut down the overhead immediately.
--
K. A. Cannon
kevin.a.cannon at gmail dot com
Don't worry about the world coming to an end today.
It's already tomorrow in Australia.
-Charles Schultz
COOSN-266-06-02374
Hammer of Thor, April 2005
PIERRE SALINGER MEMORIAL HOOK, LINE & SINKER June 2007
Barbara Woodhouse Memorial Dog Whistle X 2
#9 People ruining UseNet lits.
#6 Top Assholes on the Net lits.
#5 Most hated Usenetizens of all time
#15 AUK psychos and felons lits
#5 Cog in the AUK Hate Machine
http://www.themonastery.org/dev/cert/ulc_certificate_view.swf?id 010810040414
Kathy Morgan
> Suggestion: what about a 550 error during the SMTP transaction, with the
> same message ? You'll never have to send any mail, and won't do any harm
> that way.
>
> DATA
> ..mail
> .
> 550 In order to expedite your abuse issue please re-send it with
> [ABUSE] in the subject line so that we can get to your problem right away
I know next to nothing about mail servers. In the case of a genuine
abuse message sent by a human, would that person receive the 550 error
message? Or is it just an exchange between servers that the human
doesn't see?
--
Kathy
Xavier Roche
> I know next to nothing about mail servers. In the case of a genuine
> abuse message sent by a human, would that person receive the 550 error
> message? Or is it just an exchange between servers that the human
> doesn't see?
The SMTP transaction extract should always be placed by a reasonably
good SMTP server (RFC 3834) ; hence you should see both error code and
message in the bounce body.
The "message/delivery-status" part of a DSN should itself contain
something like:
Diagnostic-Code: SMTP; 550 message...
Of course a DSN is less clearer that a simple message, but OTOH it is
far better than sending random notices that may not be received (and the
DSN is supposed to be generated by the client's mail server, hence it is
its responsibility to ensure that the use will get it - not yours)
Xavier Roche
And (1) no more risks to send unsolicited mails to anyone and (2) you
did not accept the responsibility neither to take care of the mail nor
to send its DSN bask to the sender (which is the sole responsibility of
the sender's mail server - which is pretty good because at this point if
the user is not notified for any reason, this is not your fault)
Brian Mailman
> That being said would it be considered improper to auto-ack every
> incoming e-mail with something like:
[...]
You might want to ask in nanab about "blowback" or "backscatter" from
forged addresses.
B/
K. A. Cannon
<ofednYuoNMAX_WrU...@supernews.com> in
news.admin.net-abuse.policy on Tue, 28 Apr 2009 13:00:43 -0700:
I get backscatter from TMDA that I use for my own e-mail.
And yes...it is a problem that I considered.
Xavier's idea seems to be very workable/doable.
--
K. A. Cannon
kevin.a.cannon at gmail dot com
Don't worry about the world coming to an end today.
It's already tomorrow in Australia.
-Charles Schultz
COOSN-266-06-02374
Hal Murray
>I know next to nothing about mail servers. In the case of a genuine
>abuse message sent by a human, would that person receive the 550 error
>message? Or is it just an exchange between servers that the human
>doesn't see?
If your server give my server a 5xx, my server will package
that up in a message to me. If a botnet gets a 5xx, they
will probably drop it on the floor or try 6 more times from
other IP Addresses.
Some Microsoft mail server used to "fix" the error text.
They replaced the text from the server with their text.
That discarded any special info provided by the remote
server. Has this been fixed?
--
These are my opinions, not necessarily my employer's. I hate spam.
Hal Murray
>spam. Huge amounts of spam. So much spam that using spam assassin and
>various other filters doesn't completely alleviate the problem.
You can't use spamassassin on the body of mail to abuse@ since
it is likely to include samples of spam.
I don't know any reason to avoid content filtering on other role accounts.
(Maybe stuff that gets caught should be candidates for local
blocking by IP Address.)
Can you give us some numbers? How much spam are you getting? How
many legitimate abuse reports?
How much of your spam to abuse@ gets past a collection of
sane DNSBLs? Is there any pattern you can use for local blocking?
Can you implement the hoop-jumping only for IP ranges that produce
a lot of spam?
I consider hoop-jumping evil. On the other hand, I'd prefer the
option to jump through a reasonable hoop rather than have you
dump everything.
D. Stussy
news:gt7cdk$9kk$1...@news.httrack.net...
Having to "jump through hoops" is a problem. Before implementing such a
requirement, you might want to ask the admin at rfc-ignorant.org if this
change would or would not qualify the domain for its "abuse" dnsbl.... As
I understand that BL's listing requirements, making a REQUIREMENT to
include an "[ABUSE]" literal tag may qualify for a listing. However, if
you accept mail to "abuse@" that doesn't have the tag, then it's a
suggestion, not a requirement, and thus shouldn't be grounds for a listing
(e.g. if the purpose of the tag is to have the message bypass a [subset of
a] spam-filtering system).
"Anything without [ABUSE] gets dev/null'ed" => You will get listed at
rfc-ignorant.org.
Rfc-ignorant.org does have a mailing list:
http://lists.megacity.org/mailman/listinfo/rfci-discuss/
Maybe you should ask your question there?
Kathy Morgan
> Kathy Morgan a �crit :
> > I know next to nothing about mail servers. In the case of a genuine
> > abuse message sent by a human, would that person receive the 550 error
> > message? Or is it just an exchange between servers that the human
> > doesn't see?
>
> The SMTP transaction extract should always be placed by a reasonably
> good SMTP server (RFC 3834) ; hence you should see both error code and
> message in the bounce body.
Thanks to both you and Hal Murray for the clarification.
The 550 error sounds to me like a good solution to the spam sent to role
addresses.
--
Kathy
Xavier Roche
> It'd be interesting to see your opinion on how to accomplish this. I mean, if
> the MX server receives a message, is IT supposed to read the subject of each
> message to see if [ABUSE] is in it after first determining that the target is
> a role address?
This is the suggested hack, yes. With sendmail, a simple cf rule will do
the trick (in LOCAL_CONFIG/LOCAL_RULESETS, with regex -a@MATCH filter).
The transaction-time rejection is in many cases the ultimate weapon
against headaches.
Xavier Roche
> Having to "jump through hoops" is a problem. Before implementing such a
> requirement, you might want to ask the admin at rfc-ignorant.org if this
> change would or would not qualify the domain for its "abuse" dnsbl....
Hum, hum, that's a point I did not consider -- it's true that it would
require an additional reply (and the initial rejection would probably be
considered bad by an automated checking system). OTOH, this is probably
much better than (1) dropping the mail silently (which is something MANY
servers do, very unfortunately) or (2) generating an invalid DSN to an
innocent email address.
I'd be interested to get RFC-Ignorant.org's feedback about this issue --
will try to ask them.
grin
Hal Murray <hal-u...@ip-64-139-1-69.sjc.megapath.net> wrote:
> You can't use spamassassin on the body of mail to abuse@ since
> it is likely to include samples of spam.
so it eventually escalates to rfc-ignorant.org listings, which is fair
enough. been there a few times due to config glitches. ;-)
> Can you give us some numbers? How much spam are you getting? How
> many legitimate abuse reports?
It is worth considering, however, to spam-score incoming. And sort them
locally. I have an abuse "folder" for highscored stuff, I check around
every few months, and if I spot some visually genuine reports, move 'em
out. A few FPs there since some people really include the whole spam
(which is not bad by default, but not too wise in todays environment
either).
Btw we get relatively low amount of spam to abuse, most probably
because they all end up in the user filters, FTL. ;) Spammers seem to
avoid getting into the fast track of filtering.
<g>
--
One of the hunters being hunted.
Chris Lewis
> Having to "jump through hoops" is a problem. Before implementing such a
> requirement, you might want to ask the admin at rfc-ignorant.org if this
> change would or would not qualify the domain for its "abuse" dnsbl.... As
> I understand that BL's listing requirements, making a REQUIREMENT to
> include an "[ABUSE]" literal tag may qualify for a listing. However, if
> you accept mail to "abuse@" that doesn't have the tag, then it's a
> suggestion, not a requirement, and thus shouldn't be grounds for a listing
> (e.g. if the purpose of the tag is to have the message bypass a [subset of
> a] spam-filtering system).
No need to ask:
http://www.rfc-ignorant.org/tools/detail.php?domain=nortelnetworks.com&submi
tted=1069142577&table=abuse
The question really is "do you care what RFCI thinks?". Note the date
on the above.
--
Chris Lewis,
Age and Treachery will Triumph over Youth and Skill
It's not just anyone who gets a Starship Cruiser class named after them.
K. A. Cannon
<gt7uhn$kjf$1...@aux.snarked.org> in news.admin.net-abuse.policy on Tue,
28 Apr 2009 15:04:39 -0700:
<snip>
>"Anything without [ABUSE] gets dev/null'ed" => You will get listed at
>rfc-ignorant.org.
We were already listed by rfc-ignorant.org because a net-kook abused
their service. rfc-ignorant.org seems to be asleep at the switch more
often than not. Considering that rfc-ignorant.org listed us when in
fact we were not in violation and were RFC complaint says volumes
about the credibility and competence of rfc-ignorant.org.
>Rfc-ignorant.org does have a mailing list:
>http://lists.megacity.org/mailman/listinfo/rfci-discuss/
>Maybe you should ask your question there?
We are very responsible with our services and our bandwidth and should
not have to be held accountable to some group of people who have
anointed themselves keepers of what is and isn't RFC compliant.
I am not asking on the rfc-ignorant.org mailing list....I am asking
here. I think the feed back I have gotten so far, especially Xavier's
idea, has been very helpful.
--
K. A. Cannon
kevin.a.cannon at gmail dot com
Don't worry about the world coming to an end today.
It's already tomorrow in Australia.
-Charles Schultz
COOSN-266-06-02374
K. A. Cannon
<gt9ojt$kss$1...@zcars129.ca.nortel.com> in news.admin.net-abuse.policy
on Wed, 29 Apr 2009 07:35:41 -0700:
>According to D. Stussy <rep...@newsgroups.kd6lvw.ampr.org>:
>
>> Having to "jump through hoops" is a problem. Before implementing such a
>> requirement, you might want to ask the admin at rfc-ignorant.org if this
>> change would or would not qualify the domain for its "abuse" dnsbl.... As
>> I understand that BL's listing requirements, making a REQUIREMENT to
>> include an "[ABUSE]" literal tag may qualify for a listing. However, if
>> you accept mail to "abuse@" that doesn't have the tag, then it's a
>> suggestion, not a requirement, and thus shouldn't be grounds for a listing
>> (e.g. if the purpose of the tag is to have the message bypass a [subset of
>> a] spam-filtering system).
>
>No need to ask:
>
>http://www.rfc-ignorant.org/tools/detail.php?domain=nortelnetworks.com&subm
>itted=1069142577&table=abuse
>
>The question really is "do you care what RFCI thinks?".
Indeed...That is the question.
<snip>
--
K. A. Cannon
kevin.a.cannon at gmail dot com
Don't worry about the world coming to an end today.
It's already tomorrow in Australia.
-Charles Schultz
COOSN-266-06-02374
K. A. Cannon
<6JidnbKAEPRQ6mrU...@megapath.net> in
news.admin.net-abuse.policy on Tue, 28 Apr 2009 14:40:29 -0700:
>>Our various role addresses (as are yours) are getting inundated with
>>spam. Huge amounts of spam. So much spam that using spam assassin and
>>various other filters doesn't completely alleviate the problem.
>
>You can't use spamassassin on the body of mail to abuse@ since
>it is likely to include samples of spam.
>
>I don't know any reason to avoid content filtering on other role accounts.
>(Maybe stuff that gets caught should be candidates for local
>blocking by IP Address.)
>
>Can you give us some numbers? How much spam are you getting? How
>many legitimate abuse reports?
Let's see...we started using Ticket Track a little over a year ago and
we are already well into the 34000 numbers.
Of that 34000 I would say we have had about 30+ legitimate abuse
reports.
>How much of your spam to abuse@ gets past a collection of
>sane DNSBLs? Is there any pattern you can use for local blocking?
We have a blacklist of IP addresses and ranges, as well as domains,
that we have developed over time. Even with that you end up playing
catch up since the spam is ever changing and some spam we get is from
valid sources that is originating from a zombie-fied peecee.
(problematical)
Gary was working on a nifty idea to solve some of the spam problems
but it got side lined due to other things getting in the way.
>Can you implement the hoop-jumping only for IP ranges that produce
>a lot of spam?
Possible....but it would be easier just to make one hoop for
everybody.
>I consider hoop-jumping evil. On the other hand, I'd prefer the
>option to jump through a reasonable hoop rather than have you
>dump everything.
I understand your concern...and If there was a rational solution to
100% effectively solve the problem without hoop jumping I'd be all for
it. I have yet to see anything remotely workable.
The spammers are dictating the rules of the game. Through a massive
inundation of useless and resources wasting e-mail. Everybody has to
wade through it. DNSBL's, Spam filters, white-lists, etc. can't seem
to stop the tidal wave.
You can use a challenge response system on your own personal e-mail.
So is it automatically *evil* to implement that for a role address?
--
K. A. Cannon
kevin.a.cannon at gmail dot com
Don't worry about the world coming to an end today.
It's already tomorrow in Australia.
-Charles Schultz
COOSN-266-06-02374
Xavier Roche
> You are right...it would cut down the overhead immediately.
I got one reply from the RFCI mailing-list, from an admin of a big ISP:
both smtp-time subject-based rejection, and automatic reply, have one
serious issue: many reports are now automated (spamcop, for example),
and most usable spam reports are the automated ones (manual reports are
often useless, as full headers are not included, et al.)
With the [ABUSE] trick, you're going to lose automated reports.
Ideally, an automated system would process the spamreport at smtp
transaction time, and if (1) either the report mail can be analyzed
automatically (ie. it contains all the good stuff most automated spam
reports include) or (2) the subject contains [ABUSE], let it flow to the
mail delivery system.
D. Stussy
news:gt9rrr$487$2...@blackhelicopter.databasix.com...
> Chris Lewis <cle...@nortel.com> posted
> <gt9ojt$kss$1...@zcars129.ca.nortel.com> in news.admin.net-abuse.policy
> on Wed, 29 Apr 2009 07:35:41 -0700:
> >According to D. Stussy <rep...@newsgroups.kd6lvw.ampr.org>:
> >> Having to "jump through hoops" is a problem. Before implementing such
a
> >> requirement, you might want to ask the admin at rfc-ignorant.org if
this
> >> change would or would not qualify the domain for its "abuse" dnsbl....
As
> >> I understand that BL's listing requirements, making a REQUIREMENT to
> >> include an "[ABUSE]" literal tag may qualify for a listing. However,
if
> >> you accept mail to "abuse@" that doesn't have the tag, then it's a
> >> suggestion, not a requirement, and thus shouldn't be grounds for a
listing
> >> (e.g. if the purpose of the tag is to have the message bypass a
[subset of
> >> a] spam-filtering system).
> >
> >No need to ask:
> >
>
>http://www.rfc-ignorant.org/tools/detail.php?domain=nortelnetworks.com&sub
mitted=1069142577&table=abuse
> >
> >The question really is "do you care what RFCI thinks?".
>
> Indeed...That is the question.
That is a good question. However, rfc-ignorant is a DNSBL that is used by
some (unlike the worthless SPEWS clones). My point in bringing this to the
OP's attention: If you're going to do something that can potentially get
one's self added to someone else's RBL or ban-list, then it is better to
know that such can happen before implementing the "offensive" system or
feature that qualifies you for the listing. It may also imply that an
alternate solution (that doesn't result in a listing potential), if one
exists, or keeping the status-quo, may be better or preferred.
K. A. Cannon
<gta6j7$qt2$1...@aux.snarked.org> in news.admin.net-abuse.policy on Wed,
29 Apr 2009 11:34:08 -0700:
<snip>
>>http://www.rfc-ignorant.org/tools/detail.php?domain=nortelnetworks.com&sub
>mitted=1069142577&table=abuse
>> >
>> >The question really is "do you care what RFCI thinks?".
>>
>> Indeed...That is the question.
>
>That is a good question. However, rfc-ignorant is a DNSBL that is used by
>some (unlike the worthless SPEWS clones).
Used by some, not all. It is neither universally considered
authoritative nor it is universally considered legitimate.
>My point in bringing this to the OP's attention:
Why?
>If you're going to do something that can potentially get
>one's self added to someone else's RBL or ban-list, then it is better to
>know that such can happen before implementing the "offensive" system or
>feature that qualifies you for the listing.
How would we get on that list?....if I remember correctly last time we
played with RFCI we ended up putting a block on their IP space because
we considered the games they play abusive.
Plus the hypocrisy of RFCI making you jump through *THEIR* hoops to
get un-listed. So...I could care less about something as
hypocritically run as RFCI.
>It may also imply that an alternate solution (that doesn't result
>in a listing potential), if one exists, or keeping the status-quo,
>may be better or preferred.
The status-quo means more money spent by the large ISP's to solve the
problem. The status-quo means the spammers have the initiative and set
the rules of the game.
And it's a "REQUEST FOR COMMENTS"....enforcing that?
Who gave them their shiny badge to be RFC enforcers?
Will they set up FAQ-ignorant.org next?
Chris Lewis
> "D. Stussy" <sp...@bde-arc.ampr.org> posted
> <gta6j7$qt2$1...@aux.snarked.org> in news.admin.net-abuse.policy on Wed,
> 29 Apr 2009 11:34:08 -0700:
>
> >mitted=1069142577&table=abuse
> >> >The question really is "do you care what RFCI thinks?".
> >> Indeed...That is the question.
> >That is a good question. However, rfc-ignorant is a DNSBL that is used by
> >some (unlike the worthless SPEWS clones).
> Used by some, not all. It is neither universally considered
> authoritative nor it is universally considered legitimate.
Case in point: our (then) main domain was listed for the better
part of four years, and as far as I observed, perhaps affected
one or two pieces of email over the whole period.
I only found out about the listing by pure accident.
> >My point in bringing this to the OP's attention:
> Why?
It's probably worth mentioning, but at the same time, ALSO
worth mentioning that an RFC-I listing is only slightly more
a concern than an ASPEWS listing.
Peter J Ross
A. Cannon <kca...@insurgent.orgy> wrote:
> I figure this is as good as any place to discuss this issue.
I'd prefer NAN-AU, but it's up to you.
> Our various role addresses (as are yours) are getting inundated with
> spam. Huge amounts of spam. So much spam that using spam assassin and
> various other filters doesn't completely alleviate the problem.
>
> I know that some people have a tremendous issue with the "jump through
> hoops to get to a person" technique to solve some of the spam issues.
> That being said would it be considered improper to auto-ack every
> incoming e-mail with something like:
>
> hello...thank you for contacting abuse@ whatever dot com.
> In order to expedite your abuse issue please re-send it with
> [ABUSE] in the subject line so that we can get to your problem right
> away. Thank you for your cooperation.
>
> Anything without [ABUSE] gets dev/null'ed.
>
> This offers two advantages.
> One...solves the spam problem.
> Two...makes sure that you are getting a real person with a valid
> concern.
>
> So...is this worth considering?
> And...is it that much against RFC?
That's pretty much what Altopia does, at least for the support@
address. I don't see any reason to object to it, as long as you're
already using something like spamassassin (with frequent updates) to
reduce the potential nuisance to people whose email addresses are
being forged in From: lines.
Could you set it up so that *any* reply to your boilerplate response
that included the appropriate References/In-Reply-To lines would be
whitelisted? People who are too stupid to follow instructions for a
Subject line tag may nevertheless be reporting some genuine abuse.
--
PJR :-)
slrn newsreader v0.9.9p1: http://slrn.sourceforge.net/
extra slrn documentation: http://slrn-doc.sourceforge.net/
newsgroup name validator: http://pjr.lasnobberia.net/usenet/validator
Peter J Ross
Gary L. Burnore <gbur...@databasix.com> wrote:
> On Tue, 28 Apr 2009 20:32:57 -0700, Kathy Morgan <kmo...@spamcop.net> wrote:
>
>>Xavier Roche <xro...@free.fr.NOSPAM.invalid> wrote:
>>
>>> Kathy Morgan a écrit :
>>> > I know next to nothing about mail servers. In the case of a genuine
>>> > abuse message sent by a human, would that person receive the 550 error
>>> > message? Or is it just an exchange between servers that the human
>>> > doesn't see?
>>>
>>> The SMTP transaction extract should always be placed by a reasonably
>>> good SMTP server (RFC 3834) ; hence you should see both error code and
>>> message in the bounce body.
>>
>>Thanks to both you and Hal Murray for the clarification.
>>
>>The 550 error sounds to me like a good solution to the spam sent to role
>>addresses.
>
> That's because you're totally clueless.
The problem isn't that Kathy is totally clueless. The problem is that
90% of people who want to contact you will be totally clueless about
what a message attached to a 550 error response means, if their
software allows them to see the message at all.
Besides, I don't think a server should send an error code unless an
error has occurred. I think something like Kevin's original
challenge/response idea is the best solution.
Peter J Ross
Gary L. Burnore <gbur...@databasix.com> wrote:
> On Wed, 29 Apr 2009 20:33:41 -0700, Chris Lewis <cle...@nortel.com> wrote:
>
>>I only found out about the listing by pure accident.
>
> We only found out because Jamie the Spammer jumped up and down shouting
> he got
> us listed.
This is the first evidence I've ever seen that Lamie can be useful.
:-)
Xavier Roche
> Besides, I don't think a server should send an error code unless an
> error has occurred. I think something like Kevin's original
> challenge/response idea is the best solution.
How do you avoid to spam 90% of all users ? If most incoming mails are
spam, most C/R messages will just be unsolicited emails themselves.
Challenge-response systems are considered harmful in most situations,
because they only limit the amount of incoming spam by generating the
same amount of spam to the outside-world.
Xavier Roche
> Besides, I don't think a server should send an error code unless an
> error has occurred. I think something like Kevin's original
> challenge/response idea is the best solution.
If the rejection is not only based on the [ABUSE] subject hack (ie.
accept all automated or obviously well-formed spam reports), it might be
seen as an anti-spam filter.
There is a class of error codes for rejected message and/or rejected
content when generating an enhanced status code (5XX X.Y.Z).
For example, the enhanced mail system status codes extension
(<http://www.ietf.org/rfc/rfc1893.txt>) suggests the following:
X.7.1 Delivery not authorized, message refused
The sender is not authorized to send to the destination.
This can be the result of per-host or per-recipient
filtering. This memo does not discuss the merits of any
such filtering, but provides a mechanism to report such.
This is useful only as a permanent error.
Xavier Roche
> Having to "jump through hoops" is a problem. Before implementing such a
> requirement, you might want to ask the admin at rfc-ignorant.org if this
The RFCI feedback is that all solutions are bad (and violate RFC), but
the 55X smtp-time rejection is probably the "best solution of the bad
solutions". Generating a "backscatter" (challenge-response system) looks
like the worst solution one can imagine.
K. A. Cannon
<49faa055$0$16612$426a...@news.free.fr> in
news.admin.net-abuse.policy on Fri, 01 May 2009 00:06:51 -0700:
>Peter J Ross wrote:
>> Besides, I don't think a server should send an error code unless an
>> error has occurred. I think something like Kevin's original
>> challenge/response idea is the best solution.
>
>How do you avoid to spam 90% of all users ? If most incoming mails are
>spam, most C/R messages will just be unsolicited emails themselves.
How do you even rationalize that?
The C/R is in reply to an e-mail sent to that address.
It is not sent unsolicited. If anything the C/R is justified due to
the simple fact that it is replying to an e-mail that is *SENT* to
that address the C/R is originating from. Not unsolicited...it is a
legitimate reply to ascertain weather the original e-mail was sent by
a person who will confirm.
>Challenge-response systems are considered harmful in most situations,
>because they only limit the amount of incoming spam by generating the
>same amount of spam to the outside-world.
A legitimate reply to an incoming e-mail is *not* spam.
Your argument is specious.
Chris Witkowski
news:gtf0s0$puu$1...@blackhelicopter.databasix.com...
> Xavier Roche <xro...@free.fr.NOSPAM.invalid> posted
> <49faa055$0$16612$426a...@news.free.fr> in
> news.admin.net-abuse.policy on Fri, 01 May 2009 00:06:51 -0700:
>
> >Peter J Ross wrote:
> >> Besides, I don't think a server should send an error code unless an
> >> error has occurred. I think something like Kevin's original
> >> challenge/response idea is the best solution.
> >
> >How do you avoid to spam 90% of all users ? If most incoming mails are
> >spam, most C/R messages will just be unsolicited emails themselves.
>
> How do you even rationalize that?
> The C/R is in reply to an e-mail sent to that address.
No it isn't. In virtually all cases a challenge is the forwarding of the
spam you received to the forged reply/from/return address(es) in
the spam. It is only very rarely that it is actually a reply.
> It is not sent unsolicited. If anything the C/R is justified due to
The recipients of your challenge did not put their email addresses
into the spam you received. The spammer did. The challenge is
very much unsolicited.
> the simple fact that it is replying to an e-mail that is *SENT* to
> that address the C/R is originating from. Not unsolicited...it is a
As a general rule the from/reply/return address in spam is forged
and it is impossible to actually reply to spam. All you can do by
"replying" is to forward it to the forged address(es). (If you believe
in things like SPF then believe in them and don't send the challenge,
but, I should point out that spammers were early adopters of SPF.)
> legitimate reply to ascertain weather the original e-mail was sent by
> a person who will confirm.
Forwading spam to the forged addresses in spam is not a "legitimate reply".
> >Challenge-response systems are considered harmful in most situations,
> >because they only limit the amount of incoming spam by generating the
> >same amount of spam to the outside-world.
>
> A legitimate reply to an incoming e-mail is *not* spam.
Sending email to the forged addresses in spam is *not* a "legitimate reply".
> Your argument is specious.
And your argument isn't even as good as specious. I know you're
not the only one that doesn't get what is ridiculously obvious but let
me try just once more time: when you "reply" to spam you "reply",
i.e. forward the spam, to the forged address(es) in the spam. I don't
understand why can't understand this simple and obvious aspect of
"replying" to spam.
Also, many people reply to unsolicited challenges to make sure the
sender of the challenge gets their spam anyway as a lesson in the
stupidity and irresponsibility of what they're doing.
Before you post another word you really need to stop and THINK.
--
Christopher Witkowski chr...@ncf.ca http://web.ncf.ca/chrisw
Ph: (705) 256-5359
Chris Lewis
_Only_ if the reply goes back to the real originator of the
email. The From lines in almost ALL spam is forged...
> Your argument is specious.
You have heard of backscatter haven't you? If you know why
backscatter is bad, you'll know why C/R is also bad.
Steve Baker
<gbur...@databasix.com> wrote:
>>And your argument isn't even as good as specious. I know you're
>>not the only one that doesn't get what is ridiculously obvious but let
>>me try just once more time: when you "reply" to spam you "reply",
>>i.e. forward the spam, to the forged address(es) in the spam. I don't
>>understand why can't understand this simple and obvious aspect of
>>"replying" to spam.
>
>SO? No, seriously, _)__)_SO_<_<_?
So you're sending Unsolicited Bulk Email.
>We want to get the mail that is intended
>for a role address. If we shut down the role address, people bitch. If we
>ignore the role address, someone could bitch. If we send a bounce saying
>"reply to this and we'll see your mail", we get the legit mail and the rest
>gets blocked. If someone forges your name on an address to us, the first
>gets a C/R and the rest get dumped on the floor. Certainly better than
>sending you a 550 over and over.
Forged senders will never see a 550. What are you talking about?
>>Also, many people reply to unsolicited challenges to make sure the
>>sender of the challenge gets their spam anyway
>
>That's complete and utter bullshit. I use TMDA on my own personal account and
>never once has a spammer bothered to read a challenge. Besides, in THAT case,
>it'd BE a legitimate reply.
You missed the point, it's not about spammers responding to C/R,
it's about victims of forgery responding to the unsolicited challenges
so the sender of the unsolicited challenge will be getting the spam
"from" that address in the future. It could be looked at as revenge
for the unsolicited challenge, or as a nudge toward behavior
modification.
>> as a lesson in the stupidity and irresponsibility of what they're doing.
>>
>>Before you post another word you really need to stop and THINK.
>
>Eat me. You're not the one wading through 1000 messages/day to see if
>anyone's bitching about what someone's saying about someone in USENet.
Just because you find it expedient doesn't make it right. Now, if
you have *very* good spam filters in front of the C/R, no problem, you
won't be sending unsolicited challenges. In most cases, though, very
good spam filters make C/R moot. But when C/R is used as an anti-spam
strategy the user of C/R becomes a spammer.
--
Steve Baker
Xavier Roche
> If someone forges your name on an address to us, the first
> gets a C/R and the rest get dumped on the floor.
If someone has its _email_ address forged, _he_ will receive an
unsolicited C/R mail. And could probably send a complaint back to you,
as the mail was abusive.
Note that have a dozen of C/R domains permanently blocked now on my
various servers for this reason - and I strongly think that a
"challenge-response blacklist" could be a good idea.
> Certainly better than sending you a 550 over and over.
Why "over and over" ? This is just a permanent delivery error, withotu
any retry (5XX error code, not 4XX temporary code). Besides, you do not
_send_ any email: this is an SMTP-transaction time _reply_.
> Eat me. You're not the one wading through 1000 messages/day to see if
> anyone's bitching about what someone's saying about someone in USENet.
The real problem is if you start to send 1000 messages/day to innocent
victims with fake C/R messages because the role address is heavily spammed.
Xavier Roche
> figure out how to get their names off.
Well, excuse me, but this is precisely what spammers do: "if you do not
want to receive a mail anymore from our server, please contact us".
Yes, I do understand your point of view: you are only replying to
incoming mails. But imagine you reply to every single spam received,
using the "reply" feature of your mail, asking them "please do not
contact me anymore". What will happend ? You are going to annoy many
people, and this is probably not a good thing to do.
The real problem is: if 1000 servers are using C/R, you're not going to
contact them all so that they can "figure out how to get their names off".
> Show me some code that doesn't need to look at all of the tens of thousands of
> mails we receive daily that can quickly figure out if any are to abuse and
> already have [ABUSE] in the Subject line.
Your mail server has to "look at all of the tens of thousands of mails
you receive daily" anyway, to receive/process them. And sending back
(backscatter) a reply is even more time consuming.
A quick example (to be double-checked, I did not test it), using sendmail:
myfilter.m4,
# based on a Robert Harker recipe
LOCAL_CONFIG
HSubject: $>Subject
HTo: $>To
# define the "macro" database
Kmacro macro
# regexp used
# see for example <http://www.stud.uni-hannover.de/~jk/map-regex/>
KIsRoleAddress regex -a@MATCH (^(abuse|postmaster)\@)
KDoesNotContainAbuseKeyword regex -n -a@MATCH (^\[ABUSE\])
LOCAL_RULESETS
SSubject
R$* $| <OK>$* $@ OK
R$* $| <$*>$* $: $1
R$* $: $(DoesNotContainAbuseKeyword $1 $: <OK> $)
R<OK> $@ OK
R$* $: Does not contain the magical keyword $(macro
{Subject} $@ TRUE $)
STo
R$* $| <OK>$* $@ OK
R$* $| <$*>$* $: $1
R$* $: $(IsRoleAddress $1 $: <WARN> $)
R<WARN> $: To a role address $(macro {To} $@ TRUE $)
R$* $@ OK
Scheck_eoh
# Put macros To+Subject into the workspace
R $* $: < $&{To} > < $&{Subject} >
# Clear the macros for the next message
R$* $: $1 $(macro {To} $) $(macro {Subject} $)
# Have macros $&{To} and $&{Subject} been set
R < TRUE > < TRUE > $#error $: 553 5.7.1 Please resend the message
with [ABUSE] as leading subject keyword
(to be improved probably!)
Of course, the ideal solution would be to process the abuse message at
SMTP transaction time, and reject it after the last DATA's "." if the
message format is not recognized (ie. obvious spam complaint with valid
full headers inlined _OR_ subject containing "[ABUSE]").
> No, the real problem is spammers vs some dipshit like RFCI demanding we even
> HAVE a role address like abuse@
This is not an insane recommendation, IMHO. Many big ISP do have a valid
abuse@ role address, generally automatically processed by robots
(including automated spam complaint processing, which is a good thing).
Xavier Roche
No. I meant automatic processing at smtp time, not after delivery.
Perhaps you're unclear on the SMTP process too.
K. A. Cannon
in news.admin.net-abuse.policy on Fri, 01 May 2009 13:35:32 -0700:
>"K. A. Cannon" <kca...@insurgent.orgy> wrote in message
>news:gtf0s0$puu$1...@blackhelicopter.databasix.com...
>> Xavier Roche <xro...@free.fr.NOSPAM.invalid> posted
>> <49faa055$0$16612$426a...@news.free.fr> in
>> news.admin.net-abuse.policy on Fri, 01 May 2009 00:06:51 -0700:
>>
>> >Peter J Ross wrote:
>> >> Besides, I don't think a server should send an error code unless an
>> >> error has occurred. I think something like Kevin's original
>> >> challenge/response idea is the best solution.
>> >
>> >How do you avoid to spam 90% of all users ? If most incoming mails are
>> >spam, most C/R messages will just be unsolicited emails themselves.
>>
>> How do you even rationalize that?
>> The C/R is in reply to an e-mail sent to that address.
>
>No it isn't.
So that e-mail never came at all?
>In virtually all cases a challenge is the forwarding of the
>spam you received to the forged reply/from/return address(es) in
>the spam. It is only very rarely that it is actually a reply.
Semantics...you can set up a C/R to not quote the whole e-mail.
>> It is not sent unsolicited. If anything the C/R is justified due to
>
>The recipients of your challenge did not put their email addresses
>into the spam you received. The spammer did. The challenge is
>very much unsolicited.
So the spammers are setting the rules.
>> the simple fact that it is replying to an e-mail that is *SENT* to
>> that address the C/R is originating from. Not unsolicited...it is a
>
>As a general rule the from/reply/return address in spam is forged
>and it is impossible to actually reply to spam.
And the genuine e-mail....you completely leave that out.
>All you can do by
>"replying" is to forward it to the forged address(es). (If you believe
>in things like SPF then believe in them and don't send the challenge,
>but, I should point out that spammers were early adopters of SPF.)
>
>> legitimate reply to ascertain weather the original e-mail was sent by
>> a person who will confirm.
>
>Forwading spam to the forged addresses in spam is not a "legitimate reply".
If it is sent to our abuse@ address all e-mail has to be considered
legitimate.
>> >Challenge-response systems are considered harmful in most situations,
>> >because they only limit the amount of incoming spam by generating the
>> >same amount of spam to the outside-world.
>>
>> A legitimate reply to an incoming e-mail is *not* spam.
>
>Sending email to the forged addresses in spam is *not* a "legitimate reply".
>
>> Your argument is specious.
>
>And your argument isn't even as good as specious. I know you're
>not the only one that doesn't get what is ridiculously obvious but let
>me try just once more time: when you "reply" to spam you "reply",
>i.e. forward the spam, to the forged address(es) in the spam. I don't
>understand why can't understand this simple and obvious aspect of
>"replying" to spam.
I guess you should talk to all the ISP's that auto-ack e-mail sent to
abuse@....
or did you consider that?
>Also, many people reply to unsolicited challenges to make sure the
>sender of the challenge gets their spam anyway as a lesson in the
>stupidity and irresponsibility of what they're doing.
>
>Before you post another word you really need to stop and THINK.
We are talking about a abuse@ address.
Not anything other than that.
You argument is not convincing.
In essence...the spammers send spam and if you reply to spam to
confirm that is not spam then you might be sending spam...even though
if it is sent to an abuse@ e-mail address it has to be processed and
acknowledged. (duh...no filtering is 100% effective)
So...how about *you* come up with something other than the usual hand
wringing bad spam party line.
K. A. Cannon
<gtfp1o$k0g$1...@zcars129.ca.nortel.com> in news.admin.net-abuse.policy
on Fri, 01 May 2009 14:19:52 -0700:
>According to K. A. Cannon <kevin.a...@gmail.com>:
>> A legitimate reply to an incoming e-mail is *not* spam.
>
>_Only_ if the reply goes back to the real originator of the
>email. The From lines in almost ALL spam is forged...
Goes to abuse@... and if it gets thru the filters it get's auto-ack'ed
anyway....
>> Your argument is specious.
>
>You have heard of backscatter haven't you? If you know why
>backscatter is bad, you'll know why C/R is also bad.
Does nortel send auto-acks to e-mail sent to abuse@ ?
Chris Lewis
> <gtfp1o$k0g$1...@zcars129.ca.nortel.com> in news.admin.net-abuse.policy
> >You have heard of backscatter haven't you? If you know why
> >backscatter is bad, you'll know why C/R is also bad.
> Does nortel send auto-acks to e-mail sent to abuse@ ?
Good ghod no. Auto-acks are pointless these days, and given
that spam to our abuse box outnumbers "real reports" by a few
thousand to one, we do replies by hand to the ones that
need it.
Some random remarks about how we handle abuse@ and the one or two
other role accounts that are "filter light":
- These accounts receive something in the neighborhood of 1500-2000
emails/day.
- About 80% if them are discarded at the filter as being detected
as being _directly_ emitted to our mail servers from a provably
infected host (eg: Cutwail, Xarvester etc). These heuristics have
NEVER EVER misfired that we are aware of (this is not just against
"filter-light" accounts, but all of our production traffic).
Given that bots (eg: cutwail) aren't known for their propensity
to send valid abuse reports, this doesn't seem like much of a hazard ;-)
- Another 5% are discarded at the filter if they hit our regular
filter rules and are RCPT TO'd to more than 2 addresses (here). We
haven't seen that misfire either. CCs (whether local or otherwise)
don't count - has to be > 2 RCPT TO in one SMTP transaction.
- All other filter hits are ignored.
- The accounts end up getting around 100/day into their inboxes.
Most of them hit regular filter rules (including DNSBL), but their
"filter light" status means they get through as normal.
- Thunderbird built-in spam detection does a relatively poor job
at flagging spam in the inboxes.
- On average, about 2 non-spam emails show up per day. Of those:
- Most are from people who believe forged Received lines [1]
or From lines, and complain to us about a spam that didn't
come from us. We usually manually reply telling them it's
bogus, how to identify that they're bogus, and where the
report really should have gone.
This includes SpamCop reports, which are always acked
with a "didn't come from us, forged received line, unroutable
IP" entry on their web pages.
- We get 2-3 bogus reports per week from DMCA monitors about
copyright violations from eDonkey software. There are people
gaming the DMCA monitor sites by generating bogus eDonkey
advertisements with invalid IPs[1]. We've been warning them
they're bogus, and have went through a conversation last year
that _appeared_ to fix it. It's started happening again.
- We get perhaps one valid DMCA report per month (not eDonkey).
- We get a report every month or two from someone's "shiny"
IDS detecting _our_ TCP/IP responses to _them_ sending us a
spam as an attack on _them_.[3]
- We get 2 or 3 validish[2] spam complaints per year that
require action.
[1] When you have a /8, 1/2 of one percent of ALL randomly made
up IPs are in our allocation. Unfortunately, most spam reporters
who complain to us aren't good at recognizing bogus received lines
and sometimes even SpamCop gets it wrong. Secondly, neither they
nor the DMCA monitors bother to check to see if the IP address is
routable. Most of the reports are of unroutable/unallocated IPs,
with just enough good guesses to make us waste our time in
investigating the ones that accidentally hit an in-use IP.
[2] Valid-"ish" in the sense that theoretically everything we do
(whether inhosted or not) is at _least_ COI. I _think_ most of the
"validish" reports are COI'd addresses that have either been repurposed,
or the user didn't understand what they were asking for, and are
simply unsubscribed. That said, I monitor closely anyway, and
any campaign or outsourced mailer that garners more than one
complaint gets a much closer look and "things get fixed, or else".
[3] Huh? Lemme explain: some of our spamtraps/subnets are rather
heavily loaded, which can result in a second TCP SYN-ACK being
send back to the TCP/IP client attempting to set up a connection
to us. _Their_ IDS is detecting the second SYN-ACK (source our IP,
source port 25) as an attack. Invariably, I can show them
the very spam _they_ sent to us triggering the condition.
Chris Witkowski
From: "K. A. Cannon" <kca...@insurgent.orgy>
Newsgroups: news.admin.net-abuse.policy
Sent: Monday, May 04, 2009 11:06 AM
Subject: Re: [UseNet] Spam problem with abuse@ ... role address
> Chris Witkowski <chr...@ncf.ca> posted <gtfmef$jgi$1...@theodyn.ncf.ca>
> in news.admin.net-abuse.policy on Fri, 01 May 2009 13:35:32 -0700:
>
> [...]
> >In virtually all cases a challenge is the forwarding of the
> >spam you received to the forged reply/from/return address(es) in
> >the spam. It is only very rarely that it is actually a reply.
>
> Semantics...you can set up a C/R to not quote the whole e-mail.
Quoting is irrelevant. Spam is not about content, it's about consent.
A challenge sent to a forged address in spam you received,
regardless of the actual content of the challenge, is spam.
> >> It is not sent unsolicited. If anything the C/R is justified due to
> >
> >The recipients of your challenge did not put their email addresses
> >into the spam you received. The spammer did. The challenge is
> >very much unsolicited.
>
> So the spammers are setting the rules.
In the same way and to the extent all criminals do. It's why we have
police, courts, lawyers, locks, safes, armed guards, etc. Some people
go so far as to keep guns for their self-defence. It's not nice, it's not
fair, but, it's the way it is.
In this particular case the rule that the spammers have created is that
you can't automatically reply to email you receive and expect that reply
to actually go to the sender of the email that you are replying.
> >> the simple fact that it is replying to an e-mail that is *SENT* to
> >> that address the C/R is originating from. Not unsolicited...it is a
> >
> >As a general rule the from/reply/return address in spam is forged
> >and it is impossible to actually reply to spam.
>
> And the genuine e-mail....you completely leave that out.
The genuine e-mail is the rare exception. You wouldn't be here
engaging in this discussion if that weren't the case.
> >All you can do by
> >"replying" is to forward it to the forged address(es). (If you believe
> >in things like SPF then believe in them and don't send the challenge,
> >but, I should point out that spammers were early adopters of SPF.)
> >
> >> legitimate reply to ascertain weather the original e-mail was sent by
> >> a person who will confirm.
> >
> >Forwading spam to the forged addresses in spam is not a "legitimate reply".
>
> If it is sent to our abuse@ address all e-mail has to be considered
> legitimate.
If you consider all your abuse@ email to be legitimate then why would
you challenge it?
> >> >Challenge-response systems are considered harmful in most situations,
> >> >because they only limit the amount of incoming spam by generating the
> >> >same amount of spam to the outside-world.
> >>
> >> A legitimate reply to an incoming e-mail is *not* spam.
> >
> >Sending email to the forged addresses in spam is *not* a "legitimate reply".
> >
> >> Your argument is specious.
> >
> >And your argument isn't even as good as specious. I know you're
> >not the only one that doesn't get what is ridiculously obvious but let
> >me try just once more time: when you "reply" to spam you "reply",
> >i.e. forward the spam, to the forged address(es) in the spam. I don't
> >understand why can't understand this simple and obvious aspect of
> >"replying" to spam.
>
> I guess you should talk to all the ISP's that auto-ack e-mail sent to
> abuse@....
> or did you consider that?
I don't subscribe to "lemming logic".
Do you have children? What do you tell them when they give you the
"but Jane's mom let's her do it" or "everybody else is doing it" excuse?
Other people's bad behaviour can't legitimize yours.
> >Also, many people reply to unsolicited challenges to make sure the
> >sender of the challenge gets their spam anyway as a lesson in the
> >stupidity and irresponsibility of what they're doing.
> >
> >Before you post another word you really need to stop and THINK.
>
> We are talking about a abuse@ address.
> Not anything other than that.
>
> You argument is not convincing.
That's because you didn't stop and think as I advised.
> In essence...the spammers send spam and if you reply to spam to
> confirm that is not spam then you might be sending spam...even though
There is no "might" about it. If "you reply to spam to confirm that is not
spam" then you are sending spam.
> if it is sent to an abuse@ e-mail address it has to be processed and
> acknowledged. (duh...no filtering is 100% effective)
>
> So...how about *you* come up with something other than the usual hand
> wringing bad spam party line.
I don't have a wonderful magical solution (often referred to as the FUSSP)
for you and neither does anyone else (see http://www.fussp.org). But I do
know that C/R is not any kind of solution, that all it does is add to the spam
problem. You find the alternatives lacking and I understand that, but, that
that's life and life isn't fair.
If you do decide to go with C/R there is one thing that I forgot to mention
in my previous post. Many of those forged addresses in spam will be for
spam traps. Expect to be blocklisted (and not only in a blocklist dedicated
to backscatter). Perhaps that will be more convincing that anything I can
say.
K. A. Cannon
in news.admin.net-abuse.policy on Mon, 04 May 2009 23:04:40 -0700:
<snip>
>That's because you didn't stop and think as I advised.
I don't think eh?
Yea...sure....I am stoopid...you are smarterest.
You do not offer an alternative...all you have is "you are going to do
the bad!"
Peter J Ross
Xavier Roche <xro...@free.fr.NOSPAM.invalid> wrote:
DataBasix already has very efficient spam filters. I'd be *very*
surprised if Gary and Kevin used only the "From:" line when deciding
whether or not to send a "challenge".
I'd give different advice to people who I thought might be clueless,
such as Al*n C*nn*r or that Scandinavian chap whose name I can't
spell.
However, challenge-response is an absolute last resort, and I hope
DataBasix will be able to abandon it once the kooks have given up
flooding.
Peter J Ross
Gary L. Burnore <gbur...@databasix.com> wrote:
> On Sat, 02 May 2009 05:16:32 -0700, Xavier Roche
> <xro...@free.fr.NOSPAM.invalid> wrote:
>
>>Gary L. Burnore a écrit :
>>> We'd never see it unless they reply to the C/R. If they reply, we'd help them
>>> figure out how to get their names off.
>>
>>Well, excuse me, but this is precisely what spammers do: "if you do not
>>want to receive a mail anymore from our server, please contact us".
>>
>>Yes, I do understand your point of view: you are only replying to
>>incoming mails.
>
> As would, for example Comcast, AT&T, TW/AOL, etc. Even google sends back a
> response.
Yes, it's an *automated* response.
On the understanding that it's OK to send an automated ACK in response
to abuse reports, I don't see why the automated ACK shouldn't also
include instructions for getting the abuse report taken seriously.
Xavier and others seem to oppose the automated ACK that's already
widely used. He and they have a point, but (a) I know that your spam
filtering is both subtle and effective, and (b) if somebody is forging
my email address to contact abuse AT DataBasix, I'd like to know about
it.
Peter J Ross
Gary L. Burnore <gbur...@databasix.com> wrote:
> On Thu, 30 Apr 2009 13:13:10 -0700, Peter J Ross <p...@example.invalid> wrote:
>
>>Besides, I don't think a server should send an error code unless an
>>error has occurred. I think something like Kevin's original
>>challenge/response idea is the best solution.
>
> As do I. We're working on final testing before re-enabling TMDA. A
> legitimate email-er will receive a very carefully worded message telling them
> that all they need to do is reply and their original message and any they
> send
> from then on will make it through untouched, even if they DON'T put
> [ABUSE] in
> the subject line.
It's possible that Xavier and the many people who agree with him are
right, so I suggest caution. Don't implement this until you have time
to watch closely what's going on. And, of course, test it first.
Peter J Ross
Xavier Roche <xro...@free.fr.NOSPAM.invalid> wrote:
Yes, but here we're talking about newbies who may or may not have
detected a genuine example of an AUP violation. To a newbie, "Delivery
not authorized, message refused" is pretty much the same as "Bugger
off, cl00less n00b", which probably isn't the message Kevin and Gary
want to send. Besides, many users of broken software never see such
error messages at all.
K. A. Cannon
wrote:
<snip>
>(b) if somebody is forging my email address to contact abuse AT DataBasix,
>I'd like to know about
>it.
We told Lysaght to stop....but he just replied:
I have you in a tizzy.
--
K. A. Cannon
kevin.a.cannon at gmail.com.
Xavier Roche
> I suppose Xavier is also against a single reply from a mailing list
> saying "We
> received your request to sign up.
Mailing-lists generally do not process requests unless you specify
"subscribe" in the subject, so this is not a real problem.
Xavier Roche
>> Xavier and others seem to oppose the automated ACK that's already
>> widely used.
Well, this is not a major issue, but understand that this might decrease
your ability to deliver correctly emails.
It's like being listed in RFCI and/or any other list, or not having a
valid reverse, or running a server on known "suspicious IP block": each
issue will probably not cause any harm. But multiple ones may cause some
emails to be refused on some hosts.
>> He and they have a point, but (a) I know that your spam
>> filtering is both subtle and effective
If the spam filtering discards all forged spams/viruses messages, this
is probably good and won't do any harm, yes.
>> my email address to contact abuse AT DataBasix, I'd like to know about
>> it.
> Me too.
Humm, isn't every single public email address forged a zillion times by
botnets to send spam ? I had to setup specific bounce filters to discard
fake bounces from misconfigured servers that were sending back error
messages when receiving spam from botnets to unknown users.
And everybody probably received at least once a nice "Your message sent
to XXXX contained a virus" alert from a stupid email gateway ..
Xavier Roche
> I can go to any number of web pages and sign you up
Yes, yes. But there is a difference between
- a manual signup to annoy someone and/or a manual forged mail
and
- automated spams/viruses
In the first case, you'll probably be happy to know how and who did the
forgery, but not on the second case, because hundreds of mail servers
probably receive spams/viruses with your email address forged everyday,
and you just don't care to receive an ack for every single forgery.
Xavier Roche
> What's the difference if you're on the receiving end of a auto-ack you didn't
> send?
Humm, the number of backscatters ?
> So you'd want to know who forged you to a mailing list but not who forged you
> to send an abuse complaint?
Not to "send an abuse complaint", to "send a spam to an abuse address
from some random botnet".
> I DO see that you snipped my point about an auto-ack for every single forgery
> vs only one no matter how many forgeries occur.
I think you did not get an important point: if hundreds of servers are
configured to send a "one time" backscatter, you will anyway receive
hundreds of fake acks if your email is used by spam botnets. That's the
important point.
K. A. Cannon
<gts7ja$jad$1...@news.httrack.net> in news.admin.net-abuse.policy on Wed,
06 May 2009 07:41:46 -0700:
What Xavier did not reply to and snipped out:
>Especially if it's only once. Spammers forging someone else's name tend to
>send multiples. Only the first would get the response. The rest would be
>automagically ignored. If the user was REALLY complaining and sent 20 emails
>he'd get the ack for the first and the other 19 would hold. If he replied to
>the ack, all 20 would get released and then we'd be pissed that he sent 2
>0 when 1 is usually specific.
>Gary L. Burnore wrote:
>>> Xavier and others seem to oppose the automated ACK that's already
>>> widely used.
>> Too bad for him/them.
>
>Well, this is not a major issue, but understand that this might decrease
>your ability to deliver correctly emails.
You forgot to add...IMO...
If you even remotely understood how TMDA works you would not make that
statement.
>It's like being listed in RFCI and/or any other list, or not having a
>valid reverse, or running a server on known "suspicious IP block": each
>issue will probably not cause any harm. But multiple ones may cause some
>emails to be refused on some hosts.
"may cause"
RFC-I is useless and BS....
In order to get on most of the other *legitimate* blacklists one would
have to send *MOUNTAINS* of spam.
Your assertions do not pan out.
>>> He and they have a point, but (a) I know that your spam
>>> filtering is both subtle and effective
>
>If the spam filtering discards all forged spams/viruses messages, this
>is probably good and won't do any harm, yes.
>
>>> my email address to contact abuse AT DataBasix, I'd like to know about
>>> it.
>> Me too.
>
>Humm, isn't every single public email address forged a zillion times by
>botnets to send spam ? I had to setup specific bounce filters to discard
>fake bounces from misconfigured servers that were sending back error
>messages when receiving spam from botnets to unknown users.
On the e-mail addresses I use I rarely if ever get any of those
bounces. But I am diligent enough and careful enough to make sure the
e-mail addresses that matter don't get caught by spam bots.
>And everybody probably received at least once a nice "Your message sent
>to XXXX contained a virus" alert from a stupid email gateway ..
No....but then I expect you would get all kinds of spam.
It then confirms your skewed rational.
--
K. A. Cannon
kevin.a.cannon at gmail dot com
Don't worry about the world coming to an end today.
It's already tomorrow in Australia.
-Charles Schultz
COOSN-266-06-02374
Peter J Ross
Gary L. Burnore <gbur...@databasix.com> wrote:
> On Tue, 05 May 2009 14:20:55 -0700, Peter J Ross <p...@example.invalid> wrote:
>
>>In news.admin.net-abuse.policy on Fri, 01 May 2009 00:06:51 -0700,
>>Xavier Roche <xro...@free.fr.NOSPAM.invalid> wrote:
>>
>>> Peter J Ross wrote:
>>>> Besides, I don't think a server should send an error code unless an
>>>> error has occurred. I think something like Kevin's original
>>>> challenge/response idea is the best solution.
>>>
>>> How do you avoid to spam 90% of all users ? If most incoming mails are
>>> spam, most C/R messages will just be unsolicited emails themselves.
>>>
>>> Challenge-response systems are considered harmful in most situations,
>>> because they only limit the amount of incoming spam by generating the
>>> same amount of spam to the outside-world.
>>
>>DataBasix already has very efficient spam filters. I'd be *very*
>>surprised if Gary and Kevin used only the "From:" line when deciding
>>whether or not to send a "challenge".
>
> FTR, it's NetBasix that has the efficient spam filters (and thanks) and
> DataBasix is one of the domains it hosts. That said, correct, we do not
> decide on From: at all.
That's the answer to most of the doubts about your planned use of
challenge-response, IMO.
You ain't no Alan Connor.
<...>
> I suppose Xavier is also against a single reply from a mailing list
> saying "We
> received your request to sign up. Reply to this if you really wanted to,
> otherwise, someone is forging you." message as this is the exact same thing.
That seems like a good analogy to me.
Go ahead and try it. If the worries expressed by Xavier and others
cause problems, try something else instead.
Peter J Ross
Xavier Roche <xro...@free.fr.NOSPAM.invalid> wrote:
> Gary L. Burnore wrote:
[and previously I wrote:]
>>> Xavier and others seem to oppose the automated ACK that's already
>>> widely used.
>> Too bad for him/them.
>
> Well, this is not a major issue, but understand that this might decrease
> your ability to deliver correctly emails.
>
> It's like being listed in RFCI and/or any other list, or not having a
> valid reverse, or running a server on known "suspicious IP block": each
> issue will probably not cause any harm. But multiple ones may cause some
> emails to be refused on some hosts.
>
>>> He and they have a point, but (a) I know that your spam
>>> filtering is both subtle and effective
>
> If the spam filtering discards all forged spams/viruses messages, this
> is probably good and won't do any harm, yes.
Xavier, it would be nice if you attributed stuff I've written to me,
especially if you choose to respond to it.
I was the one who wrote "He and they have a point ..."
Anyway, we seem to agree provisionally that "this is probably good and
won't do any harm", though I expect that Gary and Kevin will need to
monitor, test and tweak their rules.
Steve Baker
<gbur...@databasix.com> wrote:
>The problem is this: The spam to our role addresses was not serious until one
>jamie baillie started blasting our role addresses out to USENet. Now we get
>99.999% spam and 1% actual complaints. Of that actual 1% complaints, in the
>last several YEARS, only one or two have been REAL Abuse complaints and not
>just "so-and-so called me a booger, make him stop".
>
>
>What Kevin said earlier about the need to treat EVERY complaint as legit until
>reviewed is correct. The problem is, we can't see the complaints from the spam
>without a few hours work/day to cull through the ticketing system.
The fact remains that if you send Challenges to spam you will be a
spammer.
--
Steve Baker
Seth
K. A. Cannon <kevin.a...@gmail.com> wrote:
>Our various role addresses (as are yours) are getting inundated with
>spam. Huge amounts of spam. So much spam that using spam assassin and
>various other filters doesn't completely alleviate the problem.
abuse@ can be filtered by looking inside the body of the message for
your domain, ip addresses, etc; if those don't appear, then the
message isn't useful to you anyway, even if legitimate.
Just don't do as bad a job of it as Yahoo.
Seth
Seth
>>The recipients of your challenge did not put their email addresses
>>into the spam you received. The spammer did. The challenge is
>>very much unsolicited.
Bingo.
>SO? No, seriously, _)__)_SO_<_<_? We want to get the mail that is intended
>for a role address. If we shut down the role address, people bitch. If we
>ignore the role address, someone could bitch. If we send a bounce saying
>"reply to this and we'll see your mail", we get the legit mail and the rest
>gets blocked.
And when a spammer forges my address and you send garbage to me,
that's unsolicited email. Do it a bunch of times, and it's spam.
> If someone forges your name on an address to us, the first
>gets a C/R
spam.
> and the rest get dumped on the floor.
You mean like my report of the C/R as spam? Now you're losing a
legitimate message.
> Certainly better than
>sending you a 550 over and over.
You can't _send_ a 550. It's a *return code*. The only way you can
emit a 550 to me is if *I* start the transaction.
>>Also, many people reply to unsolicited challenges to make sure the
>>sender of the challenge gets their spam anyway
>
>That's complete and utter bullshit.
And true, too.
>Eat me. You're not the one wading through 1000 messages/day to see if
>anyone's bitching about what someone's saying about someone in USENet.
So you think it's acceptable to spam lots of other people to solve
your problem?
Seth
Greg Samson
[snipped for emphasis]
> So you're sending Unsolicited Bulk Email.
Yes. There is NO WAY for a challenge-response system to do anything else
in the
current spam environment. Pretty much all the incoming spam has a forged
From:
address on it, which is all it has to go on; there's no way for a challenge
to be
sent "back" in the SMTP transaction.
Even worse, spammers frequently reuse addresses and domains in their spamruns.
Even one challenge-response system getting hit can cause an avalanche of
backscatter spam.
--
u wi zat clue stick dotorg
E-Mail Sent to this address will be added to the BlackLists
> Steve Baker wrote:
>> So you're sending Unsolicited Bulk Email.
>
> Yes. There is NO WAY for a challenge-response system
> to do anything else in the current spam environment.
> Pretty much all the incoming spam has a forged From:
> address on it, which is all it has to go on;
> there's no way for a challenge to be sent "back" in
> the SMTP transaction.
Thats not true.
I've seen one that did a 4xx temp fail (likely greylisting),
then later 5xx reject with a URL for a C/R.
{I couldn't tell you what software it was,
I ran into it a few years ago.}
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Greg Samson
> Greg Samson wrote:
>> Steve Baker wrote:
>>> So you're sending Unsolicited Bulk Email.
>> Yes. There is NO WAY for a challenge-response system
>> to do anything else in the current spam environment.
>> Pretty much all the incoming spam has a forged From:
>> address on it, which is all it has to go on;
>> there's no way for a challenge to be sent "back" in
>> the SMTP transaction.
>
> Thats not true.
>
> I've seen one that did a 4xx temp fail (likely greylisting),
> then later 5xx reject with a URL for a C/R.
>
> {I couldn't tell you what software it was,
> I ran into it a few years ago.}
Unfortunately that sort of C/R software seems rare nearly to the point of
nonexistence. However there's a flood of backscatter garbage from
MailInBlack,
TMDA, SpamArrest, Active Spam Killer, Spam Lion...
I've also noticed that they often seem to get used in places that are spam
hotbeds
- France, Brazil, etc. Perhaps that's the only environment that will
tolerate them.