Re: Address rewriting v Virtual alias domains

[Viktor Dukhovni]

On Tue, Jun 15, 2021 at 04:16:43PM +0200, Mono DHS wrote:

> Assuming that I maintain neither local domains nor relay domains,
> and only virtual mailbox domains, and that

You need an explicit "mydestination =" (empty) for that.  Is that the
case?

> myorigin = $myhostname

That should enable matching of unqualified (local part only) keys.

> holds, the first requirement might be accomplished with having
> 
> append_at_myorigin   = yes
> local_recipient_maps = inline:{ { postmaster = - } }

But with "mydestination" empty, local_recipient_maps is not pertinent.

> To satisfy the second requirement, I currently have
> 
> virtual_alias_domains =
> virtual_alias_maps=
> inline:{ { postmaster = postmaster@⟨some virtual mailbox domain⟩ } }
> 
> and this is where the problem starts.

You should set virtual_alias_domains explicitly to a list of your
desired virtual alias domains, or a separate table with same, unless
you really mean to have an empty list of virtual alias domains.

Do not rely on the obsolete backwards-compatibility setting:

$ postconf -d virtual_alias_domains
virtual_alias_domains = $virtual_alias_maps

> The manpage to virtual(5) suggests in section TABLE SEARCH ORDER that
> it first tries left hand sides of the form  ⟨local-part⟩@⟨domain⟩ ,
> then  ⟨local-part⟩ and finally  @⟨domain⟩ .  It also introduces the
> concept of virtual alias domains and that with an empty
>  virtual_alias_domains,

No, not "empty", rather *default*.

> However, since only the left hand side of that first line is being
> evaluated to decide what that virtual alias domain is, an ambiguity is
> introduced w.r.t. non-virtual alias domain rewriting.

The ambiguity is avoided by explicitly setting virtual_alias_domains
independently of virtual_alias_maps.

> So, the question is, how do I tell Postfix to disable its virtual alias
> domain machinery, yet have the full power of address rewriting with
> virtual(5) at my disposal?

By setting an explicit list of virtual_alias_domains (empty if you
like).

-- 
Viktor.

Re: Address rewriting v Virtual alias domains

[Wietse Venema]

For practical reaons all Postfix address rewriting table lookups
are case-insensitive by default(*), both for the domain and local
part, regardless of what the RFCs say.

(*) When creating an indexed table, the postmap command folds the
input to lowercase before writing to the table, and code that queries
such tables folds the key to lowercase. The pcre: and regexp: lookups
ignore case by default. Password file queries also use a case-folded
key.

Wietse

Address rewriting v Virtual alias domains

[Mono DHS]

Hello all,

I would like to implement rewriting of envelope recipient addresses
as they are recieved by smtpd(8) prior to the respective message being
fed into "the queue", based solely on the form of the envelope recipient
addresses in question. So far, I was able to figure out that to accomplish
this task for arbitrary address/domains, the virtual(5) tables are the
means to express these relationships, and that the cleanup(8) daemon
does the actual work.

Specifically, I would like to make sure that the case-insensitive
   forward-path as required by RFC 5321 [1] is rewritten
to   , where

mydestination = $myhostname

holds.

Secondly, I would like to have either forward-path  
and each of the(no  $proxy_interfaces  here)
rewritten to the forward-path   .

Assuming that I maintain neither local domains nor relay domains, and only
virtual mailbox domains, and that

myorigin = $myhostname

holds, the first requirement might be accomplished with having

append_at_myorigin   = yes
local_recipient_maps = inline:{ { postmaster = - } }

although I am uncertain about whether the maps specified
for  local_recipient_maps  perform case-folding like virtual(5)
maps do.  The LOCAL_RECIPIENT_README did not help in this regard,
either.

To satisfy the second requirement, I currently have

virtual_alias_domains =
virtual_alias_maps=
inline:{ { postmaster = postmaster@⟨some virtual mailbox domain⟩ } }

and this is where the problem starts.

The manpage to virtual(5) suggests in section TABLE SEARCH ORDER that
it first tries left hand sides of the form  ⟨local-part⟩@⟨domain⟩ ,
then  ⟨local-part⟩ and finally  @⟨domain⟩ .  It also introduces the
concept of virtual alias domains and that with an empty
 virtual_alias_domains , the /first line/ of (any of) the maps
in  virtual_alias_maps  tell cleanup(8) what that virtual alias domain
is. However, since only the left hand side of that first line is being
evaluated to decide what that virtual alias domain is, an ambiguity is
introduced w.r.t. non-virtual alias domain rewriting.  This is because,
syntactically, a ⟨local-part⟩ like  postmaster  is indistinguishable
from a ⟨domain⟩ [2], more so  firstname.lastname  (notice the dot).

So, the question is, how do I tell Postfix to disable its virtual alias
domain machinery, yet have the full power of address rewriting with
virtual(5) at my disposal?


Thanks,
Mono

[1] https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.1.3 RECIPIENT 
(RCPT)]
[2] https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.2 Command 
Argument Syntax


signature.asc
Description: PGP signature

Re: Address rewriting guidance

[Matt Shields]

On Fri, Feb 12, 2021 at 12:54 PM Viktor Dukhovni 
wrote:

> On Fri, Feb 12, 2021 at 12:06:02PM -0500, Matt Shields wrote:
>
>
I'll take a look at all the suggestions.

For below, this is just an internal server(behind firewall) with no
internet facing ports.  We use Office365 for corporate mail, and AWS SES
for outbound mail from systems.  We're just looking for this server to be
an intermediary so that we can make sure that what we're sending to AWS SES
has proper addresses and comes through a single IP.  Also, this server is
using host based access lists, so that the only way a server in our network
sends out mail is through this server and is on the access list.  We also
use it to keep an audit trail of messages being sent out.


> >   c. For any host not defined, change the FROM address to
> >  nore...@mycompany.com
>
> A wildcard rewrite like that is generally quite fragile, it can
> easily apply to the wrong sort of mail, e.g. to bounce messages,
> inbound mail from outside, ...  This requires care.  Is there
> a dedicated "submission only" SMTP port on this relay?  I'd
> not want to configure such a rewrite on port 25.
>
> Furthermore, when you start rewriting just the "From:" address you're
> now in a "state of sin".  What if the message has a "Cc:" address, for
> purposes of "Reply-All" a "Cc:" address is, like "From:", just another
> address to reply to.  What if the message has a "Resent-From:" header,
> should the "From:" still be rewritten? ...
>
> That sort of rewriting very much needs to happen at the point of origin.
> It is not impossible to do with Postfix, but it is difficult to do right
> in all cases.
>
>
> --
> Viktor.
>

Re: Address rewriting guidance

[Viktor Dukhovni]

On Fri, Feb 12, 2021 at 12:06:02PM -0500, Matt Shields wrote:

> 1. Rewrite the FROM address in each message
>   a. host1.lan has a process that sets the FROM as t...@mycompany.com, this
>  is okay to let relay
>   b. host2.lan has a script that sends as r...@host2.lan, rewrite FROM as
>  sysad...@mycompany.com

Rewriting the headers of outbound messages received via SMTP should if
at all possible be done on those very same machines, but if for some
reason that is not possible, then something along the lines of:

http://www.postfix.org/postconf.5.html#local_header_rewrite_clients
http://www.postfix.org/postconf.5.html#canonical_maps

local_header_rewrite_clients = permit_mynetworks
canonical_maps = inline:{ {r...@host2.lan = sysad...@example.com} }

Do not tinker with canonical_classes, sender_canonical_maps, or
recipient_canonical_maps, these are for very unusual situations, and
it is almost always a mistake to not apply the same mapping to *all*
addresses.  There is just one exception to the above, if you want to
leave the envelope recipient unmodified in order to deliver to the
right internal address, you can leave "envelope_recipient" out of
canonical_classes:

#canonical_classes =
#envelope_sender, envelope_recipient, header_sender, header_recipient
canonical_classes =
envelope_sender, header_sender, header_recipient

You can of course use some other table type other than "inline", if the
rewrites to be done are not just a static handful.

>   c. For any host not defined, change the FROM address to
>  nore...@mycompany.com

A wildcard rewrite like that is generally quite fragile, it can
easily apply to the wrong sort of mail, e.g. to bounce messages,
inbound mail from outside, ...  This requires care.  Is there
a dedicated "submission only" SMTP port on this relay?  I'd
not want to configure such a rewrite on port 25.

Furthermore, when you start rewriting just the "From:" address you're
now in a "state of sin".  What if the message has a "Cc:" address, for
purposes of "Reply-All" a "Cc:" address is, like "From:", just another
address to reply to.  What if the message has a "Resent-From:" header,
should the "From:" still be rewritten? ...

That sort of rewriting very much needs to happen at the point of origin.
It is not impossible to do with Postfix, but it is difficult to do right
in all cases.

> 2. Rewrite the TO address
>   a. host4.lan strip all TO addresses that do not match @mycompany.com.  On
>  some systems (dev/qa) we do not want to send emails to clients.

The message headers have nothing to do with where mail is delivered.
Use smtpd_recipient_restrictions and smtpd_relay_restrictions to control
which machines can relay outbound email.

-- 
Viktor.

Address rewriting guidance

[Matt Shields]

Other than setting up a very basic Postfix server for sending out email,
I'm new to the advanced rewriting capabilities.  I need to setup a server
that let's me do the following.  I've already setup SMTP relaying through
AWS SES and I've setup host based access list to make sure only certain
internal hosts can send mail.  But I'm stuck on the address rewriting.  I'm
looking for some config examples.

1. Rewrite the FROM address in each message
  a. host1.lan has a process that sets the FROM as t...@mycompany.com, this
is okay to let relay
  b. host2.lan has a script that sends as r...@host2.lan, rewrite FROM as
sysad...@mycompany.com
  c. For any host not defined, change the FROM address to
nore...@mycompany.com
2. Rewrite the TO address
  a. host4.lan strip all TO addresses that do not match @mycompany.com.  On
some systems (dev/qa) we do not want to send emails to clients.

Matt Shields
m...@shields.tv
781-424-3531

Re: [Partially solved] Re: Address rewriting not working

[Celejar]

On Fri, 4 Jan 2019 15:20:08 -0500
Viktor Dukhovni  wrote:

