Re: [SOLVED] Re: problem with pipe ${sender} to gnarwl when sender has BATV enabled

[Lst_hoe02]

Zitat von Simeon Ott <simeon....@onnet.ch>:

On 03.10.2011, at 13:13, Wietse Venema wrote:

Simeon Ott:

On 03.10.2011, at 00:35, Wietse Venema wrote:

Simeon Ott:

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.

First, few sites use BATV.

Second, BATV works perfectly fine with autoresponders that adhere
to mail standards: a) reply to the envelope sender address, and b)
send the reply with a null envelope sender address.

I suspect that BATV also inter-operates with buggy autoresponders
that violate both requirements a) and b): reply to an address in
the from header, and send email with a non-null envelope sender.

But BATV won't inter-operate with buggy autoresponders that violate
only a) or b) but not both. That is a BATV feature, not a bug.

Currently, your gnarwl setup falls into none of these categories
since it changes a remote address into a local one.

You can prevent address destruction by not using the gnarwl -s
option (this means you will violate requirement a) above), but
that won't be sufficient for BATV inter-operability unless gnarwl
also violates the b) requirement.

        Wietse

Thank you Wietse for your supportive analytical understanding. Even if i d

-oresponse.

-idn't get the two last points (a and b) you pointed me to one possible solut -ion :-) Omitting the -s parameter and it's argument forces GNARWL to read th -e senders email address from the piped mail - GNARWL doesn't fail in this ca -se and uses the correct email address (Envelope From Header) to send its aut

This is NOT THE SOLUTION. Autoresponders that reply to the header
are broken, as outlined above.

The solution is to fix gnarwl sothat it does not modify the address.

        Wietse
        Wietse

Excuse me for misunderstanding this as a solution. I do my best to understand what I am doing - that was just a case which resolved my issue for now. Prior to reconfigure my mailsystem I asked if this behavior looks like a bug in GNARWL because i just wanted to have my back covered when i fill a bug on the gnarwl buglist. I'm a postfix user not a pro administrator and do not know all the standards defined in all the RFCs. But I do my best in reading manuals to get closer. There was no precise answer to this question (is this a bug in gnarwl?) that's why I looked for other possibilities. I'm going to reconfigure GNARWL to use a null envelope sender in the sendmail command as long as this Bug (!) is not fixed in GNARWL. Or what would you suggest?

I would recomend to not use a buggy autoresponder at all.

Regards

Andreas

As of RFC 3834 a automatic reply should go to the envelope sender (Return-Path) of the original mail and the envelope sender of the autoreply should be the empty address "<>" to avoid mail loops. BATV systems try to detect forged bounces and therefore use a special envelope sender address. Every mail coming in to BATV aware systems with a empty sender address and a non BATV target address is discarded. Gnarwl is failing to use the correct BATV address as target so in order to get autoreply through you must use a non empty sender address fro your autoreply. As said before this is not recommended per RFC for loop prevention and will lead to further trouble if the sender address can not be verified by SAV for example.

smime.p7s
Description: S/MIME Cryptographic Signature