Is predictable spam filtering a vulnerability?

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

--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--

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

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

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
/ \

=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-----

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.

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.

> 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.

--==_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--

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.

> -----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.

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/); }