REDIRECT with multiple recipients

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

REDIRECT with multiple recipients

Rudy Gevaert
Hallo,

I configured smtpd_recipient_restrictions to look in an access table.  I
was intending to use the REDIRECT statement to redirect mails for
certain recipients.

unfortunately, after a selected roll out into production we noticed that
this has issues for messages sent to multiple recipients.

Of course this is mentioned in the manual page:

REDIRECT user@domain
   After the message is queued, send the message to  the  specified
   address instead of the intended recipient(s).

   Note:  this  action  overrides  the FILTER action, and currently
   affects all recipients of the message.

Is there a way that I can still use the REDIRECT statement to achieve
the same result but without braking delivery?

Thanks in advance,

Rudy
Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Noel Jones-2
On 3/2/2015 7:59 AM, Rudy Gevaert wrote:

> Hallo,
>
> I configured smtpd_recipient_restrictions to look in an access
> table.  I was intending to use the REDIRECT statement to redirect
> mails for certain recipients.
>
> unfortunately, after a selected roll out into production we noticed
> that this has issues for messages sent to multiple recipients.
>
> Of course this is mentioned in the manual page:
>
> REDIRECT user@domain
>   After the message is queued, send the message to  the  specified
>   address instead of the intended recipient(s).
>
>   Note:  this  action  overrides  the FILTER action, and currently
>   affects all recipients of the message.
>
> Is there a way that I can still use the REDIRECT statement to
> achieve the same result but without braking delivery?
>
> Thanks in advance,
>
> Rudy


To deliver mail for a specific recipient to an alternate address,
use virtual_alias_maps (NOT virtual_alias_domains).

http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Wietse Venema
In reply to this post by Rudy Gevaert
Rudy Gevaert:

> Hallo,
>
> I configured smtpd_recipient_restrictions to look in an access table.  I
> was intending to use the REDIRECT statement to redirect mails for
> certain recipients.
>
> unfortunately, after a selected roll out into production we noticed that
> this has issues for messages sent to multiple recipients.
>
> Of course this is mentioned in the manual page:
>
> REDIRECT user@domain
>    After the message is queued, send the message to  the  specified
>    address instead of the intended recipient(s).
>
>    Note:  this  action  overrides  the FILTER action, and currently
>    affects all recipients of the message.
>
> Is there a way that I can still use the REDIRECT statement to achieve
> the same result but without braking delivery?

If you want to *replace* those recipients, you could use

/etc/postfix/main.cf:
    recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
    recipient_canonical_classes = envelope_recipient

/etc/postfix/recipient_canonical:
    [hidden email] [hidden email]

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Viktor Dukhovni
On Mon, Mar 02, 2015 at 09:42:27AM -0500, Wietse Venema wrote:

> > Is there a way that I can still use the REDIRECT statement to achieve
> > the same result but without braking delivery?
>
> If you want to *replace* those recipients, you could use
>
> /etc/postfix/main.cf:
>     recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
>     recipient_canonical_classes = envelope_recipient
>
> /etc/postfix/recipient_canonical:
>     [hidden email] [hidden email]

Why not virtual_alias_maps as Noel suggested?

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Wietse Venema
Viktor Dukhovni:

> On Mon, Mar 02, 2015 at 09:42:27AM -0500, Wietse Venema wrote:
>
> > > Is there a way that I can still use the REDIRECT statement to achieve
> > > the same result but without braking delivery?
> >
> > If you want to *replace* those recipients, you could use
> >
> > /etc/postfix/main.cf:
> >     recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
> >     recipient_canonical_classes = envelope_recipient
> >
> > /etc/postfix/recipient_canonical:
> >     [hidden email] [hidden email]
>
> Why not virtual_alias_maps as Noel suggested?

It would have the same effect, but without introducing the possibility
of confusion with virtual alias domains.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Viktor Dukhovni
On Mon, Mar 02, 2015 at 11:26:14AM -0500, Wietse Venema wrote:

> > > If you want to *replace* those recipients, you could use
> > >
> > > /etc/postfix/main.cf:
> > >     recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
> > >     recipient_canonical_classes = envelope_recipient
> > >
> > > /etc/postfix/recipient_canonical:
> > >     [hidden email] [hidden email]
> >
> > Why not virtual_alias_maps as Noel suggested?
>
> It would have the same effect, but without introducing the possibility
> of confusion with virtual alias domains.

And this is a 1-to-1 mapping, where-as virtual aliases are 1-to-n.
Going with recipient canonical would not have been my first choice,
but the OP can go with whichever works best for him.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Rudy Gevaert
On 03/02/15 17:37, Viktor Dukhovni wrote:

> On Mon, Mar 02, 2015 at 11:26:14AM -0500, Wietse Venema wrote:
>
>>>> If you want to *replace* those recipients, you could use
>>>>
>>>> /etc/postfix/main.cf:
>>>>      recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
>>>>      recipient_canonical_classes = envelope_recipient
>>>>
>>>> /etc/postfix/recipient_canonical:
>>>>      [hidden email] [hidden email]
>>>
>>> Why not virtual_alias_maps as Noel suggested?
>>
>> It would have the same effect, but without introducing the possibility
>> of confusion with virtual alias domains.
>
> And this is a 1-to-1 mapping, where-as virtual aliases are 1-to-n.
> Going with recipient canonical would not have been my first choice,
> but the OP can go with whichever works best for him.
>