> > On Jan 4, 2019, at 2:56 PM, Celejar  wrote:
> > 
> > And I'm using 3.1.8, where the rewriting isn't acceptable to my mail
> > provider, and this feature isn't available ;) So I guess I'm stuck,
> > unless I can upgrade Postfix?
> 
> Your other option, if possible, is to inject email into Postfix
> with the "From:" header already constructed the way you want.
> Postfix only adds "From:" headers when missing.
> 
> You could also use a PCRE REPLACE rule in smtp_header_checks:
> 
>   # Replace some legacy "address (display name)" forms with a
>   # more modern "display name " form.
>   /^From:\s*([^\s<>]+)\s+\(([^"]*)\)\s*$/ REPLACE From: "$2" <$1>

Thanks much - this seems to be working.

> The server that's accepting "From: display name "
> and rejecting "From: address (display name)" is not blameless
> It should be able to process either form.

Of course. It's just that I have higher expectations of quality open
source software than I do of a commercial mail provider ;)

Thanks again for all the help,

Celejar

Re: [Partially solved] Re: Address rewriting not working

[Celejar]

On Fri, 4 Jan 2019 15:22:08 -0500 (EST)
Wietse Venema  wrote:

> Celejar:
> > On Fri, 4 Jan 2019 13:19:10 -0500 (EST)
> > Wietse Venema  wrote:
> > 
> > > Celejar:
> > > > Okay, by testing with swaks I've confirmed the suspicion that I broached
> > > > in my previous mail: on the problematic system, the rewrite of the email
> > > > header 'From: root' is to 'From:  (root)', which
> > > > causes the mail to be rejected by Zoho's server with '553 Relaying
> > > > disallowed as @'. On the working systems, the rewrite is to a more
> > > > normal 'From: root ', which Zoho accepts.
> > > > 
> > > > So: is this a bug? Is there some way I can get Postfix 3.1.8 to do the
> > > > rewriting the normal way, like 3.3.2 does, or do I just need to upgrade
> > > > Postfix?
> > > 
> > > See: http://www.postfix.org/postconf.5.htnl#header_from_format
> > >This feature is available in Postfix 3.3 and later.
> > 
> > And I'm using 3.1.8, where the rewriting isn't acceptable to my mail
> > provider, and this feature isn't available ;) So I guess I'm stuck,
> > unless I can upgrade Postfix?
> 
> Can you provide the From: header *before* mail enters Postfix?
> 
> Otherwise you will have to update to Postfix 3.3.

I suppose I might be able to look at individual mail sending
applications to see what they can do (cron, etc.), but it will probably
be simpler and more robust to just try to use a newer Postfix. I can't
easily upgrade the version on the current system, since it's running
Debian Stable, and the version from Unstable has unavailable
dependencies, so I'll probably just run a more recent Postfix on a
virtual machine.

Thanks for the help,

Celejar

Re: [Partially solved] Re: Address rewriting not working

[Wietse Venema]

Celejar:
> On Fri, 4 Jan 2019 13:19:10 -0500 (EST)
> Wietse Venema  wrote:
> 
> > Celejar:
> > > Okay, by testing with swaks I've confirmed the suspicion that I broached
> > > in my previous mail: on the problematic system, the rewrite of the email
> > > header 'From: root' is to 'From:  (root)', which
> > > causes the mail to be rejected by Zoho's server with '553 Relaying
> > > disallowed as @'. On the working systems, the rewrite is to a more
> > > normal 'From: root ', which Zoho accepts.
> > > 
> > > So: is this a bug? Is there some way I can get Postfix 3.1.8 to do the
> > > rewriting the normal way, like 3.3.2 does, or do I just need to upgrade
> > > Postfix?
> > 
> > See: http://www.postfix.org/postconf.5.htnl#header_from_format
> >This feature is available in Postfix 3.3 and later.
> 
> And I'm using 3.1.8, where the rewriting isn't acceptable to my mail
> provider, and this feature isn't available ;) So I guess I'm stuck,
> unless I can upgrade Postfix?

Can you provide the From: header *before* mail enters Postfix?

Otherwise you will have to update to Postfix 3.3.

Wietse

Re: [Partially solved] Re: Address rewriting not working

[Viktor Dukhovni]

> On Jan 4, 2019, at 2:56 PM, Celejar  wrote:
> 
> And I'm using 3.1.8, where the rewriting isn't acceptable to my mail
> provider, and this feature isn't available ;) So I guess I'm stuck,
> unless I can upgrade Postfix?

Your other option, if possible, is to inject email into Postfix
with the "From:" header already constructed the way you want.
Postfix only adds "From:" headers when missing.

You could also use a PCRE REPLACE rule in smtp_header_checks:

# Replace some legacy "address (display name)" forms with a
# more modern "display name " form.
/^From:\s*([^\s<>]+)\s+\(([^"]*)\)\s*$/ REPLACE From: "$2" <$1>

The server that's accepting "From: display name "
and rejecting "From: address (display name)" is not blameless
It should be able to process either form.

-- 
-- 
Viktor.

Re: [Partially solved] Re: Address rewriting not working

[Celejar]

On Fri, 4 Jan 2019 13:19:10 -0500 (EST)
Wietse Venema  wrote:

> Celejar:
> > Okay, by testing with swaks I've confirmed the suspicion that I broached
> > in my previous mail: on the problematic system, the rewrite of the email
> > header 'From: root' is to 'From:  (root)', which
> > causes the mail to be rejected by Zoho's server with '553 Relaying
> > disallowed as @'. On the working systems, the rewrite is to a more
> > normal 'From: root ', which Zoho accepts.
> > 
> > So: is this a bug? Is there some way I can get Postfix 3.1.8 to do the
> > rewriting the normal way, like 3.3.2 does, or do I just need to upgrade
> > Postfix?
> 
> See: http://www.postfix.org/postconf.5.htnl#header_from_format

...

> header_from_format (default: standard)

...

>Specify one of the following:
> 
>standard (default)
>   Produce a header formatted as "From: name ".   This  is
>   the default as of Postfix 3.3.
> 
>obsolete
>   Produce  a  header  formatted as "From: address (name)". This is
>   the behavior prior to Postfix 3.3.

...

>This feature is available in Postfix 3.3 and later.

And I'm using 3.1.8, where the rewriting isn't acceptable to my mail
provider, and this feature isn't available ;) So I guess I'm stuck,
unless I can upgrade Postfix?

Thanks for the pointer,
Celejar

[Partially solved] Re: Address rewriting not working

[Celejar]

On Wed, 2 Jan 2019 19:58:18 -0500
Viktor Dukhovni  wrote:

> > On Jan 2, 2019, at 7:12 PM, Celejar  wrote:
> > 
> > I'm configuring Postfix to relay mail via a smarthost, and I need to
> > rewrite the sender address in order for the smarthost to accept the
> > mail (and not reject it as 'relaying'). I'm using generic mapping to do
> > this, and it works correctly on two of my systems (Debian Sid,
> > running Postfix 3.3.2), but not on a third (Debian Stretch, running
> > 3.1.8). I've tried all sorts of adjustments and debugging, and I'm at
> > my wits' end. Below is the configuration and logging from the broken
> > system:
> 

> Because the queue manager logs the envelope sender prior to delivery,
> it always logs the original value, and recipient logging in delivery
> agents is also the form before generic rewriting.  The output of
> generic rewriting is not logged on the sending system (except perhaps
> in verbose logging that should not normally be enabled).

Okay, by testing with swaks I've confirmed the suspicion that I broached
in my previous mail: on the problematic system, the rewrite of the email
header 'From: root' is to 'From:  (root)', which
causes the mail to be rejected by Zoho's server with '553 Relaying
disallowed as @'. On the working systems, the rewrite is to a more
normal 'From: root ', which Zoho accepts.

So: is this a bug? Is there some way I can get Postfix 3.1.8 to do the
rewriting the normal way, like 3.3.2 does, or do I just need to upgrade
Postfix?

Celejar

Re: Address rewriting not working

[Celejar]

On Wed, 2 Jan 2019 19:58:18 -0500
Viktor Dukhovni  wrote:

> > On Jan 2, 2019, at 7:12 PM, Celejar  wrote:
> > 
> > I'm configuring Postfix to relay mail via a smarthost, and I need to
> > rewrite the sender address in order for the smarthost to accept the
> > mail (and not reject it as 'relaying'). I'm using generic mapping to do
> > this, and it works correctly on two of my systems (Debian Sid,
> > running Postfix 3.3.2), but not on a third (Debian Stretch, running
> > 3.1.8). I've tried all sorts of adjustments and debugging, and I'm at
> > my wits' end. Below is the configuration and logging from the broken
> > system:
> 
> smtp_generic_maps (a.k.a. generic_maps) is (not surprisingly), done
> in the smtp(8) delivery agent in real-time as the message is being
> sent, and not in trivial-rewrite, which only resolves addresses
> to standard form and resolves to a transport.  Hence the "trivial"
> in the name.
> 
> Pre-queue rewriting (masquerading, canonical_maps and virtual_alias_maps
> for just the recipient) happens in cleanup(8).  Post-queue rewriting
> happens in delivery agents, with just transport resolution in trivial
> rewrite called from the queue-manager in between.
> 
> Because the queue manager logs the envelope sender prior to delivery,
> it always logs the original value, and recipient logging in delivery
> agents is also the form before generic rewriting.  The output of
> generic rewriting is not logged on the sending system (except perhaps
> in verbose logging that should not normally be enabled).

Ah, okay - thanks for clearing this up. I was following the
instructions in DEBUG_README, which say:

To diagnose problems with address rewriting specify a "-v" option for
the cleanup(8) and/or trivial-rewrite(8) daemon

and the ADDRESS_REWRITING_README classifies "Generic mapping for
outgoing SMTP mail" as a form of "Address rewriting when mail is
delivered".

I suggest that the instructions in DEBUG_README be clarified to
distinguish between the different forms of address rewriting.

As to the underlying problem, I may have figured it out: I switched
to using canonical mapping, since that gets properly logged, and I saw
that the rewrite is indeed happening correctly on all systems - but one
still has the mail rejected, while the others get it accepted. I
suspected that the problem may be in the way the email 'From:' header is
being rewritten, and I used smtp_header_checks to investigate. Sure
enough, the rewrite is happening differently on the two systems:

Here's the bad system:

Jan  3 15:09:10 alice postfix/qmgr[17481]: B0A33AC40093: 
from=, size=257, nrcpt=1 (queue active)
Jan  3 15:09:12 alice postfix/smtp[17489]: B0A33AC40093: warning: header From: 
a...@zoho.com (root)
Jan  3 15:09:12 alice postfix/smtp[17489]: B0A33AC40093: 
to=, relay=smtp.zoho.com[204.141.43.189]:465, delay=1.5, 
delays=0.1/0.1/0.88/0.4, dsn=5.0.0, status=bounced (host 
smtp.zoho.com[204.141.43.189] said: 553 Relaying disallowed as @ (in reply to 
end of DATA command))

And here's one of the good ones:

Jan  3 15:14:58 lila postfix/qmgr[14708]: 9AD005E18AD: 
from=, size=249, nrcpt=1 (queue active)
Jan  3 15:15:00 lila postfix/smtp[14715]: 9AD005E18AD: warning: header From: 
root 
Jan  3 15:15:01 lila postfix/smtp[14715]: 9AD005E18AD: to=, 
relay=smtp.zoho.com[204.141.43.189]:465, delay=2.8, delays=0.27/0.06/1.4/1.1, 
dsn=2.0.0, status=sent (250 Message received)

IIUC, Zoho is being picky and rejecting the first form of the rewritten
'From:' header, with ' (root)' at the end. Does this seem right? I'm no
email expert, but that certainly seems a somewhat uncommon form. How
can I get Postfix do do something more standard?

Celejar

Re: Address rewriting not working

[Viktor Dukhovni]

> On Jan 2, 2019, at 7:12 PM, Celejar  wrote:
> 
> I'm configuring Postfix to relay mail via a smarthost, and I need to
> rewrite the sender address in order for the smarthost to accept the
> mail (and not reject it as 'relaying'). I'm using generic mapping to do
> this, and it works correctly on two of my systems (Debian Sid,
> running Postfix 3.3.2), but not on a third (Debian Stretch, running
> 3.1.8). I've tried all sorts of adjustments and debugging, and I'm at
> my wits' end. Below is the configuration and logging from the broken
> system:

smtp_generic_maps (a.k.a. generic_maps) is (not surprisingly), done
in the smtp(8) delivery agent in real-time as the message is being
sent, and not in trivial-rewrite, which only resolves addresses
to standard form and resolves to a transport.  Hence the "trivial"
in the name.

Pre-queue rewriting (masquerading, canonical_maps and virtual_alias_maps
for just the recipient) happens in cleanup(8).  Post-queue rewriting
happens in delivery agents, with just transport resolution in trivial
rewrite called from the queue-manager in between.

Because the queue manager logs the envelope sender prior to delivery,
it always logs the original value, and recipient logging in delivery
agents is also the form before generic rewriting.  The output of
generic rewriting is not logged on the sending system (except perhaps
in verbose logging that should not normally be enabled).

-- 
Viktor.

Address rewriting not working

[Celejar]

Hi,

I'm configuring Postfix to relay mail via a smarthost, and I need to
rewrite the sender address in order for the smarthost to accept the
mail (and not reject it as 'relaying'). I'm using generic mapping to do
this, and it works correctly on two of my systems (Debian Sid,
running Postfix 3.3.2), but not on a third (Debian Stretch, running
3.1.8). I've tried all sorts of adjustments and debugging, and I'm at
my wits' end. Below is the configuration and logging from the broken
system:

>From /var/log/mail.log :

Jan  2 14:05:55 alice postfix/pickup[17200]: D2324AC400BA: uid=0 from=
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: name_mask: all
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: inet_addr_local: 
configured 2 IPv4 addresses
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: inet_addr_local: 
configured 5 IPv6 addresses
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: process generation: 20 
(20)
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: connection established fd 
128
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: master_notify: status 0
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: request
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: 
request
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute value: 
rewrite
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: rule
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: rule
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute value: 
local
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: address
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: 
address
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute value: 
root
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: (list terminator)
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: 
(end)
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: `local' `root' -> 
`root@alice.villette'
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: send attr flags = 0
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: send attr address = 
root@alice.villette
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: master_notify: status 1
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: master_notify: status 0
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: request
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: 
request
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute value: 
rewrite
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: rule
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: rule
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute value: 
local
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: address
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: 
address
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute value: 
cele...@gmail.com
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: (list terminator)
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: 
(end)
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: `local' 
`cele...@gmail.com' -> `cele...@gmail.com'
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: send attr flags = 0
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: send attr address = 
cele...@gmail.com
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: master_notify: status 1
Jan  2 14:05:55 alice postfix/cleanup[19935]: D2324AC400BA: 
message-id=<20190102190555.D2324AC400BA@alice.villette>
Jan  2 14:05:55 alice postfix/qmgr[17048]: D2324AC400BA: 
from=, size=258, nrcpt=1 (queue active)
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: connection established fd 
129
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: master_notify: status 0
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: request
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: 
request
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute value: 
resolve
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: sender
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: 
sender
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute value: 
root@alice.villette
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: rewrite socket: wanted 
attribute: address
Jan  2 14:05:55 alice postfix/trivial-rewrite[19936]: input attribute name: 
address
Jan  2 14:05:55 alice 

RE: Outbound address rewriting

[Kevin Miller]

Thanks for the feedback.  It's working as advertised although in the end I used 
the canonical map.

...Kevin
--
Kevin Miller
Network/email Administrator, CBJ MIS Dept.
155 South Seward Street
Juneau, Alaska 99801
Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357


-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of /dev/rob0
Sent: Thursday, April 19, 2018 3:10 PM
To: postfix-users@postfix.org
Subject: Re: Outbound address rewriting

On Thu, Apr 19, 2018 at 09:47:27PM +, Kevin Miller wrote:
> Quick question: In the docs I don't see a reference to a line in 
> main.cf.  Will postfix pick up on the existence of the table 
> automatically once I hash it, or do I need to add something along 
> the lines of:
>   virtual_alias_maps = hash:/etc/virtual
> in main.cf?

For backward compatibility, the default value for virtual_alias_maps 
is "$virtual_maps".  If that's not set (and in 2018 it certainly 
should NOT be set) the default is empty.  You seem to have missed 
postconf.5.html#virtual_alias_maps somehow.

You do indeed need to set something for virtual_alias_maps if you 
intend to use the feature.

You might also be interested in the command line postconf(1) tool: 
"postconf virtual_alias_maps" will show what you have set for 
virtual_alias_maps.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Outbound address rewriting

[/dev/rob0]

On Thu, Apr 19, 2018 at 09:47:27PM +, Kevin Miller wrote:
> Quick question: In the docs I don't see a reference to a line in 
> main.cf.  Will postfix pick up on the existence of the table 
> automatically once I hash it, or do I need to add something along 
> the lines of:
>   virtual_alias_maps = hash:/etc/virtual
> in main.cf?

For backward compatibility, the default value for virtual_alias_maps 
is "$virtual_maps".  If that's not set (and in 2018 it certainly 
should NOT be set) the default is empty.  You seem to have missed 
postconf.5.html#virtual_alias_maps somehow.

You do indeed need to set something for virtual_alias_maps if you 
intend to use the feature.

You might also be interested in the command line postconf(1) tool: 
"postconf virtual_alias_maps" will show what you have set for 
virtual_alias_maps.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Outbound address rewriting

[Tom Hendrikx]

On 19-04-18 23:26, Kevin Miller wrote:
> -Original Message-
>> I think in this case both domains are remote, in which case the
>> bounce issue may be moot.  Only users authorized to send outbound
>> mail can create email for the destination in question, and the
>> goal is to "correct" the destination domain.
> 
> Right.  As it stands now, the mail will sit in the outbound queue for days 
> until it finally times out as undeliverable.  My thought is that with the 
> rewriting, the mail will be either immediately delivered, or the sender get a 
> 550 rejection in a timely manner.
> 

You could also simply reject inbound messages to the non-existent domain
with a somewhat helpful reject message, explaining that the sender
should use the new domain. That way users will learn very quickly to
update their address book.

Kind regards,
Tom



signature.asc
Description: OpenPGP digital signature

RE: Outbound address rewriting

[Kevin Miller]

> Use canonical_maps to rewrite all instances of the address
> (header, envelope, sender, recipient).

> Use virtual_alias_maps (not virtual_aias_domains) to rewrite
> the envelope recipient only.

Quick question:  In the docs I don't see a reference to a line in main.cf.  
Will postfix pick up on the existence of the table automatically once I hash 
it, or do I need to add something along the lines of:
  virtual_alias_maps = hash:/etc/virtual
in main.cf?

Thanks again...

...Kevin
--
Kevin Miller
Network/email Administrator, CBJ MIS Dept.
155 South Seward Street
Juneau, Alaska 99801
Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357

RE: Outbound address rewriting

[Kevin Miller]

-Original Message-
> I think in this case both domains are remote, in which case the
> bounce issue may be moot.  Only users authorized to send outbound
> mail can create email for the destination in question, and the
> goal is to "correct" the destination domain.

Right.  As it stands now, the mail will sit in the outbound queue for days 
until it finally times out as undeliverable.  My thought is that with the 
rewriting, the mail will be either immediately delivered, or the sender get a 
550 rejection in a timely manner.

Thank you gentlemen...

--
Kevin Miller
Network/email Administrator, CBJ MIS Dept.
155 South Seward Street
Juneau, Alaska 99801
Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357

Re: Outbound address rewriting

[Viktor Dukhovni]

> On Apr 19, 2018, at 4:24 PM, Wietse Venema  wrote:
> 
> In both maps,
> 
>@alaska.com@alaskan.com
> 
> would do the domain translation.
> 
> Caution: with this, Postfix will accept email for any addr...@alaska.com
> including addresses that are later found to be undeliverable. If
> someone starts to send lots of mail to random addresses at alaska.com,
> then your mail queue will fill up with bounce messages.

I think in this case both domains are remote, in which case the
bounce issue may be moot.  Only users authorized to send outbound
mail can create email for the destination in question, and the
goal is to "correct" the destination domain.

-- 
Viktor.

Re: Outbound address rewriting

[Wietse Venema]

Kevin Miller:
> Some years back a local ISP/cable company hosted the alaska.com
> domain.  They had just leased the domain, and a couple years ago
> the owners didn't renew the lease.  GCI registered a new domain,
> alaskan.com (note the "n" in alaskan).  When my users send to
> some...@alaska.com, it bounces as there is no MX host to receive
> mail for that domain.  I'd like my outbound smtp server to to
> rewrite the to address so that u...@alaska.com becomes u...@alaskan.com.
> What's the cleanest way to do so?  I've been reading through the
> postfix address rewriting pages but with so many options I'm a bit
> overwhelmed.  I'm leaning towards the generic table - would that
> be an appropriate route?

Use canonical_maps to rewrite all instances of the address
(header, envelope, sender, recipient).

Use virtual_alias_maps (not virtual_aias_domains) to rewrite
the envelope recipient only.

In both maps,

@alaska.com @alaskan.com

would do the domain translation.

Caution: with this, Postfix will accept email for any addr...@alaska.com
including addresses that are later found to be undeliverable. If
someone starts to send lots of mail to random addresses at alaska.com,
then your mail queue will fill up with bounce messages.

Wietse

Outbound address rewriting

[Kevin Miller]

Some years back a local ISP/cable company hosted the alaska.com domain.  They 
had just leased the domain, and a couple years ago the owners didn't renew the 
lease.  GCI registered a new domain, alaskan.com (note the "n" in alaskan).  
When my users send to some...@alaska.com, it bounces as there is no MX host to 
receive mail for that domain.  I'd like my outbound smtp server to to rewrite 
the to address so that u...@alaska.com becomes u...@alaskan.com.  What's the 
cleanest way to do so?  I've been reading through the postfix address rewriting 
pages but with so many options I'm a bit overwhelmed.  I'm leaning towards the 
generic table - would that be an appropriate route?

Thanks...

...Kevin
--
Kevin Miller
Network/email Administrator, CBJ MIS Dept.
155 South Seward Street
Juneau, Alaska 99801
Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357

Re: Address rewriting help?

[Noel Jones]

On 8/31/2016 5:32 PM, Tom Horsley wrote:
> On Wed, 31 Aug 2016 17:19:54 -0500
> Noel Jones wrote:
> 
>> Sounds as if smtp_generic_maps may be a better fit for this than
>> canonical maps.
>> http://www.postfix.org/ADDRESS_REWRITING_README.html#generic
> 
> I tried generic maps first, but that not only changed
> the sender address, but the To: address as well, so I
> could only send mail to myself (maybe I didn't
> read enough to configure it correctly :-).

If you use a "*" wildcard to blindly rewrite everything, that's what
will happen.

You must limit the scope of the rewriting.  The examples in the link
above showed how to do this.

Something like:
@mydomain.local   externalu...@example.com

If you have multiple local fantasy domains, each one needs to be
listed; just add more lines.  No need to list the individual users.



  -- Noel Jones

Re: Address rewriting help?

[John Stoffel]

> "Tom" == Tom Horsley  writes:

Tom> On Wed, 31 Aug 2016 18:32:03 -0400
Tom> Tom Horsley wrote:

>> I'm just reading about the pickup program and the
>> receive_override_options to turn off mapping.
>> I think that might work, only the mail from
>> fetchmail is being locally delivered via pickup.

Tom> Nah, that didn't work either, but I think I can just totally
Tom> bypass postfix in the fetchmail half of the equation by giving it
Tom> an mda to deliver to rather than telling it to do local delivery.

Tom> Just put the complicated pipe in my .forward file into
Tom> fetchmail's mda option instead.

I use fetchmail which I then pipe into procmail as the MDA, which
works awesome for sorting mail.  But... I'm now in the process of
setting up my own domain using postfix and dovecot and I'll have to
move to Sieve to do all this.

In my .fetchmailrc I have something like this:

   poll imap.gmail.com protocol IMAP
  user "somenice...@gmail.com", with password 
"brothercanyouspareadime", is
  'bob' here ssl
  mda "procmail -d %T"

and it works well.  Then in my local .procmailrc I have all my filters
into mbox style files which are the inboxes for my email folders.
Works well.

But like I said, I'm now moving to postfix/dovecot/sieve for my mail
handling.  All so I can read home mail in multiple places more easily.

John

Re: Address rewriting help?

[Tom Horsley]

On Wed, 31 Aug 2016 18:32:03 -0400
Tom Horsley wrote:

> I'm just reading about the pickup program and the
> receive_override_options to turn off mapping.
> I think that might work, only the mail from
> fetchmail is being locally delivered via pickup.

Nah, that didn't work either, but I think
I can just totally bypass postfix in the
fetchmail half of the equation by giving it
an mda to deliver to rather than telling
it to do local delivery.

Just put the complicated pipe in my .forward
file into fetchmail's mda option instead.

Re: Address rewriting help?

[Tom Horsley]

On Wed, 31 Aug 2016 17:19:54 -0500
Noel Jones wrote:

> Sounds as if smtp_generic_maps may be a better fit for this than
> canonical maps.
> http://www.postfix.org/ADDRESS_REWRITING_README.html#generic

I tried generic maps first, but that not only changed
the sender address, but the To: address as well, so I
could only send mail to myself (maybe I didn't
read enough to configure it correctly :-).

I'm just reading about the pickup program and the
receive_override_options to turn off mapping.
I think that might work, only the mail from
fetchmail is being locally delivered via pickup.

Re: Address rewriting help?

[Noel Jones]

On 8/31/2016 5:03 PM, Tom Horsley wrote:
> I'm trying to setup a relayhost to send all my mail
> through smtp.office365.com so postfix can queue it and
> I don't have to stare at a "Authenticating..." dialog
> box for 10 or 20 seconds.
> 
> I actually have things mostly working. I use
> this:
> 
> sender_canonical_maps = regexp:/etc/postfix/canonical

Sounds as if smtp_generic_maps may be a better fit for this than
canonical maps.
http://www.postfix.org/ADDRESS_REWRITING_README.html#generic



  -- Noel Jones

> 
> to change all addresses to the one and only address
> that works with my office365 account.
> 
> The problem comes when I receive mail. I'm using
> fetchmail to suck all my mail out of office365
> and deliver it locally where I can run it through
> a gazillion filters specified in a pipe in my
> ~/.forward file.
> 
> I think that is causing all the From: addresses
> in my incoming mail to also be re-written so that
> everything looks like it comes from me, which is just
> a tad confusing.
> 
> What is a good way to still manage to filter all my
> incoming mail without re-writing the From: address
> on the way in? (While still, of course, re-writing
> the outgoing address so office365 will accept it).
> 
> I don't insist on using a .forward file or even using
> fetchmail as long as there is some way I can extract
> all my mail from office365 an filter it locally.
> 

Address rewriting help?

[Tom Horsley]

I'm trying to setup a relayhost to send all my mail
through smtp.office365.com so postfix can queue it and
I don't have to stare at a "Authenticating..." dialog
box for 10 or 20 seconds.

I actually have things mostly working. I use
this:

sender_canonical_maps = regexp:/etc/postfix/canonical

to change all addresses to the one and only address
that works with my office365 account.

The problem comes when I receive mail. I'm using
fetchmail to suck all my mail out of office365
and deliver it locally where I can run it through
a gazillion filters specified in a pipe in my
~/.forward file.

I think that is causing all the From: addresses
in my incoming mail to also be re-written so that
everything looks like it comes from me, which is just
a tad confusing.

What is a good way to still manage to filter all my
incoming mail without re-writing the From: address
on the way in? (While still, of course, re-writing
the outgoing address so office365 will accept it).

I don't insist on using a .forward file or even using
fetchmail as long as there is some way I can extract
all my mail from office365 an filter it locally.

Re: Conditionnal sender address rewriting

[Noel Jones]

On 8/8/2016 1:21 PM, Julien Sansonnens wrote:
> Hi Postfix users,
> 
> For some reason, I would like my sender address to be altered,
> depending on the recipient domain.
> It's quite simple: when I send an email to j...@myexample.com domain,
> the FROM header must be changed to "mys...@myexample.com" instead of
> mys...@myhostname.com".
> 
> Here is my (non working) config to achieve this
> 
> 1. master.conf
> out_new  unix -   -   n   -   -   smtp
> -o smtp_helo_name=myexample.com
> -o sender_canonical_maps=regexp:/etc/postfix/generic_toext 

sender_canonical_maps is a property of the cleanup service, not
smtp, so you can't override that setting here.

> 
> 2. /etc/postfix/generic_toext
> /^(.*)@(.*)myhostname\.com/  $1...@myexample.com

You can probably use this same regexp with smtp_header_checks to
achieve your goal.  You /can/ use a custom smtp_header_checks
setting in a master.cf smtp transport.
http://www.postfix.org/postconf.5.html#smtp_header_checks



  -- Noel Jones

Conditionnal sender address rewriting

[Julien Sansonnens]

Hi Postfix users,

For some reason, I would like my sender address to be altered,
depending on the recipient domain.
It's quite simple: when I send an email to j...@myexample.com domain,
the FROM header must be changed to "mys...@myexample.com" instead of
mys...@myhostname.com".

Here is my (non working) config to achieve this

1. master.conf
out_new  unix -   -   n   -   -   smtp
-o smtp_helo_name=myexample.com
-o sender_canonical_maps=regexp:/etc/postfix/generic_toext

2. /etc/postfix/generic_toext
/^(.*)@(.*)myhostname\.com/  $1...@myexample.com

3. /etc/postfix/transport
myexample.comout_new:

4. main.cf
transport_maps = hash:/etc/postfix/transport

This is NOT working, and I have no idea why.
Based on logs, I see that mails to myexample.com are correctly sent
using "out_new", but the sender_canonical_maps is ignored (I checked
twice: the regex is working fine)

Now, if I put the sender_canonical_maps setting in main.cf, it's
working ! (only problem is that my FROM is changed for each message I
send).

Can anybody explain me why the sender_canonical_maps setting seems
ignored when it's written in master.cf ?

Do you any solution or workarround to make it work ?

Thanks,
cheers, julien

Re: Address rewriting

[Wietse Venema]

Robert Fitzpatrick:
> Jul  6 13:44:39 mx1 postfix/smtpd[74447]: NOQUEUE: reject: RCPT from 
> mail-dm3nam03on0135.outbound.protection.outlook.com[104.47.41.135]: 450 
> 4.1.8 : Sender address rejected: Domain not 
> found; from= to= proto=ESMTP 
> helo=

This error message has nothing to do with header rewriting.

You have reject_unknown_sender_domain in main.cf, which applies to
the MAIL FROM command in SMTP, and the domain streamer.wmnf.org
does not exist in the DNS. Header rewriting does not change this.

Perhaps someone else can help you figure out what you really need,
and how to accomplish that with Postfix. I have to return to work.

Wietse

Re: Address rewriting

[Viktor Dukhovni]

On Wed, Jul 06, 2016 at 02:10:29PM -0400, Robert Fitzpatrick wrote:

> local_header_rewrite_clients = static:all
> But from the logs
> 
> Jul  6 13:44:39 mx1 postfix/smtpd[74447]: NOQUEUE: reject: RCPT from
> mail-dm3nam03on0135.outbound.protection.outlook.com[104.47.41.135]: 450
> 4.1.8 <m...@streamer.wmnf.org>: Sender address rejected: Domain not found;
> from=<m...@streamer.wmnf.org> to=<w...@webtent.com> proto=ESMTP
> helo=

These are *envelope* addresses and not surprising header address
rewriting has no effect here.

In any case address rewriting happens in cleanup(8), and smtpd(8)
access control works with the original envelope addresses provided
in the SMTP dialogue (only ligthly rewritten to "standard form"
via trivial-rewrite(8)).

-- 
Viktor.

Re: Address rewriting

[Robert Fitzpatrick]

Wietse Venema wrote:

Robert Fitzpatrick:

local_header_rewrite_clients = static:all

I'm looking for a way to rewrite by name from any client. My canonical
maps work great for mynetworks, would like to apply the same type
rewrite to any message...


The above setting should enable canonical mapping for all email,
which was Postfix behavior before Postfix 2.3.



Yeah, so this is my issue then and perhaps I have something else in my 
config messing it up? It doesn't seem to be working. Here is a real 
world example 


root@mx1:/usr/local/etc # postconf -n|grep local_header
local_header_rewrite_clients = static:all
root@mx1:/usr/local/etc # postmap -q m...@streamer.wmnf.org 
ldap:/usr/local/etc/postfix/ldap/canonical.cf

@wmnf.org

But from the logs

Jul  6 13:44:39 mx1 postfix/smtpd[74447]: NOQUEUE: reject: RCPT from 
mail-dm3nam03on0135.outbound.protection.outlook.com[104.47.41.135]: 450 
4.1.8 : Sender address rejected: Domain not 
found; from= to= proto=ESMTP 
helo=


Perhaps something else in my config messing things up, so I took a look 
at main.cf and find that I have ...


smtpd_sender_restrictions = ..., reject_unknown_address, 
check_sender_access ldap:/usr/local/etc/postfix/ldap/verification-sender.cf


Would this cause my problem using reject_unknown_address?



postmap -q u...@host.otherdomain.com
ldap:/usr/local/etc/postfix/ldap/canonical.cf
@otherdomain.com


Don't do that. It makes your Postfix accept email for
non-existent email addresses.

Instead, make explicit rules:

us...@host.otherdomain.com  us...@otherdomain.com
us...@host.otherdomain.com  us...@otherdomain.com
us...@host.otherdomain.com  us...@otherdomain.com

Wietse


Well, good point. Guess it hasn't been an issue since my canonical 
lookup is only working on local addresses, all of which I do address 
verification as well. Never presented an issue. The original reason for 
using canonical lookup is to rewrite outgoing messages from a set of 
local servers where the hostname is used for sending administrative 
messages, to avoid having to setup extra MX records for each domain. Am 
I still in trouble with local AV?


Excuse my ignorance, trying to make sense of it all. I'm more a 
programmer than mail administrator.


--
Robert

Re: Address rewriting

[Wietse Venema]

Robert Fitzpatrick:
> local_header_rewrite_clients = static:all
> 
> I'm looking for a way to rewrite by name from any client. My canonical 
> maps work great for mynetworks, would like to apply the same type 
> rewrite to any message...

The above setting should enable canonical mapping for all email,
which was Postfix behavior before Postfix 2.3.

> postmap -q u...@host.otherdomain.com 
> ldap:/usr/local/etc/postfix/ldap/canonical.cf
> @otherdomain.com

Don't do that. It makes your Postfix accept email for
non-existent email addresses.

Instead, make explicit rules:

us...@host.otherdomain.com  us...@otherdomain.com
us...@host.otherdomain.com  us...@otherdomain.com
us...@host.otherdomain.com  us...@otherdomain.com

Wietse

Re: Address rewriting

[Robert Fitzpatrick]

Wietse Venema wrote:

Robert Fitzpatrick:

I have been using canonical_maps for some time to map local addresses,
but that doesn't seem to work for incoming mail. The message is coming
from another Postfix server with the sender specified with the hostname
of the machine


See http://www.postfix.org/postconf.html#local_header_rewrite_clients
for how to turn on header rewriting for email from outside.

Wietse


Perhaps I'm misunderstanding how it all works, very possible. I believe 
I follow how this works, but not sure how I can accomplish the rewrite I 
need of a remote sub-domain into the tld domain. It seems 
local_header_rewrite_clients only acts based on client IP? Even with the 
following in Postfix 2.11.x, I'm not able to get my canonical maps 
applied to messages from outside inet_interfaces or mynetworks...


local_header_rewrite_clients = static:all

I'm looking for a way to rewrite by name from any client. My canonical 
maps work great for mynetworks, would like to apply the same type 
rewrite to any message...


postmap -q u...@host.otherdomain.com 
ldap:/usr/local/etc/postfix/ldap/canonical.cf

@otherdomain.com

--
Robert

Re: Address rewriting

[Robert Fitzpatrick]

Wietse Venema wrote:

Robert Fitzpatrick:

I have been using canonical_maps for some time to map local addresses,
but that doesn't seem to work for incoming mail. The message is coming
from another Postfix server with the sender specified with the hostname
of the machine


See http://www.postfix.org/postconf.html#local_header_rewrite_clients
for how to turn on header rewriting for email from outside.

Wietse


Thanks Wietse! FYI - I got a 404 error on that URL you sent, but I found 
here...


http://www.postfix.org/postconf.5.html#local_header_rewrite_clients

--
Robert

Re: Address rewriting

[Wietse Venema]

Robert Fitzpatrick:
> I have been using canonical_maps for some time to map local addresses, 
> but that doesn't seem to work for incoming mail. The message is coming 
> from another Postfix server with the sender specified with the hostname 
> of the machine

See http://www.postfix.org/postconf.html#local_header_rewrite_clients
for how to turn on header rewriting for email from outside.

Wietse

Address rewriting

[Robert Fitzpatrick]

I have been using canonical_maps for some time to map local addresses, 
but that doesn't seem to work for incoming mail. The message is coming 
from another Postfix server with the sender specified with the hostname 
of the machine


Jul 6 08:35:34 mx1 postfix/smtpd[54573]: NOQUEUE: reject: RCPT from 
mail-by2nam03on0136.outbound.protection.outlook.com[104.47.42.136]: 450 
4.1.8 : Sender address rejected: Domain not 
found; from= to= 
proto=ESMTP helo=


What methods can be used strip the sub-domain and rewrite 
u...@other.theirdomain.com to u...@theirdomain.com?


-- Robert

Re: Postfix - SRS - Address rewriting

[Wietse Venema]

Pascal Maes:
> Hello,
> 
> 
> We are using the SRS mechanism to avoid problem with the SPF when
> we forward emails to external servers.
> 
> We have followed the documentation from postsrsd, in main.cf :

Suggestion: 

1) Open your preferred search engine.

2) Enter search terms: srs milter.

Wietse

Postfix - SRS - Address rewriting

[Pascal Maes]

Hello,


We are using the SRS mechanism to avoid problem with the SPF when we forward 
emails to external servers.

We have followed the documentation from postsrsd, in main.cf :


sender_canonical_maps = proxy:tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender

recipient_canonical_maps = proxy:tcp:127.0.0.1:10002
recipient_canonical_classes = envelope_recipient


but with that method, the addresses are rewritten when postfix receives the 
mail (cleanup) and it's more difficult to deal with : exceptions in MailScanner 
for exemple, logging...


It would be better if the envelope sender address was rewritten at the qmgr 
step but we don't find a way to do this, the smtp_generic_maps will rewrite 
both the envelope and the header address which should not be rewritten.


Is it possible ?
How ?


Thanks
-- 
Pascal

Re: virtual_alias_domains address rewriting?

[Jack Bates]

On 05/05/16 12:50 PM, Viktor Dukhovni wrote:

On Thu, May 05, 2016 at 12:04:09PM -0700, Jack Bates wrote:


Is there an address rewriting step that affects only virtual_alias_domains?


No.


The following achieved my desired behavior:

   virtual_alias_domains = nottheoilrig.com
   virtual_alias_maps = inline:{ @nottheoilrig.com=nottheoilrig }


You can similarly limit the domains in scope for lookup via the
"domain = ..." setting in ldap_table(5), mysql_table(5), pgsql_table(5),
...


Got it, thank you for these explanations!

Re: virtual_alias_domains address rewriting?

[Viktor Dukhovni]

On Thu, May 05, 2016 at 12:04:09PM -0700, Jack Bates wrote:

> Is there an address rewriting step that affects only virtual_alias_domains?

No.

> The following achieved my desired behavior:
> 
>   virtual_alias_domains = nottheoilrig.com
>   virtual_alias_maps = inline:{ @nottheoilrig.com=nottheoilrig }

You can similarly limit the domains in scope for lookup via the
"domain = ..." setting in ldap_table(5), mysql_table(5), pgsql_table(5),
...

-- 
Viktor.

Re: virtual_alias_domains address rewriting?

[Wietse Venema]

Jack Bates:
> Is there an address rewriting step that affects only virtual_alias_domains?

No, there is no address rewriting for virtual_alias_domains only
(or for relay_domains, or for virtual_mailbox_domains).

> I tried the following:
> 
>virtual_alias_domains = nottheoilrig.com
>virtual_alias_maps = static:nottheoilrig
> expecting to deliver all virtual_alias_domains mail to one user,
> and I was surprised when ALL mail was delivered to the user!

virtual_alias_maps is for all (recipient) email addresses.  In old
postfix versions the aliases and domains were listed in the same
table, and that was even more confusing.

> The following achieved my desired behavior:
> 
>virtual_alias_domains = nottheoilrig.com
>virtual_alias_maps = inline:{ @nottheoilrig.com=nottheoilrig }

Clever! The same could be done with a database file:

/etcpostfix/main.cf:
virtual_alias_domains = nottheoilrig.com
virtual_alias_maps = hash:/etc/postfix/virtual

/etc/postfix/virtual:
@nottheoilrig.com   nottheoilrig

But the inline version is fine for not too any entries.

Wietse

virtual_alias_domains address rewriting?

[Jack Bates]

Is there an address rewriting step that affects only virtual_alias_domains?

I tried the following:

  virtual_alias_domains = nottheoilrig.com
  virtual_alias_maps = static:nottheoilrig

expecting to deliver all virtual_alias_domains mail to one user,
and I was surprised when ALL mail was delivered to the user!

The following achieved my desired behavior:

  virtual_alias_domains = nottheoilrig.com
  virtual_alias_maps = inline:{ @nottheoilrig.com=nottheoilrig }

Recipient Address rewriting and Transport

[Rosenbaum, Larry M.]

I would like to do the following:  If the recipient is 
u...@mail.example.commailto:u...@mail.example.com, rewrite the address to 
u...@example.commailto:u...@example.com and relay it to server 
exch.example.com. How would we do this?

We are running Postfix 3.0.2 on RHEL6.

Thanks,
Larry

RE: Recipient Address rewriting and Transport

[Rosenbaum, Larry M.]

 From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
 On Mon, Aug 10, 2015 at 07:58:56PM +, Rosenbaum, Larry M. wrote:
 
  I would like to do the following:  If the recipient is
  u...@mail.example.com, rewrite the address to u...@example.com and relay
  it to server exch.example.com. How would we do this?
 
 http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual
 http://www.postfix.org/virtual.5.html
 http://www.postfix.org/postconf.5.html#virtual_alias_maps
 http://www.postfix.org/transport.5.html
 http://www.postfix.org/postconf.5.html#transport_maps
 http://www.postfix.org/postmap.1.html
 
   main.cf:
   indexed = ${default_database_type}:${config_directory}/
   virtual_alias_maps = ${indexed}virtual
   transport_maps = ${indexed}transport
 
   virtual:
   u...@mail.example.com  u...@example.com
 
   transport:
   example.com relay:[exch.example.com]
 
 You can use LDAP to do the rewriting:
 
   http://www.postfix.org/ldap_table.5.html
 
   main.cf:
   ldap = proxy:ldap:${config_directory}/
   virtual_alias_maps = ${ldap}virtual.cf
 
   virtual.cf (owner root, mode 0700):
   server_host = ldap.example.com
   search_base = dc=example,dc=com
   bind_dn = ... DN of some account object ...
   bind_pw = ... corresponding password ...
   query_filter = proxyAddresses = smtp:%s
   result_attribute = mail
 
 Test all mappings with postmap -q.

Thanks. One more thing - there will also be other mail with a @example.com 
address that does NOT go to exch.example.com - some will go to e.g. 
list.example.com, dept.example.com, etc. So it looks like the rewriting and the 
transport/relay stuff needs to happen at the same time. Is that possible?

Re: Recipient Address rewriting and Transport

[Viktor Dukhovni]

On Mon, Aug 10, 2015 at 08:50:22PM +, Rosenbaum, Larry M. wrote:

  main.cf:
  indexed = ${default_database_type}:${config_directory}/
  virtual_alias_maps = ${indexed}virtual
  transport_maps = ${indexed}transport
  
  virtual:
  u...@mail.example.com  u...@example.com
  
  transport:
  example.com relay:[exch.example.com]
  
  You can use LDAP to do the rewriting:
  
  http://www.postfix.org/ldap_table.5.html
  
  main.cf:
  ldap = proxy:ldap:${config_directory}/
  virtual_alias_maps = ${ldap}virtual.cf
  
  virtual.cf (owner root, mode 0700):
  server_host = ldap.example.com
  search_base = dc=example,dc=com
  bind_dn = ... DN of some account object ...
  bind_pw = ... corresponding password ...
  query_filter = proxyAddresses = smtp:%s
  result_attribute = mail
  
  Test all mappings with postmap -q.
 
 Thanks. One more thing - there will also be other mail with a @example.com
 address that does NOT go to exch.example.com - some will go to e.g.
 list.example.com, dept.example.com, etc. So it looks like the rewriting
 and the transport/relay stuff needs to happen at the same time. Is that
 possible?

Yes, but that is more complicated.  You can use per-user transport
mappings, either indexed file or LDAP equivalent:

transport:
u...@example.comrelay:[exch.example.com]

Or rewrite to destination-specific sub-domains:

virtual:
u...@mail.example.com  u...@exch.example.com

transport:
exch.example.com  relay:[exch.example.com]

Then, as a best-practice, add additional transport addresses to
each exchange user account:

mail: u...@example.com
proxyAddresses: SMTP:u...@example.com
proxyAddresses: smtp:u...@exch.example.com

but if that's just too difficult due to extreme bureaucratitis,
you can undo the rewrite during transmission via smtp_generic_maps

master.cf:
relay unix ... smtp
  -o smtp_generic_maps=$relay_generic_maps

main.cf:
indexed = ${default_database_type}:${config_directory}/
relay_generic_maps = ${indexed}relay-generic

relay-generic:
@exch.example.com   @example.com

-- 
Viktor.

RE: Recipient Address rewriting and Transport

[Rosenbaum, Larry M.]

 From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
 us...@postfix.org] On Behalf Of Viktor Dukhovni
 
 On Mon, Aug 10, 2015 at 08:50:22PM +, Rosenbaum, Larry M. wrote:
 
 main.cf:
 indexed = ${default_database_type}:${config_directory}/
 virtual_alias_maps = ${indexed}virtual
 transport_maps = ${indexed}transport
  
 virtual:
 u...@mail.example.com  u...@example.com
  
 transport:
 example.com relay:[exch.example.com]
  
   You can use LDAP to do the rewriting:
  
 http://www.postfix.org/ldap_table.5.html
  
 main.cf:
 ldap = proxy:ldap:${config_directory}/
 virtual_alias_maps = ${ldap}virtual.cf
  
 virtual.cf (owner root, mode 0700):
 server_host = ldap.example.com
 search_base = dc=example,dc=com
 bind_dn = ... DN of some account object ...
 bind_pw = ... corresponding password ...
 query_filter = proxyAddresses = smtp:%s
 result_attribute = mail
  
   Test all mappings with postmap -q.
 
  Thanks. One more thing - there will also be other mail with a
 @example.com
  address that does NOT go to exch.example.com - some will go to e.g.
  list.example.com, dept.example.com, etc. So it looks like the rewriting
  and the transport/relay stuff needs to happen at the same time. Is that
  possible?
 
 Yes, but that is more complicated.  You can use per-user transport
 mappings, either indexed file or LDAP equivalent:
 
 transport:
   u...@example.comrelay:[exch.example.com]
 
 Or rewrite to destination-specific sub-domains:
 
 virtual:
   u...@mail.example.com  u...@exch.example.com
 
 transport:
   exch.example.com  relay:[exch.example.com]
 
 Then, as a best-practice, add additional transport addresses to
 each exchange user account:
 
   mail: u...@example.com
   proxyAddresses: SMTP:u...@example.com
   proxyAddresses: smtp:u...@exch.example.com

