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. WietseThank 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
smime.p7s
Description: S/MIME Cryptographic Signature