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

Re: Delayed Email Issues

Expand Messages
  • Ralf Hildebrandt
    ... Show the messages. ... Why? ... Sure? ... use postcat -q to look at the mails. Where do they com from, check your log. Maybe your sending out spam. -- Ralf
    Message 1 of 5 , Aug 1, 2008
    • 0 Attachment
      * Tait Grove <tait@...>:

      > I do not have a bunch of MAILER-DAEMON notices, I do have strange
      > domain names in the mailq list and handful of temporary failure
      > messages.

      Show the messages.

      > maps_rbl_reject_code = 450

      Why?

      > relay_domains = $mydestination

      Sure?

      > Qshape:
      >
      > T 5 10 20 40 80 160 320 640 1280 1280+
      >
      > TOTAL 4573 273 341 146 669 1451 1653 9 5 7 19
      >
      > yahoo.com 164 7 5 7 34 50 61 0 0 0 0
      > gmail.com 118 15 9 3 14 30 47 0 0 0 0
      > agentimage.com 64 0 5 3 8 20 28 0 0 0 0
      > onclearcreek.com 59 3 0 9 2 12 10 4 3 4 12
      > alfonso.com 52 3 2 2 8 19 18 0 0 0 0

      use postcat -q to look at the mails. Where do they com from, check
      your log.

      Maybe your sending out spam.

      --
      Ralf Hildebrandt (Ralf.Hildebrandt@...) snickebo@...
      Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
      http://www.arschkrebs.de
      Perl - The only language that looks the same before and after RSA
      encryption." -- Keith Bostic
    • Noel Jones
      ... OK. Pick a couple messages and see how they entered your system (examine the log) and where they are going. Examine the contents and see if they appear to
      Message 2 of 5 , Aug 1, 2008
      • 0 Attachment
        Tait Grove wrote:
        > My queue is horribly backed up with over 4,000 messages and I can not
        > figure out how to shrink the queue. I do not have a bunch of
        > MAILER-DAEMON notices, I do have strange domain names in the mailq list
        > and handful of temporary failure messages. The issue is getting worst by
        > the minute. I followed the article here:
        > http://www.postfix.org/LOCAL_RECIPIENT_README.html and I think that we
        > are good as far as those settings. Any insight would be great as email
        > is severely delayed. Here is some data on our postfix setup:

        OK. Pick a couple messages and see how they entered your
        system (examine the log) and where they are going. Examine
        the contents and see if they appear to be spam.

        Today's wild guess:
        Your webserver has been hacked and is being used to spam the
        world. Turn off the webserver software until you get the
        problem fixed.

        > *postconf –n:*
        > bounce_queue_lifetime = 8h

        That's pretty short. 3-5 days is typical.

        > inet_interfaces = 127.0.0.1, localhost, $myhostname

        "127.0.0.1, localhost" is redundant. Remove the "localhost" part.

        > invalid_hostname_reject_code = 450

        This should probably be set to 550 unless you have a good
        reason to use 450.

        > maps_rbl_reject_code = 450

        This should be 554 unless you have a good reason to change it.

        > maximal_queue_lifetime = 8h

        That's pretty short. Normal is 3-5 days.

        > non_fqdn_reject_code = 450

        This should be 504 unless you have a good reason to change it.

        > relay_domains = $mydestination

        This should probably be set empty. ie.
        relay_domains =


        > smtpd_data_restrictions = reject_unauth_pipelining,
        > reject_multi_recipient_bounce, permit

        OK.

        > smtpd_recipient_restrictions = permit_mynetworks,
        > check_policy_service inet:127.0.0.1:10031,
        > permit_sasl_authenticated, permit_tls_clientcerts,
        > reject_unauth_destination, reject_invalid_helo_hostname,
        > reject_non_fqdn_sender, reject_unknown_recipient_domain,

        Note that reject_unknown_recipient_domain can only reject your
        own domain when it's after reject_unauth_destination. Best to
        just remove it.

        > reject_non_fqdn_recipient, warn_if_reject
        > reject_non_fqdn_helo_hostname, warn_if_reject
        > reject_unknown_helo_hostname, warn_if_reject
        > reject_unknown_client, reject_unverified_recipient,
        > reject_unknown_sender_domain, reject_unverified_sender,

        reject_unverified_sender shouldn't be used against every
        connection; many admins consider it abusive and will blacklist
        you for excessive probes.
        If you feel you must use it, use it for selected domains from
        an access map. Examples in the archives.

        > check_recipient_access hash:$config_directory/recipient.list,
        > reject_rbl_client cbl.abuseat.org, reject_rbl_client
        > list.dsbl.org, reject_rbl_client sbl.spamhaus.org,

        list.dsbl.org is (temporarily?) dead. Remove it.
        Most folks prefer zen.spamhaus.org rather than sbl.spamhaus.org.

        > reject_rbl_client bl.spamcop.net, reject_rbl_client
        > dnsbl.sorbs.net=127.0.0.2, reject_rbl_client
        > dnsbl.sorbs.net=127.0.0.3, reject_rbl_client
        > dnsbl.sorbs.net=127.0.0.4, reject_rbl_client
        > dnsbl.sorbs.net=127.0.0.5, reject_rbl_client
        > dnsbl.sorbs.net=127.0.0.7, reject_rbl_client
        > dnsbl.sorbs.net=127.0.0.9, reject_rbl_client
        > dnsbl.sorbs.net=127.0.0.11, reject_rbl_client
        > dnsbl.sorbs.net=127.0.0.12, permit

        OK.

        > smtpd_sender_restrictions = permit_mynetworks,
        > reject_non_fqdn_sender, reject_unknown_sender_domain, permit

        All these checks are duplicated in
        smtpd_recipient_restrictions. You can remove all these.

        > smtpd_tls_ask_ccert = yes

        Some client may choke if you ask for a certificate. Usually
        this parameter is best used only on the "submission" port or
        other non-public interface.

        >
        > *Qshape:*
        >
        > T 5 10 20 40 80 160 320 640 1280 1280+
        > TOTAL 4573 273 341 146 669 1451 1653 9 5 7 19
        > yahoo.com 164 7 5 7 34 50 61 0 0 0 0
        > gmail.com 118 15 9 3 14 30 47 0 0 0 0
        > agentimage.com 64 0 5 3 8 20 28 0 0 0 0
        > onclearcreek.com 59 3 0 9 2 12 10 4 3 4 12
        > alfonso.com 52 3 2 2 8 19 18 0 0 0 0
        > jones-healy.com 52 1 14 1 6 15 15 0 0 0 0
        > aol.com 51 1 2 2 5 23 18 0 0 0 0
        > hotmail.com 51 3 3 1 7 21 16 0 0 0 0
        > arbotco.com 46 6 4 2 5 2 27 0 0 0 0
        > traikos.us 41 3 30 0 1 6 1 0 0 0 0
        > thesaadteam.com 39 1 0 1 14 10 13 0 0 0 0
        > nostalgichomes.com 39 4 8 1 8 10 8 0 0 0 0
        > hiltonhyland.com 36 3 8 0 5 13 7 0 0 0 0
        > tetonvalleyrealty.com 35 0 1 5 2 13 14 0 0 0 0
        > carolinaproperties.com 35 4 0 1 4 12 14 0 0 0 0
        > comcast.net 34 2 7 2 2 11 10 0 0 0 0
        > georgetraikos.com 33 3 30 0 0 0 0 0 0 0 0


        --
        Noel Jones
      • Tait Grove
        ... ============================================================================ Wow Noel, I am not sure how you know all of this but this is awesome
        Message 3 of 5 , Aug 1, 2008
        • 0 Attachment
          > -----Original Message-----
          > From: owner-postfix-users@... [mailto:owner-postfix-
          > users@...] On Behalf Of Noel Jones
          > Sent: Friday, August 01, 2008 2:23 PM
          > To: Tait Grove
          > Cc: 'postfix users list'
          > Subject: Re: Delayed Email Issues
          >
          > Tait Grove wrote:
          > > My queue is horribly backed up with over 4,000 messages and I can not
          > > figure out how to shrink the queue. I do not have a bunch of
          > > MAILER-DAEMON notices, I do have strange domain names in the mailq list
          > > and handful of temporary failure messages. The issue is getting worst by

          > > the minute. I followed the article here:
          > > http://www.postfix.org/LOCAL_RECIPIENT_README.html and I think that we
          > > are good as far as those settings. Any insight would be great as email
          > > is severely delayed. Here is some data on our postfix setup:
          >
          > OK. Pick a couple messages and see how they entered your
          > system (examine the log) and where they are going. Examine
          > the contents and see if they appear to be spam.
          >
          > Today's wild guess:
          > Your webserver has been hacked and is being used to spam the
          > world. Turn off the webserver software until you get the
          > problem fixed.
          >
          > > *postconf -n:*
          > > bounce_queue_lifetime = 8h
          >
          > That's pretty short. 3-5 days is typical.
          >
          > > inet_interfaces = 127.0.0.1, localhost, $myhostname
          >
          > "127.0.0.1, localhost" is redundant. Remove the "localhost" part.
          >
          > > invalid_hostname_reject_code = 450
          >
          > This should probably be set to 550 unless you have a good
          > reason to use 450.
          >
          > > maps_rbl_reject_code = 450
          >
          > This should be 554 unless you have a good reason to change it.
          >
          > > maximal_queue_lifetime = 8h
          >
          > That's pretty short. Normal is 3-5 days.
          >
          > > non_fqdn_reject_code = 450
          >
          > This should be 504 unless you have a good reason to change it.
          >
          > > relay_domains = $mydestination
          >
          > This should probably be set empty. ie.
          > relay_domains =
          >
          >
          > > smtpd_data_restrictions = reject_unauth_pipelining,
          > > reject_multi_recipient_bounce, permit
          >
          > OK.
          >
          > > smtpd_recipient_restrictions = permit_mynetworks,
          > > check_policy_service inet:127.0.0.1:10031,
          > > permit_sasl_authenticated, permit_tls_clientcerts,
          > > reject_unauth_destination, reject_invalid_helo_hostname,
          > > reject_non_fqdn_sender, reject_unknown_recipient_domain,
          >
          > Note that reject_unknown_recipient_domain can only reject your
          > own domain when it's after reject_unauth_destination. Best to
          > just remove it.
          >
          > > reject_non_fqdn_recipient, warn_if_reject
          > > reject_non_fqdn_helo_hostname, warn_if_reject
          > > reject_unknown_helo_hostname, warn_if_reject
          > > reject_unknown_client, reject_unverified_recipient,
          > > reject_unknown_sender_domain, reject_unverified_sender,
          >
          > reject_unverified_sender shouldn't be used against every
          > connection; many admins consider it abusive and will blacklist
          > you for excessive probes.
          > If you feel you must use it, use it for selected domains from
          > an access map. Examples in the archives.
          >
          > > check_recipient_access hash:$config_directory/recipient.list,
          > > reject_rbl_client cbl.abuseat.org, reject_rbl_client
          > > list.dsbl.org, reject_rbl_client sbl.spamhaus.org,
          >
          > list.dsbl.org is (temporarily?) dead. Remove it.
          > Most folks prefer zen.spamhaus.org rather than sbl.spamhaus.org.
          >
          > > reject_rbl_client bl.spamcop.net, reject_rbl_client
          > > dnsbl.sorbs.net=127.0.0.2, reject_rbl_client
          > > dnsbl.sorbs.net=127.0.0.3, reject_rbl_client
          > > dnsbl.sorbs.net=127.0.0.4, reject_rbl_client
          > > dnsbl.sorbs.net=127.0.0.5, reject_rbl_client
          > > dnsbl.sorbs.net=127.0.0.7, reject_rbl_client
          > > dnsbl.sorbs.net=127.0.0.9, reject_rbl_client
          > > dnsbl.sorbs.net=127.0.0.11, reject_rbl_client
          > > dnsbl.sorbs.net=127.0.0.12, permit
          >
          > OK.
          >
          > > smtpd_sender_restrictions = permit_mynetworks,
          > > reject_non_fqdn_sender, reject_unknown_sender_domain, permit
          >
          > All these checks are duplicated in
          > smtpd_recipient_restrictions. You can remove all these.
          >
          > > smtpd_tls_ask_ccert = yes
          >
          > Some client may choke if you ask for a certificate. Usually
          > this parameter is best used only on the "submission" port or
          > other non-public interface.
          >
          > >
          > > *Qshape:*
          > >
          > > T 5 10 20 40 80 160 320 640 1280 1280+
          > > TOTAL 4573 273 341 146 669 1451 1653 9 5 7 19
          > > yahoo.com 164 7 5 7 34 50 61 0 0 0 0
          > > gmail.com 118 15 9 3 14 30 47 0 0 0 0
          > > agentimage.com 64 0 5 3 8 20 28 0 0 0 0
          > > onclearcreek.com 59 3 0 9 2 12 10 4 3 4 12
          > > alfonso.com 52 3 2 2 8 19 18 0 0 0 0
          > > jones-healy.com 52 1 14 1 6 15 15 0 0 0 0
          > > aol.com 51 1 2 2 5 23 18 0 0 0 0
          > hotmail.com 51 3 3 1 7 21 16 0 0 0 0
          > arbotco.com 46 6 4 2 5 2 27 0 0 0 0
          > traikos.us 41 3 30 0 1 6 1 0 0 0 0
          > thesaadteam.com 39 1 0 1 14 10 13 0 0 0 0
          > nostalgichomes.com 39 4 8 1 8 10 8 0 0 0 0
          > hiltonhyland.com 36 3 8 0 5 13 7 0 0 0 0
          > tetonvalleyrealty.com 35 0 1 5 2 13 14 0 0 0 0
          > carolinaproperties.com 35 4 0 1 4 12 14 0 0 0 0
          > comcast.net 34 2 7 2 2 11 10 0 0 0 0
          > georgetraikos.com 33 3 30 0 0 0 0 0 0 0 0
          >
          >
          > --
          > Noel Jones

          ============================================================================

          Wow Noel, I am not sure how you know all of this but this is awesome
          information! Thanks for all of the great advice.

          I am not sure about hacking, 95% of the domains look pretty legitimate. And
          I should have that type of traffic. We have over thirteen thousand email
          accounts sending email by the second. Our clients receive even more. I have
          been watching the multi-RBL's and nothing yet. I have also ran every type of
          open relay program checker and I am watching the traffic on the server and
          it looks normal too. Usually this happens after my SAN reboots and then the
          backup happens for a few days.

          Can you tell me if I am making the same types of mistakes in my master.cf
          too?

          MASTER.CF:
          smtp inet n - n - - smtpd
          -o content_filter=smtp-amavis:[127.0.0.1]:10024
          pickup fifo n - n 60 1 pickup
          cleanup unix n - n - 0 cleanup
          qmgr fifo n - n 300 1 qmgr
          tlsmgr unix - - n 1000? 1 tlsmgr
          rewrite unix - - n - - trivial-rewrite
          bounce unix - - n - 0 bounce
          defer unix - - n - 0 bounce
          trace unix - - n - 0 bounce
          verify unix - - n - 1 verify
          flush unix n - n 1000? 0 flush
          proxymap unix - - n - - proxymap
          smtp unix - - n - 500 smtp
          relay unix - - n - 275 smtp
          -o fallback_relay=
          -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
          showq unix n - n - - showq
          error unix - - n - - error
          retry unix - - n - - error
          discard unix - - n - - discard
          local unix - n n - - local
          virtual unix - n n - - virtual
          lmtp unix - - n - - lmtp
          anvil unix - - n - 1 anvil
          scache unix - - n - 1 scache
          dovecot unix - n n - - pipe
          flags=DRhu user=dovecot:dovecot argv=/usr/local/libexec/dovecot/deliver -d
          ${recipient}
          vacation unix - n n - - pipe
          flags=DRhu user=vacation argv=/var/spool/vacation/vacation.pl
          8080 inet n - n - - smtpd
          smtp-amavis unix - - n - 30 smtp
          -o smtp_data_done_timeout=1200
          -o disable_dns_lookups=yes
          127.0.0.1:10025 inet n - n - 30 smtpd
          -o content_filter=
          -o local_recipient_maps=
          -o relay_recipient_maps=
          -o smtpd_restriction_classes=
          -o smtpd_client_restrictions=
          -o smtpd_helo_restrictions=
          -o smtpd_sender_restrictions=
          -o mynetworks=127.0.0.0/8,10.0.0.0/8,38.119.86.0/25
          -o smtpd_recipient_restrictions=permit_mynetworks,
          $transport_maps,reject
          -o strict_rfc821_envelopes=yes
          proxywrite unix - - n - - proxymap


          Thanks a billion,


          Tait
        • Noel Jones
          ... OK, that s good information to share. Your previous mails implied that the number of mails in your queue was unusual and unexpected, so I withdraw my wild
          Message 4 of 5 , Aug 2, 2008
          • 0 Attachment
            Tait Grove wrote:
            >> -----Original Message-----
            >
            > I am not sure about hacking, 95% of the domains look pretty legitimate. And
            > I should have that type of traffic. We have over thirteen thousand email
            > accounts sending email by the second. Our clients receive even more. I have
            > been watching the multi-RBL's and nothing yet. I have also ran every type of
            > open relay program checker and I am watching the traffic on the server and
            > it looks normal too. Usually this happens after my SAN reboots and then the
            > backup happens for a few days.

            OK, that's good information to share. Your previous mails
            implied that the number of mails in your queue was unusual and
            unexpected, so I withdraw my wild guesses. You need to
            examine your mail logs to see where the delay is. Maybe some
            of the recipient domains are throttling you.

            Is the postfix queue on a SAN? I don't have experience with
            that, but I understand it can cause problems. Maybe someone
            else will comment on that issue.

            >
            > Can you tell me if I am making the same types of mistakes in my master.cf
            > too?
            >
            > MASTER.CF:
            > smtp inet n - n - - smtpd
            > -o content_filter=smtp-amavis:[127.0.0.1]:10024
            > pickup fifo n - n 60 1 pickup
            > cleanup unix n - n - 0 cleanup
            > qmgr fifo n - n 300 1 qmgr
            > tlsmgr unix - - n 1000? 1 tlsmgr
            > rewrite unix - - n - - trivial-rewrite
            > bounce unix - - n - 0 bounce
            > defer unix - - n - 0 bounce
            > trace unix - - n - 0 bounce
            > verify unix - - n - 1 verify
            > flush unix n - n 1000? 0 flush
            > proxymap unix - - n - - proxymap
            > smtp unix - - n - 500 smtp
            > relay unix - - n - 275 smtp
            > -o fallback_relay=
            > -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
            > showq unix n - n - - showq
            > error unix - - n - - error
            > retry unix - - n - - error
            > discard unix - - n - - discard
            > local unix - n n - - local
            > virtual unix - n n - - virtual
            > lmtp unix - - n - - lmtp
            > anvil unix - - n - 1 anvil
            > scache unix - - n - 1 scache
            > dovecot unix - n n - - pipe
            > flags=DRhu user=dovecot:dovecot argv=/usr/local/libexec/dovecot/deliver -d
            > ${recipient}
            > vacation unix - n n - - pipe
            > flags=DRhu user=vacation argv=/var/spool/vacation/vacation.pl
            > 8080 inet n - n - - smtpd
            > smtp-amavis unix - - n - 30 smtp
            > -o smtp_data_done_timeout=1200
            > -o disable_dns_lookups=yes
            > 127.0.0.1:10025 inet n - n - 30 smtpd
            > -o content_filter=
            > -o local_recipient_maps=
            > -o relay_recipient_maps=
            > -o smtpd_restriction_classes=
            > -o smtpd_client_restrictions=
            > -o smtpd_helo_restrictions=
            > -o smtpd_sender_restrictions=
            > -o mynetworks=127.0.0.0/8,10.0.0.0/8,38.119.86.0/25

            on the amavis reinjection port, usually one has
            mynetworks=127.0.0.1
            since there is no reason for others to connect directly to
            that port.

            > -o smtpd_recipient_restrictions=permit_mynetworks,
            > $transport_maps,reject

            $transport_maps doesn't belong here.

            > -o strict_rfc821_envelopes=yes

            what? you want to reject mail from amavis if the envelope is
            botched? remove this.

            --
            Noel Jones
          Your message has been successfully submitted and would be delivered to recipients shortly.