[Mimedefang] Both_Receive

Chris Myers chris at by-design.net
Tue Jul 8 14:15:10 EDT 2003


----- Original Message ----- 
From: "Carol Man" <mimedefang at yahoo.com>
To: <mimedefang at lists.roaringpenguin.com>
Sent: Tuesday, July 08, 2003 12:48 PM
Subject: Re: [Mimedefang] Both_Receive


> Thanks for your explanation, Lucas! =)
>  Hum.. do you have another good explanation to this
> question? Because now I have to try to convince my
> boss to not give a notification to the sender..
>
>  Just for curiosity: don't you think it's necessary to
> notify the sender that he email was blocked? For
> example, if I send an email to my friend and the MD/SA
> blocked my message, I think that the notification is
> necessary for me, isn't it?

The definition of "notification" is somewhat variable.

First, why never to send notifications:

1) This actually generates a new e-mail message that is sent to the
_alleged_ sender of a message.  In the case of spam, the alleged sender is
usually falsified and you'll end up bombarding an innocent third party.  In
the case of mail from a mailing list, you may end up sending the
notification to the entire mailing list (describe this as "we will spam the
mailing list").  At the very least you've doubled the workload of your mail
server for spam messages (and I've seen folks where >90% of the incoming
mail is spam).

2) If the return address is falsified, many times it will actually be an
unreplyable address.  Enough undeliverable mail messages will tend to clog
up your sendmail queue and delay/prevent the delivery of "real" mail.  The
undeliverables also often end up, a week later, in your postmaster mailbox
... sucking up more people time and disk space.

Next, why I say the definition of "notification" is variable...

What you were describing was a process that starts with someone sending you
a mail message.  Your filter says "Nope, not taking that one" and then it
says "Let's create a NEW mail message saying 'we refuse to accept your
message' and send it off to whoever we think originated that message."  This
is one way to notify the sender, but for the reasons stated above it's not a
good idea.

How about notifying the sender by telling the sender IN THE SMTP TRANSACTION
that the message will not be accepted -- with action_bounce.  Now you
haven't created a new mail message, but you have still notified the *REAL*
sender that the message wasn't accepted.  By doing this, you're actually
using less bandwidth, less CPU, less disk space, less people time AND you
aren't unintentionally blasting innocent third parties.

Chris Myers
Networks By Design





More information about the MIMEDefang mailing list