Is predictable spam filtering a vulnerability?

[R Armiento]

During a recent email conversation with several participants, we discovered that the email service of one participant silently dropped legitimate emails that happened to contain certain combinations of words common in spam. I believe this sort of filter i
s common practice, and in fact even in place for some of my own email addresses.

However, this experience made me think: isn't predictable spam filtering in general a vulnerability that could be used as a hoax device? Since most users reply to an email citing the complete source email, including filter-offending words, it should be po
ssible to keep a reply, forward, or even a whole thread, under the radar of specific recipients. If used in combination with forged replies from addresses predictably dropping emails, I think this may be a dangerous tool for social engineering.

For example: attacker 'A' sends 'B' a social engineering request for "the secret plans" and says "if you are unsure, forward my request to your boss and ask if this is okay". 'B' forwards the email to his boss 'C' and asks "Is this okay?". However, 'C':s
spam filter silently drops the email. 'A' forges a reply from 'C' saying: "Sure, no problem, go ahead."

Regards,
R. Armiento

[Joel Eriksson]

On Wed, Jun 16, 2004 at 01:26:28PM +0200, R Armiento wrote:
[snip]
> For example: attacker 'A' sends 'B' a social engineering request
> for "the secret plans" and says "if you are unsure, forward my
> request to your boss and ask if this is okay". 'B' forwards the
> email to his boss 'C' and asks "Is this okay?". However, 'C':s
> spam filter silently drops the email. 'A' forges a reply from
> 'C' saying: "Sure, no problem, go ahead."

Many will probably discard the above as farfetched or ignore it
since it's not a "real" vulnerability that gives remote root to
the attacker, I think it's beautiful though. :)

Security is a state of mind, a way of thinking. Vulnerabilities
are all around us and the one you point out above is certainly
one of them.

> Regards,
> R. Armiento

--
Best Regards,
Joel Eriksson
-------------------------------------------------
Cellphone: +46-70 228 64 16 Home: +46-26-10 23 37
Security Research & Systems Development at Bitnux
PGP Key Server pgp.mit.edu, PGP Key ID 0x08811B44
DF38 5806 0EFB 196E E4B6 34B5 4C01 73BB 0881 1B44
-------------------------------------------------

[Hamlesh Motah]

Interesting insight that, in most cases I'd think B and C are likely to =
be
on the same network, possibly protected by the same spam filtering, =
meaning
that A's email wouldn't reach B. I know this isn't always the case, =
just my
thoughts on it.

The above would help reduce the probability of finding a scenario where =
this
would work, that said securing against social engineering attacks is a =
tad
challenging :)

Again all of the above just my two cents.

Kind regards.

Hamlesh Motah.
IT Consultant.

tel: +44 (0)709 212 0732
fax: +44 (0)709 212 0732
ema: admin@hamlesh.com
web: www.hamlesh.com

Hamlesh Consultants - IT Consultancy - Total Solutions Provider.

The Information contained in this E-Mail and any subsequent =
correspondence
is private and is intended solely for the intended recipient(s). For =
those
other than the recipient any disclosure, copying, distribution, or any
action taken or omitted to be taken in reliance on such information is
prohibited and may be unlawful.


: -----Original Message-----
: From: R Armiento [mailto:rar_bt@armiento.se]=20
: Sent: 16 June 2004 11:26
: To: bugtraq@securityfocus.com
: Subject: Is predictable spam filtering a vulnerability?
:=20
:=20
:=20
: During a recent email conversation with several participants,=20
: we discovered that the email service of one participant=20
: silently dropped legitimate emails that happened to contain=20
: certain combinations of words common in spam. I believe this=20
: sort of filter is common practice, and in fact even in place=20
: for some of my own email addresses.
:=20
: However, this experience made me think: isn't predictable=20
: spam filtering in general a vulnerability that could be used=20
: as a hoax device? Since most users reply to an email citing=20
: the complete source email, including filter-offending words,=20
: it should be possible to keep a reply, forward, or even a=20
: whole thread, under the radar of specific recipients. If used=20
: in combination with forged replies from addresses predictably=20
: dropping emails, I think this may be a dangerous tool for=20
: social engineering.=20
:=20
: For example: attacker 'A' sends 'B' a social engineering=20
: request for "the secret plans" and says "if you are unsure,=20
: forward my request to your boss and ask if this is okay". 'B'=20
: forwards the email to his boss 'C' and asks "Is this okay?".=20
: However, 'C':s spam filter silently drops the email. 'A'=20
: forges a reply from 'C' saying: "Sure, no problem, go ahead."
:=20
: Regards,
: R. Armiento
:=20

[Aaron Cake]

> During a recent email conversation with several participants, we
> discovered that the email service of one participant silently
> dropped legitimate emails that happened to contain certain
> combinations of words common in spam. I believe this sort of
> filter is common practice, and in fact even in place for some of
> my own email addresses.
>
> However, this experience made me think: isn't predictable spam
> filtering in general a vulnerability that could be used as a hoax
> device?

Certainly. I have brought this issue up with several other ISPs who insist
on blocking my personal domain because I'm a "little guy". They can't prove
that I don't spam, so they default to blocking everything that comes from me
instead. AOL is the biggest and perhaps most annoying offender.

I personally see this as a denial of service attack against MYSELF.
Obviously not meant to be malicious in nature, but quite effective
regardless.

Imagine if I decided to use a spam fitler against someone else...I make an
email that contains known rejected words. I send that email, setting the
"FROM" address and header to be that of my victim. If I send out hundreds of
these messages, I can use someone else's spam filter to mail-bomb my victim
with "rejected" messages.

The REAL issue is that any email filter that silently drops messages can
easily mistake legitimate mail for spam. The user never knows, sometimes the
sender doesn't know, and the braindead admins who set up the filter think
they've done their job. What is even more useless is when the message is
bounced with instructions on how to get off their block list. You send an
email to their admin, yet it is bounced!

Spam filters are often worse then the spam problem itself.

---
Aaron Cake
Technical Services
Advanced Computer Ideas
Phone: 1-519-433-0279
Fax: 1-519-433-5413

[David F. Skoll]

On Wed, 16 Jun 2004, R Armiento wrote:

> However, 'C':s spam filter silently drops the email.

In my opinion, any spam filter that silently drops e-mail is broken, and
is indeed a security risk. A spam filter MUST respond with a 500 SMTP
failure code if it rejects a message.

Regards,

David.

[Jon Fiedler]

David F. Skoll wrote:

>On Wed, 16 Jun 2004, R Armiento wrote:
>
>
>
>>However, 'C':s spam filter silently drops the email.
>>
>>
>
>In my opinion, any spam filter that silently drops e-mail is broken, and
>is indeed a security risk. A spam filter MUST respond with a 500 SMTP
>failure code if it rejects a message.
>
>Regards,
>
>David.
>
>
This ignores client side spam filters, and doesn't really change the
attack. The 500 message would be sent back to A, but not B, so B is
still in the dark about C not receiving the emails.

