[Mimedefang] How to change envelope sender?

Benoit Panizzon benoit.panizzon at imp.ch
Mon May 6 03:13:45 EDT 2013

> > I do consider backscatter the more serious problem.
> I strongly disagree. Notifying the sender of delivery problems is an
> essential and nonnegotiable element of E-mail. IOW dropping a mail without
> notifying the server is Bad. Full stop.

I fully agree that dropping an email without notificatin to anyone is bad. But 
that is not what I intend.
I intend to notify the owner of the address being forwarded to another 


Sender: Bob at aol.example.com
Recipient: Alice at bluewin.example.com
           (being forwarded to Emma at gmx.example.com)

So Bob is sending an email to Alice.

Alice has forwarded her Mailbox zu Emma, but that Mailbox is full.
I do rewrite the envelope sender of Bob's Email to Alice at bluewin.example.com

If the subsequent forwarding to Emma fails, Alice is getting that bounce and 
not Bob (who could be a spamer and using a forged sender address).

As Alice set up that forwarding, it is her responsibility to make sure that 
forwarding is working.

Another advantage: Alice does not disclose to bob, that her email address is 
being forwarded.
Antoher advantage: If aol.example.com is protected by SPF, I don't run into a 
problem. (SRS is not defined by an RFC yet as I understood).

> Backscatter OTOH is a nuisance, which should be minimized of course, but
> cannot be completely avoided. Blacklisting because of backscatter would be
> a Bad Idea (TM) which I thankfully never encountered so far, but if
> someone did that it would certainly be their own fault if they blocked
> legitimate mail as a result. In my experience, misguided measures like
> that tend to get lifted very quickly if senders and (intended) recipients
> of blocked mails are informed in no unclear words who's responsible for
> the communication failure.

Well, there are such blacklists I can tell you as a tech at an ISP.

Still that does not solve the problem of spam being sent via your 
infrastructure as result of phished email accounts etc. You need some kind of 
rate limmiting to detect unusual behaviour from users, or unusual logins with 
the same credentials from many different ip addresses, a functional abuse desk 
etc, but you can not fully prevent some spam being sent over your 
We had even the case where one single email was sent over our infrastructure 
to a 'special' spamcop.net spamtrap causing immediate blacklisting of our main 
outbound server. And spamcop.net is widely used.

Kind regards

Benoit Panizzon
I m p r o W a r e   A G    -    

Zurlindenstrasse 29             Tel  +41 61 826 93 07
CH-4133 Pratteln                Fax  +41 61 826 93 02
Schweiz                         Web  http://www.imp.ch

More information about the MIMEDefang mailing list