I have a case that is odd to me and I can't figure it out. Hopefully
someone here will be able to set me straight. This is on a friend's
system that I am helping to maintain.
My friend somewhat out of the blue decided to start sending mail from
a rented VM server. I hadn't expected and don't think it is really
set up as it should for it. But people do what people do. It is not
set up with DKIM. "inet_interfaces = loopback-only" so it cannot
receive mail and therefore cannot possibly be relaying spam. This was
a clean IP as far as I could tell and my friend has used it for the
last few years. Therefore I know that it has not generated any email
at all other than what my friend has recently decided to send out
personally.
root@ergo:~$ grep 4E7541E092 /var/log/mail.log
Dec 19 13:11:55 ergo postfix/qmgr[2592]: 4E7541E092: from=<[[redacted]]>,
size=4861, nrcpt=2 (queue active)
Dec 19 13:11:55 ergo postfix/smtp[7858]: 4E7541E092:
to=<[[redacted]]@fortboise.org>,
relay=mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4]:25, delay=315407,
delays=315407/0.02/0.14/0, dsn=4.7.1, status=deferred (host
mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4] refused to talk to me: 554
5.7.1 Service unavailable; Client host [93.184.216.34] blocked using
urbl.hostedemail.com; Your IP has been manually blacklisted)
Dec 19 14:21:55 ergo postfix/qmgr[2592]: 4E7541E092: from=<[[redacted]]>,
size=4861, nrcpt=2 (queue active)
Dec 19 14:21:55 ergo postfix/smtp[19888]: 4E7541E092:
to=<[[redacted]]@fortboise.org>,
relay=mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4]:25, delay=319607,
delays=319607/0.02/0.18/0, dsn=4.7.1, status=deferred (host
mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4] refused to talk to me: 554
5.7.1 Service unavailable; Client host [93.184.216.34] blocked using
urbl.hostedemail.com; Your IP has been manually blacklisted)
And the above repeats. I made some obvious redactions and
93.184.216.34 is actually example.com but you can understand me
keeping my friend's information out of my email here. The IP listed
was the IP of my friend's VM originating the mail.
There are currently 15 requests in the queue. Which all appear to be
personal correspondence that my friend typed in. Prolific! They
eventually timeout after, I think, bounce_queue_lifetime as expected.
Here is a sample of the bounce message generated. Which is why I am
involved trying to help.
<[[redacted]]@fortboise.org>: host
mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4]
refused to talk to me: 554 5.7.1 Service unavailable; Client host
[93.184.216.34] blocked using urbl.hostedemail.com; Your IP has been
manually blacklisted
But this confuses me. It appears to me that the message was rejected
at SMTP time with a 554 code. Therefore shouldn't that generate a
bounce message immediately? Why is dsn=4.7.1 being logged there?
Was the actual SMTP rejecting a 554? Or was it a 471? I feel it must
have been a 471 because it is retrying instead of immediately
bouncing. Yet here it is saying it was a 554. In which case why
isn't it bouncing immediately?
I will include some hopefully useful information below.
Thanks!
Bob
root@ergo:~# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
inet_interfaces = loopback-only
inet_protocols = ipv4
local_header_rewrite_clients = permit_mynetworks, permit_sasl_authenticated
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
masquerade_classes = envelope_sender, header_sender
masquerade_domains = [[redacted]]
masquerade_exceptions = root
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
myhostname = ergo.[[redacted]]
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
This is on the Debian 9 Stretch version of Postfix for which I will
try to avoid the gasp of age from the version number as I don't think
that is the issue here. :-)