jon

[David F. Skoll]

On Fri, 18 Jun 2004, Jon Fiedler wrote:

> >In my opinion, any spam filter that silently drops e-mail is broken, and
> >is indeed a security risk. A spam filter MUST respond with a 500 SMTP
> >failure code if it rejects a message.

> This ignores client side spam filters,

Client-side spam filters that silently drop e-mail are broken. They
should generate a non-delivery notification.

Of course, that leads to all kinds of other nasty problems, so I've
concluded that client-side spam filters in general are broken, and the
only proper way to do it is on the server, and only by failing the
SMTP transaction.

> and doesn't really change the
> attack. The 500 message would be sent back to A, but not B, so B is
> still in the dark about C not receiving the emails.

No; B would get the failure message, because B is the envelope sender.

Regards,

David.

[Romulo M. Cholewa]

Greetings,

spam filters are a really big concern for most customers we have. They =
sure
hate spam, know that it statistically means that their employees will =
loose
some time filtering it out, not to mention those evil spam that carry
malicious code or point to malicious sites.

Content filtering is really tricky, and most of those customers try to =
avoid
it. They do it because they don't want to risk blocking a legitimate
message in favor of 10 blocked spams.

TBH, most of them employ 2 basic spam filtering techniques: source =
domain
filtering and realtime blackhole lists (RBLs).

The source domain filtering has some concerns. The biggest one is the =
fact
that most spam today forge the source email address, trying specifically =
to
avoid such mechanism. But they don't choose wisely (hope spammers won't =
read
this message) and usually choose borked email domains making it easier =
to
filter them out. Currently, some customers have lists of as much as =
20.000
blocked domains and emails. what is really strange is the fact that it
proves to be an effective way of blocking spam, so far.

The RBLs are now widely available, and some of them are more aggressive =
than
others.

Together, filtering by source domain / email address (with wildcards, =
such
as addresses with *no_reply*@*, *buycheap*@*, even *spam*@*), subject, =
and
RBLs prove to be around 60% effective (empyrical observation). Those
customers that employ content filtering increase their filtering rate to
around 70% with their desired settings, but also the amount of =
legitimate
emails blocked.

But bear in mind that those who do any sort of filtering have someone
actively monitoring incoming emails to keep up 2 date with filtering =
rules.
There is no way of employing a tool that does the job unnatended, or the
current tools are not capable of this (at least, not for now).

One of the actions we do to reduce such occurences with border / gateway
smtp filtering is to have some "loose" rules for internal messages, or
making internal messages don't pass the border smtp gateway. Internal =
emails
are treated differently than those coming from the outside, and all =
clients
using the corporate email systems from the outside use specific
authentication mechanisms to treat them as internal, in most cases.

One thing that content filtering really does help is to avoid malicious =
code
to be dropped to an internal inbox, and also, those emails that point to
malicious sites or downloads. Here in Brazil, it's really common to =
receive
bank scams trying to fool the user into loading a spoofed page to gather
users and passwords. There are groups specialized in this tactic.

Regards,

Romulo M. cholewa
Home: http://www.rmc.eti.br
News: http://www.rmc.eti.br/news
PGP key id 0x7F8A3B40



] -----Original Message-----
] From: Aaron Cake [mailto:aaron@vltpm.com]=20
] Sent: Thursday, June 17, 2004 11:19 AM
] To: bugtraq@securityfocus.com
] Subject: RE: Is predictable spam filtering a vulnerability?
]=20
] > During a recent email conversation with several participants, we=20
] > discovered that the email service of one participant=20
] silently dropped=20
] > legitimate emails that happened to contain certain combinations of=20
] > words common in spam. I believe this sort of filter is common=20
] > practice, and in fact even in place for some of my own email=20
] > addresses.
] >
] > However, this experience made me think: isn't predictable spam=20
] > filtering in general a vulnerability that could be used as a hoax=20
] > device?
]=20
] Certainly. I have brought this issue up with several other=20
] ISPs who insist on blocking my personal domain because I'm a=20
] "little guy". They can't prove that I don't spam, so they=20
] default to blocking everything that comes from me instead.=20
] AOL is the biggest and perhaps most annoying offender.

(...)

[Gadi Evron]

R Armiento wrote:

> During a recent email conversation with several participants, we discovered that the email service of one participant silently dropped legitimate emails that happened to contain certain combinations of words common in spam. I believe this sort of filter
is common practice, and in fact even in place for some of my own email addresses.
>
> However, this experience made me think: isn't predictable spam filtering in general a vulnerability that could be used as a hoax device? Since most users reply to an email citing the complete source email, including filter-offending words, it should be
possible to keep a reply, forward, or even a whole thread, under the radar of specific recipients. If used in combination with forged replies from addresses predictably dropping emails, I think this may be a dangerous tool for social engineering.

Generally, the word 'vulnerability' is attributed to actual flaw in
code. Me? I believe that if a software fails to do it's job due to
missing a feature or a feature not working correctly, it is indeed a
vulnerability, a weakness, or whatever other name you'd like to call it.

Using the word 'vulnerability' for it might not be the best of choices,
but it fits.

On the other hand, security products have to keep up with an evolving
world. New attacks and ways of circumventing detection show up daily,
and products update themselves accordingly. Is it being out-dated or
vulnerable for a product to act as you describe?

Maybe there is a time-issue on if and when the product gets updates, or
perhaps even if new blocks are required and old products can't be
expected to keep up.

Me? I believe that if a product does not keep up-to-date for doing what
it claims to do, it is useless. Not vulnerable.

Another good example is virus scanners which do not support unpacking of
different PE packers, when nowadays malware gets released and
re-released simply re-packed with a different packer, making it
undetectable to about half of the current top-products. Sometimes
getting a new name while at it for the media to chew on.

A poor choice of wording or plain exaggerations? I suppose that with a
missing definitions each person would have to decide for him/herself.
Calling it a vulnerability is fine.. but don't complain about the
stoning later. :) I didn't.

Gadi Evron.

[Jason Coombs]

> On Wed, Jun 16, 2004 at 01:26:28PM +0200, R Armiento wrote:
>>For example: attacker 'A' sends 'B' a social engineering request
>>for "the secret plans"
....
>>spam filter silently drops the email. 'A' forges a reply

Joel Eriksson wrote:
> it's not a "real" vulnerability that gives remote root to
> the attacker, I think it's beautiful though. :)

More likely I will ask your boss to approve payment of an invoice and
then send my own forged authorization.

This is a widespread vulnerability in the way that organizations
improperly trust computer communications.

The only solution is to implement some type of authentication for
important electronic communications, and we all know that new
vulnerabilities are exposed once there is an authentication mechanism.

To presume that electronic communications and stored communications are
trustworthy, the way that the parties to civil litigation generally do,
and the way that criminal courts nearly always do, creates endless
potential for very bad things to happen. We must always doubt by default
anything that is in electronic form.

