Brian Blood wrote:
On Tue, 25 Nov 2003 09:25:44 -0800, Christian G. Warden wrote:
On Tue, Nov 25, 2003 at 04:57:59PM -0000, Aaron Stone wrote:
I believe that the best way to handle spam is by using an MTA based spam
checker which adds identifying headers, prefixes the subject line, or
otherwise marks the incoming email without disrupting the MTA path towards
DBMail delivery.
At delivery time, use a Sieve script to put all of the spam into a folder, or
discard it, or keep it in INBOX, or bounce it back, or call you pager, etc.
You should *not* bounce spam as the sender is always forged (or often
enough that it's safe to say always). Either keep it, discard it, or
reject it at SMTP time.
If you are going to reject a message, then by RFC you should bounce it.
Unfortunately, the RFC is obsolete w/r the real world.
Yes, most of the time the sender is forged, but it's that 1% of the time
where the sender MUST be informed that their message did not reach the
intended destination. Otherwise, you have not had a full accounting of the
delivery.
You will not get that - or much of anything else - if your bounce to a
forged address gets you into a 'bounce war' with the ISP who was the
victim of the forgery.
Worse - there are , and have been for sometime, script-kiddies and
MS-Weenies offering advice/products to send fake bounces, and do so from
the MUA.
This is one fire to NOT pour gasoline onto - RFC or not.
If you have sent someone's $10K contract into the bit bucket without letting
the sender know, you will have a pretty p*d-off customer.
Brian
If a $10K contract was sent solely by email, was not already traveling
along a previously proven route (prior messages were exchanged
successfully between the parties), did not request or
receive-if-requested a delivery confirmation, or make a follow-up phone
call or contact, then you have a pretty careless customer.
And your Terms of Service should *always* remind folks that
internet-base email is a "best efforts" animal.
Bill Hacker
