2

I'm trying to send an email through Postfix from mydomain.com to an address I know exists (info@example.org). Postfix is reporting though that the address does not exist.

Excerpt from mail.log

Jun  7 07:01:47 mydomain postfix/smtp[50352]: 010BB40606: to=<info@example.org>, relay=remote.example.org[redacted]:25, delay=1.2, delays=0.37/0/0.37/0.48, dsn=5.0.0, status=bounced (host remote.example.org[redacted] said: 550 Address unknown (in reply to RCPT TO command))
.

Here is the telnet session (from the server where Postfix runs) showing that the address exists:

# telnet remote.example.org 25
Trying [redacted]...
Connected to remote.example.org.
Escape character is '^]'.
220 sophos.example.local ESMTP ready.
HELO mydomain.com
250 sophos.example.local Hello mydomain.com [redacted]
MAIL FROM: <myaddress@mydomain.com>
250 OK
RCPT TO: <info@example.org>
250 Accepted

Here is the output from "postconf -n":

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 2h
inet_interfaces = loopback-only
inet_protocols = ipv4
mailbox_size_limit = 0
maximal_backoff_time = 15m
maximal_queue_lifetime = 2h
milter_default_action = accept
milter_protocol = 2
minimal_backoff_time = 5m
mydestination = mydomain.com, localhost.mydomain.com
myhostname = mydomain.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters = inet:localhost:12301
queue_run_delay = 5m
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_milters = inet:localhost:12301
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_tls_cert_file = /etc/letsencrypt/live/www.mydomain.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/www.mydomain.com/privkey.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes

The message has bounced several times.

Help much appreciated.

herrherr
  • 155
  • 1
  • 8
  • 2
    This looks like an issue on the remote side. Can you talk to the guys in change there? – Andreas Rogge Jun 08 '17 at 12:55
  • Yes, indeed. After some more research it looks like a Sophos firewall(?) is causing this problem by what seems to be called "recipient verification". The address I'm sending from and and the address in the return-path do exist though. – herrherr Jun 08 '17 at 13:15
  • yep. that's probably why it sais "address unknown" and not "user unkown" – Andreas Rogge Jun 08 '17 at 13:17
  • @AndreasRogge I think it would be worthwhile to develop that a little more and post it as an answer as I can see that it would be of benefit to others who come across this issue. I, for one, probably wouldn't attach any importance to getting "address unknown" instead of "user unkown". – Anthony Geoghegan Jun 08 '17 at 13:53

1 Answers1

1

The relevant part of your log is host remote.example.org[redacted] said: 550 Address unknown (in reply to RCPT TO command). This basically means the remote host decided not to accept this mail. It sais that an address is unknown.

In today's time of spam filters error messages don't always mean what they say. Also "Address unknown" is rather unspecific as it could mean the recipient or the sender.

As the response is recieved in response to RCPT TO command the remote host has rather limited knowledge (i.e. it hasn't seen the mail content, return-path, etc. yet). The decision could be based on the sending server's ip-address, HELO hostname, MAIL FROM address or RCPT TO address.

If the error message is correct it must be related to MAIL FROM or RCPT TO as these are "addresses" - the other two are (at least in an SMTP context) not addresses.

When you're talking to a "normal" mail server that gives more verbose output the response for an unknown recipient address usually reads "user unknown" or "recipient address rejected". The terse "address unknown" is a slight hint that something is going on. In this case there's two things to do:

  1. Try the telnet debug session with the same HELO or EHLO your mail system uses and use the same MAIL FROM and RCPT TO as the mail that failed.
  2. Contact the owner of the recieving server that you're having issues sending legitimate mail to her system. Most people in charge will actually try to help you with that. The logs on the recieving side are usually way more informative than on the sending side. Make sure you include the exact Date and Time along with your from- and to-addresses to your request as it really helps to find the corresponding log entry.
Andreas Rogge
  • 2,853
  • 11
  • 24