With that in mind, remember that the attacker in the scenario presented
will only succeed once per target and then the target will adapt and
defend. In practice that is an acceptable risk, and the natural
condition of our exposure to computer vulnerabilities.

Where we really see harm come from improper computing practices on a
large scale is in court. As a society we will never be capable of
adapting to threats because there will always be new people who have not
previously suffered the consequences of each mode of attack.

Sincerely,

Jason Coombs

Director of Forensic Services
PivX Solutions, Inc.
http://www.pivx.com

[Andrew Hunter]

I think spam filters arn't the solution to the spam problem. If someone gets
200 spam emails aday then what use is a spam filter telling them the email
was rejected? The user will end up not looking at the list of rejected
emails because it's sooo big.

Filtering certain works is also bad aswell eg "penis", "viagra".
It can easyly be evoided:
Email "Free penis enlargement pills" - Would be filterd
Email "Free pen is enlargement pills" - Wouldn't be filtered

So in order to be effective it has to look for variations on the works
For example "penis" it could look for "P E N I S", "peni$" etc...

This is when the problems start. I get sent 200 spam emails the rejected
emails log is huge, i can't be bothed to look through it, it'll take tooo
long, but it has removed an important email.

Email "Dear Andiroo, I have found your pen, it was under my desk. You PEN IS
now in the top draw of your desk".

Ok i lost my sepcial pen, my friend has found it but look "PEN IS" is like
"PENIS" so it's been taken by the spam filter.

My solution for spam:
I think there should be a huge database on spam emails, just like an anti
virus scanner but for spam. I think it is that simple have an anti-virus but
for spam, i am sure that if i get a spam email someone else will have
exactly the same email so if i can submit it to the database and it's added
to it quickly so everyone can get the updates then there would be no
problem, but there is soooo much spam out there we would for ever have to
update or ever growing in size databases.

I think this would eliminate alot of spam, I have ran out of ideas for
preventing spam emails, so what other effective solutions already out there?



>From: "Aaron Cake" <aaron@vltpm.com>
>To: <bugtraq@securityfocus.com>
>Subject: RE: Is predictable spam filtering a vulnerability?
>Date: Thu, 17 Jun 2004 10:18:46 -0400
>MIME-Version: 1.0
>Received: from outgoing2.securityfocus.com ([205.206.231.26]) by
>mc8-f2.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Fri, 18 Jun 2004
>14:43:23 -0700
>Received: from lists2.securityfocus.com (lists2.securityfocus.com
>[205.206.231.20])by outgoing2.securityfocus.com (Postfix) with QMQPid
>78FB1143812; Fri, 18 Jun 2004 18:26:43 -0600 (MDT)
>Received: (qmail 4774 invoked from network); 17 Jun 2004 08:06:11 -0000
>X-Message-Info: JGTYoYF78jEQIQmJRqn4zIchqtVGhE2/
>Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@securityfocus.com>
>List-Help: <mailto:bugtraq-help@securityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
>Delivered-To: mailing list bugtraq@securityfocus.com
>Delivered-To: moderator for bugtraq@securityfocus.com
>Message-ID: <009601c45476$00737fe0$650aa8c0@aaronxp>
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2739.300
>In-reply-to: <200406161326.AA304546076@dewmill.com>
>Return-Path: bugtraq-return-14825-andiroohunter=msn.com@securityfocus.com
>X-OriginalArrivalTime: 18 Jun 2004 21:43:23.0227 (UTC)
>FILETIME=[478332B0:01C4557D]
>
> > During a recent email conversation with several participants, we
> > discovered that the email service of one participant silently
> > dropped legitimate emails that happened to contain certain
> > combinations of words common in spam. I believe this sort of
> > filter is common practice, and in fact even in place for some of
> > my own email addresses.
> >
> > However, this experience made me think: isn't predictable spam
> > filtering in general a vulnerability that could be used as a hoax
> > device?
>
>Certainly. I have brought this issue up with several other ISPs who insist
>on blocking my personal domain because I'm a "little guy". They can't prove
>that I don't spam, so they default to blocking everything that comes from
>me
>instead. AOL is the biggest and perhaps most annoying offender.
>
>I personally see this as a denial of service attack against MYSELF.
>Obviously not meant to be malicious in nature, but quite effective
>regardless.
>
>Imagine if I decided to use a spam fitler against someone else...I make an
>email that contains known rejected words. I send that email, setting the
>"FROM" address and header to be that of my victim. If I send out hundreds
>of
>these messages, I can use someone else's spam filter to mail-bomb my victim
>with "rejected" messages.
>
>The REAL issue is that any email filter that silently drops messages can
>easily mistake legitimate mail for spam. The user never knows, sometimes
>the
>sender doesn't know, and the braindead admins who set up the filter think
>they've done their job. What is even more useless is when the message is
>bounced with instructions on how to get off their block list. You send an
>email to their admin, yet it is bounced!
>
>Spam filters are often worse then the spam problem itself.
>
>---
>Aaron Cake
>Technical Services
>Advanced Computer Ideas
>Phone: 1-519-433-0279
>Fax: 1-519-433-5413
>
>

__________________________________________________ _______________
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger

