[Mimedefang] Both_Receive

Les Mikesell les at futuresource.com
Tue Jul 8 15:05:02 EDT 2003

On Tue, 2003-07-08 at 13:13, Chris Myers wrote:

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

Unfortunately it is almost never quite that simple because it is rare
for email to be delivered in one connection from the creator to the
recipient.   Generally email is created on machines that don't run
servers that can perform periodic retries so they are configured to
relay through smtp servers that can.  Once a message is accepted by
a relay machine, that machine is obligated to generate and return a
bounce message if delivery cannot be performed.  Thus, except in the
case where your mimedefang filter is checking messages on the first
hop from your local machines configured to use it as a relay, an
SMTP rejection doesn't prevent the creation of another piece of
email, it just forces another machine to do it.  All of the problems
of the target likely being wrong still apply even though it is
someone else's queue that gets clogged.

  Les Mikesell
   les at futuresource.com

More information about the MIMEDefang mailing list