maildrop transport, why using ${nexthop} instead of ${domain}
Hi.
Just for my understanding
http://www.postfix.org/MAILDROP_README.html#direct uses -d ${us...@${nexthop}.
Why is nexthop used instead of domain? And when would these two be different?
Thanks,
Philippe.
Re: maildrop transport, why using ${nexthop} instead of ${domain}
Philippe Cerfon:
Hi.
Just for my understanding
http://www.postfix.org/MAILDROP_README.html#direct uses -d
${us...@${nexthop}.
Why is nexthop used instead of domain? And when would these two be different?
Like Rome, Postfix was not built in one day.
Unfortunately these is no way to AUTOMATICALLY find all the pieces
of documentation that need to be updated when a new feature (such
as ${domain}) is introduced.
Wietse
man 8 pipe
PIPE(8)PIPE(8)
NAME
pipe - Postfix delivery to external command
SYNOPSIS
pipe [generic Postfix daemon options] command_attributes...
...
${domain}
This macro expands to the domain portion of the recipient
address. For example, with an address user+...@domain
the domain is domain.
...
This feature is available as of Postfix 2.5.
Re: maildrop transport, why using ${nexthop} instead of ${domain}
On Fri, Jan 8, 2010 at 4:40 PM, Wietse Venema wie...@porcupine.org wrote:
Like Rome, Postfix was not built in one day.
Unfortunately these is no way to AUTOMATICALLY find all the pieces
of documentation that need to be updated when a new feature (such
as ${domain}) is introduced.
Ah so they're the same? Could you perhaps add this to the docs for
future new-commers? :)
Another cosmetic thing that could be added here is:
- The null_sender section tells that it's also subject to the q flag,
the description of the q flag however doesn't list it.
- user and extension sections they that they're subject to u or h
flags, the respective flag descriptions mention however only
recipient, sender, domain, nexthop and original_recipien
By the way, may I ask two more minor questions, regarding pipe:
1) Why is the default for null_sender=MAILER-DAEMON? I believe you
that it has some good reason, just would like to know which one? Are
there MUAs that misbehave if they get emails with an empty return
path?
2) I do not fully understand the q flag. Does it mean that pipe gets
addresses from postfix which can contain spaces or other non-ascii
character, and with that it's encoded?
Thanks,
Philippe.
Re: maildrop transport, why using ${nexthop} instead of ${domain}
Philippe Cerfon:
On Fri, Jan 8, 2010 at 4:40 PM, Wietse Venema wie...@porcupine.org wrote:
Like Rome, Postfix was not built in one day.
Unfortunately these is no way to AUTOMATICALLY find all the pieces
of documentation that need to be updated when a new feature (such
as ${domain}) is introduced.
Ah so they're the same?
I will refer you to the pipe(8) manual page.
Another cosmetic thing that could be added here is:
- The null_sender section tells that it's also subject to the q flag,
the description of the q flag however doesn't list it.
The manual page says that the expansion of $sender is subject to
the q flag. This is true regardless of where the expansion result
comes from, so there is no need to repeat this for null_sender.
- user and extension sections they that they're subject to u or h
flags,
These sections say that they are subject to the u flag.
By the way, may I ask two more minor questions, regarding pipe:
1) Why is the default for null_sender=MAILER-DAEMON? I believe you
that it has some good reason, just would like to know which one? Are
there MUAs that misbehave if they get emails with an empty return
path?
As documented in the manual page, a null sender address is easily
mis-parsed by naive programs. If their programmer is aware that
empty strings require special handling, then they can recommend
changing the null_sender setting. Otherwise, don't change it.
2) I do not fully understand the q flag. Does it mean that pipe gets
addresses from postfix which can contain spaces or other non-ascii
character, and with that it's encoded?
As documented in the manual page, the address is quoted per RFC
822 rules. You are welcome to review that document, or any of its
successors, RFC 2822 and RFC 5322.
Wietse