[Ilya Sher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

R Armiento wrote:
| During a recent email conversation with several participants, we
discovered that the email service of one participant silently
dropped legitimate emails that happened to contain certain
combinations of words common in spam. I believe this sort of filter
is common practice, and in fact even in place for some of my own
email addresses.
|
| However, this experience made me think: isn't predictable spam
filtering in general a vulnerability that could be used as a hoax
device? Since most users reply to an email citing the complete
source email, including filter-offending words, it should be
possible to keep a reply, forward, or even a whole thread, under the
radar of specific recipients. If used in combination with forged
replies from addresses predictably dropping emails, I think this may
be a dangerous tool for social engineering.
|
| For example: attacker 'A' sends 'B' a social engineering request
for "the secret plans" and says "if you are unsure, forward my
request to your boss and ask if this is okay". 'B' forwards the
email to his boss 'C' and asks "Is this okay?". However, 'C':s spam
filter silently drops the email. 'A' forges a reply from 'C' saying:
"Sure, no problem, go ahead."
|
| Regards,
| R. Armiento
|
|

Interesting idea.

That might be problematic if the originator doesn't intercept the
letter to boss as it may contain some important data for
faking the boss's answer

- --
Ilya Sher: 3A4A 810C 1C81 79F3 A8C6 2545 90FD 6114 F730 0680
Rules: UNIX,UTF-8,Lisp,S-exps,Encryption,OSS,VIM,Gnome
Sucks: M$,XML,Morons on the web
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA0VSakP1hFPcwBoARApNYAKCT2vjCpSd7GL30qbXiAG aySvTsTwCgk1Jj
BiwFRjU/rRRMrrjeCbnt6aI=
=9G+O
-----END PGP SIGNATURE-----

[Lance James]

Your point on the Rejected messages is that it does happen. Reverse-NDR's
are a real problem - and are a loophole since NDR is a smtp spec.

On a second note, your comment on filters, (not involving the me2 spam
filter companies) filters do not stop spam, and sometimes they are truly
more detrimental.

There was an article posted on security focus that brought up all of these
issues with security and spam.

www.securityfocus.com/infocus/1763 (it's two parts, that's the first one, it
leads to the other one.).

The social engineering attack would have to be well surveilled to pull off,
but it is definitely possible by a long term and determined attacker.

Lance

-----Original Message-----
From: Aaron Cake [mailto:aaron@vltpm.com]
Sent: Thursday, June 17, 2004 7:19 AM
To: bugtraq@securityfocus.com
Subject: RE: Is predictable spam filtering a vulnerability?

> During a recent email conversation with several participants, we
> discovered that the email service of one participant silently
> dropped legitimate emails that happened to contain certain
> combinations of words common in spam. I believe this sort of
> filter is common practice, and in fact even in place for some of
> my own email addresses.
>
> However, this experience made me think: isn't predictable spam
> filtering in general a vulnerability that could be used as a hoax
> device?

Certainly. I have brought this issue up with several other ISPs who insist
on blocking my personal domain because I'm a "little guy". They can't prove
that I don't spam, so they default to blocking everything that comes from me
instead. AOL is the biggest and perhaps most annoying offender.

I personally see this as a denial of service attack against MYSELF.
Obviously not meant to be malicious in nature, but quite effective
regardless.

Imagine if I decided to use a spam fitler against someone else...I make an
email that contains known rejected words. I send that email, setting the
"FROM" address and header to be that of my victim. If I send out hundreds of
these messages, I can use someone else's spam filter to mail-bomb my victim
with "rejected" messages.

The REAL issue is that any email filter that silently drops messages can
easily mistake legitimate mail for spam. The user never knows, sometimes the
sender doesn't know, and the braindead admins who set up the filter think
they've done their job. What is even more useless is when the message is
bounced with instructions on how to get off their block list. You send an
email to their admin, yet it is bounced!

Spam filters are often worse then the spam problem itself.

---
Aaron Cake
Technical Services
Advanced Computer Ideas
Phone: 1-519-433-0279
Fax: 1-519-433-5413

[Bill Burge]

This is nothing new to spam filtering. Any dynamic/proactive filter=
mechanism is subject to the sam shenanigans.

This has been a "feature" of IntrusionPreventionSystems since they came=
out. Spoof an attack from an IP you want to be denied, and the IDS=
updates the ruleset on the firewall (what a IPS really is, an IDS talking=
to a firewall) and that third party can't get past that perimeter.

bburge
someguy who does this kinda stuff

*********** REPLY SEPARATOR ***********

On 6/17/2004 at 7:27 PM Joel Eriksson wrote:

>On Wed, Jun 16, 2004 at 01:26:28PM +0200, R Armiento wrote:
>[snip]
>> For example: attacker 'A' sends 'B' a social engineering request
>> for "the secret plans" and says "if you are unsure, forward my
>> request to your boss and ask if this is okay". 'B' forwards the
>> email to his boss 'C' and asks "Is this okay?". However, 'C':s
>> spam filter silently drops the email. 'A' forges a reply from
>> 'C' saying: "Sure, no problem, go ahead."
>
>Many will probably discard the above as farfetched or ignore it
>since it's not a "real" vulnerability that gives remote root to
>the attacker, I think it's beautiful though. :)
>
>Security is a state of mind, a way of thinking. Vulnerabilities
>are all around us and the one you point out above is certainly
>one of them.
>
>> Regards,
>> R. Armiento
>
>--
>Best Regards,
> Joel Eriksson
>-------------------------------------------------
>Cellphone: +46-70 228 64 16 Home: +46-26-10 23 37
>Security Research & Systems Development at Bitnux
>PGP Key Server pgp.mit.edu, PGP Key ID 0x08811B44
>DF38 5806 0EFB 196E E4B6 34B5 4C01 73BB 0881 1B44
>-------------------------------------------------

[Sean Straw / PSE]

At 19:27 2004-06-17 +0200, Joel Eriksson wrote:
>On Wed, Jun 16, 2004 at 01:26:28PM +0200, R Armiento wrote:
>[snip]
> > For example: attacker 'A' sends 'B' a social engineering request
> > for "the secret plans" and says "if you are unsure, forward my
> > request to your boss and ask if this is okay". 'B' forwards the
> > email to his boss 'C' and asks "Is this okay?". However, 'C':s
> > spam filter silently drops the email. 'A' forges a reply from
> > 'C' saying: "Sure, no problem, go ahead."
>
>Many will probably discard the above as farfetched or ignore it
>since it's not a "real" vulnerability that gives remote root to
>the attacker, I think it's beautiful though. :)

A far more plausible vulnerability would be for the attacker, if they had
exploited the mail and/or DNS hosts used by user B to intercept or redirect
mail. This would significantly increase the workability of further
socially engineered exploits.

FTR, the proposed failing wouldn't be possible if such decisions were
digitally signed (PGP/GNUPG, etc) - the "forged" email would fail to be
verified.

The success of the supposed mail vulnerability relies upon the gullibility
of user B, not upon an automated system. There are other factors to
consider in there as well, such as SPF filtering at the mailhost of user B
(which could reject the forged mail because the originating mailserver
isn't correct for the sending address), or of user B sending a response to
the forged authorization, and THAT message going unresponded to, or at
least of user A (attacker) not RECEIVING that message to know to respond to
it. For that matter, it relies upon the message from user B to user C not
including other details which user A would fail to address when sending the
forged reply, and that user B doesn't simply pick up the phone and call
user C, which renders the whole matter moot.

---
Please DO NOT carbon me on list replies. I'll get my copy from the list.

Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395

[krispykringle@gentoo.org]

Very interesting proposition, but I can't think of any real advantage here. In the hypothetical scenario, could the attacker not simply send an email purportedly from the boss to begin with saying, ``please forward the secret plans to attacker@hijackeddom
ain.com''? For that matter, isn't it likely that a recipient in such a poorly run system with such little regard for reading headers (and I don't delude myself that this is uncommon) would not notice if an attacker were to send an e-mail with a from addre
ss boss@company.tld but a reply-to of hax0r@istealcreditcardnumbers.com? In other words, the specific ``exploit'' here is not the spam filter so much as the ignorance of the victim.

Anywho, it seems most decent spam filters have whitelisting; bigcheese@company.com is unlikely to filter out servileMBA@company.com, even if the e-mail does contain the key words. The spam filter is usually not applied to legitimate known-good e-mail addr
esses.

Interesting discussion nonetheless.

Dan

On Wed, Jun 16, 2004 at 01:26:28PM +0200, R Armiento wrote:
>
> During a recent email conversation with several participants, we discovered that the email service of one participant silently dropped legitimate emails that happened to contain certain combinations of words common in spam. I believe this sort of filter
is common practice, and in fact even in place for some of my own email addresses.
>
> However, this experience made me think: isn't predictable spam filtering in general a vulnerability that could be used as a hoax device? Since most users reply to an email citing the complete source email, including filter-offending words, it should be
possible to keep a reply, forward, or even a whole thread, under the radar of specific recipients. If used in combination with forged replies from addresses predictably dropping emails, I think this may be a dangerous tool for social engineering.
>
> For example: attacker 'A' sends 'B' a social engineering request for "the secret plans" and says "if you are unsure, forward my request to your boss and ask if this is okay". 'B' forwards the email to his boss 'C' and asks "Is this okay?". However, 'C':
s spam filter silently drops the email. 'A' forges a reply from 'C' saying: "Sure, no problem, go ahead."
>
> Regards,
> R. Armiento

[Kyle Wheeler]

--WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 17, 2004 at 07:28:45AM -0400, David F. Skoll quoth:
> On Wed, 16 Jun 2004, R Armiento wrote:
>=20
> > However, 'C':s spam filter silently drops the email.
>=20
> In my opinion, any spam filter that silently drops e-mail is broken, and
> is indeed a security risk. A spam filter MUST respond with a 500 SMTP
> failure code if it rejects a message.

A 4xx response code should also be acceptable in some cases (for
example, if an email is being rejected because the return address domain
doesn't resolve: which can only be treated as a temporary error).

The point is that the sender MUST eventually find out the mail didn't
get to it's intended recipient.

~Kyle

--=20
The average Ph.D thesis is nothing but the transference of bones from one
graveyard to another.
-- J. Frank Dobie, "A Texan in England"

--WIyZ46R2i8wDzkSu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iD8DBQFA1FQiBkIOoMqOI14RAhEyAJ9G4Br+KGCP5HPhKMn97j D0g35r0gCg1AnR
oT/mwFNPgSymj4SpfbIdF+U=
=ZgEy
-----END PGP SIGNATURE-----

--WIyZ46R2i8wDzkSu--

[Chris Brown]

Aaron Cake wrote:

>Imagine if I decided to use a spam fitler against someone else...I make an
>email that contains known rejected words. I send that email, setting the
>"FROM" address and header to be that of my victim. If I send out hundreds of
>these messages, I can use someone else's spam filter to mail-bomb my victim
>with "rejected" messages.
>
>
This definitely is a problem, but not just like you describe. Spammers
themselves do the same thing based simply on the way SMTP works. At the
ISP I work for we've had tons of problems with a spammer (or multiple
spammers) using an address from one of our domains as the sender and
then a bad recipient address and sending thousands of messages. The
recipient server bounces messages back to the apparent sender,
effectively mail-bombing them like you describe. Its even worse when
the victim address doesn't actually exist because then the postmaster
address at both ends gets all kinds of warnings as well.

I've seen some ISPs have started to block mail sent by <> to put an end
to this sort of thing, but that doesn't seem like a very good solution
as it probably blocks legitimate bounce messages.

Chris

[Crispin Cowan]

Andrew Hunter wrote:

> I think spam filters arn't the solution to the spam problem. If
> someone gets 200 spam emails aday then what use is a spam filter
> telling them the email was rejected? The user will end up not looking
> at the list of rejected emails because it's sooo big.
>
> Filtering certain works is also bad aswell eg "penis", "viagra".
> It can easyly be evoided:
> Email "Free penis enlargement pills" - Would be filterd
> Email "Free pen is enlargement pills" - Wouldn't be filtered

Sounds like you don't have much experience with spam filters.

I use the Bayesian spam filter built into Mozilla. On average, I get:

* 95 legitimate mails per day
* 180 additional spam per day
* about 10 spam per day end up in the legitimate box, and the
remaining 170 are filtered into the Junk folder, for periodic
inspection
* about 1 legitimate mail per month is mis-classified and put in the
Junk folder
o zero of them are critical, as the spam filter automatically
does not Junk anything from anyone in my address book

Note that spammers *do* use hacks like "Free pen is enlargement" (and a
broad variety of other cute typos) and the Bayesian filter catches on to
them very quickly.

> So in order to be effective it has to look for variations on the works
> For example "penis" it could look for "P E N I S", "peni$" etc...
>
> This is when the problems start. I get sent 200 spam emails the
> rejected emails log is huge, i can't be bothed to look through it,
> it'll take tooo long, but it has removed an important email.
>
> Email "Dear Andiroo, I have found your pen, it was under my desk. You
> PEN IS now in the top draw of your desk".
>
> Ok i lost my sepcial pen, my friend has found it but look "PEN IS" is
> like "PENIS" so it's been taken by the spam filter.

The Bayesian filter is not fooled by these issues either way. I can say
"penis" in an e-mail and it will not get filtered, because the scoring
system balances the total score.

> My solution for spam:
> I think there should be a huge database on spam emails, just like an
> anti virus scanner but for spam. I think it is that simple have an
> anti-virus but for spam, i am sure that if i get a spam email someone
> else will have exactly the same email so if i can submit it to the
> database and it's added to it quickly so everyone can get the updates
> then there would be no problem, but there is soooo much spam out there
> we would for ever have to update or ever growing in size databases.

That has been tried and failed a long time ago. The problem is that the
spammers caught on to it quickly, and started adding random junk to
their mails just so that no two of them would have the same checksum.
That is why you see random junk characters in the headers and bodies of
spams.

> I think this would eliminate alot of spam, I have ran out of ideas for
> preventing spam emails, so what other effective solutions already out
> there?

I think if the penalty for spamming was having your head mounted on a
stick then there would be a lot less spam :)

