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=<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.
> 

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

Reply via email to