[Mimedefang] How to change envelope sender?
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
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.
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