Crispin

--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com

[Luca Berra]

On Thu, Jun 17, 2004 at 07:28:45AM -0400, David F. Skoll wrote:
>On Wed, 16 Jun 2004, R Armiento wrote:
>
>> However, 'C':s spam filter silently drops the email.
>
>In my opinion, any spam filter that silently drops e-mail is broken, and
>is indeed a security risk. A spam filter MUST respond with a 500 SMTP
>failure code if it rejects a message.
>
David,
the problem with your proposed behaviour is the fact that to be able to
respond with 5xx in the smtp transaction would require the spam filter
to analyze content on the fly.
This is a very resource intensive operation and usually people triyng
this approach will DOS themselves.
The most common approach for spam (content) filters is to queue messages
and process them later, in this case the filter MUST NOT generate a NDN,
since there is no way to guarantee that the envelope sender is not
faked.
I hold that after suitable training of the spam filter (this includes
generation of whitelists and such), dropping mail into oblivion is
perfectly safe.
I am speaking of serious spam filters, not regexps that match random
words in the meddage contents.

Regards,
L.

--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \

[Phil Barnett]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 18 June 2004 6:05 pm, Andrew Hunter wrote:

> Filtering certain works is also bad aswell eg "penis", "viagra".
> It can easyly be evoided:
> Email "Free penis enlargement pills" - Would be filterd
> Email "Free pen is enlargement pills" - Wouldn't be filtered
>
> So in order to be effective it has to look for variations on the works
> For example "penis" it could look for "P E N I S", "peni$" etc...