We're trying to see if we can get rid of that second proxyAddress

 but if that's just too difficult due to extreme bureaucratitis,
 you can undo the rewrite during transmission via smtp_generic_maps
 
   master.cf:
   relay unix ... smtp
 -o smtp_generic_maps=$relay_generic_maps
 
   main.cf:
   indexed = ${default_database_type}:${config_directory}/
   relay_generic_maps = ${indexed}relay-generic
 
   relay-generic:
   @exch.example.com   @example.com
 

I think the smtp_generic_maps solution is going to work for us. Thanks.

Re: Recipient Address rewriting and Transport

[Viktor Dukhovni]

On Mon, Aug 10, 2015 at 09:46:33PM +, Rosenbaum, Larry M. wrote:

  Then, as a best-practice, add additional transport addresses to
  each exchange user account:
  
  mail: u...@example.com
  proxyAddresses: SMTP:u...@example.com
  proxyAddresses: smtp:u...@exch.example.com
 
 We're trying to see if we can get rid of that second proxyAddress

It is far better to keep it.

  but if that's just too difficult due to extreme bureaucratitis,
  you can undo the rewrite during transmission via smtp_generic_maps
  
  master.cf:
  relay unix ... smtp
-o smtp_generic_maps=$relay_generic_maps
  
  main.cf:
  indexed = ${default_database_type}:${config_directory}/
  relay_generic_maps = ${indexed}relay-generic
  
  relay-generic:
  @exch.example.com   @example.com
  
 
 I think the smtp_generic_maps solution is going to work for us. Thanks.