Thanks for the possible alternatives.

In this case I chose to go with the REDIRECT because we have an option
to also do REJECT.  (User can chose to redirect or reject through a
webinterface).  It was nice to do it in one lookup.

I didn't see in the manual that REJECT is limited to one recipient.  But
I should still test it.

In the end I will need to go with the virtual_alias_maps because I'm
already using the canonical rewritting (but in headers and envelope).

Rudy

Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Rudy Gevaert
On 03/03/15 10:00, Rudy Gevaert wrote:

> Thanks for the possible alternatives.
>
> In this case I chose to go with the REDIRECT because we have an option
> to also do REJECT.  (User can chose to redirect or reject through a
> webinterface).  It was nice to do it in one lookup.
>
> I didn't see in the manual that REJECT is limited to one recipient.  But
> I should still test it.

It doesn't pose a problem.

I've now already noticed we also have the relecoated_maps.  It seems I
should be using instead of the a map with REJECT clause.

Could someone tell me if there any other differences between using
[hidden email] REJECT The user has moved

and a relocated map with:
[hidden email] The user has moved

Thanks!

Rudy
Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Koko Wijatmoko
On Tue, 03 Mar 2015 10:58:20 +0100
Rudy Gevaert <[hidden email]> wrote:

> Could someone tell me if there any other differences
> between using
> [hidden email] REJECT The user has moved
>
> and a relocated map with:
> [hidden email] The user has moved
>
There is no "REJECT" in relocated map...
http://www.postfix.org/relocated.5.html

TABLE FORMAT
       The input format for the postmap(1) command is as follows:

       o      An entry has one of the following form:

                   pattern      new_location

              Where new_location specifies  contact  information  such
              as  an email  address, or perhaps a street address or
              telephone number.

       o      Empty lines and whitespace-only lines are ignored, as
              are  lines whose first non-whitespace character is a `#'.

       o      A  logical  line  starts  with  non-whitespace text. A
              line that starts with whitespace continues a logical line.
Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Rudy Gevaert
On 03/03/15 11:09, Koko Wijatmoko wrote:

> On Tue, 03 Mar 2015 10:58:20 +0100
> Rudy Gevaert <[hidden email]> wrote:
>
>> Could someone tell me if there any other differences
>> between using
>> [hidden email] REJECT The user has moved
>>
>> and a relocated map with:
>> [hidden email] The user has moved
>>
> There is no "REJECT" in relocated map...


I know, I'm asking what is the big difference between REJECT in an
access map and the relocated maps.  The behaviour is the same (as I
currently can see).  What is then different.

Thanks

Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Wietse Venema
Rudy Gevaert:
> I know, I'm asking what is the big difference between REJECT in an
> access map and the relocated maps.  The behaviour is the same (as I
> currently can see).  What is then different.

SMTP server only: "REJECT The user has moved".

All mail: relocated_maps with "[hidden email] The user has moved".
It is roughly equivalent to a transport_maps entry that resolves
to "error:The user has moved".


        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Wietse Venema
In reply to this post by Rudy Gevaert
Rudy Gevaert:
> I didn't see in the manual that REJECT is limited to one recipient.  But
> I should still test it.

It does say that "redirect address" overrides all recipients, but
it does not explicitly describe the result of multiple "redirect"
actions (each "redirect" action overrides previous ones). I have
added a note on that to the manpage.

       REDIRECT user@domain
              After the message is queued, send the message to  the  specified
              address instead of the intended recipient(s).  When multiple RE-
              DIRECT actions fire, only the last one takes effect.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: REDIRECT with multiple recipients

Noel Jones-2
In reply to this post by Rudy Gevaert
On 3/3/2015 3:58 AM, Rudy Gevaert wrote:

> On 03/03/15 10:00, Rudy Gevaert wrote:
>
>> Thanks for the possible alternatives.
>>
>> In this case I chose to go with the REDIRECT because we have an
>> option
>> to also do REJECT.  (User can chose to redirect or reject through a
>> webinterface).  It was nice to do it in one lookup.
>>
>> I didn't see in the manual that REJECT is limited to one
>> recipient.  But
>> I should still test it.
>
> It doesn't pose a problem.
>
> I've now already noticed we also have the relecoated_maps.  It seems
> I should be using instead of the a map with REJECT clause.
>
> Could someone tell me if there any other differences between using
> [hidden email] REJECT The user has moved
>
> and a relocated map with:
> [hidden email] The user has moved
>
> Thanks!
>
> Rudy


With either a REJECT or relocated_maps your result is the same, the
recipient is rejected.

The difference is what a real sender will sees on the reject message.

The relocated_maps sends a "mailbox moved" extended status code that
may provide better information to sender.

The "REJECT" sends a general "policy violation" extended status code.

Some desktop mail programs don't display the helpful text you
supply, instead giving their own explanation of the extended status
code, possibly in the local user's language.

If it's more convenient to use an access table with REJECT, you can
use "REJECT 5.1.6 The user has moved" to send the proper extended
status code.



  -- Noel Jones