It's not all that hard to make a better filter with regex. The following wo=
uld=20
catch everything you suggested.

'p.?[e=E9].?n.?[|=ED=EDiil1].?[s$]'

It would also catch p.e.n.i.s and p e-ni-s, etc.

Yes, it's possible that it would stop "Your pen is in your top drawer". I=20
whitelist the people I know. They never see the filter.

After administering a bunch of Mailman lists, I had to automate or spend ho=
urs=20
thumbing through the reject list. Now, I can automatically kill 95+% of the=
=20
messages on hold that are spam and look through what's left. List members=20
never see the filter as long as they post in plain text. (I hold for mime=20
headers, too)

=2D --=20

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA1Pl3WMqSOYd58pwRAgdeAJ49xwYqnqE3gxEklgrqWS 9BujvTNgCfYL/4
omWs39lqrDefqfCrvQ9Ykyk=3D
=3DgeC0
=2D----END PGP SIGNATURE-----

[Sean Straw / PSE]

At 15:52 2004-06-20 +0200, Luca Berra wrote:
>the problem with your proposed behaviour is the fact that to be able to
>respond with 5xx in the smtp transaction would require the spam filter
>to analyze content on the fly.

Agreed.

There's the additional issue of MX precedence. It's a well known fact that
spammers send mail to backup MX'es (often completely skipping even TRYING
to deliver to the primary MX) on the basis that they often do not employ
the same level of spam protection (such as DNSBLs) as the mail hosts they
serve, and generally do not validate recipients (allowing the spammer to
deliver a message for hundreds of recipients at your domain, deferring any
rulesets which may check for invalid recipients until after the spammer has
dropped their message and shot off to their next victim).

>The most common approach for spam (content) filters is to queue messages
>and process them later, in this case the filter MUST NOT generate a NDN,
>since there is no way to guarantee that the envelope sender is not
>faked.

If the envelope sender is faked, then rejecting the message at SMTP time
(say, due to a DNSBL check) will result in an NDN directed at that faked
address anyway, excepting when the sending mail host is really a zombie PC
or spamware to begin with, in which case it'd be dropping the NDNs into the
ether. The chief difference is that with an SMTP time rejection, YOUR mail
server doesn't _deliver_ anything - the server which was attempting to
deliver the message to you would be responsible for delivering the bounce
based on your SMTP replies during the transaction.

