Simeon Ott:
> > What happens when you send mail by hand to prvs=whatever@whatever?
> >
> > $ echo this is a test | /usr/sbin/sendmail prvs=whatever@whatever
...
> Oct 2 18:54:05 ares postfix/smtp[17722]: 1795B2C64AC:
> to=<prvs=1254408a08=simeon_...@stud.phzh.ch>,
> relay=mail.messaging.microsoft.com[65.55.88.22]:25, delay=0.98,
> delays=0.14/0.03/0.38/0.43, dsn=2.6.0, status=sent (250 2.6.0
> <20111002165403.252d12c6...@ares.intra.example.com> [InternalId=25661879]
> Queued mail for delivery)
>
> that's what i'm looking for. does this mean that GNARWL is doing
> something wrong when batv encoded addresses are used?
Let's see:
1) We know from the last test that prvs=whatever@whatever is left
intact when given directly to Postfix.
2) We know from the previous test that BATV information is removed
when the address is given to gnarwl which then gives it to Postfix.
Therefore, gnarwl removes BATV information.
> i asked patrick ahlbrecht, the author of GNARWL prior to posting
> this question here on the postfx-users mailinglist.
>
> "[...] theres no way to teach the address parser about it (short of rewriting
> the cleanAddress() function). Also, there is no way to configure gnarwl
> to use a different header field. Easiest option is probably to patch
> mailhandler.c to look for the X-Envelope-From instead of the FROM
> header. In line 94, simply replace the (!strcasecmp("from",tmp[0]) with
> (!strcasecmp("x-envelope-from",tmp[0])"
This also confirms that gnarwl removes BATV information.
> ... i thought there has to be another option beside from patching
> sources of a debian stable package.
After BATV information is removed, not even Postfix can put it back.
Wietse
