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



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 didn't get the two last points (a and b) you pointed me to one possible solution :-) Omitting the -s parameter and it's argument forces GNARWL to read the senders email address from the piped mail - GNARWL doesn't fail in this case and uses the correct email address (Envelope From Header) to send its autoresponse.

So you opted to violate a.) (sent back to the from address and not to the envelope sender). If you also use the null envelope sender "<>" as you should you wont get any auto replies to BATV using senders anyway.

In case other people experience similar problems here is my solution:

The "solution" would be gnarwl using the correct BATV envelope sender as target address.

Regards

Andreas

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to