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

problem with pipe ${sender} to gnarwl when sender has BATV enabled

Expand Messages
  • Simeon Ott
    hello, i recently configured gnarwl autoresponder on my mailserver. the autoresponder works great as long as the sender doesn t use BATV. otherwise the
    Message 1 of 17 , Sep 30 10:25 AM
    • 0 Attachment
      hello,

      i recently configured gnarwl autoresponder on my mailserver. the autoresponder works great as long as the sender doesn't use BATV. otherwise the autoresponded message is not delivered to the origin sender. is there a possibility to pipe another attribute then ${sender} in the master.cf?

      here are the relevant configuration parts:
      master.cf:
      gnarwl unix - n n - - pipe flags=F
      user=vmail argv=/usr/bin/gnarwl -a ${user} -s ${sender}

      transport(.db)
      autoreply.example.com gnarwl:

      gnarwl.cfg
      # Name of the macro, refering to the "From:" field of a received mail map_sender $sender
      # How to send mail. Specify full name to your MTA plus arguments. Only the
      # map_sender and map_receiver macros are expanded. This program must be
      # able to accept email from stdin.
      # mta /usr/sbin/sendmail -F $recepient -t $sender
      mta /usr/sbin/sendmail -f $recepient -F $recepient $sender

      if I send an email from a server which uses BATV verification (as microsoft does), in the following case «sender1@...», postfix pipes for the sender attribute something like this to gnarwl: <prvs=1254408a08=sender1@...>

      gnarwl picks this up and tries to send an autoresponse via mta. it failes with trying to send a message to <prvs>, which does not exist on the system.

      following the mail.log of the explained mail exchange
      Sep 30 09:22:33 ares postgrey[28908]: action=pass, reason=triplet found, delay=903, client_name=am1ehsobe002.messaging.microsoft.com, client_address=213.199.154.205, sender=prvs=1254408a08=sender1@..., recipient=rcpt1@...
      Sep 30 09:22:33 ares postfix/smtpd[23207]: DC9FE2C6101: client=am1ehsobe002.messaging.microsoft.com[213.199.154.205]
      Sep 30 09:22:33 ares postfix/cleanup[23790]: DC9FE2C6101: message-id=<0FD46E70-F8B5-40A1-818B-3ABE7871A8A8@...>
      Sep 30 09:22:34 ares postfix/qmgr[23383]: DC9FE2C6101: from=<prvs=1254408a08=sender1@...>, size=2824, nrcpt=2 (queue active)
      Sep 30 09:22:34 ares postfix/smtpd[23207]: disconnect from am1ehsobe002.messaging.microsoft.com[213.199.154.205]
      Sep 30 09:22:35 ares postfix/smtpd[23796]: connect from localhost[127.0.0.1]
      Sep 30 09:22:35 ares postfix/smtpd[23796]: B00CF2C649F: client=localhost[127.0.0.1]
      Sep 30 09:22:35 ares postfix/cleanup[23790]: B00CF2C649F: message-id=<0FD46E70-F8B5-40A1-818B-3ABE7871A8A8@...>
      Sep 30 09:22:35 ares postfix/qmgr[23383]: B00CF2C649F: from=<prvs=1254408a08=sender1@...>, size=3407, nrcpt=3 (queue active)
      Sep 30 09:22:35 ares postfix/smtpd[23796]: disconnect from localhost[127.0.0.1]
      Sep 30 09:22:35 ares amavis[23051]: (23051-08) Passed CLEAN, [213.199.154.205] [193.138.69.163] <prvs=1254408a08=sender1@...> -> <"rcpt1@...,rcpt1@..."@...>,<rcpt1@...,rcpt1@...>, Message-ID: <0FD46E70-F8B5-40A1-818B-3ABE7871A8A8@...>, mail_id: uyNBYKR8Tz1s, Hits: -2.6, size: 2824, queued_as: B00CF2C649F, 1817 ms
      Sep 30 09:22:35 ares postfix/smtp[23791]: DC9FE2C6101: to=<rcpt1@...,rcpt1@...@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=2, delays=0.19/0/0.01/1.8, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=23051-08, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as B00CF2C649F)
      Sep 30 09:22:35 ares postfix/smtp[23791]: DC9FE2C6101: to=<rcpt1@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=2, delays=0.19/0/0.01/1.8, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=23051-08, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as B00CF2C649F)
      Sep 30 09:22:35 ares postfix/qmgr[23383]: DC9FE2C6101: removed
      Sep 30 09:22:35 ares postfix/pipe[23797]: B00CF2C649F: to=<rcpt1@...>, relay=maildrop, delay=0.22, delays=0.09/0.01/0/0.12, dsn=2.0.0, status=sent (delivered via maildrop service)
      Sep 30 09:22:35 ares postfix/pickup[23053]: EE6662C64A7: uid=5000 from=<rcpt1@...>
      Sep 30 09:22:35 ares postfix/cleanup[23790]: EE6662C64A7: message-id=<20110930072235.EE6662C64A7@...>
      Sep 30 09:22:36 ares postfix/pipe[23817]: B00CF2C649F: to=<rcpt1@...,rcpt1@...@...>, relay=gnarwl, delay=0.3, delays=0.09/0.04/0/0.17, dsn=2.0.0, status=sent (delivered via gnarwl service)
      Sep 30 09:22:36 ares postfix/pipe[23817]: B00CF2C649F: to=<rcpt1@...,rcpt1@...@...>, relay=gnarwl, delay=0.35, delays=0.09/0.04/0/0.22, dsn=2.0.0, status=sent (delivered via gnarwl service)
      Sep 30 09:22:36 ares postfix/qmgr[23383]: B00CF2C649F: removed
      Sep 30 09:22:36 ares postfix/qmgr[23383]: EE6662C64A7: from=<rcpt1@...>, size=935, nrcpt=1 (queue active)
      Sep 30 09:22:40 ares postfix/smtpd[23796]: connect from localhost[127.0.0.1]
      Sep 30 09:22:40 ares postfix/smtpd[23796]: F1F592C6101: client=localhost[127.0.0.1]
      Sep 30 09:22:41 ares postfix/cleanup[23790]: F1F592C6101: message-id=<20110930072235.EE6662C64A7@...>
      Sep 30 09:22:41 ares postfix/qmgr[23383]: F1F592C6101: from=<rcpt1@...>, size=1578, nrcpt=1 (queue active)
      Sep 30 09:22:41 ares postfix/smtpd[23796]: disconnect from localhost[127.0.0.1]
      Sep 30 09:22:41 ares amavis[23081]: (23081-08) Passed CLEAN, <rcpt1@...> -> <prvs@...>, Message-ID: <20110930072235.EE6662C64A7@...>, mail_id: Ie+WuC0MyE5S, Hits: -1.901, size: 933, queued_as: F1F592C6101, 5101 ms
      Sep 30 09:22:41 ares postfix/smtp[23791]: EE6662C64A7: to=<prvs@...>, orig_to=<prvs>, relay=127.0.0.1[127.0.0.1]:10024, delay=5.3, delays=0.17/0/0.01/5.1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=23081-08, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as F1F592C6101)
      Sep 30 09:22:41 ares postfix/qmgr[23383]: EE6662C64A7: removed
      Sep 30 09:22:41 ares postfix/local[23824]: F1F592C6101: to=<prvs@...>, relay=local, delay=0.31, delays=0.17/0.05/0/0.09, dsn=5.1.1, status=bounced (unknown user: "prvs")
      Sep 30 09:22:41 ares postfix/cleanup[23790]: 4A6A52C64A7: message-id=<20110930072241.4A6A52C64A7@...>
      Sep 30 09:22:41 ares postfix/qmgr[23383]: 4A6A52C64A7: from=<>, size=3502, nrcpt=1 (queue active)
      Sep 30 09:22:41 ares postfix/bounce[23825]: F1F592C6101: sender non-delivery notification: 4A6A52C64A7
      Sep 30 09:22:41 ares postfix/qmgr[23383]: F1F592C6101: removed
      Sep 30 09:22:41 ares postfix/pipe[23797]: 4A6A52C64A7: to=<rcpt1@...>, relay=maildrop, delay=0.16, delays=0.07/0.01/0/0.08, dsn=2.0.0, status=sent (delivered via maildrop service)
      Sep 30 09:22:41 ares postfix/qmgr[23383]: 4A6A52C64A7: removed

      any ideas how i could fix this?
      thank you in advance for your help
    • Simeon Ott
      ... i forgot to add my configuration in main.cf. here it is: # autoresponder recipient_bcc_maps = ldap:ar ar_server_host = ldap.intra.example.com
      Message 2 of 17 , Sep 30 11:56 AM
      • 0 Attachment
        On 30.09.2011, at 19:25, Simeon Ott wrote:

        > hello,
        >
        > i recently configured gnarwl autoresponder on my mailserver. the autoresponder works great as long as the sender doesn't use BATV. otherwise the autoresponded message is not delivered to the origin sender. is there a possibility to pipe another attribute then ${sender} in the master.cf?
        >
        > here are the relevant configuration parts:
        > master.cf:
        > gnarwl unix - n n - - pipe flags=F
        > user=vmail argv=/usr/bin/gnarwl -a ${user} -s ${sender}
        >
        > transport(.db)
        > autoreply.example.com gnarwl:
        >
        > gnarwl.cfg
        > # Name of the macro, refering to the "From:" field of a received mail map_sender $sender
        > # How to send mail. Specify full name to your MTA plus arguments. Only the
        > # map_sender and map_receiver macros are expanded. This program must be
        > # able to accept email from stdin.
        > # mta /usr/sbin/sendmail -F $recepient -t $sender
        > mta /usr/sbin/sendmail -f $recepient -F $recepient $sender
        >
        > if I send an email from a server which uses BATV verification (as microsoft does), in the following case «sender1@...», postfix pipes for the sender attribute something like this to gnarwl: <prvs=1254408a08=sender1@...>
        >
        > gnarwl picks this up and tries to send an autoresponse via mta. it failes with trying to send a message to <prvs>, which does not exist on the system.
        >
        > following the mail.log of the explained mail exchange
        > Sep 30 09:22:33 ares postgrey[28908]: action=pass, reason=triplet found, delay=903, client_name=am1ehsobe002.messaging.microsoft.com, client_address=213.199.154.205, sender=prvs=1254408a08=sender1@..., recipient=rcpt1@...
        > Sep 30 09:22:33 ares postfix/smtpd[23207]: DC9FE2C6101: client=am1ehsobe002.messaging.microsoft.com[213.199.154.205]
        > Sep 30 09:22:33 ares postfix/cleanup[23790]: DC9FE2C6101: message-id=<0FD46E70-F8B5-40A1-818B-3ABE7871A8A8@...>
        > Sep 30 09:22:34 ares postfix/qmgr[23383]: DC9FE2C6101: from=<prvs=1254408a08=sender1@...>, size=2824, nrcpt=2 (queue active)
        > Sep 30 09:22:34 ares postfix/smtpd[23207]: disconnect from am1ehsobe002.messaging.microsoft.com[213.199.154.205]
        > Sep 30 09:22:35 ares postfix/smtpd[23796]: connect from localhost[127.0.0.1]
        > Sep 30 09:22:35 ares postfix/smtpd[23796]: B00CF2C649F: client=localhost[127.0.0.1]
        > Sep 30 09:22:35 ares postfix/cleanup[23790]: B00CF2C649F: message-id=<0FD46E70-F8B5-40A1-818B-3ABE7871A8A8@...>
        > Sep 30 09:22:35 ares postfix/qmgr[23383]: B00CF2C649F: from=<prvs=1254408a08=sender1@...>, size=3407, nrcpt=3 (queue active)
        > Sep 30 09:22:35 ares postfix/smtpd[23796]: disconnect from localhost[127.0.0.1]
        > Sep 30 09:22:35 ares amavis[23051]: (23051-08) Passed CLEAN, [213.199.154.205] [193.138.69.163] <prvs=1254408a08=sender1@...> -> <"rcpt1@...,rcpt1@..."@...>,<rcpt1@...,rcpt1@...>, Message-ID: <0FD46E70-F8B5-40A1-818B-3ABE7871A8A8@...>, mail_id: uyNBYKR8Tz1s, Hits: -2.6, size: 2824, queued_as: B00CF2C649F, 1817 ms
        > Sep 30 09:22:35 ares postfix/smtp[23791]: DC9FE2C6101: to=<rcpt1@...,rcpt1@...@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=2, delays=0.19/0/0.01/1.8, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=23051-08, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as B00CF2C649F)
        > Sep 30 09:22:35 ares postfix/smtp[23791]: DC9FE2C6101: to=<rcpt1@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=2, delays=0.19/0/0.01/1.8, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=23051-08, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as B00CF2C649F)
        > Sep 30 09:22:35 ares postfix/qmgr[23383]: DC9FE2C6101: removed
        > Sep 30 09:22:35 ares postfix/pipe[23797]: B00CF2C649F: to=<rcpt1@...>, relay=maildrop, delay=0.22, delays=0.09/0.01/0/0.12, dsn=2.0.0, status=sent (delivered via maildrop service)
        > Sep 30 09:22:35 ares postfix/pickup[23053]: EE6662C64A7: uid=5000 from=<rcpt1@...>
        > Sep 30 09:22:35 ares postfix/cleanup[23790]: EE6662C64A7: message-id=<20110930072235.EE6662C64A7@...>
        > Sep 30 09:22:36 ares postfix/pipe[23817]: B00CF2C649F: to=<rcpt1@...,rcpt1@...@...>, relay=gnarwl, delay=0.3, delays=0.09/0.04/0/0.17, dsn=2.0.0, status=sent (delivered via gnarwl service)
        > Sep 30 09:22:36 ares postfix/pipe[23817]: B00CF2C649F: to=<rcpt1@...,rcpt1@...@...>, relay=gnarwl, delay=0.35, delays=0.09/0.04/0/0.22, dsn=2.0.0, status=sent (delivered via gnarwl service)
        > Sep 30 09:22:36 ares postfix/qmgr[23383]: B00CF2C649F: removed
        > Sep 30 09:22:36 ares postfix/qmgr[23383]: EE6662C64A7: from=<rcpt1@...>, size=935, nrcpt=1 (queue active)
        > Sep 30 09:22:40 ares postfix/smtpd[23796]: connect from localhost[127.0.0.1]
        > Sep 30 09:22:40 ares postfix/smtpd[23796]: F1F592C6101: client=localhost[127.0.0.1]
        > Sep 30 09:22:41 ares postfix/cleanup[23790]: F1F592C6101: message-id=<20110930072235.EE6662C64A7@...>
        > Sep 30 09:22:41 ares postfix/qmgr[23383]: F1F592C6101: from=<rcpt1@...>, size=1578, nrcpt=1 (queue active)
        > Sep 30 09:22:41 ares postfix/smtpd[23796]: disconnect from localhost[127.0.0.1]
        > Sep 30 09:22:41 ares amavis[23081]: (23081-08) Passed CLEAN, <rcpt1@...> -> <prvs@...>, Message-ID: <20110930072235.EE6662C64A7@...>, mail_id: Ie+WuC0MyE5S, Hits: -1.901, size: 933, queued_as: F1F592C6101, 5101 ms
        > Sep 30 09:22:41 ares postfix/smtp[23791]: EE6662C64A7: to=<prvs@...>, orig_to=<prvs>, relay=127.0.0.1[127.0.0.1]:10024, delay=5.3, delays=0.17/0/0.01/5.1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=23081-08, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as F1F592C6101)
        > Sep 30 09:22:41 ares postfix/qmgr[23383]: EE6662C64A7: removed
        > Sep 30 09:22:41 ares postfix/local[23824]: F1F592C6101: to=<prvs@...>, relay=local, delay=0.31, delays=0.17/0.05/0/0.09, dsn=5.1.1, status=bounced (unknown user: "prvs")
        > Sep 30 09:22:41 ares postfix/cleanup[23790]: 4A6A52C64A7: message-id=<20110930072241.4A6A52C64A7@...>
        > Sep 30 09:22:41 ares postfix/qmgr[23383]: 4A6A52C64A7: from=<>, size=3502, nrcpt=1 (queue active)
        > Sep 30 09:22:41 ares postfix/bounce[23825]: F1F592C6101: sender non-delivery notification: 4A6A52C64A7
        > Sep 30 09:22:41 ares postfix/qmgr[23383]: F1F592C6101: removed
        > Sep 30 09:22:41 ares postfix/pipe[23797]: 4A6A52C64A7: to=<rcpt1@...>, relay=maildrop, delay=0.16, delays=0.07/0.01/0/0.08, dsn=2.0.0, status=sent (delivered via maildrop service)
        > Sep 30 09:22:41 ares postfix/qmgr[23383]: 4A6A52C64A7: removed
        >
        > any ideas how i could fix this?
        > thank you in advance for your help

        i forgot to add my configuration in main.cf. here it is:

        # autoresponder
        recipient_bcc_maps = ldap:ar
        ar_server_host = ldap.intra.example.com
        ar_search_base = ou=domains,dc=intra,dc=example,dc=com
        ar_scope = sub
        ar_query_filter = (&(&(objectClass=CourierMailAccount)(vacationActive=TRUE))(mail=%s))
        ar_result_attribute = mail
        ar_result_format = %s,%s@...
        ar_version = 3

        jimmy
      • Simeon Ott
        ... any chance to get help for this? anyone uses gnarwl together with postfix and has similar problems? i d really appreciate any help or directions how i
        Message 3 of 17 , Oct 2, 2011
        • 0 Attachment
          On 30.09.2011, at 19:25, Simeon Ott wrote:

          > hello,
          >
          > i recently configured gnarwl autoresponder on my mailserver. the autoresponder works great as long as the sender doesn't use BATV. otherwise the autoresponded message is not delivered to the origin sender. is there a possibility to pipe another attribute then ${sender} in the master.cf?
          >
          > here are the relevant configuration parts:
          > master.cf:
          > gnarwl unix - n n - - pipe flags=F
          > user=vmail argv=/usr/bin/gnarwl -a ${user} -s ${sender}
          >
          > transport(.db)
          > autoreply.example.com gnarwl:
          >
          > gnarwl.cfg
          > # Name of the macro, refering to the "From:" field of a received mail map_sender $sender
          > # How to send mail. Specify full name to your MTA plus arguments. Only the
          > # map_sender and map_receiver macros are expanded. This program must be
          > # able to accept email from stdin.
          > # mta /usr/sbin/sendmail -F $recepient -t $sender
          > mta /usr/sbin/sendmail -f $recepient -F $recepient $sender
          >
          > if I send an email from a server which uses BATV verification (as microsoft does), in the following case «sender1@...», postfix pipes for the sender attribute something like this to gnarwl: <prvs=1254408a08=sender1@...>
          >
          > gnarwl picks this up and tries to send an autoresponse via mta. it failes with trying to send a message to <prvs>, which does not exist on the system.
          >
          >

          any chance to get help for this? anyone uses gnarwl together with postfix and has similar problems?

          i'd really appreciate any help or directions how i could find a solution.
        • Simeon Ott
          ... as suggested in the debugging how-to here is my postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no
          Message 4 of 17 , Oct 2, 2011
          • 0 Attachment
            On 30.09.2011, at 19:25, Simeon Ott wrote:

            > hello,
            >
            > i recently configured gnarwl autoresponder on my mailserver. the autoresponder works great as long as the sender doesn't use BATV. otherwise the autoresponded message is not delivered to the origin sender. is there a possibility to pipe another attribute then ${sender} in the master.cf?
            >
            > here are the relevant configuration parts:
            > master.cf:
            > gnarwl unix - n n - - pipe flags=F
            > user=vmail argv=/usr/bin/gnarwl -a ${user} -s ${sender}
            >
            > transport(.db)
            > autoreply.example.com gnarwl:
            >
            > gnarwl.cfg
            > # Name of the macro, refering to the "From:" field of a received mail map_sender $sender
            > # How to send mail. Specify full name to your MTA plus arguments. Only the
            > # map_sender and map_receiver macros are expanded. This program must be
            > # able to accept email from stdin.
            > # mta /usr/sbin/sendmail -F $recepient -t $sender
            > mta /usr/sbin/sendmail -f $recepient -F $recepient $sender
            >
            > if I send an email from a server which uses BATV verification (as microsoft does), in the following case «sender1@...», postfix pipes for the sender attribute something like this to gnarwl: <prvs=1254408a08=sender1@...>
            >
            > gnarwl picks this up and tries to send an autoresponse via mta. it failes with trying to send a message to <prvs>, which does not exist on the system.
            >
            > following the mail.log of the explained mail exchange

            as suggested in the debugging how-to here is my postconf -n

            alias_database = hash:/etc/aliases
            alias_maps = hash:/etc/aliases
            append_dot_mydomain = no
            best_mx_transport = local
            biff = no
            broken_sasl_auth_clients = yes
            command_directory = /usr/sbin
            config_directory = /etc/postfix
            content_filter = smtp-amavis:[127.0.0.1]:10024
            daemon_directory = /usr/lib/postfix
            disable_vrfy_command = yes
            html_directory = /usr/share/doc/postfix/html
            ignore_mx_lookup_error = yes
            inet_interfaces = localhost, mail.intra.example.com
            mailbox_command =
            mailbox_size_limit = 0
            message_size_limit = 15360000
            mydestination = ares, ares.intra.example.com, mail.intra.example.com, mail.example.com, localhost
            myhostname = ares.intra.example.com
            mynetworks = 127.0.0.0/8, 123.123.123.0/24
            readme_directory = /usr/share/doc/postfix
            recipient_bcc_maps = ldap:ar
            recipient_delimiter = +
            relayhost =
            setgid_group = postdrop
            smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
            smtpd_helo_required = yes
            smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service inet:[127.0.0.1]:10023, reject_rbl_client cbl.abuseat.org
            smtpd_sasl_auth_enable = yes
            smtpd_sasl_local_domain = example.com
            smtpd_sasl_security_options = noanonymous
            smtpd_tls_CAfile = /etc/postfix/tls/cacert.crt
            smtpd_tls_auth_only = yes
            smtpd_tls_cert_file = /etc/postfix/tls/mail.crt
            smtpd_tls_key_file = /etc/postfix/tls/mail.key
            smtpd_tls_loglevel = 3
            smtpd_tls_received_header = yes
            smtpd_tls_session_cache_timeout = 3600s
            smtpd_use_tls = yes
            transport_maps = hash:/etc/postfix/transport
            virtual_alias_maps = ldap:valias, ldap:vgroup
            virtual_gid_maps = static:5000
            virtual_mailbox_base = /var/spool/postfix/virtual
            virtual_mailbox_domains = ldap:vdomain
            virtual_mailbox_maps = ldap:vuser
            virtual_minimum_uid = 100
            virtual_transport = maildrop:
            virtual_uid_maps = static:5000
          • Wietse Venema
            ... The above shows that you provide gnarwl with the BATV-ed envelope sender address. You also mention that gnarwl replies to some different address but
            Message 5 of 17 , Oct 2, 2011
            • 0 Attachment
              Simeon Ott:
              > On 30.09.2011, at 19:25, Simeon Ott wrote:
              >
              > > hello,
              > >
              > > i recently configured gnarwl autoresponder on my mailserver. the
              > autoresponder works great as long as the sender doesn't use BATV.
              > otherwise the autoresponded message is not delivered to the origin
              > sender. is there a possibility to pipe another attribute then
              > ${sender} in the master.cf?
              > >
              > > here are the relevant configuration parts:
              > > master.cf:
              > > gnarwl unix - n n - - pipe flags=F
              > > user=vmail argv=/usr/bin/gnarwl -a ${user} -s ${sender}
              ...
              > Sep 30 09:22:35 ares postfix/qmgr[23383]: B00CF2C649F: from=<prvs=1254408a08=sender1@...>, size=3407, nrcpt=3 (queue active)
              > Sep 30 09:22:36 ares postfix/pipe[23817]: B00CF2C649F: to=<rcpt1@...,rcpt1@...@...>, relay=gnarwl, delay=0.3, delays=0.09/0.04/0/0.17, dsn=2.0.0, status=sent (delivered via gnarwl service)

              The above shows that you provide gnarwl with the BATV-ed envelope
              sender address.

              You also mention that gnarwl replies to some different address but
              provide no concrete evidence.

              If the sender really looks like
              <rcpt1@...,rcpt1@...@...>
              then that is badly malformed and that should be fixed first.

              To debug gnarwl, take an email message and invoke gnarwl by hand:

              $ gnarwl -a rcpt1@whatever -s prvs=whatever@whatever < email-message-file

              Then, observe what happens. If it does not reply to the sender
              that you specify, then gnarwl is mis-configured or broken.

              Wietse
            • Simeon Ott
              Thanks Wietse for your help! ... sorry, i have to clarify this.. if you have a look at the following logfile entries, there is some evidence Sep 30 09:22:41
              Message 6 of 17 , Oct 2, 2011
              • 0 Attachment
                Thanks Wietse for your help!

                On 02.10.2011, at 14:59, Wietse Venema wrote:

                > Simeon Ott:
                >> On 30.09.2011, at 19:25, Simeon Ott wrote:
                >>
                >>> hello,
                >>>
                >>> i recently configured gnarwl autoresponder on my mailserver. the
                >> autoresponder works great as long as the sender doesn't use BATV.
                >> otherwise the autoresponded message is not delivered to the origin
                >> sender. is there a possibility to pipe another attribute then
                >> ${sender} in the master.cf?
                >>>
                >>> here are the relevant configuration parts:
                >>> master.cf:
                >>> gnarwl unix - n n - - pipe flags=F
                >>> user=vmail argv=/usr/bin/gnarwl -a ${user} -s ${sender}
                > ...
                >> Sep 30 09:22:35 ares postfix/qmgr[23383]: B00CF2C649F: from=<prvs=1254408a08=sender1@...>, size=3407, nrcpt=3 (queue active)
                >> Sep 30 09:22:36 ares postfix/pipe[23817]: B00CF2C649F: to=<rcpt1@...,rcpt1@...@...>, relay=gnarwl, delay=0.3, delays=0.09/0.04/0/0.17, dsn=2.0.0, status=sent (delivered via gnarwl service)
                >
                > The above shows that you provide gnarwl with the BATV-ed envelope
                > sender address.
                >
                > You also mention that gnarwl replies to some different address but
                > provide no concrete evidence.

                sorry, i have to clarify this.. if you have a look at the following logfile entries, there is some evidence

                Sep 30 09:22:41 ares amavis[23081]: (23081-08) Passed CLEAN, <rcpt1@...> -> <prvs@...>, Message-ID: <20110930072235.EE6662C64A7@...>, mail_id: Ie+WuC0MyE5S, Hits: -1.901, size: 933, queued_as: F1F592C6101, 5101 ms
                Sep 30 09:22:41 ares postfix/smtp[23791]: EE6662C64A7: to=<prvs@...>, orig_to=<prvs>, relay=127.0.0.1[127.0.0.1]:10024, delay=5.3, delays=0.17/0/0.01/5.1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=23081-08, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as F1F592C6101)
                Sep 30 09:22:41 ares postfix/qmgr[23383]: EE6662C64A7: removed
                Sep 30 09:22:41 ares postfix/local[23824]: F1F592C6101: to=<prvs@...>, relay=local, delay=0.31, delays=0.17/0.05/0/0.09, dsn=5.1.1, status=bounced (unknown user: "prvs")

                these are the log entries from gnarwl after the mail is processed. GNARWL tries to send an email to prvs@... (localhost) instead of sender1@.... so the value is truncated at the equal sign.

                >
                > If the sender really looks like
                > <rcpt1@...,rcpt1@...@...>
                > then that is badly malformed and that should be fixed first.
                >

                that was indeed a misconfiguration and I fixed it. thank you to point this out.

                > To debug gnarwl, take an email message and invoke gnarwl by hand:
                >
                > $ gnarwl -a rcpt1@whatever -s prvs=whatever@whatever < email-message-file
                >
                > Then, observe what happens. If it does not reply to the sender
                > that you specify, then gnarwl is mis-configured or broken.
                >
                > Wietse

                i invoked gnarwl by hand and the same thing happend. it sends an email to <prvs> instead of whatever@whatever. i can't change this behavior in gnarwl that's why i was looking for another solution to pass the senders email address instead of the batv-ed envelope from. any suggestions?
              • Wietse Venema
                ... What happens when you send mail by hand to prvs=whatever@whatever? $ echo this is a test | /usr/sbin/sendmail prvs=whatever@whatever Wietse
                Message 7 of 17 , Oct 2, 2011
                • 0 Attachment
                  > i invoked gnarwl by hand and the same thing happend. it sends an
                  > email to <prvs> instead of whatever@whatever.

                  What happens when you send mail by hand to prvs=whatever@whatever?

                  $ echo this is a test | /usr/sbin/sendmail prvs=whatever@whatever

                  Wietse
                • Simeon Ott
                  ... i tried the following: $ echo this is a test | /usr/sbin/sendmail prvs=1254408a08=simeon_ott@stud.phzh.ch and that s the result: Oct 2 18:54:03 ares
                  Message 8 of 17 , Oct 2, 2011
                  • 0 Attachment
                    On 02.10.2011, at 16:20, Wietse Venema wrote:

                    >> i invoked gnarwl by hand and the same thing happend. it sends an
                    >> email to <prvs> instead of whatever@whatever.
                    >
                    > What happens when you send mail by hand to prvs=whatever@whatever?
                    >
                    > $ echo this is a test | /usr/sbin/sendmail prvs=whatever@whatever
                    >
                    > Wietse

                    i tried the following: $ echo this is a test | /usr/sbin/sendmail prvs=1254408a08=simeon_ott@...

                    and that's the result:
                    Oct 2 18:54:03 ares postfix/pickup[17132]: 252D12C64B1: uid=0 from=<root>
                    Oct 2 18:54:03 ares postfix/cleanup[17716]: 252D12C64B1: message-id=<20111002165403.252D12C64B1@...>
                    Oct 2 18:54:03 ares postfix/qmgr[14003]: 252D12C64B1: from=<root@...>, size=311, nrcpt=1 (queue active)
                    Oct 2 18:54:04 ares postfix/smtpd[17721]: initializing the server-side TLS engine
                    Oct 2 18:54:04 ares postfix/smtpd[17721]: connect from localhost[127.0.0.1]
                    Oct 2 18:54:04 ares postfix/smtpd[17721]: 1795B2C64AC: client=localhost[127.0.0.1]
                    Oct 2 18:54:04 ares postfix/cleanup[17716]: 1795B2C64AC: message-id=<20111002165403.252D12C64B1@...>
                    Oct 2 18:54:04 ares postfix/qmgr[14003]: 1795B2C64AC: from=<root@...>, size=1012, nrcpt=1 (queue active)
                    Oct 2 18:54:04 ares postfix/smtpd[17721]: disconnect from localhost[127.0.0.1]
                    Oct 2 18:54:04 ares amavis[14768]: (14768-11) Passed CLEAN, <root@...> -> <prvs=1254408a08=simeon_ott@...>, Message-ID: <20111002165403.252D12C64B1@...>, mail_id: tHQF5WA-fWx1, Hits: -0.102, size: 311, queued_as: 1795B2C64AC, 1033 ms
                    Oct 2 18:54:04 ares postfix/smtp[17717]: 252D12C64B1: to=<prvs=1254408a08=simeon_ott@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.3, delays=0.21/0.01/0.01/1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=14768-11, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 1795B2C64AC)
                    Oct 2 18:54:04 ares postfix/qmgr[14003]: 252D12C64B1: removed
                    Oct 2 18:54:05 ares postfix/smtp[17722]: 1795B2C64AC: to=<prvs=1254408a08=simeon_ott@...>, 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.252D12C64B1@...> [InternalId=25661879] Queued mail for delivery)
                    Oct 2 18:54:05 ares postfix/qmgr[14003]: 1795B2C64AC: removed

                    that's what i'm looking for. does this mean that GNARWL is doing something wrong when batv encoded addresses are used?

                    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])"

                    ... i thought there has to be another option beside from patching sources of a debian stable package.

                    thanks for your help
                  • Wietse Venema
                    ... 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
                    Message 9 of 17 , Oct 2, 2011
                    • 0 Attachment
                      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_ott@...>, 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.252D12C64B1@...> [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.

                      Wietse
                    • Simeon Ott
                      ... 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
                      Message 10 of 17 , Oct 2, 2011
                      • 0 Attachment
                        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_ott@...>, 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.252D12C64B1@...> [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
                      • Wietse Venema
                        ... First, few sites use BATV. Second, BATV works perfectly fine with autoresponders that adhere to mail standards: a) reply to the envelope sender address,
                        Message 11 of 17 , Oct 2, 2011
                        • 0 Attachment
                          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
                        • Simeon Ott
                          ... 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
                          Message 12 of 17 , Oct 3, 2011
                          • 0 Attachment
                            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.

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

                            master.cf: changing the following line from ...
                            gnarwl unix - n n - - pipe flags=F user=vmail argv=/usr/bin/gnarwl -a ${user} -s ${sender}

                            to ...
                            gnarwl unix - n n - - pipe flags=F user=vmail argv=/usr/bin/gnarwl -a ${user}

                            .. did the job.
                          • 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 13 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 14 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 15 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 16 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 17 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.