Andreas Weigel:
> Hi everyone,
>
> I stumbled upon a very minor bug with regard to parsing the supported
> XFORWARD attributes from the EHLO reply in smtpd_proxy: the last
> attribute is never acknowledged because when tokenizing, the appended
> '\r' is not removed and leads to a failed string comparison in name_code
> an thereby to the last attribute not being added to
> server_xforward_features.
> I guess this has so far never come up because the last in line of
> advertised XFORWARD attributes by postfix currently is IDENT, which
> seems to never be set in this scenario anyways(?). The attached patch
> should fix the issue.
Thanks for that fix.
> This brings me to my actual question:
> I wanted to access the equivalent of the sendmail{daemon_addr} macro
> from within a before-queue content filter, so I just modified postfix to
> add the DAEMONADDR attribute to the XFORWARD command, which worked
> perfectly for that one attribute (at least after applying the mentioned
> fix :) ).
> Is there a chance for such a change to be accepted upstream or are there
> even plans/willingness to add more (all?) (milter-)sendmail macros as
> XFORWARD attributes in future? The comment in
> src/cleanup/cleanup_milter.c:cleanup_milter_eval suggests that this
> thought is not entirely new.
I think not because
1) XFORWARD is for client properties, whereas DAEMONADDR is a server
property. This may seem like a silly argument, but that is how
Postfix works: simple principles that work consistently.
2) Every attribute set with XFORWARD needs to be propagated through
Postfix SMTP server programs, Postfix queue files, Postfix SMTP
clients, and maybe have a Milter equivalent. That is one of the
problems with adding more XFORWARD attributes.
So let's not create chaos with partial solutions that make Postfix
harder to use, and increasingly harder to maintain consistently.
Wietse