This is a hack, per-destination mailbox addresses are less likely
to loop, make logs less confusing, ...

If you already have secondary proxyAddresses, keep using them!

-- 
Viktor.

Re: Recipient Address rewriting and Transport

[Viktor Dukhovni]

On Mon, Aug 10, 2015 at 07:58:56PM +, Rosenbaum, Larry M. wrote:

 I would like to do the following:  If the recipient is
 u...@mail.example.com, rewrite the address to u...@example.com and relay
 it to server exch.example.com. How would we do this?

http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual
http://www.postfix.org/virtual.5.html
http://www.postfix.org/postconf.5.html#virtual_alias_maps
http://www.postfix.org/transport.5.html
http://www.postfix.org/postconf.5.html#transport_maps
http://www.postfix.org/postmap.1.html

main.cf:
indexed = ${default_database_type}:${config_directory}/
virtual_alias_maps = ${indexed}virtual
transport_maps = ${indexed}transport

virtual:
u...@mail.example.com  u...@example.com

transport:
example.com relay:[exch.example.com]

You can use LDAP to do the rewriting:

http://www.postfix.org/ldap_table.5.html

main.cf:
ldap = proxy:ldap:${config_directory}/
virtual_alias_maps = ${ldap}virtual.cf

virtual.cf (owner root, mode 0700):
server_host = ldap.example.com
search_base = dc=example,dc=com
bind_dn = ... DN of some account object ...
bind_pw = ... corresponding password ...
query_filter = proxyAddresses = smtp:%s
result_attribute = mail

Test all mappings with postmap -q.

-- 
Viktor.

postfix, address rewriting and bcc maps

[Koldo Navarro]

Hello,

I am setting up an email server using postfix.

I use an internal domain for internal mails, and address rewriting for
outgoing emails. In main.cf, the parameter

smtp_generic_maps = hash:/etc/postfix/generic

and a file generic with lines like this:

user@mycompany.localextern_u...@mydomain.com

As fas as I know, it works, since outgoing emails are sent with the right
sender's external address.

I also use sender_bcc_maps to send a copy of all outgoing emails. In main.cf,
the parameter

sender_bcc_maps = hash:/etc/postfix/sender

and a file sender with lines like this:

