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

Problems with new postfix servers

Expand Messages
  • R. Berger
    postconf -n address_verify_sender = postmaster@domain.nl alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no
    Message 1 of 14 , Jan 7, 2014
    • 0 Attachment
      postconf -n

      address_verify_sender = postmaster@...
      alias_database = hash:/etc/aliases
      alias_maps = hash:/etc/aliases
      append_dot_mydomain = no
      biff = no
      config_directory = /etc/postfix
      disable_vrfy_command = yes
      empty_address_recipient = postmaster@...
      header_checks = regexp:/etc/postfix/header_checks
      html_directory = /usr/share/doc/postfix/html
      inet_interfaces = all
      local_recipient_maps =
      local_transport = error:No local mail delivery
      mailbox_command = procmail -a "$EXTENSION"
      mailbox_size_limit = 0
      maximal_queue_lifetime = 30d
      message_size_limit = 31457280
      mydestination =
      myhostname = bsd5.domain.net
      mynetworks = 127.0.0.0/8 [::1]/128 83.96.158.128/25
      myorigin = nedport.net
      postscreen_access_list = permit_mynetworks
      postscreen_dnsbl_action = enforce
      postscreen_dnsbl_sites = b.barracudacentral.org*2, zen.spamhaus.org*3,
      bl.spamcop.net*1, psbl.surriel.com*1, dnsbl.ahbl.org*2,
      bl.spameatingmonkey.net*1, virbl.dnsbl.bit.nl*3
      postscreen_dnsbl_threshold = 3
      postscreen_greet_action = enforce
      readme_directory = /usr/share/doc/postfix
      recipient_delimiter = +
      relay_domains = mysql:/etc/postfix/mysql-relay_domains.cf
      relay_recipient_maps = mysql:/etc/postfix/mysql-relay_recipients.cf
      relayhost =
      smtpd_banner = myname.net ESMTP Mailgateway
      smtpd_client_restrictions = permit_sasl_authenticated,
      permit_mynetworks, permit
      smtpd_data_restrictions = permit_mynetworks, reject_unauth_pipelining
      smtpd_delay_reject = yes
      smtpd_helo_required = yes
      smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks,
      permit
      smtpd_recipient_limit = 200
      smtpd_recipient_restrictions = permit_mynetworks,
      reject_unauth_destination, reject_unknown_recipient_domain,
      reject_unverified_recipient, whitelist_policy, permit
      smtpd_restriction_classes = whitelist_policy
      smtpd_sender_restrictions = permit_mynetworks,
      permit_sasl_authenticated, reject_non_fqdn_sender,
      reject_unknown_sender_domain, permit
      strict_rfc821_envelopes = no
      transport_maps = mysql:/etc/postfix/mysql-transports.cf
      virtual_alias_maps = hash:/etc/postfix/virtual
      whitelist_policy = check_client_access
      mysql:/etc/postfix/mysql-global_whitelist.cf, check_sender_access
      mysql:/etc/postfix/mysql-global_whitelist.cf
      --------------------------------------------------------

      I have migrated 2 sendmail servers to postfix/dovecot servers using the
      spamsnake tutorial. The first server runs the spamsnake and the second
      handles the mail for the clients.
      I tested it for a while and it seemed to run ok, but after turning it
      in production i got a few errors.
      -The biggest problem now is that some clients can't get their email
      using their exchange 2008 pop connector, because it stop after 5
      messages with corrupt headers. I don't know where this comes from or to
      find a solution. This is a sample header:

      Return-Path: <MAILER-DAEMON>
      Delivered-To: info.test@...
      Received: from bsd5.domain.net (bsd5.domain.net [83.x.x.x])
      by mail.domain.net (Postfix) with ESMTP id 56C771B53204
      for <info@...>; Tue, 7 Jan 2014 14:22:10 +0100 (CET)
      Received: by bsd5.domain.net (Postfix)
      id 2A62AA41455; Tue, 7 Jan 2014 14:22:04 +0100 (CET)
      Date: Tue, 7 Jan 2014 14:22:04 +0100 (CET)
      From: MAILER-DAEMON@... (Mail Delivery System)
      Subject: Undelivered Mail Returned to Sender
      To: info@...
      Auto-Submitted: auto-replied
      MIME-Version: 1.0
      Content-Type: multipart/report; report-type=delivery-status;
      boundary="21EA9A41450.1389100924/bsd5.domain.net"
      Content-Transfer-Encoding: 8bit
      Message-Id: <20140107132204.2A62AA41455@...>

      This is a MIME-encapsulated message.
      etc..

      second problem is that on the first server (spamsnake) I get sometimes this error:

      Jan 7 14:56:56 bsd5 postfix/error[7639]: 0BF47A41459: to=<carla@...>, relay=none, delay=20, delays=20/0/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error)

      when it happens I got several messages in about a minute and then it
      stops. the messsages are resend without a problem after about 9 minutes.

      Third problem is that I have reject_unverified_recipient enabled but it
      is not working I have one domain which receives about 100 mails an hour
      off which 99 are spam. the use only one emailaccount (no catchall) but
      the mail is refused at the second server after it has gone through the
      spamsnake. This was working ok, but I don't know what I did to break
      this ;-)

      Thanks,

      Roger
    • Wietse Venema
      ... I suggest that this is a question for the Dovecot mailing list. ... Look for an error/fatal/panic record BEFORE these.
      Message 2 of 14 , Jan 7, 2014
      • 0 Attachment
        R. Berger:
        > -The biggest problem now is that some clients can't get their email
        > using their exchange 2008 pop connector, because it stop after 5
        > messages with corrupt headers. I don't know where this comes from or to
        > find a solution. This is a sample header:

        I suggest that this is a question for the Dovecot mailing list.

        > second problem is that on the first server (spamsnake) I get sometimes this error:
        >
        > Jan 7 14:56:56 bsd5 postfix/error[7639]: 0BF47A41459: to=<carla@...>, relay=none, delay=20, delays=20/0/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error)

        Look for an error/fatal/panic record BEFORE these.

        http://www.postfix.org/DEBUG_README.html#logging

        Look for obvious signs of trouble

        Postfix logs all failed and successful deliveries to a logfile. The
        file is usually called /var/log/maillog or /var/log/mail; the exact
        pathname is defined in the /etc/syslog.conf file.

        When Postfix does not receive or deliver mail, the first order of
        business is to look for errors that prevent Postfix from working
        properly:

        % egrep '(warning|error|fatal|panic):' /some/log/file | more

        Note: the most important message is near the BEGINNING of the output.
        Error messages that come later are less useful.

        The nature of each problem is indicated as follows:

        * "panic" indicates a problem in the software itself that only a
        programmer can fix. Postfix cannot proceed until this is fixed.

        * "fatal" is the result of missing files, incorrect permissions,
        incorrect configuration file settings that you can fix. Postfix
        cannot proceed until this is fixed.

        * "error" reports an error condition. For safety reasons, a Postfix
        process will terminate when more than 13 of these happen.

        * "warning" indicates a non-fatal error. These are problems that
        you may not be able to fix (such as a broken DNS server elsewhere
        on the network) but may also indicate local configuration errors
        that could become a problem later.

        > Third problem is that I have reject_unverified_recipient enabled but it
        > is not working I have one domain which receives about 100 mails an hour
        > off which 99 are spam. the use only one emailaccount (no catchall) but
        > the mail is refused at the second server after it has gone through the
        > spamsnake. This was working ok, but I don't know what I did to break
        > this ;-)

        Unfortunately, there is not enough concrete content that allows
        anyone to reproduce this.

        Wietse
      • R. Berger
        ... I am not sure. Googling shows me several of the problem, all pointing to postfix and none pointing to dovecot. The problem is the Return-Path:
        Message 3 of 14 , Jan 7, 2014
        • 0 Attachment
          Wietse Venema schreef op 7-1-2014 19:42:
          > R. Berger:
          >> -The biggest problem now is that some clients can't get their email
          >> using their exchange 2008 pop connector, because it stop after 5
          >> messages with corrupt headers. I don't know where this comes from or to
          >> find a solution. This is a sample header:
          > I suggest that this is a question for the Dovecot mailing list.
          I am not sure. Googling shows me several of the problem, all pointing to
          postfix and none pointing to dovecot. The problem is the "Return-Path:
          <MAILER-DAEMON>" header which is not confirming RFC2821 (I think) and
          therefore refused by Exchange when delivered by the popconnector.
          >
          >> second problem is that on the first server (spamsnake) I get sometimes this error:
          >>
          >> Jan 7 14:56:56 bsd5 postfix/error[7639]: 0BF47A41459: to=<carla@...>, relay=none, delay=20, delays=20/0/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error)
          > Look for an error/fatal/panic record BEFORE these.
          >
          > http://www.postfix.org/DEBUG_README.html#logging
          >
          > Look for obvious signs of trouble
          >
          > Postfix logs all failed and successful deliveries to a logfile. The
          > file is usually called /var/log/maillog or /var/log/mail; the exact
          > pathname is defined in the /etc/syslog.conf file.
          >
          > When Postfix does not receive or deliver mail, the first order of
          > business is to look for errors that prevent Postfix from working
          > properly:
          >
          > % egrep '(warning|error|fatal|panic):' /some/log/file | more
          >
          > Note: the most important message is near the BEGINNING of the output.
          > Error messages that come later are less useful.
          >
          > The nature of each problem is indicated as follows:
          >
          > * "panic" indicates a problem in the software itself that only a
          > programmer can fix. Postfix cannot proceed until this is fixed.
          >
          > * "fatal" is the result of missing files, incorrect permissions,
          > incorrect configuration file settings that you can fix. Postfix
          > cannot proceed until this is fixed.
          >
          > * "error" reports an error condition. For safety reasons, a Postfix
          > process will terminate when more than 13 of these happen.
          >
          > * "warning" indicates a non-fatal error. These are problems that
          > you may not be able to fix (such as a broken DNS server elsewhere
          > on the network) but may also indicate local configuration errors
          > that could become a problem later.

          OK, I found these:
          Jan 7 20:42:47 bsd5 postfix/smtpd[32633]: warning: hostname
          server.alleactiesophetweb.com does not resolve to address 178.18.86.76:
          Name or service not known
          Jan 7 20:42:50 bsd5 postfix/smtp[717]: fatal: garbage after numerical
          service in server description: [217.195.119.6]:25,smtp:[217.195.119.6]:25
          Jan 7 20:42:50 bsd5 postfix/smtp[718]: fatal: garbage after numerical
          service in server description: [217.195.119.6]:25,smtp:[217.195.119.6]:25
          Jan 7 20:42:50 bsd5 postfix/smtp[719]: fatal: garbage after numerical
          service in server description: [217.195.119.6]:25,smtp:[217.195.119.6]:25
          Jan 7 20:42:51 bsd5 postfix/qmgr[19731]: warning: private/smtp socket:
          malformed response
          Jan 7 20:42:51 bsd5 postfix/qmgr[19731]: warning: transport smtp
          failure -- see a previous warning/fatal/panic logfile record for the
          problem description
          Jan 7 20:42:51 bsd5 postfix/master[19724]: warning: process
          /usr/lib/postfix/smtp pid 717 exit status 1
          Jan 7 20:42:51 bsd5 postfix/master[19724]: warning:
          /usr/lib/postfix/smtp: bad command startup -- throttling
          Jan 7 20:42:51 bsd5 postfix/qmgr[19731]: warning: private/smtp socket:
          malformed response
          Jan 7 20:42:51 bsd5 postfix/qmgr[19731]: warning: transport smtp
          failure -- see a previous warning/fatal/panic logfile record for the
          problem description
          Jan 7 20:42:51 bsd5 postfix/master[19724]: warning: process
          /usr/lib/postfix/smtp pid 718 exit status 1
          Jan 7 20:42:51 bsd5 postfix/qmgr[19731]: warning: private/smtp socket:
          malformed response
          Jan 7 20:42:51 bsd5 postfix/qmgr[19731]: warning: transport smtp
          failure -- see a previous warning/fatal/panic logfile record for the
          problem description
          Jan 7 20:42:51 bsd5 postfix/master[19724]: warning: process
          /usr/lib/postfix/smtp pid 719 exit status 1
          Jan 7 20:44:34 bsd5 postfix/smtpd[31300]: warning: hostname
          ktm.magnumhost.net does not resolve to address 69.64.64.71: Name or
          service not known

          >
          >> Third problem is that I have reject_unverified_recipient enabled but it
          >> is not working I have one domain which receives about 100 mails an hour
          >> off which 99 are spam. the use only one emailaccount (no catchall) but
          >> the mail is refused at the second server after it has gone through the
          >> spamsnake. This was working ok, but I don't know what I did to break
          >> this ;-)
          > Unfortunately, there is not enough concrete content that allows
          > anyone to reproduce this.
          Working:
          Jan 7 16:19:27 bsd5 postfix/smtpd[13920]: connect from
          summer2.hostnet.nl[91.184.19.58]
          Jan 7 16:19:27 bsd5 postfix/cleanup[13923]: 1DCA1A412D2:
          message-id=<20140107151927.1DCA1A412D2@...>
          Jan 7 16:19:27 bsd5 postfix/qmgr[3929]: 1DCA1A412D2:
          from=<postmaster@...>, size=226, nrcpt=1 (queue active)
          Jan 7 16:19:27 bsd5 postfix/smtp[14158]: 1DCA1A412D2:
          to=<info@...>, relay=31.151.138.50[31.151.138.50]:25,
          delay=0.35, delays=0/0/0.26/0.09, dsn=5.1.1, status=undeliverable (host
          31.151.138.50[31.151.138.50] said: 550 5.1.1 <info@...>:
          Recipient address rejected: User unknown in local recipient table (in
          reply to RCPT TO command))
          Jan 7 16:19:27 bsd5 postfix/qmgr[3929]: 1DCA1A412D2: removed
          Jan 7 16:19:29 bsd5 postfix/smtpd[11781]: disconnect from
          mx2.digitalrevolution.nl[193.164.144.11]
          Jan 7 16:19:30 bsd5 postfix/postscreen[3930]: PASS NEW
          [217.92.229.18]:12733
          Jan 7 16:19:30 bsd5 postfix/smtpd[13920]: NOQUEUE: reject: RCPT from
          summer2.hostnet.nl[91.184.19.58]: 450 4.1.1 <info@...>:
          Recipient address rejected: unverified address: host
          31.151.138.50[31.151.138.50] said: 550 5.1.1 <info@...>:
          Recipient address rejected: User unknown in local recipient table (in
          reply to RCPT TO command); from=<mieke@...>
          to=<info@...> proto=ESMTP helo=<summer2.hostnet.nl>
          Jan 7 16:19:30 bsd5 postfix/smtpd[13920]: disconnect from
          summer2.hostnet.nl[91.184.19.58]

          Not working:
          Jan 7 21:09:28 bsd5 postfix/smtpd[32230]: 657CDA4128E:
          client=outmail014.prn2.facebook.com[66.220.144.141]
          Jan 7 21:09:28 bsd5 postfix/cleanup[1318]: 657CDA4128E: hold: header
          Received: from mx-out.facebook.com (outmail014.prn2.facebook.com
          [66.220.144.141])??by bsd5.domain.net (Postfix) with ESMTP id
          657CDA4128E??for <nikola_1995@...>; Tue, 7 Jan 2014 21:09:28
          +0100 from outmail014.prn2.facebook.com[66.220.144.141];
          from=<update+zj4o4yjsy09c@...> to=<nikola_1995@...>
          proto=ESMTP helo=<mx-out.facebook.com>
          Jan 7 21:09:28 bsd5 postfix/cleanup[1318]: 657CDA4128E:
          message-id=<493f1c6806a0a3360ea2e930a6c9ee0d@...>
          Jan 7 21:09:33 bsd5 MailScanner[1590]: Requeue: 657CDA4128E.AFEBB to
          8F25CA40953
          Jan 7 21:09:33 bsd5 MailScanner[1590]: Requeue: 657CDA4128E.AFEBB to
          8F25CA40953
          Jan 7 21:09:33 bsd5 postfix/qmgr[19731]: 8F25CA40953:
          from=<update+zj4o4yjsy09c@...>, size=11166, nrcpt=1 (queue
          active)
          Jan 7 21:09:33 bsd5 postfix/smtp[2393]: 8F25CA40953:
          to=<nikola_1995@...>, relay=bsd4.domain.net[83.96.158.143]:25,
          delay=4.8, delays=4.8/0/0.02/0, dsn=2.0.0, status=sent (250 2.0.0 Ok:
          queued as D65871B530AC)

          Can you see anything in this?

          Thanks so far Wietse.


          >
          > Wietse
          Thanks so far Wietse,
        • Wietse Venema
          ... What concrete evidence do you have that Return-Path: trips up exchange? I find this hard to believe. I recall Microsoft having
          Message 4 of 14 , Jan 7, 2014
          • 0 Attachment
            R. Berger:
            > -The biggest problem now is that some clients can't get their email
            > using their exchange 2008 pop connector, because it stop after 5
            > messages with corrupt headers. I don't know where this comes from or to
            > find a solution. This is a sample header:

            Wietse:
            > I suggest that this is a question for the Dovecot mailing list.

            R. Berger:
            > I am not sure. Googling shows me several of the problem, all pointing to
            > postfix and none pointing to dovecot. The problem is the "Return-Path:
            > <MAILER-DAEMON>" header which is not confirming RFC2821 (I think) and
            > therefore refused by Exchange when delivered by the popconnector.

            What concrete evidence do you have that "Return-Path: <MAILER-DAEMON>"
            trips up exchange? I find this hard to believe. I recall Microsoft
            having difficulties with null bytes in headers.

            > Jan 7 20:42:50 bsd5 postfix/smtp[717]: fatal: garbage after numerical
            > service in server description: [217.195.119.6]:25,smtp:[217.195.119.6]:25

            See the Postfix documentation for relayhost syntax.

            > Not working:
            > Jan 7 21:09:28 bsd5 postfix/smtpd[32230]: 657CDA4128E:
            > client=outmail014.prn2.facebook.com[66.220.144.141]
            > Jan 7 21:09:28 bsd5 postfix/cleanup[1318]: 657CDA4128E: hold: header
            > Received: from mx-out.facebook.com (outmail014.prn2.facebook.com
            > [66.220.144.141])??by bsd5.domain.net (Postfix) with ESMTP id
            > 657CDA4128E??for <nikola_1995@...>; Tue, 7 Jan 2014 21:09:28
            > +0100 from outmail014.prn2.facebook.com[66.220.144.141];
            > from=<update+zj4o4yjsy09c@...> to=<nikola_1995@...>
            > proto=ESMTP helo=<mx-out.facebook.com>
            > Jan 7 21:09:28 bsd5 postfix/cleanup[1318]: 657CDA4128E:
            > message-id=<493f1c6806a0a3360ea2e930a6c9ee0d@...>
            > Jan 7 21:09:33 bsd5 MailScanner[1590]: Requeue: 657CDA4128E.AFEBB to
            > 8F25CA40953
            > Jan 7 21:09:33 bsd5 MailScanner[1590]: Requeue: 657CDA4128E.AFEBB to
            > 8F25CA40953
            > Jan 7 21:09:33 bsd5 postfix/qmgr[19731]: 8F25CA40953:
            > from=<update+zj4o4yjsy09c@...>, size=11166, nrcpt=1 (queue
            > active)
            > Jan 7 21:09:33 bsd5 postfix/smtp[2393]: 8F25CA40953:
            > to=<nikola_1995@...>, relay=bsd4.domain.net[83.96.158.143]:25,
            > delay=4.8, delays=4.8/0/0.02/0, dsn=2.0.0, status=sent (250 2.0.0 Ok:
            > queued as D65871B530AC)
            >
            > Can you see anything in this?

            Your "working" example rejects mail for an unknown LOCAL recipient,
            whereas the "not working" example accepts and forwards mail for a
            REMOTE recipient. What is wrong with that?

            Wietse
          • Viktor Dukhovni
            ... This is easy to verify, just set the null_sender pipe(8) option in the LDA transport correctly, after carefully reading the pipe(8) documentation. --
            Message 5 of 14 , Jan 7, 2014
            • 0 Attachment
              On Tue, Jan 07, 2014 at 04:49:56PM -0500, Wietse Venema wrote:

              > R. Berger:
              > > -The biggest problem now is that some clients can't get their email
              > > using their exchange 2008 pop connector, because it stop after 5
              > > messages with corrupt headers. I don't know where this comes from or to
              > > find a solution. This is a sample header:
              >
              > Wietse:
              > > I suggest that this is a question for the Dovecot mailing list.
              >
              > R. Berger:
              > > I am not sure. Googling shows me several of the problem, all pointing to
              > > postfix and none pointing to dovecot. The problem is the "Return-Path:
              > > <MAILER-DAEMON>" header which is not confirming RFC2821 (I think) and
              > > therefore refused by Exchange when delivered by the popconnector.
              >
              > What concrete evidence do you have that "Return-Path: <MAILER-DAEMON>"
              > trips up exchange? I find this hard to believe. I recall Microsoft
              > having difficulties with null bytes in headers.

              This is easy to verify, just set the null_sender pipe(8) option in
              the LDA transport correctly, after carefully reading the pipe(8)
              documentation.

              --
              Viktor.
            • R. Berger
              ... Nothing really, but that is the only thing that comes up while googling. The error on the exchange server (popconnector log) is: [t 0] 01/07/14, 22:59:06:
              Message 6 of 14 , Jan 7, 2014
              • 0 Attachment

                Wietse Venema schreef op 7-1-2014 22:49:
                R. Berger:
                
                -The biggest problem now is that some clients can't get their email
                using their exchange 2008 pop connector, because it stop after 5
                messages with corrupt headers. I don't know where this comes from or to
                find a solution.  This is a sample header:
                
                Wietse:
                
                I suggest that this is a question for the Dovecot mailing list.
                
                R. Berger:
                
                I am not sure. Googling shows me several of the problem, all pointing to 
                postfix and none pointing to dovecot. The problem is the  "Return-Path: 
                <MAILER-DAEMON>" header which is not confirming RFC2821 (I think) and 
                therefore refused by Exchange when delivered by the popconnector.
                
                What concrete evidence do you have that "Return-Path: <MAILER-DAEMON>"
                trips up exchange? I find this hard to believe. I recall Microsoft
                having difficulties with null bytes in headers.
                
                Nothing really, but that is the only thing that comes up while googling.
                The error on the exchange server (popconnector log) is:
                [t 0] 01/07/14, 22:59:06: EVENT: One or more (4) e-mail messages in the POP3 mailbox account 'info.domain' on the POP3 server 'mail.domain.nl' have invalid header fields. Because of this, the messages cannot be delivered to the Exchange Server mailbox 'info@...' in Windows Small Business Server. The messages are still on the POP3 server. To resolve this issue, connect to the POP3 mailbox account, and then manually retrieve or delete the messages.
                [t 0] 01/07/14, 23:03:36: Error: The "MAIL FROM" address ("MAILER-DAEMON", from header field "Return-Path") was rejected. Continuing.
                So it leaves the mails on the server and when there are more than 5 such mails it completely stops. If I understand right, the Return-Path has to be an emailaddress by RFC, but it is commonly used with just Mailer-Daemon for spamming reasons.

                Jan  7 20:42:50 bsd5 postfix/smtp[717]: fatal: garbage after numerical 
                service in server description: [217.195.119.6]:25,smtp:[217.195.119.6]:25
                
                See the Postfix documentation for relayhost syntax.
                Thanks,
                I'll check it. I saw also that all those fatal are on the same server.

                
                
                Not working:
                Jan  7 21:09:28 bsd5 postfix/smtpd[32230]: 657CDA4128E: 
                client=outmail014.prn2.facebook.com[66.220.144.141]
                Jan  7 21:09:28 bsd5 postfix/cleanup[1318]: 657CDA4128E: hold: header 
                Received: from mx-out.facebook.com (outmail014.prn2.facebook.com 
                [66.220.144.141])??by bsd5.domain.net (Postfix) with ESMTP id 
                657CDA4128E??for <nikola_1995@...>; Tue,  7 Jan 2014 21:09:28 
                +0100 from outmail014.prn2.facebook.com[66.220.144.141]; 
                from=<update+zj4o4yjsy09c@...> to=<nikola_1995@...> 
                proto=ESMTP helo=<mx-out.facebook.com>
                Jan  7 21:09:28 bsd5 postfix/cleanup[1318]: 657CDA4128E: 
                message-id=<493f1c6806a0a3360ea2e930a6c9ee0d@...>
                Jan  7 21:09:33 bsd5 MailScanner[1590]: Requeue: 657CDA4128E.AFEBB to 
                8F25CA40953
                Jan  7 21:09:33 bsd5 MailScanner[1590]: Requeue: 657CDA4128E.AFEBB to 
                8F25CA40953
                Jan  7 21:09:33 bsd5 postfix/qmgr[19731]: 8F25CA40953: 
                from=<update+zj4o4yjsy09c@...>, size=11166, nrcpt=1 (queue 
                active)
                Jan  7 21:09:33 bsd5 postfix/smtp[2393]: 8F25CA40953: 
                to=<nikola_1995@...>, relay=bsd4.domain.net[83.96.158.143]:25, 
                delay=4.8, delays=4.8/0/0.02/0, dsn=2.0.0, status=sent (250 2.0.0 Ok: 
                queued as D65871B530AC)
                
                Can you see anything in this?
                
                Your "working" example rejects mail for an unknown LOCAL recipient,
                whereas the "not working" example accepts and forwards mail for a
                REMOTE recipient.  What is wrong with that?
                Well, there are no local users and the remote recipient doesn't exist and should be rejected.
                
                	Wietse
                

              • R. Berger
                ... I allready tried that. I have this in my master: maildrop unix - n n - - pipe flags=DRhu null_sender=postmaster@domain.net
                Message 7 of 14 , Jan 7, 2014
                • 0 Attachment
                  Viktor Dukhovni schreef op 7-1-2014 22:58:
                  > On Tue, Jan 07, 2014 at 04:49:56PM -0500, Wietse Venema wrote:
                  >
                  >> R. Berger:
                  >>> -The biggest problem now is that some clients can't get their email
                  >>> using their exchange 2008 pop connector, because it stop after 5
                  >>> messages with corrupt headers. I don't know where this comes from or to
                  >>> find a solution. This is a sample header:
                  >> Wietse:
                  >>> I suggest that this is a question for the Dovecot mailing list.
                  >> R. Berger:
                  >>> I am not sure. Googling shows me several of the problem, all pointing to
                  >>> postfix and none pointing to dovecot. The problem is the "Return-Path:
                  >>> <MAILER-DAEMON>" header which is not confirming RFC2821 (I think) and
                  >>> therefore refused by Exchange when delivered by the popconnector.
                  >> What concrete evidence do you have that "Return-Path: <MAILER-DAEMON>"
                  >> trips up exchange? I find this hard to believe. I recall Microsoft
                  >> having difficulties with null bytes in headers.
                  > This is easy to verify, just set the null_sender pipe(8) option in
                  > the LDA transport correctly, after carefully reading the pipe(8)
                  > documentation.
                  I allready tried that. I have this in my master:
                  maildrop unix - n n - - pipe
                  flags=DRhu null_sender=postmaster@... user=vmail
                  argv=/usr/bin/maildrop -d ${recipient}
                • Viktor Dukhovni
                  ... NEVER set the null sender to a real mailbox. This creates mail loops. It MUST be either MAILER-DAEMON or empty. If however, a valid email address did
                  Message 8 of 14 , Jan 7, 2014
                  • 0 Attachment
                    On Tue, Jan 07, 2014 at 11:17:01PM +0100, R. Berger wrote:

                    > >This is easy to verify, just set the null_sender pipe(8) option in
                    > >the LDA transport correctly, after carefully reading the pipe(8)
                    > >documentation.
                    >
                    > I allready tried that. I have this in my master:

                    > maildrop unix - n n - - pipe
                    > flags=DRhu null_sender=postmaster@... user=vmail
                    > argv=/usr/bin/maildrop -d ${recipient}

                    NEVER set the null sender to a real mailbox. This creates mail
                    loops. It MUST be either "MAILER-DAEMON" or empty.

                    If however, a valid email address did not address the POP clients,
                    then MAILER-DAEMON is NOT the problem. You really need to look at
                    the interaction between the POP client and server, neither of which
                    is Postfix.

                    --
                    Viktor.
                  • R. Berger
                    ... I ve removed the null_sender from master.cf but can t see any change in the Return-Path of the NDR s Thanks, Roger
                    Message 9 of 14 , Jan 7, 2014
                    • 0 Attachment
                      Viktor Dukhovni schreef op 7-1-2014 23:22:
                      > On Tue, Jan 07, 2014 at 11:17:01PM +0100, R. Berger wrote:
                      >
                      >>> This is easy to verify, just set the null_sender pipe(8) option in
                      >>> the LDA transport correctly, after carefully reading the pipe(8)
                      >>> documentation.
                      >> I allready tried that. I have this in my master:
                      >> maildrop unix - n n - - pipe
                      >> flags=DRhu null_sender=postmaster@... user=vmail
                      >> argv=/usr/bin/maildrop -d ${recipient}
                      > NEVER set the null sender to a real mailbox. This creates mail
                      > loops. It MUST be either "MAILER-DAEMON" or empty.
                      >
                      > If however, a valid email address did not address the POP clients,
                      > then MAILER-DAEMON is NOT the problem. You really need to look at
                      > the interaction between the POP client and server, neither of which
                      > is Postfix.
                      >
                      I've removed the null_sender from master.cf but can't see any change in
                      the Return-Path of the NDR's
                      Thanks,
                      Roger
                    • Viktor Dukhovni
                      ... NO DO NOT REMOVE from master.cf, rather set it EMPTY! mytransport unix - n n - - pipe flags=ORDq user=nobody null_sender=
                      Message 10 of 14 , Jan 7, 2014
                      • 0 Attachment
                        On Tue, Jan 07, 2014 at 11:38:20PM +0100, R. Berger wrote:

                        > >NEVER set the null sender to a real mailbox. This creates mail
                        > >loops. It MUST be either "MAILER-DAEMON" or empty.
                        > >
                        > >If however, a valid email address did not address the POP clients,
                        > >then MAILER-DAEMON is NOT the problem. You really need to look at
                        > >the interaction between the POP client and server, neither of which
                        > >is Postfix.
                        >
                        > I've removed the null_sender from master.cf but can't see any change
                        > in the Return-Path of the NDR's

                        NO DO NOT REMOVE from master.cf, rather set it EMPTY!

                        mytransport unix - n n - - pipe
                        flags=ORDq user=nobody null_sender= argv=/my-lda ${recipient}

                        Adjusting the flags to your needs. Make sure that the transport
                        recipient for this transport limit is correctly set to 1.

                        This will correctly generate:

                        Return-Path: <>

                        when the original message is a bounce.

                        --
                        Viktor.
                      • R. Berger
                        ... I don t get it, whatever I put in I just keep getting: Return-Path: As firs line off the header.
                        Message 11 of 14 , Jan 7, 2014
                        • 0 Attachment
                          Viktor Dukhovni schreef op 7-1-2014 23:48:
                          > On Tue, Jan 07, 2014 at 11:38:20PM +0100, R. Berger wrote:
                          >
                          >>> NEVER set the null sender to a real mailbox. This creates mail
                          >>> loops. It MUST be either "MAILER-DAEMON" or empty.
                          >>>
                          >>> If however, a valid email address did not address the POP clients,
                          >>> then MAILER-DAEMON is NOT the problem. You really need to look at
                          >>> the interaction between the POP client and server, neither of which
                          >>> is Postfix.
                          >> I've removed the null_sender from master.cf but can't see any change
                          >> in the Return-Path of the NDR's
                          > NO DO NOT REMOVE from master.cf, rather set it EMPTY!
                          >
                          > mytransport unix - n n - - pipe
                          > flags=ORDq user=nobody null_sender= argv=/my-lda ${recipient}
                          >
                          > Adjusting the flags to your needs. Make sure that the transport
                          > recipient for this transport limit is correctly set to 1.
                          >
                          > This will correctly generate:
                          >
                          > Return-Path: <>
                          >
                          > when the original message is a bounce.
                          I don't get it, whatever I put in I just keep getting:

                          Return-Path: <MAILER-DAEMON>

                          As firs line off the header.
                        • Viktor Dukhovni
                          ... Then you re changing the wrong transport entry, or the wrong master.cf file, or not running postfix reload . Perhaps it is not even Postfix that is
                          Message 12 of 14 , Jan 7, 2014
                          • 0 Attachment
                            On Wed, Jan 08, 2014 at 12:02:56AM +0100, R. Berger wrote:

                            > > mytransport unix - n n - - pipe
                            > > flags=ORDq user=nobody null_sender= argv=/my-lda ${recipient}
                            > >
                            > >Adjusting the flags to your needs. Make sure that the transport
                            > >recipient for this transport limit is correctly set to 1.
                            > >
                            > >This will correctly generate:
                            > >
                            > > Return-Path: <>
                            > >
                            > >when the original message is a bounce.
                            >
                            > I don't get it, whatever I put in I just keep getting:
                            >
                            > Return-Path: <MAILER-DAEMON>

                            Then you're changing the wrong transport entry, or the wrong
                            master.cf file, or not running "postfix reload". Perhaps it is
                            not even Postfix that is placing the message in the mailbox.
                            Or you're looking at the wrong messages, ...

                            I am afraid I can't help you any further. I've given all the
                            information you should need. Sorry about that.

                            --
                            Viktor.
                          • R. Berger
                            ... OK thanks, I ll go digging deeper into this. Thanks for all the help. Roger
                            Message 13 of 14 , Jan 7, 2014
                            • 0 Attachment
                              Viktor Dukhovni schreef op 8-1-2014 0:13:
                              > On Wed, Jan 08, 2014 at 12:02:56AM +0100, R. Berger wrote:
                              >
                              >>> mytransport unix - n n - - pipe
                              >>> flags=ORDq user=nobody null_sender= argv=/my-lda ${recipient}
                              >>>
                              >>> Adjusting the flags to your needs. Make sure that the transport
                              >>> recipient for this transport limit is correctly set to 1.
                              >>>
                              >>> This will correctly generate:
                              >>>
                              >>> Return-Path: <>
                              >>>
                              >>> when the original message is a bounce.
                              >> I don't get it, whatever I put in I just keep getting:
                              >>
                              >> Return-Path: <MAILER-DAEMON>
                              > Then you're changing the wrong transport entry, or the wrong
                              > master.cf file, or not running "postfix reload". Perhaps it is
                              > not even Postfix that is placing the message in the mailbox.
                              > Or you're looking at the wrong messages, ...
                              >
                              > I am afraid I can't help you any further. I've given all the
                              > information you should need. Sorry about that.
                              >
                              OK thanks,
                              I'll go digging deeper into this.

                              Thanks for all the help.

                              Roger
                            • R. Berger
                              ... Ok, got it working. After starting fresh this morning ;-) , I started all over again and tried to send email from the old server (which was working
                              Message 14 of 14 , Jan 7, 2014
                              • 0 Attachment
                                Viktor Dukhovni schreef op 8-1-2014 0:13:
                                > On Wed, Jan 08, 2014 at 12:02:56AM +0100, R. Berger wrote:
                                >
                                >>> mytransport unix - n n - - pipe
                                >>> flags=ORDq user=nobody null_sender= argv=/my-lda ${recipient}
                                >>>
                                >>> Adjusting the flags to your needs. Make sure that the transport
                                >>> recipient for this transport limit is correctly set to 1.
                                >>>
                                >>> This will correctly generate:
                                >>>
                                >>> Return-Path: <>
                                >>>
                                >>> when the original message is a bounce.
                                >> I don't get it, whatever I put in I just keep getting:
                                >>
                                >> Return-Path: <MAILER-DAEMON>
                                > Then you're changing the wrong transport entry, or the wrong
                                > master.cf file, or not running "postfix reload". Perhaps it is
                                > not even Postfix that is placing the message in the mailbox.
                                > Or you're looking at the wrong messages, ...
                                >
                                > I am afraid I can't help you any further. I've given all the
                                > information you should need. Sorry about that.
                                >
                                Ok, got it working. After starting fresh this morning ;-) , I started
                                all over again and tried to send email from the old server (which was
                                working before). These mail got stuck also so I figured I had to look at
                                the second server for this (which is actually quite logical) . I added
                                the null_sender= and everything started working. Now I have to find out
                                why the spamsnake server is not checking recipient addresses before
                                accepting mail. This was working before, but somehow I broke the config.

                                Thanks,
                                Viktor
                              Your message has been successfully submitted and would be delivered to recipients shortly.