Disclaimer to forwarded mails to external domain?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Disclaimer to forwarded mails to external domain?

Vinícius Ferrão
Hello dudes,

I'm considering to implement a new feature in my Postfix Mail Filtering Gateway.

It would be great to add a disclaimer note to forwarded mails to an external domain. Since I'm already running amavisd-new, with all his friends, I was thinking to invite alterMIME to the party.

The tricky part is how to detected which messages are automatically forwarded to an external domain.

A quick example:

Our domain is mydomain.com and all mails received by [hidden email] are automatically redirected (forwarded) to [hidden email]. And when this behaviour is detected the disclaimer must be added to the received message message.

So the main question is: how to do this? And just in case: alterMIME is the best solution?

Thanks in advance,
Vinícius Ferrão

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disclaimer to forwarded mails to external domain?

Michael Orlitzky-2
On 07/31/12 01:57, Vinícius Ferrão wrote:
> Hello dudes,
>
> I'm considering to implement a new feature in my Postfix Mail
> Filtering Gateway.
>
> It would be great to add a disclaimer note to forwarded mails to an
> external domain. Since I'm already running amavisd-new, with all his
> friends, I was thinking to invite alterMIME to the party.

Is this so that people won't mark those messages as spam (thus pinning
the blame on your mail server)?

If so, let me assure you that it will be ignored. I've even called some
of our customers with forwarded addresses on the phone and personally
asked them to stop marking stuff as spam. They still ignore me.


> The tricky part is how to detected which messages are automatically
> forwarded to an external domain.

If this is a filtering gateway, I'm guessing all of your recipients are
listed in relay_recipient_maps? If so, you should be able to override
the default_transport (which defaults to smtp:).

For example, you could set up a disclaimer-only instance of amavis on
port 10029, and then set the default_transport to
smtp:[localhost]:10029. I would beware of unintended consequences,
though. You're liable to stick a disclaimer on some things by accident.

Reply | Threaded
Open this post in threaded view
|

Re: Disclaimer to forwarded mails to external domain?

Michael Orlitzky-2
On 09/03/2012 05:07 PM, Vinícius Ferrão wrote:

>>
>> Is this so that people won't mark those messages as spam (thus pinning
>> the blame on your mail server)?
>>
>> If so, let me assure you that it will be ignored. I've even called some
>> of our customers with forwarded addresses on the phone and personally
>> asked them to stop marking stuff as spam. They still ignore me.
>
> Actually we have user that automatic redirect messages to their personal
> accounts. And this behaviour is not 100% approved by the university. So
> I want to put a disclaimer in those people, as
> example: [hidden email] <mailto:[hidden email]> redirects
> to [hidden email] <mailto:[hidden email]>. I want to put a disclaimer in
> *ALL* messages redirected to external domains.
>

OK disregard my cynicism then =)


>>
>>> The tricky part is how to detected which messages are automatically
>>> forwarded to an external domain.
>>
>> If this is a filtering gateway, I'm guessing all of your recipients are
>> listed in relay_recipient_maps? If so, you should be able to override
>> the default_transport (which defaults to smtp:).
>>
>> For example, you could set up a disclaimer-only instance of amavis on
>> port 10029, and then set the default_transport to
>> smtp:[localhost]:10029. I would beware of unintended consequences,
>> though. You're liable to stick a disclaimer on some things by accident.
>
> There's no recipient check in my mail filtering gateway. I leave this
> job to my final destination. It's not easy to get the final destination
> since we have some different end destination servers and a separate
> mailman server.

Although it isn't related to your current problem, you really must check
recipient validity at receipt time. Otherwise, you're a backscatter source.

If I send spam to you (To: user@invalid) claiming to be from
[hidden email], you'll accept it, because you aren't validating the
recipient. When you try to send it to its final destination, it will
reject it, because user@invalid doesn't live there. Now, you're stuck
with the message, and your filtering server will try to return it to the
sender. But the sender was forged! So you wind up returning my spam to
[hidden email].

If it's not possible to get a list of valid recipients, you can fall
back to address verification:

  http://www.postfix.org/ADDRESS_VERIFICATION_README.html

Basically, postfix will put the sender on hold, contact the destination
server in the background, check that the recipient is valid, and relay
the answer to the sender.


> I can't really understand your example: in this situation everything
> will be "disclaimed"; and I just want to modify messages to people that
> receive their corporate emails in their personal account.

It depends on how you're set up. There are two transports that are
basically the same[1]: 'relay' and 'smtp'. If your domains are listed in
relay_domains, mail to them will be relayed to the destination via the
'relay' transport.

The idea was, if all of your domains are listed in relay_domains, then
any mail using the default_transport='smtp' instead of 'relay' must be
going off-site. The only stuff going off-site should be mail that's
being forwarded to external domains. Unfortunately, unless you validate
your recipients, you'll be bouncing messages, and those go off-site too
so the reasoning doesn't hold.

The first thing I would do is fix your recipient validation. Once that's
done, it's probably safe to add the disclaimer to the 'smtp' transport.
I would also ask on the postfix-users list -- there are people there who
know a lot more than I do and might be able to point out a reason why it
wouldn't work. But the first thing they would tell you to do is fix the
recipient validation, so you might as well get that out of the way!



[1] http://www.postfix.org/ADDRESS_CLASS_README.html