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