extern_u...@mydomain.comto_copy@mycompany.local

I am pretty sure that this mechanism worked for a time, but I recently
noticed that it isn't working anymore.

The problem is that the address rewriting sets the sender's external
address AFTER the sender_bcc_maps adds the bcc destinations. So,

it never detects an email from @mycompany.com, because all of them are sent
by @mycompany.local.

I'm looking for a way to have a copy of outgoing emails and sender's
address rewriting at the same time. I have already tried using

regular expressions, but I have failed so far (i am still trying though).

Any ideas will be welcome.

Thank you indeed.

Address Rewriting vs Aliasing - I need all recipients to see each other

[Charles Marcus]

Hi all,

I'm under the gun, and reading furiously, but I'm hoping someone will 
help point me in the right direction...


I want to set up an email alias for my domain, ie:

facilit...@example.com

That sends the email to two (or more) external addresses:

us...@example2.com
us...@example2.com

Currently, if I set up the alias, each recipient only sees themselves as 
the recipient, but I need all recipients to see each other, so each 
knows the other received it.


I would prefer they not see the original alias, but it isn't that important.

I'd also like for one the be added as 'To:', and the other as 'CC:', but 
again, not really that important, as long as they will each see the 
other got it.


I'm guessing I need to use Address Rewriting rather than just an alias, 
but I'm not sure which method or how to accomplish it.


Thanks,

Charles

Re: Address Rewriting vs Aliasing - I need all recipients to see each other

[Dominik George]

Hi Charles,

 Currently, if I set up the alias, each recipient only sees
 themselves as the recipient, but I need all recipients to see each
 other, so each knows the other received it.

I do not quite understand that. Normally, when you use a simple alias,
no adresses are rewritten, so the original headers should be preserved -
resulting in all recipients seeing the alias rather than any of the
resulting addresses.

Maybe there are canonical rewrites in place somewhere already?

Cheers,
Nik

-- 
* concerning Mozilla code leaking assertion failures to tty without D-BUS *
mirabilos That means, D-BUS is a tool that makes software look better
than it actually is.

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296


signature.asc
Description: Digital signature

Re: Address Rewriting vs Aliasing - I need all recipients to see each other

[Charles Marcus]

Thanks for the reply Dominik, but...

On 2014-02-02 9:17 AM, Dominik George n...@naturalnet.de wrote:

Currently, if I set up the alias, each recipient only sees
themselves as the recipient, but I need all recipients to see each
other, so each knows the other received it.



I do not quite understand that. Normally, when you use a simple alias,
no adresses are rewritten, so the original headers should be preserved -
resulting in all recipients seeing the alias rather than any of the
resulting addresses.


That is precisely what is happening with my normal alias - but as I said 
in my email, that is NOT what I want.


I WANT each recipient to see ALL of the other recipients (I honestly 
don't see how that was unclear)...


Also - why did I receive no less than three copies of your email? Please 
keep traffic on list, and I don't need to be CC'd, as I'm on the list.


Thanks again,

--

Best regards,

Charles

Re: Address Rewriting vs Aliasing - I need all recipients to see each other

[Viktor Dukhovni]

On Sun, Feb 02, 2014 at 09:06:03AM -0500, Charles Marcus wrote:

 I want to set up an email alias for my domain, ie:
 
 facilit...@example.com
 
 That sends the email to two (or more) external addresses:
 
 us...@example2.com
 us...@example2.com
 
 Currently, if I set up the alias, each recipient only sees
 themselves as the recipient,

How's that done?  Generally, the message headers are unchanged and
all you see is the alias.  So not sure what you mean by only
sees themselves.

 but I need all recipients to see each
 other, so each knows the other received it.

s/received it/was another recipient/

 I'd also like for one the be added as 'To:', and the other as 'CC:',
 but again, not really that important, as long as they will each see
 the other got it.

They can't know the other recipient got the message, they can only
know that it was alleged to have been sent to the other recipient,
and for this it is sufficient for them to know that they're both
targets of the alias.  The requirement you have is rather strange,
it appears to be appeasing someone's confusion rather than enlightened
interest.

All that said, Postfix has no facilities for 1-to-many header
recipient rewriting.  This would need to be done via procmail
or other external filter.

-- 
Viktor.

Postmaster address rewriting in bounce mail header

[robby]

Hi,

I'm using the latest version of postfix on Debian 6. I'm using an email
application to send mailings which automatically handles bounces through a
pipe php script. I have successfully setup a mail alias for postmaster to
the pipe script.
However in the bounce emails the To field in the mail header contains
postmaster. The email application requires the To field to be a valid
email address like postmaster@domain. 

Is it possible to change this in Postfix ?

Thx
Robby



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Postmaster-address-rewriting-in-bounce-mail-header-tp61428.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Postmaster address rewriting in bounce mail header

[Wietse Venema]

robby:
 Hi,
 
 I'm using the latest version of postfix on Debian 6. I'm using an email
 application to send mailings which automatically handles bounces through a
 pipe php script. I have successfully setup a mail alias for postmaster to
 the pipe script.

Please don't solve the wrong problem.

You must send mail with the correct envelope sender address, and
handle delivery notifications sent to that address (not postmaster).

With SMTP, the envelope sender is the address in the MAIL FROM
command; with /usr/sbin/sendmail, that's the address specified with
the -f command-line option.

Wietse

Address Rewriting

[test test]

Hi,



I have a setup with several virtual mailboxes, e.g. local1@, local2@.



Now I would like the local mail addresses to have some kind of mapping to external addresses:

local1@postfixserver - external1@externaldomain1

local2@postfixserver - external2@externaldomain2



If a mail arrives at postfix from external2 to recipient local1, I would like the following to happen: The mail should be forwarded with sender local2@ to recipient external1@ .

So incoming header looks like this: from external2, to local1

Outgoing header looks liks this: from local2, to external1



Does anyone know, if I can achieve this with postfix?



E.g. with some address rewriting feature? http://www.postfix.org/ADDRESS_REWRITING_README.html

I am very new to postfix, so I dont completely understand the manual here. I could imagine, that I need to put the mapping local-external into some configuration file?



I could imagine, that for incoming mails, adress rewriting will be done for the sender: if external2@externaldomain2 is found as sender, then sender will be rewritten to local2.

And for all incoming mails to local1 a copy is forwarded to external1



Kind Regards

Henning

Aw: Address Rewriting

[Henning]

Sorry, my last mail was Html only. I hope it's better now :-)

Hi,
 
I have a setup with several virtual mailboxes, e.g. local1@, local2@.
 
Now I would like the local mail addresses to have some kind of mapping to 
external addresses:
local1@postfixserver - external1@externaldomain1
local2@postfixserver - external2@externaldomain2
 
If a mail arrives at postfix from external2 to recipient local1, I would like 
the following to happen: The mail should be forwarded with sender local2@ to 
recipient external1@ .
So incoming header looks like this: from external2, to local1
Outgoing header looks liks this: from local2, to external1
 
Does anyone know, if I can achieve this with postfix?
 
E.g. with some address rewriting feature? 
http://www.postfix.org/ADDRESS_REWRITING_README.html
I am very new to postfix, so I don't completely understand the manual here.  I 
could imagine, that I need to put the mapping local-external into some 
configuration file?
 
I could imagine, that for incoming mails, adress rewriting will be done for the 
sender: if external2@externaldomain2 is found as sender, then sender will be 
rewritten to local2.
And for all incoming mails to local1 a copy is forwarded to external1
 
Kind Regards
Henning

Address rewriting

[lutz . niederer]

Hi!

We do have several domains listed with mydomains.  The users are the same for 
all domains and exist locally, means mail gets delivered locally.  Aliases file 
is used to expand to lists of recipients.  This works ok and we only have one 
set of files (aliases) that works for all domains.

We will now add another domain.  All users are again local and are the same as 
with the domains above.  All domains use info@ and contact@ and deliver to the 
same group of recipients.
Now for this one domain info@ and contact@ should be delivered to other users.  
It would be great if we could write the following into the aliases file (I know 
it does not work):
info: user1, user2
contact: user3, user4
info@this_other_domain.com: john, jane
contact@this_other_domain.com: john, pete

Can we use virtual_alias_maps for this?  Without using virtual_alias_domains?  
Is there still a processing of aliases file?  Is that before or after 
virtual_aliases_maps?

Is virtual_aliases_maps the correct way to handle these two exceptions or would 
you do it another and better way?

Thanks,
-lutzn

Re: Address rewriting

[Noel Jones]

On 7/19/2012 4:11 PM, lutz.niede...@gmx.net wrote:
 Hi!
 
 We do have several domains listed with mydomains.  The users are the same for 
 all domains and exist locally, means mail gets delivered locally.  Aliases 
 file is used to expand to lists of recipients.  This works ok and we only 
 have one set of files (aliases) that works for all domains.
 
 We will now add another domain.  All users are again local and are the same 
 as with the domains above.  All domains use info@ and contact@ and deliver to 
 the same group of recipients.
 Now for this one domain info@ and contact@ should be delivered to other 
 users.  It would be great if we could write the following into the aliases 
 file (I know it does not work):
 info: user1, user2
 contact: user3, user4
 info@this_other_domain.com: john, jane
 contact@this_other_domain.com: john, pete
 
 Can we use virtual_alias_maps for this?  Without using virtual_alias_domains? 
  Is there still a processing of aliases file?  Is that before or after 
 virtual_aliases_maps?
 
 Is virtual_aliases_maps the correct way to handle these two exceptions or 
 would you do it another and better way?
 
 Thanks,
 -lutzn
 
 


Yes, virtual_alias_maps is the correct solution for general-purpose
address rewriting.  The domain does not need to be listed in
virtual_alias_domains.

In general, it's good practice to always use address@domain rather
than just bare usernames in virtual_alias_maps:
i...@example.com   user1@localhost, us...@hotmail.com
Note there is no : separator used in this file.

If the rewritten address is delivered locally, that address will
then be subject to rewriting by the usual aliases file.


http://www.postfix.org/ADDRESS_REWRITING_README.html
http://www.postfix.org/OVERVIEW.html



  -- Noel Jones

Re: address rewriting

[dino muzic]

1) inside server = postfix = outside 

works fine!


2) outside = postfix = inside server
doesn't, because generic is rewriting user1@mydomain.local back to 
us...@mydomain.com before relaying it to inside server

how can I disable generic on incoming mail?

thanks
dm



 From: Wietse Venema wie...@porcupine.org
To: Postfix users postfix-users@postfix.org 
Sent: Saturday, March 3, 2012 3:55 PM
Subject: Re: address rewriting
 
dino muzic:
 how can I do this? 
1) inside server = postfix = outside:
from:user1@mydomain.local? to:us...@yahoo.com??= POSTFIX =
from:us...@mydomain.com to:us...@yahoo.com ?

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

2) outside = postfix = inside server
from:us...@yahoo.com to:us...@mydomain.com = POSTFIX =
from:us...@yahoo.com? to:user1@mydomain.local

http://www.postfix.org/virtual.5.html

    Wietse

Re: address rewriting

[/dev/rob0]

Please do not top-post your replies. Thank you.

On Sun, Mar 04, 2012 at 05:17:30AM -0800, dino muzic wrote:
 1) inside server = postfix = outside 
 
 works fine!
 
 
 2) outside = postfix = inside server

What is this inside server? What is the role of Postfix supposed to 
be? Perhaps you don't even need it?

 doesn't, because generic is rewriting user1@mydomain.local back
 to us...@mydomain.com before relaying it to inside server
 
 how can I disable generic on incoming mail?

Our ability to guess exactly what is happening is somewhat limited. 
You could eliminate the need to guess by complying with these 
guidelines for posting here:

http://www.postfix.org/DEBUG_README.html#mail
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if /dev/rob0 is in the Subject:

Re: address rewriting

[Wietse Venema]

dino muzic:
 2) outside = postfix = inside server
 doesn't, because generic is rewriting user1@mydomain.local back
 to us...@mydomain.com before relaying it to inside server

Postfix uses different SMTP mail delivery agents for inbound mail
and outbound.

If the destination is in relay_domains, Postfix uses the relay
service in master.cf. This is what you should use for inbound
mail.

If the destination is NOT in relay_domains, Postfix uses the smtp
service in master.cf. This is what you should use for outbound
mail.

Therefore, you must apply generic mapping ONLY on the smtp service,
not on the relay service.

/etc/postfix/master.cf:
smtp  unix  -   -   n   -   -   smtp
-o smtp_generic_maps=maptype:mapname
relay unix  -   -   n   -   -   smtp

Wietse

Re: address rewriting

[dino muzic]

Thanks Wietse!

it works!


dm



 From: Wietse Venema wie...@porcupine.org
To: Postfix users postfix-users@postfix.org 
Sent: Sunday, March 4, 2012 3:14 PM
Subject: Re: address rewriting
 
dino muzic:
 2) outside = postfix = inside server
 doesn't, because generic is rewriting user1@mydomain.local back
 to us...@mydomain.com before relaying it to inside server

Postfix uses different SMTP mail delivery agents for inbound mail
and outbound.

If the destination is in relay_domains, Postfix uses the relay
service in master.cf. This is what you should use for inbound
mail.

If the destination is NOT in relay_domains, Postfix uses the smtp
service in master.cf. This is what you should use for outbound
mail.

Therefore, you must apply generic mapping ONLY on the smtp service,
not on the relay service.

/etc/postfix/master.cf:
    smtp      unix  -       -       n       -       -       smtp
    -o smtp_generic_maps=maptype:mapname
    relay     unix  -       -       n       -       -       smtp

    Wietse

address rewriting

[dino muzic]

how can I do this? 
 
1) inside server = postfix = outside:
from:user1@mydomain.local  to:us...@yahoo.com  = POSTFIX = 
from:us...@mydomain.com to:us...@yahoo.com 
 
2) outside = postfix = inside server
from:us...@yahoo.com to:us...@mydomain.com = POSTFIX = from:us...@yahoo.com  
to:user1@mydomain.local
 
 
thanks
 
dino muzic

Re: address rewriting

[Wietse Venema]

dino muzic:
 how can I do this? 
1) inside server = postfix = outside:
from:user1@mydomain.local? to:us...@yahoo.com??= POSTFIX =
from:us...@mydomain.com to:us...@yahoo.com ?

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

2) outside = postfix = inside server
from:us...@yahoo.com to:us...@mydomain.com = POSTFIX =
from:us...@yahoo.com? to:user1@mydomain.local

http://www.postfix.org/virtual.5.html

Wietse

postfix as relay and address rewriting

[dino muzic]

hi,
 
have basic question to ask. how can I rewrite recipient address from 
u...@outside.com to u...@inside.com?
my configuration consists of internal mail server (@inside.com) and postfix 
relay situated in between internal lan and isp.
I have already configured postfix for outbound address rewriting :  
u...@inside.com = internal server = postfix = u...@outside.com, 
but I can't figure out how to do it in reverse!
 
 
 
any help will be greatly appreciated
 
thanks
 
dino muzic

Re: postfix as relay and address rewriting

[Noel Jones]

On 2/28/2012 10:50 AM, dino muzic wrote:
 hi,
  
 have basic question to ask. how can I rewrite recipient address from
 u...@outside.com to u...@inside.com?
 my configuration consists of internal mail server (@inside.com) and
 postfix relay situated in between internal lan and isp.
 I have already configured postfix for outbound address rewriting : 
 u...@inside.com = internal mailto:u...@inside.com = internal
 server = postfix = u...@outside.com mailto:u...@outside.com,
 but I can't figure out how to do it in reverse!
  
  
  
 any help will be greatly appreciated
  
 thanks
  
 dino muzic
  
  