Since we know spammers don't bother to remove bad addresses from their
databases (and generally aren't receiving NDNs anyway), one can question
whether issuing SMTP-time rejection codes is a wise idea anyway: it allows
the spammer to probe your system and possibly determine what type of spam
filtering you are using, which may then provide them with information on
how to best circumvent that. Not that spammers are operating the same way
that a blackhat would relative to any individual target, but what if the
spamware were to profile each recipient host and provide that data to the
spamware author so that they could have a database identifying different
hosts with different exploitable weaknesses in their spam filtering, thus
allowing the spamware author to revise their approach?

>I hold that after suitable training of the spam filter (this includes
>generation of whitelists and such), dropping mail into oblivion is
>perfectly safe.

A preferred method is dropping suspect content-matched spam into an
ARCHIVE, and providing data about the event to the recipient (either in a
daily report or making it available via a web query mechanism). It is the
recipients option to check that report and determine if there are any false
positives. Since the messages haven't been discarded, false positives can
be retrieved from the archive and the senders added to the recipients
personal whitelist. Even if you discard mail rather than archiving it,
providing a LOG of that action, accessible by the intended recipient, is
desireable. Spew which has gone unreviewed for some period of time can be
purged from the archive to conserve resources.


I still maintain that the original concern of a vulnerability due to
"predictable spam filtering" relies upon human action, as well as users A
and B somehow being on separate mail systems (such that B would have
received the message but A would silently reject it) *AND* that user B
would both have forwarded the message verbatim as well as themselves NOT
being in A's whitelist to begin with. It supposes entirely too many
specific configuration issues and human actions, AND still doesn't provide
for any automated exploitation of system resources or exposure of secured
data, excepting by human action.

---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Founding member of the campaign against email bloat.

[Michael A. Dickerson]

On Sun, 20 Jun 2004, Luca Berra wrote:
> the problem with your proposed behaviour is the fact that to be able to
> respond with 5xx in the smtp transaction would require the spam filter
> to analyze content on the fly.
> This is a very resource intensive operation and usually people triyng
> this approach will DOS themselves.

That's right .. and I agree with David. In my environment, there are only
two responsible ways to do spam filtering:

1. You can deliver all messages to the mail client and let the client
decide what to do with them. You can mark suspected messages as spam,
deliver them to a different folder, etc. but a human must have access to
them so that, at the very least, when somebody calls on the phone and
says, "Didn't you get my email," it can be found.

2. If you or your users are too lazy for #1, you have to put up the money
to do your filtering inline with the SMTP transaction, BEFORE the MTA has
returned a success code indicating acceptance of the message. Then real
mail, relayed by a real SMTP server with a real envelope sender, will get
an immediate bounce message that they can respond to. As others have
seen, spambots will ignore the failure code and nobody cares.

If you are too lazy to do #1 and too cheap to do #2, then you have set up
a system that *will* drop important messages in a silent and untraceable
way. I have a hard time imagining an environment where that is OK. If
you don't care whether an email gets delivered, why would you bother
writing it? Then, as soon as a trustee sends the president an email that
disappears into the void, I will have plenty of time to explain the
(possibly very good) statistical performance of the spam filter to the
unemployment clerk.

> The most common approach for spam (content) filters is to queue messages
> and process them later, in this case the filter MUST NOT generate a NDN,
> since there is no way to guarantee that the envelope sender is not
> faked.

This is meaningless; there is no way to guarantee that the envelope sender
is correct on ANY message, spam or not.

> I hold that after suitable training of the spam filter (this includes
> generation of whitelists and such), dropping mail into oblivion is
> perfectly safe.
> I am speaking of serious spam filters, not regexps that match random
> words in the meddage contents.

Nobody in research or industry has yet claimed an accuracy rate better
than about 98-99%, and that rate is only achieved by the most "serious"
and well trained spam filters yet devised.

M.D.

[John Fitzgibbon]

> It is the
> recipients option to check that report and determine if there are any false
> positives.

This, IMHO, is a cop-out on the part of the receiving mail administrator.
You're telling your clients, "Here's the list of 100's of emails per day that
we silently ignored on your behalf, now you go figure out if you needed any
of them". For all the good that does, you may as well just deliver everything
and let the user sort through their inbox.

A 5xx provides timely feedback to legitimate senders, (without bouncing to
faked addresses), so that they can find another means to contact the
receiver.

Archiving the dropped mail *and* terminating with a 5xx would be a much better
approach.

John Fitzgibbon



On Wednesday 23 June 2004 10:07 am, Sean Straw / PSE wrote:
> At 15:52 2004-06-20 +0200, Luca Berra wrote:
> >the problem with your proposed behaviour is the fact that to be able to
> >respond with 5xx in the smtp transaction would require the spam filter
> >to analyze content on the fly.
>
> Agreed.
>
> There's the additional issue of MX precedence. It's a well known fact that
> spammers send mail to backup MX'es (often completely skipping even TRYING
> to deliver to the primary MX) on the basis that they often do not employ
> the same level of spam protection (such as DNSBLs) as the mail hosts they
> serve, and generally do not validate recipients (allowing the spammer to
> deliver a message for hundreds of recipients at your domain, deferring any
> rulesets which may check for invalid recipients until after the spammer has
> dropped their message and shot off to their next victim).
>
> >The most common approach for spam (content) filters is to queue messages
> >and process them later, in this case the filter MUST NOT generate a NDN,
> >since there is no way to guarantee that the envelope sender is not
> >faked.
>
> If the envelope sender is faked, then rejecting the message at SMTP time
> (say, due to a DNSBL check) will result in an NDN directed at that faked
> address anyway, excepting when the sending mail host is really a zombie PC
> or spamware to begin with, in which case it'd be dropping the NDNs into the
> ether. The chief difference is that with an SMTP time rejection, YOUR mail
> server doesn't _deliver_ anything - the server which was attempting to
> deliver the message to you would be responsible for delivering the bounce
> based on your SMTP replies during the transaction.
>
> Since we know spammers don't bother to remove bad addresses from their
> databases (and generally aren't receiving NDNs anyway), one can question
> whether issuing SMTP-time rejection codes is a wise idea anyway: it allows
> the spammer to probe your system and possibly determine what type of spam
> filtering you are using, which may then provide them with information on
> how to best circumvent that. Not that spammers are operating the same way
> that a blackhat would relative to any individual target, but what if the
> spamware were to profile each recipient host and provide that data to the
> spamware author so that they could have a database identifying different
> hosts with different exploitable weaknesses in their spam filtering, thus
> allowing the spamware author to revise their approach?
>
> >I hold that after suitable training of the spam filter (this includes
> >generation of whitelists and such), dropping mail into oblivion is
> >perfectly safe.
>
> A preferred method is dropping suspect content-matched spam into an
> ARCHIVE, and providing data about the event to the recipient (either in a
> daily report or making it available via a web query mechanism). It is the
> recipients option to check that report and determine if there are any false
> positives. Since the messages haven't been discarded, false positives can
> be retrieved from the archive and the senders added to the recipients
> personal whitelist. Even if you discard mail rather than archiving it,
> providing a LOG of that action, accessible by the intended recipient, is
> desireable. Spew which has gone unreviewed for some period of time can be
> purged from the archive to conserve resources.
>
>
> I still maintain that the original concern of a vulnerability due to
> "predictable spam filtering" relies upon human action, as well as users A
> and B somehow being on separate mail systems (such that B would have
> received the message but A would silently reject it) *AND* that user B
> would both have forwarded the message verbatim as well as themselves NOT
> being in A's whitelist to begin with. It supposes entirely too many
> specific configuration issues and human actions, AND still doesn't provide
> for any automated exploitation of system resources or exposure of secured
> data, excepting by human action.
>
> ---
> Please DO NOT carbon me on list replies. I'll get my copy from the list.
> Founding member of the campaign against email bloat.

[Valdis.Kletnieks@vt.edu]

--==_Exmh_1326342004P
Content-Type: text/plain; charset=us-ascii

On Sun, 20 Jun 2004 15:52:00 +0200, Luca Berra <bluca@comedia.it> said:

> I hold that after suitable training of the spam filter (this includes
> generation of whitelists and such), dropping mail into oblivion is
> perfectly safe.

Assume a spam filter that's 99.8% accurate. This is probably a *high*
estimate - we're talking only 2 errors per every thousand mails...

Assume several million messages a day (which is *not* a very large load
by today's standards - we're merely a large university, and even *after*
subtracting spam and virus mail, we're in that range)...

Calculate how many mails get dropped into oblivion each day.

I suspect that you and I have differing definitions of "*perfectly* safe".....

--==_Exmh_1326342004P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA2oBycC3lWbTT17ARApSwAKCEcd4VtUVlU3VN5+f2Xd UT9kBP5QCfW7FX
m8l2H27gUebYXImNjwPfCxA=
=EtQx
-----END PGP SIGNATURE-----

--==_Exmh_1326342004P--

[Sean Straw / PSE]

At 10:44 2004-06-24 -0700, John Fitzgibbon wrote:

>This, IMHO, is a cop-out on the part of the receiving mail administrator.

You're welcome to your opinion. I don't happen to agree with it.

Many sites employ SpamAssassin and the like to simply FLAG messages and
pass them along to the intended recipient, who can then employ their own
filter process within their email client (or with procmail, etc) to do as
they wish with the messages (which I assure you, doesn't generally involve
bouncing any NDNs to the apparent sender, and is so far past the SMTP
transaction that result codes aren't part of the picture). Unfortunatley,
those users who don't have shell access generally end up having to DOWNLOAD
the crap and THEN deal with it. Speak with users who value their time, and
you'll find in most cases, they're rather keen on not downloading junk to
their workstation.

Then there's the least common denominator: the mass-market internet
consumer user. The yo-yo using whatever ISP was cheap the day they went
looking to get online, and end up with usernames ending in numeric
sequences. They either hawk over their email, or more commonly, check mail
about twice a week (if that), and when they're deluged with junk, they
select a pile of email in their inbox and hit DELETE to get rid of it all,
figuring that if someone sent them something important, they'll send it
again, or give them a call. I'm ashamed to say, I've got relatives who fit
into this category, and despite frequent reminders, they still do this and
send out a followup message to everyone in their addressbook saying "I'm
back online, and just deleted all my mail, so if you sent me something
important, just send it again."

Reasonably intelligent folk can manage with an archive-and-report mechanism
just fine. The rest of the net however, wouldn't know the difference
anyway. Most endusers can't comprehend a standard bounce message, and a
bounce message referring to a DNSBL or any number of other rejection
reasons really sends some people for a spin as they fail to sort WHO
refused the mail.

On a good ISP, users on the receiving host NOT wanting to subject their
email to post-SMTP time mail filtering certainly have the ability to opt in
or out of such filtering. So, if the RECIPIENT has opted to silently
discard (well, archive and report) mail which has been classified as junk,
why should the sender have to be notified?

Of course, what do I know? Up till now, I assumed intelligent folk could
manage to send a reply to a listserv without also sending an unnecessary
carbon to the original message poster, and if not, at least courteous
people would pay attention to the sigline making such a request...

>You're telling your clients, "Here's the list of 100's of emails per day that
>we silently ignored on your behalf, now you go figure out if you needed any
>of them".

Er, as versus bouncing messages to the sender, in which case the recipient
doesn't even KNOW that someone tried to send them anything? That logic is
no better. If the sender knows of no other way to reach the intended
recipient, how is it that they're supposed to get through?

Does the same logic apply to twit filters? If someone were on a mailing
list and BOUNCED messages because of the author of those messages (and yes,
this does happen), I'd consider that abuse and kick the filtering user --
either those messages are bouncing to the admin (who sure as hell doesn't
need the extra crap), or to the author, who was posting to the LIST, not to
the individual recipient.

The archive and report approach means that the intended recipient HAS
CONTROL over their email - if something was misclassified, they can recover
it from the archive, greenlist the sender, and get on with life. Compare
that to someone trying to email them something and getting a bounce and not
necessarily having any alternate method of establishing contact.

For me, glancing through the report takes barely over a minute each
morning, and is a *LOT* less aggravating than pouring through some
mailfolder and finding it peppered with spam. I personally find that when
there are false positives, they're worthless junk anyway - mumbling idiots
on a listserv using an abundance of punctuation in the subject line, HTML
only email, and a flakey email address, etc, and thus aren't even something
I'd have elected to read had it shown up in my mailbox to begin with, so I
spend virtually no time recovering messages from the archive.

>For all the good that does, you may as well just deliver everything
>and let the user sort through their inbox.

The user isn't forced to deal with DOWNLOADING the crap in their regular
mail stream, and yet they retain control over recovering from false
positives. This is a cop out?

This beats the turd out of the moronic "prove you love me" schemes where in
order to send a message to someone (who may have emailed you directly to
begin with, so you're actually REPLYING to them), you've got to respond to
some automated system at their mail server that insists that if you're not
a spammer, you've got the time to manage THEIR spam problem for them. Even
EARTHLINK does this. I don't bother to waste my time with them - when met
with a PYLM autoresponder, I just quit corresponding -- invariably, it
seems to be when I'm wasting my time answering a question someone sent me
out of the blue anyway.

>A 5xx provides timely feedback to legitimate senders, (without bouncing to
>faked addresses), so that they can find another means to contact the
>receiver.

What on earth do you mean "without bouncing to faked addresses"? Sure,
totally bogus addresses won't get bounces (not that the mail system won't
attempt to deliver them - and I can attest that doing so CAN in fact get
you blacklisted - yahoo for instance dynamically blocks all mail from your
server after you've attempted to deliver mail to a sufficient number of
invalid recipients - not just in ONE message, but a plurality of messages)
- but Joe-Jobs and other forgeries get FLOODED with bounces for messages
THEY DID NOT SEND. As an administrator of several mailing lists, I can
tell you that getting bounces from A/V systems that send advisories to the
From: address on messages containing viruses KNOWN to employ forgery is
rather aggravating.

>Archiving the dropped mail *and* terminating with a 5xx would be a much
>better approach.

I believe your opinion of how much better this approach is would be
dramatically different once you've had actual experience cleaning up after
a joe-job.

Perhaps it'd help if you looked at the archive and report approach from
another perspective: what if the user received the email but didn't bother
to open it because the subject/etc looked like spam anyway? There's
nothing that says that just because delivery was successful that someone
will actually READ the email, so why should the user have to download it to
their system? If they have ready ACCESS to the messages, it is virtually
the same as if it was delivered to their mailbox, and as a new user becomes
more familiar with the archive-and-report mechanism and finds that it
virtually never has a significant false positive, checking it becomes more
an issue if you were expecting a message (or received a phone call about
one) that you didn't see in your inbox.

This is my last post on this topic - while spam is a problem many have an
interest in dealing with, we've gone *FAR* afield of any security issue
related to sending or not sending bounces, and there are much better lists
for discussion of spam fighting techniques.


[big snip]

Bugtraq has a webarchive, so wholesale copies of previous messages seem a
major waste of bandwidth, esp when you factor the number of recipients on
this list, each receiving a custom delivered copy of the message.

---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Founding member of the campaign against email bloat.

[David Brodbeck]

> -----Original Message-----
> From: PSE-L@mail.professional.org [mailto:PSE-L@mail.professional.org]

> Many sites employ SpamAssassin and the like to simply FLAG
> messages and pass them along to the intended recipient, who can then
> employ their own filter process within their email client

This is what I do. Spam is tagged by a statistical filter, then tagged
messages are filtered into a "Junk Mail" folder by the user's email client.

In a corporate environment, where silently dropping mail from a customer is
totally unacceptable, this is a good compromise. The user can skim their
junk mail folder now and then and pick out anything that looks like it's
important. (I do this about once a day; only takes a few seconds. A
non-spam message in a folder full of spam tends to be surprisingly obvious.)

> Of course, what do I know? Up till now, I assumed
> intelligent folk could
> manage to send a reply to a listserv without also sending an
> unnecessary
> carbon to the original message poster, and if not, at least courteous
> people would pay attention to the sigline making such a request...

If I did this earlier, I'm sorry. I correspond with a lot of people who
prefer to get carbon copies of list replies, especially on moderated lists.
I'm also not in the habit of reading signatures because they tend to be a
waste of time. After seeing several dozen with bogus disclaimers and the
like in them you lose interest...

> John Fitzgibbon wrote:
> >Archiving the dropped mail *and* terminating with a 5xx would be a much
> >better approach.

To me that seems *totally* broken. A 5xx response means you didn't deliver
the mail, and the failure was permanent. Terminating with a 5xx and then
delivering the mail somewhere isn't kosher; in fact, it's the worst of both
worlds. You've still accepted the spam, *and* you've potentially created a
DSN.

[The Fungi]

On Wed, Jun 23, 2004 at 10:07:31AM -0700, Sean Straw / PSE wrote:
[...]
> If the envelope sender is faked, then rejecting the message at SMTP time
> (say, due to a DNSBL check) will result in an NDN directed at that faked
> address anyway, excepting when the sending mail host is really a zombie PC
> or spamware to begin with, in which case it'd be dropping the NDNs into the
> ether. The chief difference is that with an SMTP time rejection, YOUR mail
> server doesn't _deliver_ anything - the server which was attempting to
> deliver the message to you would be responsible for delivering the bounce
> based on your SMTP replies during the transaction.
[...]

We get around this problem at work by performing recipient address
verification on our primaries and using cached call-forward
recipient verification on our secondaries. When a secondary server
receives a message destined for an address it hasn't seen recently,
it will try to reach the primary and find out if the address will
accept mail before returning either 250 or 550 to the sender. If it
can't contact the destination immediately, it will elect to defer
the message like a secondary would normally. This is all done using
the "callout" feature in Exim v4. The only time this has become an
issue for us is when our primary is under a denial of service from
an incoming spam flood or is otherwise offline, in which case the
secondary still has to try (in vain usully) to send NDRs to the
spammers afterward. Of course, we are not employing any spam
filtering that results in NDRs or rejection of messages (we filter
them into separate mailboxes), so this has not been an issue for us.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi@yuggoth.org); IRC(fungi@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi@yuggoth.org);
MUD(Nergel@srmud.net:2325); WWW(http://fungi.yuggoth.org/); }