Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Lst_hoe02@kwsoft.de
    ... 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
    Message 1 of 17 , Oct 3, 2011
    • 0 Attachment
      Zitat von Simeon Ott <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 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
    • Wietse Venema
      ... 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
      Message 2 of 17 , Oct 3, 2011
      • 0 Attachment
        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
        >-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
        >-oresponse.

        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
      • Simeon Ott
        ... 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
        Message 3 of 17 , Oct 3, 2011
        • 0 Attachment
          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
          >> -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
          >> -oresponse.
          >
          > 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?
        • Wietse Venema
          ... Sorry, I m just the guy who wrote Postfix. I can t answer questions about how to configure gnawrl, because I have never used it. Wietse
          Message 4 of 17 , Oct 3, 2011
          • 0 Attachment
            Simeon Ott:
            > 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
            > >> -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
            > >> -oresponse.
            > >
            > > 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 underst
            >-and 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 b
            >-ug 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 no
            >-t know all the standards defined in all the RFCs. But I do my best in readin
            >-g manuals to get closer. There was no precise answer to this question (is th
            >-is 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 sendm
            >-ail command as long as this Bug (!) is not fixed in GNARWL. Or what would yo
            >-u suggest?

            Sorry, I'm just the guy who wrote Postfix. I can't answer questions
            about how to configure gnawrl, because I have never used it.

            Wietse
          • Lst_hoe02@kwsoft.de
            ... 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
            Message 5 of 17 , Oct 3, 2011
            • 0 Attachment
              Zitat von Simeon Ott <simeon.ott@...>:

              >
              > 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
              >>> -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
              >>> -oresponse.
              >>
              >> 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?
              >

              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.
              I would recomend to not use a buggy autoresponder at all.

              Regards

              Andreas
            Your message has been successfully submitted and would be delivered to recipients shortly.