Typically one would use virtual_alias_maps to rewrite the outside
address to an inside address, and canonical_maps to rewrite inside
to outside.
http://www.postfix.org/ADDRESS_REWRITING_README.html



  -- Noel Jones

Re: Many to one address rewriting, exceptions exist.

[Wietse Venema]

Noel Jones:
 On 9/26/2011 3:12 PM, Wietse Venema wrote:
  Randy Ramsdell:
  /etc/postfix/virtual:
#f...@example.com  stays itself.
f...@example.com f...@example.com
 
#b...@example.com  goes elsewhere.
b...@example.com other@elsewhere
 
  /etc/postfix/virtual.pcre:
# Everything else goes to the mailsink.
/./  mails...@example.net
 
  ?
  
  Plus the portion of my example that you left out, and that lists
  the PCRE file last in the virtual_alias_maps settings.
  
  Wietse
 
 
 But don't we need an identity 1-1 mapping in the hash file for
 other@elsewhere so the pcre /./ catchall doesn't rewrite it also?

I suppose it does. No 1-1 mapping is needed for mails...@example.net.
(I started from an example that wild-carded @example.com not /./).

Wietse

Re: Many to one address rewriting, exceptions exist.

[Randy Ramsdell]

On 09/26/11 16:12, Wietse Venema wrote:

Randy Ramsdell:
[ Charset ISO-8859-1 unsupported, converting... ]

On 09/26/11 14:36, Noel Jones wrote:

On 9/26/2011 1:31 PM, Randy Ramsdell wrote:

On 09/26/11 14:18, Noel Jones wrote:

On 9/26/2011 1:00 PM, Randy Ramsdell wrote:

On 09/22/11 13:45, Randy Ramsdell wrote:

I cannot find the the way to grab all to's rewritten to go to a
single to:. We need to send all mail coming out of our QA
environment and send that to a single, probably, local address.
The list of senders will be in the thousands and so using a
catchall for these has to be configured.

We will also select a few to's where we send these off as normal.

No external to our network mail we need to be routed.

So far I read about transport maps and the address rewriting but
don't see a way or the best way to accomplish this.

Advice appreciated,
Randy Ramsdell

When virtual_alias_maps using two maps as suggested.

virtual_alias_maps =
   hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre

This has order correct ?i.e As in the maps are checked sequentially?



The maps are checked sequentially and recursively. Recursion stops
when the result is the same as the input key or not found.

For this application, you would need 1-1 identity mappings in the
hash file, and a catchall in the pcre.


 -- Noel Jones

r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual
real@madeupdomain rramsdell@nonlocaldomain

need to add an identity mapping to the hash file:

rramsdell@nonlocaldomain   rramsdell@nonlocaldomain






r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual.pcre
/./ itstaff


This per Wietse.

Debug :

Sep 26 13:54:43 mail1-test postfix/smtpd[6842]: maps_find:
virtual_alias_maps: hash:/etc/postfix/virtual(0,lock|fold_fix):
real@madeupdomain = rramsdell@nonlocaldomain

. . .

Sep 26 13:54:53 mail1-test postfix/local[6848]: C311517A7BF:
to=itst...@mail1.dfb.qa.vn, orig_to=real@madeupdomain,
relay=local, delay=19, delays=19/0/0/0.05, dsn=2.0.0, status=sent
(delivered to maildir)

This looks like it matches virtual and then applies the pcre virtual.



Yes, that's what recursion does.




-- Noel Jones

/etc/postfix/virtual:
   #f...@example.com  stays itself.
   f...@example.com f...@example.com

   #b...@example.com  goes elsewhere.
   b...@example.com other@elsewhere

/etc/postfix/virtual.pcre:
   # Everything else goes to the mailsink.
   /./  mails...@example.net

?

Plus the portion of my example that you left out, and that lists
the PCRE file last in the virtual_alias_maps settings.

Wietse

virtual_alias_maps =
hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre

Has been this way since I started with your example.

Re: Many to one address rewriting, exceptions exist.

[Noel Jones]

On 9/27/2011 8:03 AM, Randy Ramsdell wrote:
 /etc/postfix/virtual:
#f...@example.com  stays itself.
f...@example.comf...@example.com

#b...@example.com  goes elsewhere.
b...@example.comother@elsewhere

 /etc/postfix/virtual.pcre:
# Everything else goes to the mailsink.
/./mails...@example.net

 ?
 Plus the portion of my example that you left out, and that lists
 the PCRE file last in the virtual_alias_maps settings.

 Wietse
 virtual_alias_maps =
 hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre
 
 Has been this way since I started with your example.
 
 


When you have a /./ catchall, you need an identity mapping in the
hash file for every user to keep the catchall from grabbing it.

In your example above, you would add
   other@elsewhere   other@elsewhere
to your hash file.

Wietse's examples started out with just aliasing @example.com and
not the whole world.  In the case of aliasing only @example.com, no
identity mapping would be needed for @elsewhere as it wouldn't match
the domain wildcard.  But you're using a global wildcard, not just a
domain wildcard.


  -- Noel Jones

Re: Many to one address rewriting, exceptions exist.

[Randy Ramsdell]

On 09/27/11 09:33, Noel Jones wrote:

On 9/27/2011 8:03 AM, Randy Ramsdell wrote:

/etc/postfix/virtual:
#f...@example.com  stays itself.
f...@example.comf...@example.com

#b...@example.com  goes elsewhere.
b...@example.comother@elsewhere

/etc/postfix/virtual.pcre:
# Everything else goes to the mailsink.
/./mails...@example.net

?

Plus the portion of my example that you left out, and that lists
the PCRE file last in the virtual_alias_maps settings.

 Wietse

virtual_alias_maps =
 hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre

Has been this way since I started with your example.




When you have a /./ catchall, you need an identity mapping in the
hash file for every user to keep the catchall from grabbing it.

In your example above, you would add
other@elsewhere   other@elsewhere
to your hash file.

Wietse's examples started out with just aliasing @example.com and
not the whole world.  In the case of aliasing only @example.com, no
identity mapping would be needed for @elsewhere as it wouldn't match
the domain wildcard.  But you're using a global wildcard, not just a
domain wildcard.


   -- Noel Jones
Okay. Tried so many iterations of this also had another person try 
without success.


CONFIGS:

r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual
r...@mail1.dfb.qa.vnrramsdell@elsewhere

r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual.pcre
/rramsdell\@elsewhere/  rramsdell@elsewhere
/./ itstaff

r...@mail1-test.dfb.qa.vn:/etc/postfix # cat main.cf | grep virtual.pcre
virtual_alias_maps = hash:/etc/postfix/virtual 
pcre:/etc/postfix/virtual.pcre


TESTING

r...@mail1-test.dfb.qa.vn:/etc/postfix # telnet 192.168.21.31 25
Trying 192.168.21.31...
Connected to 192.168.21.31.
Escape character is '^]'.
220 mail1.dfb.qa.vn ESMTP Postfix
helo rramsdell
250 mail1.dfb.qa.vn
mail from: rramsd...@elsewhere.com
250 2.1.0 Ok
rcpt to: r...@mail1.dfb.qa.vn
250 2.1.5 Ok
data
354 End data with CRLF.CRLF
.
250 2.0.0 Ok: queued as 6252A17A809


RESULT

Sep 27 12:25:38 mail1-test postfix/smtpd[16575]: 6252A17A809: 
client=mail1-test.dfb.qa.vn[192.168.21.31]
Sep 27 12:25:42 mail1-test postfix/cleanup[16592]: 6252A17A809: 
message-id=20110927162538.6252a17a...@mail1.dfb.qa.vn
Sep 27 12:25:42 mail1-test postfix/qmgr[16563]: 6252A17A809: 
from=rramsdell@elsewhere, size=352, nrcpt=1 (queue active)
Sep 27 12:25:42 mail1-test postfix/error[16593]: 6252A17A809: 
to=rramsdell@elsewhere, orig_to=r...@mail1.dfb.qa.vn, relay=none, 
delay=25, delays=25/0/0/0.03, dsn=5.0.0, status=bounced (User unknown in 
virtual alias table)
Sep 27 12:25:42 mail1-test postfix/cleanup[16592]: A556C17A810: 
message-id=20110927162542.a556c17a...@mail1.dfb.qa.vn
Sep 27 12:25:42 mail1-test postfix/qmgr[16563]: A556C17A810: from=, 
size=2208, nrcpt=1 (queue active)
Sep 27 12:25:42 mail1-test postfix/bounce[16594]: 6252A17A809: sender 
non-delivery notification: A556C17A810

Sep 27 12:25:42 mail1-test postfix/qmgr[16563]: 6252A17A809: removed
Sep 27 12:25:42 mail1-test postfix/error[16593]: A556C17A810: 
to=rramsdell@elsewhere, relay=none, delay=0.06, delays=0.03/0/0/0.03, 
dsn=5.0.0, status=bounced (User unknown in virtual alias table)

Sep 27 12:25:42 mail1-test postfix/qmgr[16563]: A556C17A810: removed

POSTCONF

r...@mail1-test.dfb.qa.vn:/etc/postfix # postconf -n
biff = no
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter =
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
defer_transports =
delay_warning_time = 1h
disable_dns_lookups = no
disable_mime_output_conversion = no
home_mailbox = Maildir/
html_directory = /usr/share/doc/packages/postfix-doc/html
inet_interfaces = all
inet_protocols = all
mail_owner = postfix
mail_spool_directory = /var/mail
mailbox_command =
mailbox_size_limit = 0
mailbox_transport =
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_domains =
masquerade_exceptions = root
message_size_limit = 0
message_strip_characters = \0
mydestination = $myhostname, localhost.$mydomain
myhostname = mail1.dfb.qa.vn
mynetworks = 192.168.21.0/24 127.0.0.0/8
mynetworks_style = subnet
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
relocated_maps = hash:/etc/postfix/relocated
sample_directory = /usr/share/doc/packages/postfix-doc/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtp_enforce_tls = no
smtp_sasl_auth_enable = no
smtp_use_tls = no
smtpd_client_restrictions =
smtpd_helo_required = no
smtpd_helo_restrictions =
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
smtpd_sasl_auth_enable = no
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_use_tls = no
strict_8bitmime = no

Re: Many to one address rewriting, exceptions exist.

[Wietse Venema]

Randy Ramsdell:
 Sep 27 12:25:42 mail1-test postfix/error[16593]: 6252A17A809: 
 to=rramsdell@elsewhere, orig_to=r...@mail1.dfb.qa.vn, relay=none, 
 delay=25, delays=25/0/0/0.03, dsn=5.0.0, status=bounced (User unknown in 
 virtual alias table)

You need to override the virtual_alias_domains default setting.

/etc/postfix/main.cf:
virtual_alias_domains =

Otherwise, your /./ wildcard will match all domains.

virtual_alias_domains requires that the address is rewritten to a
different domain, otherwise it reports user unknown in virtual
alias table.

Wietse

Re: Many to one address rewriting, exceptions exist.

[Randy Ramsdell]

On 09/22/11 13:45, Randy Ramsdell wrote:
I cannot find the the way to grab all to's rewritten to go to a 
single to:. We need to send all mail coming out of our QA 
environment and send that to a single, probably, local address. The 
list of senders will be in the thousands and so using a catchall for 
these has to be configured.


We will also select a few to's where we send these off as normal.

No external to our network mail we need to be routed.

So far I read about transport maps and the address rewriting but don't 
see a way or the best way to accomplish this.


Advice appreciated,
Randy Ramsdell


When virtual_alias_maps using two maps as suggested.

virtual_alias_maps =
hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre

This has order correct ?i.e As in the maps are checked sequentially?

Re: Many to one address rewriting, exceptions exist.

[Noel Jones]

On 9/26/2011 1:00 PM, Randy Ramsdell wrote:
 On 09/22/11 13:45, Randy Ramsdell wrote:
 I cannot find the the way to grab all to's rewritten to go to a
 single to:. We need to send all mail coming out of our QA
 environment and send that to a single, probably, local address.
 The list of senders will be in the thousands and so using a
 catchall for these has to be configured.

 We will also select a few to's where we send these off as normal.

 No external to our network mail we need to be routed.

 So far I read about transport maps and the address rewriting but
 don't see a way or the best way to accomplish this.

 Advice appreciated,
 Randy Ramsdell
 
 When virtual_alias_maps using two maps as suggested.
 
 virtual_alias_maps =
 hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre
 
 This has order correct ?i.e As in the maps are checked sequentially?
 
 


The maps are checked sequentially and recursively. Recursion stops
when the result is the same as the input key or not found.

For this application, you would need 1-1 identity mappings in the
hash file, and a catchall in the pcre.


  -- Noel Jones

Re: Many to one address rewriting, exceptions exist.

[Noel Jones]

On 9/26/2011 1:18 PM, Noel Jones wrote:
 On 9/26/2011 1:00 PM, Randy Ramsdell wrote:
 On 09/22/11 13:45, Randy Ramsdell wrote:
 I cannot find the the way to grab all to's rewritten to go to a
 single to:. We need to send all mail coming out of our QA
 environment and send that to a single, probably, local address.
 The list of senders will be in the thousands and so using a
 catchall for these has to be configured.

 We will also select a few to's where we send these off as normal.

 No external to our network mail we need to be routed.

 So far I read about transport maps and the address rewriting but
 don't see a way or the best way to accomplish this.

 Advice appreciated,
 Randy Ramsdell

 When virtual_alias_maps using two maps as suggested.

 virtual_alias_maps =
 hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre

 This has order correct ?i.e As in the maps are checked sequentially?


 
 
 The maps are checked sequentially and recursively. Recursion stops
 when the result is the same as the input key or not found.

Before someone gets the wrong idea, I should clarify that recursion
is a feature of virtual_alias_maps and not a general feature.  Maps
that are searched recursively are so noted in the docs.


  -- Noel Jones

 
 For this application, you would need 1-1 identity mappings in the
 hash file, and a catchall in the pcre.
 
 
   -- Noel Jones

Re: Many to one address rewriting, exceptions exist.

[Randy Ramsdell]

On 09/26/11 14:18, Noel Jones wrote:

On 9/26/2011 1:00 PM, Randy Ramsdell wrote:

On 09/22/11 13:45, Randy Ramsdell wrote:

I cannot find the the way to grab all to's rewritten to go to a
single to:. We need to send all mail coming out of our QA
environment and send that to a single, probably, local address.
The list of senders will be in the thousands and so using a
catchall for these has to be configured.

We will also select a few to's where we send these off as normal.

No external to our network mail we need to be routed.

So far I read about transport maps and the address rewriting but
don't see a way or the best way to accomplish this.

Advice appreciated,
Randy Ramsdell

When virtual_alias_maps using two maps as suggested.

virtual_alias_maps =
 hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre

This has order correct ?i.e As in the maps are checked sequentially?




The maps are checked sequentially and recursively. Recursion stops
when the result is the same as the input key or not found.

For this application, you would need 1-1 identity mappings in the
hash file, and a catchall in the pcre.


   -- Noel Jones


r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual
real@madeupdomain rramsdell@nonlocaldomain


r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual.pcre
/./ itstaff


This per Wietse.

Debug :

Sep 26 13:54:43 mail1-test postfix/smtpd[6842]: maps_find: 
virtual_alias_maps: hash:/etc/postfix/virtual(0,lock|fold_fix): 
real@madeupdomain = rramsdell@nonlocaldomain


. . .

