warning: hostname dc1.xxx.com.au does not resolve to address xxx.xxx.73.197
I'd appreciate you help with the following:
I'm looking after two server on 2 differents domains. During testing I
found the following issue.
On the sending server I get the following
Jul 1 14:18:24 mail postfix/smtp[2135]: 9172F5FA8D: host
mail1..com[xxx.xxx.231.229] said: 450 4.7.25 Client host rejected:
cannot find your hostname, [xxx.xxx.73.197] (in reply to RCPT TO command)
On the receiving server I get:
Jul 1 06:18:21 mail1 postfix/postscreen[19345]: CONNECT from
[xxx.xxx.73.197]:44014 to [xxx.xxx.231.229]:25
Jul 1 06:18:21 mail1 postfix/postscreen[19345]: PASS OLD
[xxx.xxx.73.197]:44014
Jul 1 06:18:21 mail1 postfix/smtpd[19348]: warning: hostname
dc1.xxx.com.au does not resolve to address xxx.xxx.73.197: Name or
service not known
Jul 1 06:18:21 mail1 postfix/smtpd[19348]: connect from
unknown[xxx.xxx.73.197]
Jul 1 06:18:24 mail1 postfix/smtpd[19348]: NOQUEUE: reject: RCPT from
unknown[xxx.xxx.73.197]: 450 4.7.25 Client host rejected: cannot find
your hostname, [150.107.73.197]; from= to=
proto=ESMTP helo=
I can ping 'mail.xxx.net' on this server ok.
Sending Server postconf -n
output
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
delay_warning_time = 4h
inet_interfaces = 127.0.0.1, ::1, xxx.xxx.73.197
inet_protocols = all
local_recipient_maps = $virtual_mailbox_maps
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 52428800
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_protocol = 6
mua_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject
mua_relay_restrictions =
reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
mua_sender_restrictions =
permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = xxx.net
myhostname = mail.xxx.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters = inet:localhost:11332
postscreen_access_list = permit_mynetworks
cidr:/etc/postfix/postscreen_access
postscreen_blacklist_action = drop
postscreen_dnsbl_action = drop
postscreen_dnsbl_sites = ix.dnsbl.manitu.net*2 zen.spamhaus.org*2
postscreen_dnsbl_threshold = 2
postscreen_greet_action = drop
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_dns_support_level = dnssec
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_ciphers = high
smtp_tls_policy_maps = mysql:/etc/postfix/sql/tls-policy.cf
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = mail.xxx.net
smtpd_client_restrictions = permit_mynetworks check_client_access
hash:/etc/postfix/without_ptr reject_unknown_client_hostname
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
smtpd_milters = inet:localhost:11332
smtpd_recipient_restrictions = check_recipient_access
mysql:/etc/postfix/sql/recipient-access.cf
smtpd_relay_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/2803b51614cb032f.crt
smtpd_tls_ciphers = high
smtpd_tls_key_file = /etc/ssl/private/wildcard.xxx.net.key
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
tls_high_cipherlist =
EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION
virtual_alias_maps = mysql:/etc/postfix/sql/aliases.cf
virtual_mailbox_domains = mysql:/etc/postfix/sql/domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/sql/accounts.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp
Sending Server postconf -Mf output ---
smtp inet n - y - 1 postscreen
-o smtpd_sasl_auth_enable=no
smtpd pass - - y - - smtpd
dnsblog unix - - y - 0 dnsblog
tlsproxy unix - - y - 0 tlsproxy
9925 inet n - y - - smtpd
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o
Re: Delays in receiving mail
On Jun 30, 2019, at 20:42, Viktor Dukhovni wrote: >> On Jun 30, 2019, at 8:14 PM, Doug Hardie wrote: >> >>> By default, the Postfix SMTP server invokes the proxymap >>> service for local user lookup, because the default >>> local_recipient_maps setting looks like this: >>> >>> local_recipient_maps = proxy:unix:passwd.byname $alias_maps >>> >>> Try, as a root user: >>> >>> postmap -q nosuchuser proxy:unix:passwd.byname >>> postmap -q root proxy:unix:passwd.byname >>> >>> I suspect that your proxymap service is busted. >>> >> >> brain# postmap -q nosuchuser proxy:unix:passwd.byname >> postmap: fatal: proxymap service is not configured for table >> "unix:passwd.byname" >> brain# postmap -q root proxy:unix:passwd.byname >> postmap: fatal: proxymap service is not configured for table >> "unix:passwd.byname" > > Not surprising, since you're not the default local_recipient_maps setting. Thanks Viktor and Wietse. This was a strange one. I finally found the problem and it was not with the postfix configuration. Ypbind failed to start up correctly. I don’t quite understand how that could happen, but by restarting it, mail started flowing in correctly. All of the user id’s and passwords are found via YP.
Re: Delays in receiving mail
> On Jun 30, 2019, at 8:14 PM, Doug Hardie wrote: > >> By default, the Postfix SMTP server invokes the proxymap >> service for local user lookup, because the default >> local_recipient_maps setting looks like this: >> >> local_recipient_maps = proxy:unix:passwd.byname $alias_maps >> >> Try, as a root user: >> >>postmap -q nosuchuser proxy:unix:passwd.byname >>postmap -q root proxy:unix:passwd.byname >> >> I suspect that your proxymap service is busted. >> > > brain# postmap -q nosuchuser proxy:unix:passwd.byname > postmap: fatal: proxymap service is not configured for table > "unix:passwd.byname" > brain# postmap -q root proxy:unix:passwd.byname > postmap: fatal: proxymap service is not configured for table > "unix:passwd.byname" Not surprising, since you're not the default local_recipient_maps setting. -- Viktor.
Re: Delays in receiving mail
> On Jun 30, 2019, at 19:22, Wietse Venema wrote: > > Doug Hardie: >> This is a small server with a few users that are all local. There >> are several domain names that point to this server, but all of >> them are just aliases for the main name. Received mail stops at >> the rcpt to: line. There is no OK that occurs until shortly after >> 3 minutes from that line being received. During that time ktrace >> shows multiple calls and sleeps for proxymap. After the 3+ minute >> delay, it issues the OK and then they rest proceeds normally. I >> suspect this is a configuration error since this server was just >> updated to 3.3.4 from an earlier version. The earlier version >> worked fine. This problem started when the upgrade completed. > > By default, the Postfix SMTP server invokes the proxymap > service for local user lookup, because the default > local_recipient_maps setting looks like this: > >local_recipient_maps = proxy:unix:passwd.byname $alias_maps > > Try, as a root user: > > postmap -q nosuchuser proxy:unix:passwd.byname > postmap -q root proxy:unix:passwd.byname > > I suspect that your proxymap service is busted. > brain# postmap -q nosuchuser proxy:unix:passwd.byname postmap: fatal: proxymap service is not configured for table "unix:passwd.byname" brain# postmap -q root proxy:unix:passwd.byname postmap: fatal: proxymap service is not configured for table "unix:passwd.byname"
Re: Delays in receiving mail
On Sun, Jun 30, 2019 at 07:22:42PM -0400, Wietse Venema wrote: > Doug Hardie: > > This is a small server with a few users that are all local. There > > are several domain names that point to this server, but all of > > them are just aliases for the main name. Received mail stops at > > the rcpt to: line. There is no OK that occurs until shortly after > > 3 minutes from that line being received. During that time ktrace > > shows multiple calls and sleeps for proxymap. After the 3+ minute > > delay, it issues the OK and then they rest proceeds normally. I > > suspect this is a configuration error since this server was just > > updated to 3.3.4 from an earlier version. The earlier version > > worked fine. This problem started when the upgrade completed. > > By default, the Postfix SMTP server invokes the proxymap > service for local user lookup, because the default > local_recipient_maps setting looks like this: > > local_recipient_maps = proxy:unix:passwd.byname $alias_maps > > Try, as a root user: > > postmap -q nosuchuser proxy:unix:passwd.byname > postmap -q root proxy:unix:passwd.byname > > I suspect that your proxymap service is busted. The OP's reported "postconf -n" has: local_recipient_maps = unix:passwd.byname $alias_maps which (if correct) removes proxymap from the picture. While the proxymap service opens all the tables that some other Postfix service might use, and if there are issues with any of those, proxymap may fail to start, it would then not recover after a delay. Sending a probe to the system, shows a successful RCPT command, but with an ~200s delay: Jun 30 19:45:40 amnesiac postfix/smtp[26623]: 8D5C539A7E: to=, relay=mail.remotesupportservicesllc.com[47.51.29.162]:25, delay=202, delays=0/0.03/1.5/201, dsn=2.1.5, status=deliverable (250 2.1.5 Ok) I rather more suspect the milter: smtpd_milters = unix:/var/run/clamav/clmilter.sock and/or DNS lookup timeouts. -- Viktor.
Re: Delays in receiving mail
Doug Hardie: > This is a small server with a few users that are all local. There > are several domain names that point to this server, but all of > them are just aliases for the main name. Received mail stops at > the rcpt to: line. There is no OK that occurs until shortly after > 3 minutes from that line being received. During that time ktrace > shows multiple calls and sleeps for proxymap. After the 3+ minute > delay, it issues the OK and then they rest proceeds normally. I > suspect this is a configuration error since this server was just > updated to 3.3.4 from an earlier version. The earlier version > worked fine. This problem started when the upgrade completed. By default, the Postfix SMTP server invokes the proxymap service for local user lookup, because the default local_recipient_maps setting looks like this: local_recipient_maps = proxy:unix:passwd.byname $alias_maps Try, as a root user: postmap -q nosuchuser proxy:unix:passwd.byname postmap -q root proxy:unix:passwd.byname I suspect that your proxymap service is busted. Wietse
Delays in receiving mail
This is a small server with a few users that are all local. There are several domain names that point to this server, but all of them are just aliases for the main name. Received mail stops at the rcpt to: line. There is no OK that occurs until shortly after 3 minutes from that line being received. During that time ktrace shows multiple calls and sleeps for proxymap. After the 3+ minute delay, it issues the OK and then they rest proceeds normally. I suspect this is a configuration error since this server was just updated to 3.3.4 from an earlier version. The earlier version worked fine. This problem started when the upgrade completed. brain# postmap -n postmap: fatal: usage: postmap [-NfinoprsuUvw] [-c config_dir] [-d key] [-q key] [map_type:]file... brain# postconf -n command_directory = /usr/local/sbin compatibility_level = 2 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debug_peer_list = faxage.com debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $proce html_directory = /usr/local/share/doc/postfix inet_protocols = ipv4 local_recipient_maps = unix:passwd.byname $alias_maps mail_owner = postfix mail_spool_directory = /var/mail/ mailbox_size_limit = 0 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man message_size_limit = 10240 mydestination = $myhostname, localhost.$mydomain, localhost, remotesupportservicesllc.com, rssllc.us, mail.rem .us mydomain = remotesupportservicesllc.com mynetworks_style = host newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtpd_authorized_xclient_hosts = 10.0.1.0/24 smtpd_error_sleep_time = 10 smtpd_hard_error_limit = 10 smtpd_milters = unix:/var/run/clamav/clmilter.sock smtpd_recipient_restrictions = reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_soft_error_limit = 1 smtpd_tls_cert_file = /etc/mail/certs/mail.pem smtpd_tls_key_file = /etc/mail/certs/mail.key smtpd_tls_loglevel = 1 smtpd_tls_security_level = may unknown_local_recipient_reject_code = 550 -- Doug
Re: Duplicate spamd lines in Postfix log file
Thanks Matus
In main.cf
virtual_transport=spamass-dovecot
In master.cf
spamass-dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/bin/spamc -u spamd -e
/usr/lib/dovecot/deliver -d ${recipient}
I hope this helps.
Regards
--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Duplicate spamd lines in Postfix log file
On 30.06.19 06:36, dpjanda wrote: It sure is is, and that's why I posted the original question here. As it could, perhaps, be an error on my part how I call it from POSTFIX, so I thought I would ask the question here, first. you have not attached any information about how you call spamd from postfix. However, only process 2142 seems to be related to the mail you are receiving. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
Re: Duplicate spamd lines in Postfix log file
It sure is is, and that's why I posted the original question here. As it could, perhaps, be an error on my part how I call it from POSTFIX, so I thought I would ask the question here, first. -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Duplicate spamd lines in Postfix log file
dpjanda: > Thanks. > > Yes, I should have clarified that my log file is from multiple sources. > Sorry about that. > > Is it normal to have more than one spamd process per message? This is the POSTFIX mailing list.
Re: Duplicate spamd lines in Postfix log file
Thanks. Yes, I should have clarified that my log file is from multiple sources. Sorry about that. Is it normal to have more than one spamd process per message? Regards -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Duplicate spamd lines in Postfix log file
dpjanda: > Jun 29 09:20:10 email spamd[1101]: util: setuid: ruid=5001 euid=5001 > rgid=5001 5001 5001 egid=5001 5001 5001 > Jun 29 09:20:15 email spamd[1102]: util: setuid: ruid=5001 euid=5001 > rgid=5001 5001 5001 egid=5001 5001 5001 First, these lines are logged by different spamd processes. Second, this is not a Postfix logfile. It's a file that contains logging from multiple programs. Wietser
Duplicate spamd lines in Postfix log file
Greetings I hope someone can help with what is not a problem as such, but a query. In every Spamassassin (spamd) exchange there appears to be two lines that are *almost* identicle. Jun 29 09:20:09 email spamd[2142]: spamd: connection from ::1 [::1]:57558 to port 783, fd 5 Jun 29 09:20:09 email spamd[2142]: spamd: processing message <20190627140139?thesys...@tastecard.co.uk> for spamd:5001 Jun 29 09:20:10 email spamd[1101]: util: setuid: ruid=5001 euid=5001 rgid=5001 5001 5001 egid=5001 5001 5001 Jun 29 09:20:15 email spamd[1102]: util: setuid: ruid=5001 euid=5001 rgid=5001 5001 5001 egid=5001 5001 5001 Jun 29 09:20:18 email spamd[2142]: spamd: identified spam (3.0/3.0) for spamd:5001 in 8.4 seconds, 16236 bytes. Jun 29 09:20:18 email spamd[2142]: spamd: result: Y 3 - blah blah blah Jun 29 09:20:18 email spamd[1550]: prefork: child states: II It's the util: setuid lines. As stated, all is well, but can someone tell me why this is the case, and if there is an actual problem? Many thanks dpjanda -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Duplicate spamd entries in log file - I think
Greetings I hope someone can help with what is not a problem as such, but a query. In every Spamassassin (spamd) exchange there appears to be two lines that are *almost* identicle. It's the util: setuid lines. As stated, all is well, but can someone tell me why this is the case, and if there is an actual problem? Many thanks dpjanda -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
