[pfx] Re: Different outgoing IP address by virtual domain
On 1/1/24 11:29 AM, Wietse Venema via Postfix-users wrote: First, verify that your sender_dependent_default_transport_maps is not pre-empted by a higher-precedence mechanism: Thanks Wietse, That was the clue I needed. I thought I had commented out gmail from the transport file. Well I did, but then neglected to run postmap against it. As soon as I ran postmap transport and restarted postfix, I started to see email sent to gmail from that domain get though. It did go to spam, but given the current state of gmail I am not surprised that happens to a previously unseen (by gmail) IP address. I'll work on reputation next. Thanks again. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Different outgoing IP address by virtual domain
I have a long time running Postfix server (version 2.10) where I need to send from specific IP addresses for some virtual domains. I have it working, sort of. If I send email from this server to another server running postfix, it all seems to work. The sent email shows the transport required IP address in the header and all is well. DMARC, SPF and DKIM all pass. However, most times I send an email from that server to any gmail account, that email is bounced with the following error from gmail: The IP address sending this message does not have a PTR 550-5.7.25 record setup, or the corresponding forward DNS entry does not point 550-5.7.25 to the sending IP. As a policy, Gmail does not accept messages from 550-5.7.25 IPs with missing PTR records. For more information, go to 550 5.7.25 The email is sometime accepted, but put in the SPAM folder. When I look at the headers for the email sent to SPAM I see that it is not sent from the specified IP address. When checking the headers in the email that was successfully received by my other postfix server I see that that email is sent from the specified IP address, which is why it passes SFP and FQDN. Before I set up the transports to specify different IP addresses for some domains this was all working. The problem I am attempting to fix it that one of the domains sends out an opt-in newsletter three or four times a month, and so sometimes causes it's IP address to be placed on one or more RBLs. Of course when that happens all of the other email domains sending on that IP address fail spam checks. So we want to send the newsletters from their own IP address. In main.cf: myhostname = animalshelter.tld mydomain = animalshelter.tld mydestination = localhost, ###.##.##.40, ###.##.##.38 sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport In sender_transport: @newsletterdomain.tlddomain_hm @animalshelter.tlddomain_vo @dogtrainer.tlddomain_vo In master.cf: domain_hm unix - - n - - smtp -o syslog_name=postfix-HM -o smtp_helo_name=newsletterdomain.tld -o smtp_bind_address=###.##.##.38 ###.##.##.38:smtp inet n - n - - smtpd -o smtpd_sasl_auth_enable=no -o content_filter=amavisfeed:[127.0.0.1]:10040 domain_vo unix - - n - - smtp -o syslog_name=postfix-VO -o smtp_helo_name=animalshelter.tld -o smtp_bind_address=###.##.##.40 ###.##.##.40:smtp inet n - n - - smtpd -o smtpd_sasl_auth_enable=no -o content_filter=amavisfeed:[127.0.0.1]:10040 I ran postmap sender_transport and restarted postfix. Note that when sending to my other postfix server I see "postfix-HM" in the this server's log, and when sending to gmail "postfix-HM" is not there. Sending from any of the other domain on that server to gmail seems to work OK. However, they all send from the animalshelter.tld host which is at ###.##.##.40, and that is that is the IP address that shows up in the received header as the sending IP address. I've been beating my head against this wall for a while. There is clearly something I am not understanding. Any help would be appreciated. TL;DR Why is mail received by gmail different than those received by Postfix. Emmett ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: Virtual domains
On 4/15/22 10:15 AM, Matus UHLAR - fantomas wrote: On 14.04.22 08:26, Emmett Culley wrote: I recently changed the host name of one of the servers from one domain I am hosting to another of the domains the server is serving. Upon verifying the server I noticed that the Received: headers on email sent via that server now have the new host name This is completely irelevant to mail processing, unless the new mail server's name does not exist in DNS, or has a SPF record that disqualifies the server from announcing itself. and so causes Thunderbird to show the from address in red for emails from domains that are different from the server's hostname. Sorry, I have no idea what you are talking about. Can you provide a screenshot somehow? Is there anything I can do to specify that the Recieved: headers have the "correct" domain name depending on what domain is sending an email (From:)? you do not need this. your problem apparently I have DKIM working in such a manner. When an email is sent for domain.one (From: domain.one) the dkim signature contains the signature for domain.one and if sent for domain.two (From: domain.two) it contains the dkim signature for domain.two. No matter what the server's hostname is set to. I guess I am asking if there is any way to map the sending domain written to the header (From.: domain.tld) to the domain the email was sent as? Similar to how opendkim does when choosing the DKINM signature to add to the outgoing email's header. the domain in From: should be the one you or other senders have configured in thunderbird or other mail clients, and is not related to the mail server's name. This was caused by a missed configuration with my mail server's openDKIM configuration. Thanks for the clue. On 4/14/22 9:58 AM, Wietse Venema wrote: The Received: headers contain the value of the "myhostname" parameter, i.e. the identity of this Postfix MTA instance. This name should match the IP address where the MTA sends and receives mail. Postfix can send and receive email on behalf of many domains. Email is not like HTTP, and there is no requirement that the Postfix MTA identity matches the name of every domain that it handles mail for. But it is supported ever since Postfix got SNI support a few years ago. On 14.04.22 10:02, Emmett Culley wrote: Thanks Wietse. I will study up on SNI. I am working on new servers with RockyLinux 8 and so will also be using a newer version of postfix. SNI is only used when you connect to the server to send or receive e-mail, and your customers have multiple servernames configured in their mail clients. If you have @example.com domain address and connect to mail.example.com, you only need SNI if other users with @example.net address use mail.example.net on the same server. This way, if you have separate certificates for mail.example.com, mail.example.net etc, you need SNI. If you have single certificate with alternative names mail.example.com, mail.example.net etc, you do NOT need SNI. Usually, people use mail.example.org as smtp/imap/pop3 server and use @example.com or @example.net addresses, and server only needs certificate for mail.example.org. I see that I was concerned about nothing, simply because thunderbird had a working DKIM checker. I had assumed it was a misconfiguration on the mail server that was causing the warning. It wasn't until I looked a the header source for those emails that looked "bad" that I found they did not have a dkim signature. They all relay via my main servers and the "bad" one's were not listed in the opendkim trustedhosts file on those servers, and so no DKIM signature was added upon relay for those servers. Emmett
Re: Virtual domains
On 4/14/22 9:58 AM, Wietse Venema wrote: Emmett Culley: Is there anything I can do to specify that the Recieved: headers have the "correct" domain name depending on what domain is sending an email (From:)? The Received: headers contain the value of the "myhostname" parameter, i.e. the identity of this Postfix MTA instance. This name should match the IP address where the MTA sends and receives mail. Postfix can send and receive email on behalf of many domains. Email is not like HTTP, and there is no requirement that the Postfix MTA identity matches the name of every domain that it handles mail for. But it is supported ever since Postfix got SNI support a few years ago. Wietse Thanks Wietse. I will study up on SNI. I am working on new servers with RockyLinux 8 and so will also be using a newer version of postfix. Emmett
Re: Virtual domains
On 4/14/22 8:38 AM, Shawn Heisey wrote: On 4/14/22 09:26, Emmett Culley wrote: I would include the output of postconf, but it is very large and I don't know how to narrow it down to what is needed to help resolve this issue. Try "postconf -n". This should only show settings that are different from default. elyograg@bilbo:~$ postconf -n | wc -l 94 elyograg@bilbo:~$ postconf | wc -l 1059 Thanks, Shawn Thanks for that: alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases bounce_queue_lifetime = 0 broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix cyrus_destination_recipient_limit = 1 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 5 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 default_privs = mail html_directory = no inet_interfaces = all inet_protocols = ipv4 lmtp_sasl_type = cyrus local_recipient_maps = mail_owner = postfix mailbox_command = /usr/bin/procmail -f- -a "$USER" mailbox_size_limit = 128000 mailbox_transport = cyrus mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 9 milter_default_action = accept milter_protocol = 6 mydestination = localhost, 23.xxx.1.40, 23.xxx.1.38 mydomain = hostname.com myhostname = hostname.com mynetworks = 127.0.0.0/8, 23.249.1.67 newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = $smtpd_milters owner_request_special = no polite_destination_concurrency_failed_cohort_limit = 0 polite_destination_concurrency_limit = 2 polite_destination_rate_delay = 0 polite_destination_recipient_limit = 5 queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES recipient_canonical_maps = mysql:/etc/postfix/mysql-canonical.cf recipient_delimiter = + sample_directory = /usr/share/doc/postfix-2.10.1/samples sender_canonical_maps = mysql:/etc/postfix/mysql-canonical.cf sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_destination_concurrency_limit = 2 smtp_extra_recipient_limit = 10 smtp_generic_maps = hash:/etc/postfix/generic smtp_sasl_type = cyrus smtp_tls_loglevel = 4 smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1 smtp_tls_note_starttls_offer = yes smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1 smtpd_client_connection_count_limit = 5 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_unauth_pipelining, permit smtpd_milters = inet:127.0.0.1:8891 smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, reject_unauth_destination, reject_unlisted_recipient, reject_unverified_recipient, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, permit smtpd_reject_unlisted_sender = yes smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, permit smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_path = smtpd smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_sasl_type = cyrus smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unlisted_sender, reject_rhsbl_sender dsn.rfc-ignorant.org, permit smtpd_timeout = 45s smtpd_tls_cert_file = /etc/letsencrypt/live/mail.something.else/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/mail.something.else/privkey.pem smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1 smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes strict_rfc821_envelopes = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport turtle_destination_concurrency_failed_cohort_limit = 0 turtle_destination_concurrency_limit = 5 turtle_destination_rate_delay = 3s turtle_destination_recipient_limit = 10 unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 unverified_recipient_reject_code = 550 virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf virtual_mailbox_domains = mysql:/etc/postfix/mysql-mydestination.cf virtual_transport = cyrus yahoo_destination_concurrency_limit = 10 yahoo_destination_rate_delay = 5s yahoo_destination_recipient_limit = 2 yahoo_initial_destination_concurrency = 5
Virtual domains
I run a couple of mail servers using postfix, currently at version 2.10.1. They are set up to send and receive email for multiple virtual domains and have been doing that beautifully for years. I recently changed the host name of one of the servers from one domain I am hosting to another of the domains the server is serving. Upon verifying the server I noticed that the Received: headers on email sent via that server now have the new host name and so causes Thunderbird to show the from address in red for emails from domains that are different from the server's hostname. To be honest, I have been seeing the for a long while and just ingnored it until now. Is there anything I can do to specify that the Recieved: headers have the "correct" domain name depending on what domain is sending an email (From:)? I have DKIM working in such a manner. When an email is sent for domain.one (From: domain.one) the dkim signature contains the signature for domain.one and if sent for domain.two (From: domain.two) it contains the dkim signature for domain.two. No matter what the server's hostname is set to. I guess I am asking if there is any way to map the sending domain written to the header (From.: domain.tld) to the domain the email was sent as? Similar to how opendkim does when choosing the DKINM signature to add to the outgoing email's header. I would include the output of postconf, but it is very large and I don't know how to narrow it down to what is needed to help resolve this issue. Emmett
Re: Deprecated: white is better than black
On 2/24/21 12:40 PM, Dirk Stöcker wrote: On Wed, 24 Feb 2021, Wietse Venema wrote: Postfix version 3.6 deprecates terminology that implies white is better than black. Instead, Postfix prefers 'allowlist', 'denylist', and variations on those words. We had a late start, but it seems Newspeak will be established until 2050 as originally intended by ministery of truth. Doubleplusgood! Ciao What it the problem people seem to have with honest attempts to address systemic racism in the world and the US especially. We can expect NOTHING to change if we take a "I couldn't be bothered" attitude. I can only assume that if you are complaining about someone else's attempt to begin taking action, then you are a racist. If not, then I apologize. But only if you are not. Yes, it took some effort to make these recent changes, and All I can say is thank you for doing that! Emmett
Re: SASL auth not working
On 04/15/2018 01:31 PM, Viktor Dukhovni wrote: > On Sun, Apr 15, 2018 at 01:26:54PM -0700, Emmett Culley wrote: > >> smtpd_sasl_path = smptd >> >> -- listing of /etc/sasl2 -- >> -rw-rw-r--1 root root 49 Apr 15 07:10 smtpd.conf >> >> -- content of /etc/sasl2/smtpd.conf -- >> pwcheck_method: saslauthd >> mech_list: plain login > > Look closely. > Gah! I actually broke that while trying other changes. Thanks for the very quick response. All work as expected now. Emmett
SASL auth not working
I am not able to get postfix to authenticate on port 465 or 587 to allow account holders to relay via this server. Everything else works. That is, we can use the account name and password to log into Cyrus IMAP, though I know it isn't postfix that makes that connection, it does mean that SASL is working and accepts the mail account creds used in all the tests in the attachment. Thunderbird is set up to user SSL/TLS with normal password on port 465 for outgoing email. It looks to me like postfix is not getting a positive response from SASL, so I expect something is not configured correctly. I've spent the last two days trying to find the issue and have run out of ideas. Any help would be appreciated. Regards, Emmett I am not able to get postfix to authenticate on port 465 or 587 to allow account holders to relay via this server. Everything else works. That is, we can use the account name and password to log into Cyrus IMAP, though I know it isn't postfix that makes that connection, it does mean that SASL is working and accepts the mail account creds used in all the tests shown below. Thunderbird is set up to user SSL/TLS with normal password on port 465 for outgoing email. It looks to me like postfix is not getting a positive response from SASL, so I expect something is not configured correctly. Any help would be appreciated. -- saslfinger -- saslfinger - postfix Cyrus sasl configuration Sun Apr 15 13:07:50 PDT 2018 version: 1.0.2 mode: server-side SMTP AUTH -- basics -- Postfix: 2.10.1 System: CentOS Linux release 7.4.1708 (Core) -- smtpd is linked to -- libsasl2.so.3 => /lib64/libsasl2.so.3 (0x7f0f3265e000) -- active SMTP AUTH and TLS parameters for smtpd -- broken_sasl_auth_clients = yes smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_path = smptd smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_sasl_type = cyrus smtpd_tls_CAfile = /etc/pki/comodo.ca-bundle smtpd_tls_cert_file = /etc/pki/n=mail-domain.info/n=mail-domain.crt smtpd_tls_key_file = /etc/pki/n=mail-domain.info/n=mail-domain.key smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1 smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes -- listing of /usr/lib64/sasl2 -- total 856 drwxr-xr-x. 2 root root 4096 Sep 21 2017 . dr-xr-xr-x. 123 root root 90112 Apr 12 08:18 .. -rwxr-xr-x1 root root 19968 Aug 2 2017 libanonymous.so -rwxr-xr-x1 root root 19968 Aug 2 2017 libanonymous.so.3 -rwxr-xr-x1 root root 19968 Aug 2 2017 libanonymous.so.3.0.0 -rwxr-xr-x1 root root 24176 Aug 2 2017 libcrammd5.so -rwxr-xr-x1 root root 24176 Aug 2 2017 libcrammd5.so.3 -rwxr-xr-x1 root root 24176 Aug 2 2017 libcrammd5.so.3.0.0 -rwxr-xr-x1 root root 57904 Aug 2 2017 libdigestmd5.so -rwxr-xr-x1 root root 57904 Aug 2 2017 libdigestmd5.so.3 -rwxr-xr-x1 root root 57904 Aug 2 2017 libdigestmd5.so.3.0.0 -rwxr-xr-x1 root root 36936 Aug 2 2017 libgssapiv2.so -rwxr-xr-x1 root root 36936 Aug 2 2017 libgssapiv2.so.3 -rwxr-xr-x1 root root 36936 Aug 2 2017 libgssapiv2.so.3.0.0 -rwxr-xr-x1 root root 2 Aug 2 2017 liblogin.so -rwxr-xr-x1 root root 2 Aug 2 2017 liblogin.so.3 -rwxr-xr-x1 root root 2 Aug 2 2017 liblogin.so.3.0.0 -rwxr-xr-x1 root root 19992 Aug 2 2017 libplain.so -rwxr-xr-x1 root root 19992 Aug 2 2017 libplain.so.3 -rwxr-xr-x1 root root 19992 Aug 2 2017 libplain.so.3.0.0 -rwxr-xr-x1 root root 28208 Aug 2 2017 libsasldb.so -rwxr-xr-x1 root root 28208 Aug 2 2017 libsasldb.so.3 -rwxr-xr-x1 root root 28208 Aug 2 2017 libsasldb.so.3.0.0 -rwxr-xr-x1 root root 28328 Aug 2 2017 libsql.so -rwxr-xr-x1 root root 28328 Aug 2 2017 libsql.so.3 -rwxr-xr-x1 root root 28328 Aug 2 2017 libsql.so.3.0.0 -- listing of /etc/sasl2 -- total 16 drwxr-xr-x. 2 root root 23 Apr 15 07:10 . drwxr-xr-x. 141 root root 8192 Apr 12 08:18 .. -rw-rw-r--1 root root 49 Apr 15 07:10 smtpd.conf -- content of /etc/sasl2/smtpd.conf -- pwcheck_method: saslauthd mech_list: plain login -- active services in /etc/postfix/master.cf -- # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) 192.198.208.222:smtp inet n - n - - smtpd -o smtpd_sasl_auth_enable=no 127.0.0.1:smtp inet n - n - - smtpd -o mynetworks=127.0.0.0/8 -o receive_override_options=no_header_body_checks smtpsinet n - n - - smtpd -o content_filter=amavisfeed:[127.0.0.1]:10044 -o smtpd_enforce_tls=yes -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject pickupfifo n - n 60 1 pickup -o
Re: virtual_mailbox_domains
On 12/14/2017 10:53 AM, Viktor Dukhovni wrote: > > >> On Dec 14, 2017, at 1:44 PM, Emmett Culley <lst_man...@webengineer.com> >> wrote: >> >> Recipient address rejected: unverified address: Address verification in >> progress; > > http://www.postfix.org/ADDRESS_VERIFICATION_README.html > Thanks Viktor. So I set it up as I described before, using virtual_mailbox_domains instead of mydestination, but with reject_unverified_recipient removed from smtpd_recipient_restrictions. Now it seems to be working as expected. The doc seems to recommended that address verification can be a problem. Is that correct? If I reenable reject_unverified_recipient all mail is rejected with the 450 Recipient address rejected: unverified address: Address verification in progress; error. Emmett
Re: virtual_mailbox_domains
Sorry, I miss typed virtual_mailbox_domains Should have been virtual_mailbox_domains = mysql:/etc/postfix/mysql-mydestination.cf Emmett On 12/14/2017 10:44 AM, Emmett Culley wrote: > Recently I've been working on upgrading to Postfix 3 and a rewrite of > web-cyradm, and so have been studying the Postfix docs. It seems to me that > I have been doing virtual mailboxes wrong, even though it has been working > for years. > > For a long time I've been managing virtual domains using > > mydestination = localhost, $mydomain, /etc/postfix/local_destinations, > /etc/postfix/local_destinations > > From the doc it appears that I should be using virtual_mailbox_domains = > mysql:/etc/postfix/mysql-mydestination.cf instead (taking out the > mysql-mydestinations.cf entry from mydestiabtion. > > When I made that change and restarted Postfix I was not able to receive email > for any of the virtual domains. Instead I got the following error: > > Recipient address rejected: unverified address: Address verification in > progress; > > I changed nothing but: > > mydestination = localhost, $mydomain, /etc/postfix/local_destinations > > to > > mydestination = localhost > > And added > > virtual_mailbox_domains = /etc/postfix/local_destinations > > virtual_alias_maps is still the same: > > virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf > > So what am I missing? > > Current Postfix version is 2.6.6-8.el6.x86_64 > > Emmett >
virtual_mailbox_domains
Recently I've been working on upgrading to Postfix 3 and a rewrite of web-cyradm, and so have been studying the Postfix docs. It seems to me that I have been doing virtual mailboxes wrong, even though it has been working for years. For a long time I've been managing virtual domains using mydestination = localhost, $mydomain, /etc/postfix/local_destinations, /etc/postfix/local_destinations >From the doc it appears that I should be using virtual_mailbox_domains = >mysql:/etc/postfix/mysql-mydestination.cf instead (taking out the >mysql-mydestinations.cf entry from mydestiabtion. When I made that change and restarted Postfix I was not able to receive email for any of the virtual domains. Instead I got the following error: Recipient address rejected: unverified address: Address verification in progress; I changed nothing but: mydestination = localhost, $mydomain, /etc/postfix/local_destinations to mydestination = localhost And added virtual_mailbox_domains = /etc/postfix/local_destinations virtual_alias_maps is still the same: virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf So what am I missing? Current Postfix version is 2.6.6-8.el6.x86_64 Emmett
What is queued as
I am seeing that some email appears in the the intended receivers mail box and some don't. The ones that don't get delivered to the remote mail server have log entries like this: Mar 18 03:15:02 aoakley postfix/smtp[1714]: 6835847611D: to=ksome...@domain1.com, relay=mail1.domain1.com[xxx.xxx.xx.x]:25, delay=0.68, delays=0.06/0.01/0.14/0.47, dsn=2.0.0, status=sent (250 Ok: queued as 1499652CD48) And those that do get delivered have log entries like this: Mar 18 03:15:36 aoakley postfix/smtp[1712]: 6835847611D: to=esomeb...@domain2.com, relay=mx.domain2.net[yyy.yyy.yy.y]:25, delay=35, delays=0.06/0.01/0.16/34, dsn=2.0.0, status=sent (250 OK id=f137m907301NGbHLcq564) I can send email successfully to both domains from other postfix served locations without a problem. Running host against the failing domain I get: domain1.com has address xxx.xxx.xx.x domain1.com mail is handled by 0 mail.anotherdomain.net. I don't see any rejections or bounces that would tell me an email failed to get delivered. Is there more logging that I can enable? I am running on CentOS 5.4 with the latest stable version of Postfix compiled to support MySQL. Emmett
Re: Mail from cron delay
On 12/10/2009 11:37 AM, Victor Duchovni wrote: On Thu, Dec 10, 2009 at 11:12:36AM -0800, Emmett Culley wrote: It seems like understanding where the delay=86457 and delays=86457/0/0.36/0.18 come from would probably help me to understand the 24 delay. Not really. The message took 1 day to enter the active queue, not surprising, since pickup seems to have it a day late. Did your system clock get changed (by a day or so) while Postfix was running? So, where does the delay=86457 come from? It is clear to me that the cron job's email is getting stuck on the originating machine for 24 hours. It comes from the message sitting in the maildrop queue for 24 hours, or from a 24 hour delay between the invocation of sendmail(1) and EOF on the message body. If, for example, the process that has the write-side of the pipe to sendmail(1) keeps it open for 24 hours, the message will be delayed by 24 hours. I cannot let go of the fact that the log shows a delay=86457 (which is a few second more that 24 hours) isn't related to the late delivery. It is of course related, but does not answer your underlying question. Where does the delay=86457 come from? Who sets it? What does it represent? Where is the messages stored for the missing 24 hours? The pre-active delay is measured from the time message is created until it enters the active queue (in this case for the first time). So the message was either: - Not yet fully formed (delayed EOF in the mail(1)-sendmail(1)-postdrop(1)) process chain) - Fully formed, but unprocessed in the maildrop queue for 24 hours. - Fully formed, but unprocessed in the incoming queue for 24 hours. The last can be ruled out, because the pickup(8) and cleanup(8) log entries do not predate the qmgr(8) log entries by 24 hours. So, it is one of the first two. None of this requires in-depth understanding of the delay or delays fields, because the same evidence is clear from the logs and headers. The delays=1day value just corroborates the fact that the message went nowhere for 24 hours. Do try to rule out the possibility that the code creating the message is directly or via a child-process keeping the write-side pipe open for 24 hours or so. If this happens every day, just list the maildrop queue a few hours before the expected departure time of the message: # ls -l /var/spool/postfix/maildrop and report your findings. If you find any files there with a timestamp nearly a day old, also run: # fuser /var/spool/postfix/maildrop/filename and report the ps -ppid output for that process id (any parent processes also if relevant). Thanks to the hints above I looked into the code that I was calling from the cron job. I found that one of the scripts that was being called never returned until the next night when it was executed again. Hence the 24 hour delay. I fixed that script and now the email from cron arrives when it should. Thanks for your comments.
Re: Mail from cron delay
On 11/30/2009 10:48 AM, Victor Duchovni wrote: On Mon, Nov 30, 2009 at 10:35:02AM -0800, Emmett Culley wrote: It seems like understanding where the delay=86457 and delays=86457/0/0.36/0.18 come from would probably help me to understand the 24 delay. Not really. The message took 1 day to enter the active queue, not surprising, since pickup seems to have it a day late. Did your system clock get changed (by a day or so) while Postfix was running? The pickup(8) daemon scans the maildrop queue every 60 seconds by default, and on-demand when postdrop(1) sends a wakeup trigger after creating a new message. If you have SE-Linux, AppArmor, ... they could block postdrop from accessing the pickup service socket. Also file/directory permissions could be wrong, or your clock erratic. So, where does the delay=86457 come from? It is clear to me that the cron job's email is getting stuck on the originating machine for 24 hours. snip email header Received: from den1.thisserver.net (den1.thisserver.net [198.202.202.21]) by g1.example.com (Postfix) with ESMTP id 3586C400032 for webmas...@example.com; Sun, 29 Nov 2009 02:15:59 -0800 (PST) Received: by den1.thisserver.net (Postfix, from userid 0) id ; Sun, 29 Nov 2009 03:15:58 -0700 (MST) From: r...@den1.thisserver.net (Cron Daemon) To: webmas...@example.com Subject: Cron r...@den1 /usr/lib/myco/rstcron Content-Type: text/plain; charset=UTF-8 Auto-Submitted: auto-generated X-Cron-Env: mailto=webmas...@example.com X-Cron-Env: SHELL=/bin/sh X-Cron-Env: HOME=/root X-Cron-Env: PATH=/usr/bin:/bin X-Cron-Env: LOGNAME=root X-Cron-Env: USER=root Message-Id: 20091129101558.b0771588...@den1.thisserver.net Date: Sat, 28 Nov 2009 03:15:01 -0700 (MST) snip Something (is assume cron) is putting the original sent date (last line) into the header, then from the first Received: header item I assume that postfix didn't get it until 24 hours later. That is if I am correct that postfix places that Received item into the message. This happens every day on four systems. I cannot let go of the fact that the log shows a delay=86457 (which is a few second more that 24 hours) isn't related to the late delivery. Where does the delay=86457 come from? Who sets it? What does it represent? Where is the messages stored for the missing 24 hours? What document can I read that will answer these questions? Emmett
Re: Mail from cron delay
On 11/29/2009 03:27 PM, Wietse Venema wrote: Emmett Culley: For some months I've been noticing on multiple servers that mail from a cron job defined in the root's crontab takes 24 hours to get to it's destination. It finally bugged me enough to have me take a look for the reason. This is what I found in the maillog for each day: Nov 29 03:15:58 den1 postfix/pickup[8219]: B0771588D1B: uid=0 from=root Nov 29 03:15:58 den1 postfix/cleanup[7689]: B0771588D1B: message-id=20091129101558.b0771588...@den1.thisserver.net Nov 29 03:15:58 den1 postfix/qmgr[3361]: B0771588D1B: from=r...@den1.thisserver.net, size=819, nrcpt=1 (queue active) Nov 29 03:15:59 den1 postfix/smtp[7691]: B0771588D1B: to=webmas...@example.com, relay=example.com[123.45.67.89]:25, delay=86457, delays=86457/0/0.36/0.18, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 3586C400032) This message is queued on a DIFFERENT mail system example.com[123.45.67.89]:25, meaning it was sent via the SMTP port (port 25) to a mail system on a named example.com with IP address 123.45.67.89. Is the local machine running MacOS? Apple has made some changes such that Postfix is not running all of the time. This is a change that is specific to APPLE, and may explain why mail not picked up as soon as it is enqueued. Is the queue on a file server, and are the client and file server clocks out of sync? Looking at the Received: in your message as delivered, the clocks on those systems are all out of sync. Wietse Both machines are running CentOS and Postfix. One is on MST (sender, thisserver.net) the the other is on PST (receiver, example.com). The log entries are from thisserver.net. So I think I am seeing the cron process hitting the local Postfix server 24 hours after cron says it was sent. After taking a closer look at the email, the first Received: header says the email was received from cron by the sender on 11/29 at 3:15:58, yet cron and the email content show that it was sent 24 hours earlier. Email Header: - snip --- Received: from g1.example.com ([127.0.0.1]) by localhost (g1.example.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dS+5g5AAK5vQ for webmaster.example@example.com; Sun, 29 Nov 2009 02:15:59 -0800 (PST) Received: from den1.thisserver.net (den1.thisserver.net [98.76.54.32]) by g1.example.com (Postfix) with ESMTP id 3586C400032 for webmas...@example.com; Sun, 29 Nov 2009 02:15:59 -0800 (PST) Received: by den1.thisserver.net (Postfix, from userid 0) id ; Sun, 29 Nov 2009 03:15:58 -0700 (MST) - snip -- Date: Sat, 28 Nov 2009 03:15:01 -0700 (MST) Email content: - snip --- Sat Nov 28 03:16:05 MST 2009 - That along with the log showing that Postfix (on the sender) didn't see it from cron until the next day, like the email headers indicate, tells me it must be something between cron and Postfix. It was only the delay=86457 that had me query the Postfix users mailing list. Nov 29 03:15:58 den1 postfix/pickup[8219]: B0771588D1B: uid=0 from=root Nov 29 03:15:58 den1 postfix/cleanup[7689]: B0771588D1B: message-id=20091129101558.b0771588...@den1.thisserver.net Nov 29 03:15:58 den1 postfix/qmgr[3361]: B0771588D1B: from=r...@den1.thisserver.net, size=819, nrcpt=1 (queue active) Nov 29 03:15:59 den1 postfix/smtp[7691]: B0771588D1B: to=webmas...@example.com, relay=example.com[123.45.67.89]:25, delay=86457, delays=86457/0/0.36/0.18, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 3586C400032) Please note, however that the last log line shows that the email was queued as 3586C400032, which is the same ESMTP id as in the next Received: header. It seems like understanding where the delay=86457 and delays=86457/0/0.36/0.18 come from would probably help me to understand the 24 delay. Emmett
Mail from cron delay
For some months I've been noticing on multiple servers that mail from a cron job defined in the root's crontab takes 24 hours to get to it's destination. It finally bugged me enough to have me take a look for the reason. This is what I found in the maillog for each day: Nov 29 03:15:58 den1 postfix/pickup[8219]: B0771588D1B: uid=0 from=root Nov 29 03:15:58 den1 postfix/cleanup[7689]: B0771588D1B: message-id=20091129101558.b0771588...@den1.thisserver.net Nov 29 03:15:58 den1 postfix/qmgr[3361]: B0771588D1B: from=r...@den1.thisserver.net, size=819, nrcpt=1 (queue active) Nov 29 03:15:59 den1 postfix/smtp[7691]: B0771588D1B: to=webmas...@example.com, relay=example.com[123.45.67.89]:25, delay=86457, delays=86457/0/0.36/0.18, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 3586C400032) Nov 29 03:15:59 den1 postfix/qmgr[3361]: B0771588D1B: removed Nov 29 04:05:59 den1 postfix/pickup[8219]: 8F5C358913E: uid=0 from=root Nov 29 04:05:59 den1 postfix/cleanup[10278]: 8F5C358913E: message-id=20091129110559.8f5c3589...@den1.thisserver.net Nov 29 04:05:59 den1 postfix/qmgr[3361]: 8F5C358913E: from=r...@den1.thisserver.net, size=2488, nrcpt=1 (queue active) Nov 29 04:05:59 den1 postfix/cleanup[10278]: A6027589038: message-id=20091129110559.8f5c3589...@den1.thisserver.net Nov 29 04:05:59 den1 postfix/qmgr[3361]: A6027589038: from=r...@den1.thisserver.net, size=2626, nrcpt=1 (queue active) Nov 29 04:05:59 den1 postfix/local[10280]: 8F5C358913E: to=r...@den1.thisserver.net, orig_to=root, relay=local, delay=7.5, delays=7.4/0.03/0/0.05, dsn=2.0.0, status=sent (forwarded as A6027589038) Nov 29 04:05:59 den1 postfix/qmgr[3361]: 8F5C358913E: removed Nov 29 04:06:00 den1 postfix/smtp[10286]: A6027589038: to=webmas...@example.com, orig_to=root, relay=example.com[123.45.67.89]:25, delay=0.41, delays=0.04/0.01/0.21/0.16, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as F0C77400032) Nov 29 04:06:00 den1 postfix/qmgr[3361]: A6027589038: removed The first object (B0771588D1B) is the mail generated by root's crontab job (see below). The first thing I noticed is that the delay=86417 is within a few seconds of 24 hours. There is also a status=sent and that it is queued. So I am assuming that it gets queued somewhere. However, running postqueue -p shows that nothing is queued. Still, that email must be stored somewhere on this server because it always get received at it's original destination 24 hour later. Note the second email that is received by Postfix, at 4:05. It also originates from cron, although it is from logwatch and not from the root's crontab. I am certain this isn't a Postfix issue. It almost certainly has to do with cron, but I can find no references to cron job mail delays when searching the web. Can someone tell me how the delay= value gets set? And possibly where such a delayed email might be stored while waiting for the delay time to elapse? --- email B0771588D1B -- From - Sun Nov 29 02:16:04 2009 X-Mozilla-Status: 0001 X-Mozilla-Status2: Return-Path: r...@den1.thisserver.net Received: from murder ([unix socket]) by g1.example.com (Cyrus v2.3.7-Invoca-RPM-2.3.7-7.el5_4.3) with LMTPA; Sun, 29 Nov 2009 02:16:04 -0800 X-Sieve: CMU Sieve 2.3 Received: from localhost (localhost.localdomain [127.0.0.1]) by g1.example.com (Postfix) with ESMTP id 049AD40003C for webmaster.example@example.com; Sun, 29 Nov 2009 02:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at example.com Received: from g1.example.com ([127.0.0.1]) by localhost (g1.example.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dS+5g5AAK5vQ for webmaster.example@example.com; Sun, 29 Nov 2009 02:15:59 -0800 (PST) Received: from den1.thisserver.net (den1.thisserver.net [198.202.202.21]) by g1.example.com (Postfix) with ESMTP id 3586C400032 for webmas...@example.com; Sun, 29 Nov 2009 02:15:59 -0800 (PST) Received: by den1.thisserver.net (Postfix, from userid 0) id ; Sun, 29 Nov 2009 03:15:58 -0700 (MST) From: r...@den1.thisserver.net (Cron Daemon) To: webmas...@example.com Subject: Cron r...@den1 /usr/lib/freefi/freefirstcron Content-Type: text/plain; charset=UTF-8 Auto-Submitted: auto-generated X-Cron-Env: mailto=webmas...@example.com X-Cron-Env: SHELL=/bin/sh X-Cron-Env: HOME=/root X-Cron-Env: PATH=/usr/bin:/bin X-Cron-Env: LOGNAME=root X-Cron-Env: USER=root Message-Id: 20091129101558.b0771588...@den1.thisserver.net Date: Sat, 28 Nov 2009 03:15:01 -0700 (MST) Stopping httpd: [ OK ] Starting httpd: [ OK ] Stopping squid: [ OK ] Starting squid: .[ OK ] Reseting FreeFi gateway daemon: [ OK ][ OK ] Sat Nov 28 03:16:05 MST 2009 --- Note the second Received (bottom up) is seen by our mail server 24 hours after Postfix received it from cron. Emmett