Sep 26 13:54:53 mail1-test postfix/local[6848]: C311517A7BF: 
to=itst...@mail1.dfb.qa.vn, orig_to=real@madeupdomain, relay=local, 
delay=19, delays=19/0/0/0.05, dsn=2.0.0, status=sent (delivered to maildir)


This looks like it matches virtual and then applies the pcre virtual.

Re: Many to one address rewriting, exceptions exist.

[Noel Jones]

On 9/26/2011 1:31 PM, Randy Ramsdell wrote:
 On 09/26/11 14:18, Noel Jones wrote:
 On 9/26/2011 1:00 PM, Randy Ramsdell wrote:
 On 09/22/11 13:45, Randy Ramsdell wrote:
 I cannot find the the way to grab all to's rewritten to go to a
 single to:. We need to send all mail coming out of our QA
 environment and send that to a single, probably, local address.
 The list of senders will be in the thousands and so using a
 catchall for these has to be configured.

 We will also select a few to's where we send these off as normal.

 No external to our network mail we need to be routed.

 So far I read about transport maps and the address rewriting but
 don't see a way or the best way to accomplish this.

 Advice appreciated,
 Randy Ramsdell
 When virtual_alias_maps using two maps as suggested.

 virtual_alias_maps =
  hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre

 This has order correct ?i.e As in the maps are checked sequentially?



 The maps are checked sequentially and recursively. Recursion stops
 when the result is the same as the input key or not found.

 For this application, you would need 1-1 identity mappings in the
 hash file, and a catchall in the pcre.


-- Noel Jones
 
 r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual
 real@madeupdomain rramsdell@nonlocaldomain

need to add an identity mapping to the hash file:

rramsdell@nonlocaldomain   rramsdell@nonlocaldomain





 
 
 r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual.pcre
 /./ itstaff
 
 
 This per Wietse.
 
 Debug :
 
 Sep 26 13:54:43 mail1-test postfix/smtpd[6842]: maps_find:
 virtual_alias_maps: hash:/etc/postfix/virtual(0,lock|fold_fix):
 real@madeupdomain = rramsdell@nonlocaldomain
 
 . . .
 
 Sep 26 13:54:53 mail1-test postfix/local[6848]: C311517A7BF:
 to=itst...@mail1.dfb.qa.vn, orig_to=real@madeupdomain,
 relay=local, delay=19, delays=19/0/0/0.05, dsn=2.0.0, status=sent
 (delivered to maildir)
 
 This looks like it matches virtual and then applies the pcre virtual.
 
 

Yes, that's what recursion does.




  -- Noel Jones

Re: Many to one address rewriting, exceptions exist.

[Randy Ramsdell]

On 09/26/11 14:36, Noel Jones wrote:

On 9/26/2011 1:31 PM, Randy Ramsdell wrote:

On 09/26/11 14:18, Noel Jones wrote:

On 9/26/2011 1:00 PM, Randy Ramsdell wrote:

On 09/22/11 13:45, Randy Ramsdell wrote:

I cannot find the the way to grab all to's rewritten to go to a
single to:. We need to send all mail coming out of our QA
environment and send that to a single, probably, local address.
The list of senders will be in the thousands and so using a
catchall for these has to be configured.

We will also select a few to's where we send these off as normal.

No external to our network mail we need to be routed.

So far I read about transport maps and the address rewriting but
don't see a way or the best way to accomplish this.

Advice appreciated,
Randy Ramsdell

When virtual_alias_maps using two maps as suggested.

virtual_alias_maps =
  hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre

This has order correct ?i.e As in the maps are checked sequentially?



The maps are checked sequentially and recursively. Recursion stops
when the result is the same as the input key or not found.

For this application, you would need 1-1 identity mappings in the
hash file, and a catchall in the pcre.


-- Noel Jones

r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual
real@madeupdomain rramsdell@nonlocaldomain

need to add an identity mapping to the hash file:

rramsdell@nonlocaldomain   rramsdell@nonlocaldomain







r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual.pcre
/./ itstaff


This per Wietse.

Debug :

Sep 26 13:54:43 mail1-test postfix/smtpd[6842]: maps_find:
virtual_alias_maps: hash:/etc/postfix/virtual(0,lock|fold_fix):
real@madeupdomain = rramsdell@nonlocaldomain

. . .

Sep 26 13:54:53 mail1-test postfix/local[6848]: C311517A7BF:
to=itst...@mail1.dfb.qa.vn, orig_to=real@madeupdomain,
relay=local, delay=19, delays=19/0/0/0.05, dsn=2.0.0, status=sent
(delivered to maildir)

This looks like it matches virtual and then applies the pcre virtual.



Yes, that's what recursion does.




   -- Noel Jones


/etc/postfix/virtual:
 #f...@example.com  stays itself.
 f...@example.com   f...@example.com

 #b...@example.com  goes elsewhere.
 b...@example.com   other@elsewhere

/etc/postfix/virtual.pcre:
 # Everything else goes to the mailsink.
 /./mails...@example.net

?

Re: Many to one address rewriting, exceptions exist.

[Noel Jones]

On 9/26/2011 2:34 PM, Randy Ramsdell wrote:

 
 /etc/postfix/virtual:
  #f...@example.com  stays itself.
  f...@example.comf...@example.com

OK.

 
  #b...@example.com  goes elsewhere.
  b...@example.comother@elsewhere

you need an identity mapping for other@elsewhere, or it will be
rewritten by the catchall.

other@elsewhere  other@elsewhere


As was stated before, lookups to virtual_alias_maps are recursive.
Recursion stops when either there is no match (which will never
happen with a catchall), or the input key matches the output (which
is why you need a 1-1 or identity entry).


  -- Noel Jones


 
 /etc/postfix/virtual.pcre:
  # Everything else goes to the mailsink.
  /./mails...@example.net
 
 ?
 

Re: Many to one address rewriting, exceptions exist.

[Wietse Venema]

Randy Ramsdell:
[ Charset ISO-8859-1 unsupported, converting... ]
 On 09/26/11 14:36, Noel Jones wrote:
  On 9/26/2011 1:31 PM, Randy Ramsdell wrote:
  On 09/26/11 14:18, Noel Jones wrote:
  On 9/26/2011 1:00 PM, Randy Ramsdell wrote:
  On 09/22/11 13:45, Randy Ramsdell wrote:
  I cannot find the the way to grab all to's rewritten to go to a
  single to:. We need to send all mail coming out of our QA
  environment and send that to a single, probably, local address.
  The list of senders will be in the thousands and so using a
  catchall for these has to be configured.
 
  We will also select a few to's where we send these off as normal.
 
  No external to our network mail we need to be routed.
 
  So far I read about transport maps and the address rewriting but
  don't see a way or the best way to accomplish this.
 
  Advice appreciated,
  Randy Ramsdell
  When virtual_alias_maps using two maps as suggested.
 
  virtual_alias_maps =
hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre
 
  This has order correct ?i.e As in the maps are checked sequentially?
 
 
  The maps are checked sequentially and recursively. Recursion stops
  when the result is the same as the input key or not found.
 
  For this application, you would need 1-1 identity mappings in the
  hash file, and a catchall in the pcre.
 
 
  -- Noel Jones
  r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual
  real@madeupdomain rramsdell@nonlocaldomain
  need to add an identity mapping to the hash file:
 
  rramsdell@nonlocaldomain   rramsdell@nonlocaldomain
 
 
 
 
 
 
  r...@mail1-test.dfb.qa.vn:/etc/postfix # cat virtual.pcre
  /./ itstaff
 
 
  This per Wietse.
 
  Debug :
 
  Sep 26 13:54:43 mail1-test postfix/smtpd[6842]: maps_find:
  virtual_alias_maps: hash:/etc/postfix/virtual(0,lock|fold_fix):
  real@madeupdomain = rramsdell@nonlocaldomain
 
  . . .
 
  Sep 26 13:54:53 mail1-test postfix/local[6848]: C311517A7BF:
  to=itst...@mail1.dfb.qa.vn, orig_to=real@madeupdomain,
  relay=local, delay=19, delays=19/0/0/0.05, dsn=2.0.0, status=sent
  (delivered to maildir)
 
  This looks like it matches virtual and then applies the pcre virtual.
 
 
  Yes, that's what recursion does.
 
 
 
 
 -- Noel Jones
 
 /etc/postfix/virtual:
   #f...@example.com  stays itself.
   f...@example.comf...@example.com
 
   #b...@example.com  goes elsewhere.
   b...@example.comother@elsewhere
 
 /etc/postfix/virtual.pcre:
   # Everything else goes to the mailsink.
   /./ mails...@example.net
 
 ?

Plus the portion of my example that you left out, and that lists
the PCRE file last in the virtual_alias_maps settings.

Wietse

Re: Many to one address rewriting, exceptions exist.

[Noel Jones]

On 9/26/2011 3:12 PM, Wietse Venema wrote:
 Randy Ramsdell:
 /etc/postfix/virtual:
   #f...@example.com  stays itself.
   f...@example.com   f...@example.com

   #b...@example.com  goes elsewhere.
   b...@example.com   other@elsewhere

 /etc/postfix/virtual.pcre:
   # Everything else goes to the mailsink.
   /./mails...@example.net

 ?
 
 Plus the portion of my example that you left out, and that lists
 the PCRE file last in the virtual_alias_maps settings.
 
   Wietse


But don't we need an identity 1-1 mapping in the hash file for
other@elsewhere so the pcre /./ catchall doesn't rewrite it also?



  -- Noel Jones

Re: Many to one address rewriting, exceptions exist.

[Randy Ramsdell]

On 09/22/11 16:33, Wietse Venema wrote:

Randy Ramsdell:

/etc/postfix/main.cf:
  virtual_alias_maps = hash:/etc/postfix/virtual

/etc/postfix/virtual:
  # All example.com users become mails...@example.net.
  @example.com  mails...@example.net

  # Except for f...@example.com, which stays itself.
  f...@example.com  f...@example.com

  # And except for b...@example.com, which goes elsewhere.
  b...@example.com  other@elsewhere

See http://www.postfix.org/DATABASE_README.html for tips to translate
this into other database formats.

Wietse

ahh however we need :

@singleuser@domain.

I tried this but does not work.

No surprise. The form @ is not documented anywhere.

If you really must rewrite any domain, use regular expressions instead.

/etc/postfix/main.cf:
 virtual_alias_maps =
hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre

/etc/postfix/virtual:
 # f...@example.com stays itself.
 f...@example.com   f...@example.com

 # b...@example.com goes elsewhere.
 b...@example.com   other@elsewhere

/etc/postfix/virtual.pcre:
 # Everything else goes to the mailsink.
 /./mails...@example.net

Wietse
Well this worked and somehow I broke it or really not sure. We only want 
to accept mail from the app servers.


hostname -f
mail1-test.dfb.qa.vn

Relevant logs:

Sep 23 13:28:20 mail1-test postfix/error[18015]: 2760D17A7F6: 
to=itst...@outdomain.com, orig_to=rramsd...@joeblow.com, relay=none, 
delay=0.07, delays=0.04/0/0/0.03, dsn=5.0.0, status=bounced (User 
unknown in virtual alias table)



postconf -n
biff = no
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter =
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
defer_transports =
delay_warning_time = 1h
disable_dns_lookups = no
disable_mime_output_conversion = no
html_directory = /usr/share/doc/packages/postfix-doc/html
inet_interfaces = all
inet_protocols = all
mail_owner = postfix
mail_spool_directory = /var/mail
mailbox_command =
mailbox_size_limit = 0
mailbox_transport =
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_domains =
masquerade_exceptions = root
message_size_limit = 0
message_strip_characters = \0
mydestination = $myhostname, localhost.$mydomain,*.com
myhostname = mail1-test.dfb.qa.vn
mynetworks_style = subnet
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
relocated_maps = hash:/etc/postfix/relocated
sample_directory = /usr/share/doc/packages/postfix-doc/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtp_enforce_tls = no
smtp_sasl_auth_enable = no
smtp_use_tls = no
smtpd_client_restrictions =
smtpd_helo_required = no
smtpd_helo_restrictions =
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
smtpd_sasl_auth_enable = no
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_use_tls = no
strict_8bitmime = no
strict_rfc821_envelopes = no
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = pcre:/etc/postfix/virtual.pcre

Re: Many to one address rewriting, exceptions exist.

[Randy Ramsdell]

On 09/23/11 13:35, Randy Ramsdell wrote:


Please disregard. Typo but I doubt you've seen the last issue regarding 
this configuration. :)

Re: Many to one address rewriting, exceptions exist.

[Wietse Venema]

Randy Ramsdell:
  If you really must rewrite any domain, use regular expressions instead.
 
  /etc/postfix/main.cf:
   virtual_alias_maps =
  hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre
 
  /etc/postfix/virtual:
   # f...@example.com stays itself.
   f...@example.com   f...@example.com
 
   # b...@example.com goes elsewhere.
   b...@example.com   other@elsewhere
 
  /etc/postfix/virtual.pcre:
   # Everything else goes to the mailsink.
   /./mails...@example.net
 
  Wietse
 Well this worked and somehow I broke it or really not sure. We only want 
 to accept mail from the app servers.
 
 hostname -f
 mail1-test.dfb.qa.vn
 
 Relevant logs:
 
 Sep 23 13:28:20 mail1-test postfix/error[18015]: 2760D17A7F6: 
 to=itst...@outdomain.com, orig_to=rramsd...@joeblow.com, relay=none, 
 delay=0.07, delays=0.04/0/0/0.03, dsn=5.0.0, status=bounced (User 
 unknown in virtual alias table)

If you have a /./ regular expression at the end of virtual_alias_maps,
then the above error message is impossible, because every user will
match the /./ pattern and resolve to mails...@example.net.

Except when you have -o virtual_alias_maps=somethingelse in
master.cf, or when you are looking at the wrong set of configuration
files. Maybe someone else on the list has more time to play detective.

Wietse 

Many to one address rewriting, exceptions exist.

[Randy Ramsdell]

I cannot find the the way to grab all to's rewritten to go to a single 
to:. We need to send all mail coming out of our QA environment and 
send that to a single, probably, local address. The list of senders will 
be in the thousands and so using a catchall for these has to be configured.


We will also select a few to's where we send these off as normal.

No external to our network mail we need to be routed.

So far I read about transport maps and the address rewriting but don't 
see a way or the best way to accomplish this.


Advice appreciated,
Randy Ramsdell

Re: Many to one address rewriting, exceptions exist.

[Randy Ramsdell]

On 09/22/11 15:51, Wietse Venema wrote:

Randy Ramsdell:

I cannot find the the way to grab all to's rewritten to go to a single
to:. We need to send all mail coming out of our QA environment and
send that to a single, probably, local address. The list of senders will
be in the thousands and so using a catchall for these has to be configured.

We will also select a few to's where we send these off as normal.

No external to our network mail we need to be routed.

So far I read about transport maps and the address rewriting but don't
see a way or the best way to accomplish this.

The Berkeley DB version:

/etc/postfix/main.cf:
 virtual_alias_maps = hash:/etc/postfix/virtual

/etc/postfix/virtual:
 # All example.com users become mails...@example.net.
 @example.com   mails...@example.net

 # Except for f...@example.com, which stays itself.
 f...@example.com   f...@example.com

 # And except for b...@example.com, which goes elsewhere.
 b...@example.com   other@elsewhere

See http://www.postfix.org/DATABASE_README.html for tips to translate
this into other database formats.

Wietse

ahh however we need :

@singleuser@domain.

I tried this but does not work.

Thanks,
RCR

Re: Many to one address rewriting, exceptions exist.

[Wietse Venema]

