On 02.10.2011, at 20:26, Wietse Venema wrote:
> 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=<[email protected]>,
>> 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
>> <[email protected]> [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.
>
i got this, in fact gnarwl is the problem...
but... i'm still looking for a possibility to resolve this problem before it
appears. is the variable ${sender} in master.cf the only way to pass senders
information (as an argument) to a transport service? because if there would be
a way of passing the senders email without the BATV prvs, gnarwl won't fail in
sending an autoresponse.
do i have to consider this as a bug in GNARWL?
and how did you guys configure gnarwl without having these problems? am i the
only one who experienced this with GNARWL? that sounds a bit strange to me.
simeon