Randy Ramsdell:
  /etc/postfix/main.cf:
   virtual_alias_maps = hash:/etc/postfix/virtual
 
  /etc/postfix/virtual:
   # All example.com users become mails...@example.net.
   @example.com   mails...@example.net
 
   # Except for f...@example.com, which stays itself.
   f...@example.com   f...@example.com
 
   # And except for b...@example.com, which goes elsewhere.
   b...@example.com   other@elsewhere
 
  See http://www.postfix.org/DATABASE_README.html for tips to translate
  this into other database formats.
 
  Wietse
 ahh however we need :
 
 @singleuser@domain.
 
 I tried this but does not work.

No surprise. The form @ is not documented anywhere.

If you really must rewrite any domain, use regular expressions instead.

/etc/postfix/main.cf:
virtual_alias_maps = 
hash:/etc/postfix/virtual pcre:/etc/postfix/virtual.pcre

/etc/postfix/virtual:
# f...@example.com stays itself.
f...@example.comf...@example.com

# b...@example.com goes elsewhere.
b...@example.comother@elsewhere

/etc/postfix/virtual.pcre:
# Everything else goes to the mailsink.
/./ mails...@example.net

Wietse

Re: Many to one address rewriting, exceptions exist.

[Amedeo Rinaldo]

Il 22/09/2011 22:33, Wietse Venema ha scritto:

.. [cut] ..

/etc/postfix/virtual.pcre:
 # Everything else goes to the mailsink.
 /./mails...@example.net

Wietse



Similar need, to intercept specific local-part for all domains.
If i'm not wrong, something like..

/etc/postfix/virtual.pcre:
 # Forward elsewhere specific local-part (all domains)
 /^localpart(+.)?@./forward@elsewhere


..should do the trick ?



Amedeo Rinaldo
--
Una volta eliminato l'impossibile, quello che resta, per improbabile che 
sia, deve essere la verità  (Sherlock Holmes)

Re: Re: Address Rewriting for relayed emails

[Michael . H . Grimm]

Thanks for the config hint.

It works fine if I add an email address like this to generic

laserjetscan...@domain.local notificati...@domain.com

It does not work if I want to do the following:

@domain.com notificati...@domain.com

It then appears to rewrite the recipients address as well and not only the  
senders address.

So the account notificati...@domain.com receives it's own emails.

Can I restrict the rule to the sender only?

Kind regards
Michael

On Nov 29, 2010 5:10pm, John Adams mailingli...@belfin.ch wrote:

Am 29.11.2010 16:24, schrieb michael.h.gr...@googlemail.com:




Dear all,





Is it possible to configure postfix for the following scenario?



Our ERP-System wants to send emails over a dedicated account to it's



users. As it tries to send the email as the current user, using the



users address, the e-mail gets rejected by our provider (who is running



Exchange).



As the providers security policy doesn't allow me to grant the Exchange



Send as permission to the ERP-Account I want to do the following:





Configure an internal postfix installation to accept these faked emails



Forward them to the Exchange server



replacing the faked senders address with the valid address of the



account dedicated to the ERP-System.





Is this possible?



I guess I have to use the Address Rewriting capabilities in Postfix. But



where to start?





Kind regards and many thanks in advance



Michael






man generic



u...@domain address



Replace u...@domain by address. This form has the highest Precedence.





HTH



John

Re: Address Rewriting for relayed emails

[Jeroen Geilman]

On 12/02/2010 10:10 AM, michael.h.gr...@googlemail.com wrote:

Thanks for the config hint.

It works fine if I add an email address like this to generic

laserjetscan...@domain.local notificati...@domain.com

It does not work if I want to do the following:

@domain.com notificati...@domain.com

It then appears to rewrite the recipients address as well and not only 
the senders address.

So the account notificati...@domain.com receives it's own emails.

Can I restrict the rule to the sender only?



Use sender_canonical_classes combined with sender_canonical_maps instead.


--
J.

Re: Address Rewriting for relayed emails

[Victor Duchovni]

On Thu, Dec 02, 2010 at 05:23:33PM +0100, Jeroen Geilman wrote:

 On 12/02/2010 10:10 AM, michael.h.gr...@googlemail.com wrote:
 Thanks for the config hint.

 It works fine if I add an email address like this to generic

 laserjetscan...@domain.local notificati...@domain.com

 It does not work if I want to do the following:

 @domain.com notificati...@domain.com

 It then appears to rewrite the recipients address as well and not only the 
 senders address.
 So the account notificati...@domain.com receives it's own emails.

 Can I restrict the rule to the sender only?


 Use sender_canonical_classes combined with sender_canonical_maps instead.

No.

When rewriting addresses in headers, all addresses, both sender
and recipint should be rewritten, if a domain is invalid in the sender
address, it is also invalid in the To/Cc addresses which are used in
the same way as From: in Reply-All.

-- 
Viktor.

Address Rewriting for relayed emails

[Michael . H . Grimm]

Dear all,

Is it possible to configure postfix for the following scenario?
Our ERP-System wants to send emails over a dedicated account to it's users.  
As it tries to send the email as the current user, using the users address,  
the e-mail gets rejected by our provider (who is running Exchange).
As the providers security policy doesn't allow me to grant the  
Exchange Send as permission to the ERP-Account I want to do the following:


Configure an internal postfix installation to accept these faked emails
Forward them to the Exchange server
replacing the faked senders address with the valid address of the account  
dedicated to the ERP-System.


Is this possible?
I guess I have to use the Address Rewriting capabilities in Postfix. But  
where to start?


Kind regards and many thanks in advance
Michael

Re: Address Rewriting for relayed emails

[Noel Jones]

On 11/29/2010 9:24 AM, michael.h.gr...@googlemail.com wrote:

Dear all,

Is it possible to configure postfix for the following scenario?
Our ERP-System wants to send emails over a dedicated account
to it's users. As it tries to send the email as the current
user, using the users address, the e-mail gets rejected by our
provider (who is running Exchange).
As the providers security policy doesn't allow me to grant the
Exchange Send as permission to the ERP-Account I want to do
the following:

Configure an internal postfix installation to accept these
faked emails
Forward them to the Exchange server
replacing the faked senders address with the valid address of
the account dedicated to the ERP-System.

Is this possible?
I guess I have to use the Address Rewriting capabilities in
Postfix. But where to start?

Kind regards and many thanks in advance
Michael



Use the smtp_generic_maps feature to rewrite the bogus sender 
to a valid address.


# main.cf
smtp_generic_maps = hash:/etc/postfix/generic

# /etc/postfix/generic
bogus_u...@example.com  u...@other.example.com


Run postfix reload after editing main.cf.
Run postmap generic after editing the map file.


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

You may also need:
http://www.postfix.org/BASIC_CONFIGURATION_README.html
http://www.postfix.org/SOHO_README.html
http://www.postfix.org/STANDARD_CONFIGURATION_README.html
http://www.postfix.org/ADDRESS_CLASS_README.html

These and more can be found at
http://www.postfix.org/documentation.html




  -- Noel Jones

Re: Address Rewriting for relayed emails

[John Adams]

Am 29.11.2010 16:24, schrieb michael.h.gr...@googlemail.com:

Dear all,

Is it possible to configure postfix for the following scenario?
Our ERP-System wants to send emails over a dedicated account to it's
users. As it tries to send the email as the current user, using the
users address, the e-mail gets rejected by our provider (who is running
Exchange).
As the providers security policy doesn't allow me to grant the Exchange
Send as permission to the ERP-Account I want to do the following:

Configure an internal postfix installation to accept these faked emails
Forward them to the Exchange server
replacing the faked senders address with the valid address of the
account dedicated to the ERP-System.

Is this possible?
I guess I have to use the Address Rewriting capabilities in Postfix. But
where to start?

Kind regards and many thanks in advance
Michael


man generic
  u...@domain address
  Replace u...@domain by address. This form has the highest Precedence.

HTH
John

Re: Postfix + stunnel SMTPS = address rewriting issue

[Jack Browning]

On Tue, Jun 1, 2010 at 6:17 PM, Wietse Venema wie...@porcupine.org wrote:
 Jack Browning:

 No address rewriting is occurring even though Postfix is invoking its
 SMTP client to deliver the mail to the remote host, and my generic map
 (after postmap and a reload) contains an entry like this:

 zzz...@jnjroos.net    xxx...@att.net

 Sorry this is very incorrect.

 The from= line, logged by the queue manager, is not subject to SMTP
 generic mapping. It never was, and it never will.

 SMTP generic mapping is implemented in the Postfix SMTP client.
 This mapping is done only for information that is sent over the
 network.  This also explains why:

 1) SMTP generic mapping has no effect on SASL password lookup.  It
 never did, and it never will.

 2) SMTP generic mapping does not change with the destination host.
 It never did, and it never will.

        Wietse

Live and learn. Since the fix suggested earlier in this thread --
keying the remote username:password entries to the users' local
addresses -- produces the desired result, the issue didn't involve
generic mapping at all. No generic mapping was done until the message
was actually sent to the remote server, and the message was not being
sent because the mis-keyed password lookup table resulted in bad (or
no) credentials being presented to the remote server, which rejected
the authentication attempt and terminated the session before the
message itself was transmitted. No transmission = no rewriting.

Anyway, that's my story, and I'm sticking to it.

JEB

Re: Postfix + stunnel SMTPS = address rewriting issue

[Wietse Venema]

Jack Browning:
 Live and learn. Since the fix suggested earlier in this thread --
 keying the remote username:password entries to the users' local
 addresses -- produces the desired result, the issue didn't involve
 generic mapping at all. No generic mapping was done until the message
 was actually sent to the remote server, and the message was not being
 sent because the mis-keyed password lookup table resulted in bad (or
 no) credentials being presented to the remote server, which rejected
 the authentication attempt and terminated the session before the
 message itself was transmitted. No transmission = no rewriting.
 
 Anyway, that's my story, and I'm sticking to it.

Are you sticking with your subject line Postfix + stunnel SMTPS
= address rewriting issue? All I have seen sofar is that
sender-dependent SASL password lookups are working as promised.

Wietse

Re: Postfix + stunnel SMTPS = address rewriting issue

[Jack Browning]

On Fri, May 28, 2010 at 1:27 PM, Wietse Venema wie...@porcupine.org wrote:
 Jack Browning:
 I'm curious as to why the generic map isn't working for mail sent to
 the relayhost.

 Generic mapping is implemented in the Postfix SMTP client, so you
 need to configure the Postfix SMTP client appropriately.  Setting
 the generic mapping on other Postfix programs has no effect.

Perhaps there was a misunderstanding because of my description of the issue.

To connect to the ATT/U-verse SMTP server, I am using a variant of the
configuration described at:

http://www.postfix.org/TLS_README.html#client_smtps

The only differences in my stunnel.conf and the stunnel.conf in the
README are nominal, to wit:

r...@dell:/etc/init.d# cat /etc/stunnel/stunnel.conf
client = yes
foreground = no

[att-smtps]
accept = 2525
connect = smtp.att.yahoo.com:smtps

My main.cf looks like this:

r...@dell:/etc/postfix# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = yes
biff = no
config_directory = /etc/postfix
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = all
mailbox_size_limit = 104857600
message_size_limit = 52428800
mydestination = dell.jnjroos.net, localhost.jnjroos.net, localhost, jnjroos.net
myhostname = dell.jnjroos.net
mynetworks = 127.0.0.0/8, 192.168.0.0/24
myorigin = /etc/mailname
queue_minfree = 78643200
relayhost = [localhost]:2525
smtp_generic_maps = hash:/etc/postfix/generic
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sender_dependent_authentication = yes
smtp_use_tls = no
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

Note the relayhost specification, which, again, only differs nominally
from the configuration stated in the README. Note, too, the
specification of smtp_sasl_password_maps, which implements the
sender-based authentication the remote server requires. Finally, note
the specification of smtp_generic_maps, which I had hoped would
rewrite the sender address for outgoing mail being delivered to the
relayhost. jnjroos.net is, of course, a fantasy name for my local
network.

As I stated in my original post, everything works as it should when
the local e-mail clients (Windows Live Mail and Sylpheed) are
configured with the user's ATT e-mail address as the From address.
Here is a redacted log excerpt for outgoing mail when the local
clients are configured that way:

Jun  1 13:42:28 dell postfix/smtpd[16260]: connect from
asus.jnjroos.net[192.168.0.4]
Jun  1 13:42:28 dell postfix/smtpd[16260]: 6E5C71C157:
client=asus.jnjroos.net[192.168.0.4]
Jun  1 13:42:28 dell postfix/cleanup[16263]: 6E5C71C157:
message-id=20100601134228.d563162f.xxx...@att.net
Jun  1 13:42:28 dell postfix/qmgr[16015]: 6E5C71C157:
from=xxx...@att.net, size=828, nrcpt=1 (queue active)
Jun  1 13:42:28 dell postfix/smtpd[16260]: disconnect from
asus.jnjroos.net[192.168.0.4]
Jun  1 13:42:29 dell postfix/smtp[16264]: 6E5C71C157:
to=yyy...@gmail.com, relay=127.0.0.1[127.0.0.1]:2525, delay=1.3,
delays=0.06/0/1/0.22, dsn=2.0.0, status=sent (250 OK , completed)
Jun  1 13:42:29 dell postfix/qmgr[16015]: 6E5C71C157: removed

As you can see,  everything (including sender-based authentication)
works, and the delivery to the remote host (via Postfix's SMTP client)
is successful.

Now, when I change the From address in the local e-mail clients to the
user's local e-mail address, i.e., from xxx...@att.net to
zzz...@jnjroos.net, this is what happens:

Jun  1 14:17:24 dell postfix/smtpd[16469]: connect from
asus.jnjroos.net[192.168.0.4]
Jun  1 14:17:24 dell postfix/smtpd[16469]: B01C11C157:
client=asus.jnjroos.net[192.168.0.4]
Jun  1 14:17:24 dell postfix/cleanup[16472]: B01C11C157:
message-id=20100601141724.a4213911.zzz...@jnjroos.net
Jun  1 14:17:24 dell postfix/qmgr[16317]: B01C11C157:
from=zzz...@jnjroos.net, size=850, nrcpt=1 (queue active)
Jun  1 14:17:24 dell postfix/smtpd[16469]: disconnect from
asus.jnjroos.net[192.168.0.4]
Jun  1 14:17:25 dell postfix/smtp[16473]: B01C11C157:
to=yyy...@gmail.com, relay=localhost[127.0.0.1]:2525, delay=0.28,
delays=0.05/0.01/0.18/0.04, dsn=5.0.0, status=bounced (host
localhost[127.0.0.1] said: 530 authentication required - for help go
to http://help.yahoo.com/sbc/dsl/mail/pop/pop-11.html (in reply to
MAIL FROM command))
Jun  1 14:17:25 dell postfix/cleanup[16472]: 2144A1C297:
message-id=20100601191725.2144a1c...@dell.jnjroos.net
Jun  1 14:17:25 dell postfix/bounce[16475]: B01C11C157: sender
non-delivery notification: 2144A1C297
Jun  1 14:17:25 dell postfix/qmgr[16317]: 2144A1C297: from=,
size=2825, nrcpt=1 (queue active)
Jun  1 14:17:25 dell postfix/qmgr[16317]: B01C11C157: removed
Jun  1 14:17:25 dell postfix/local[16476]: 2144A1C297:
to=zzz...@jnjroos.net, relay=local, delay=0.02,
delays=0.01/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
Jun  1 14:17:25 dell postfix/qmgr[16317]: 2144A1C297: removed

No address rewriting is occurring even though