"NOQUEUE: reject: RCPT from ... : Recipient address rejected" etc error

Question

Level 1

0 points

"NOQUEUE: reject: RCPT from ... : Recipient address rejected" etc error

I've got the following error in my SL Server 10.6.4 mail server log:

Sep 4 17:22:06 myservername postfix/smtpd[74713]: connect from asmtpout028.mac.com[17.148.16.103]
Sep 4 17:22:06 myservername postfix/smtpd[74713]: NOQUEUE: reject: RCPT from asmtpout028.mac.com[17.148.16.103]: 450 4.7.1 <myaccountname@myspecificdomain.com>: Recipient address rejected: Service is unavailable; from=<myaccountname@me.com> to=<myaccountname@mydomain.com> proto=ESMTP helo=<asmtpout028.mac.com>
Sep 4 17:22:07 myservername postfix/smtpd[74713]: disconnect from asmtpout028.mac.com[17.148.16.103]

and I get the same result any time my server must deliver to its internal recipients some mail from MobileMe.

While emails arrive from other mail servers, e.g. gmail, the system accepts averything and delivers it.

Just to see the log of an incoming mail from gmail:

Sep 4 17:39:46 myservername postfix/smtpd[74953]: connect from mail-ww0-f47.google.com[74.125.82.47]
Sep 4 17:39:56 myservername postfix/smtpd[74953]: A2871BA721: client=mail-ww0-f47.google.com[74.125.82.47]
Sep 4 17:39:56 myservername postfix/smtpd[75004]: connect from mail-ww0-f47.google.com[74.125.82.47]
Sep 4 17:39:57 myservername postfix/cleanup[74983]: A2871BA721: message-id=<longcodehere@mail.gmail.com>
Sep 4 17:39:57 myservername postfix/qmgr[59405]: A2871BA721: from=<myaccountname@gmail.com>, size=1897, nrcpt=1 (queue active)
Sep 4 17:39:57 myservername postfix/smtpd[74986]: connect from localhost[127.0.0.1]
Sep 4 17:39:57 myservername postfix/smtpd[74986]: C08F4BA728: client=localhost[127.0.0.1]
Sep 4 17:39:57 myservername postfix/cleanup[74983]: C08F4BA728: message-id=<AANLkTi=longcodehere@mail.gmail.com>
Sep 4 17:39:57 myservername postfix/smtpd[74986]: disconnect from localhost[127.0.0.1]
Sep 4 17:39:57 myservername postfix/qmgr[59405]: C08F4BA728: from=<myaccountname@gmail.com>, size=2358, nrcpt=1 (queue active)
Sep 4 17:39:57 myservername postfix/pipe[74989]: C08F4BA728: to=<myaccountname@mydomain.it>, relay=dovecot, delay=0.02, delays=0/0/0/0.01, dsn=2.0.0, status=sent (delivered via dovecot service)
Sep 4 17:39:57 myservername postfix/qmgr[59405]: C08F4BA728: removed

it delivers the message but I've the suspect that some redundance occurs.

No problems with outgoing mail.

This is my postfix configuration:

myserver:/ root# postconf -n
biff = no
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug peerlevel = 2
enable serveroptions = yes
header_checks = pcre:/etc/postfix/custom headerchecks
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
local recipientmaps =
mail_owner = _postfix
mailbox sizelimit = 0
mailbox_transport = dovecot
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps rbldomains =
message sizelimit = 31457280
mydestination = $myhostname, localhost.$mydomain, mail.mydomain.com, www.mydomain.com, $mydomain
mydomain = mydomain.com
mydomain_fallback = localhost
myhostname = myservername.mydomain.com
mynetworks = 127.0.0.0/8
newaliases_path = /usr/bin/newaliases
queue_directory = /private/var/spool/postfix
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relayhost =
sample_directory = /usr/share/doc/postfix/examples
sendmail_path = /usr/sbin/sendmail
setgid_group = _postdrop
smtp sasl_passwordmaps =
smtpd clientrestrictions = permit_mynetworks permit saslauthenticated permit
smtpd enforcetls = no
smtpd helorequired = yes
smtpd helorestrictions = reject invalid_helohostname reject non_fqdn_helohostname
smtpd pw_server_securityoptions = cram-md5
smtpd recipientrestrictions = permit saslauthenticated permit_mynetworks reject unauthdestination check policyservice unix:private/policy permit
smtpd sasl_authenable = yes
smtpd tlsCAfile = /etc/certificates/myservername.mydomain.com.longcodehere.chain.pem
smtpd tls_certfile = /etc/certificates/myservername.mydomain.com.longcodehere.cert.pem
smtpd tls_excludeciphers = SSLv2, aNULL, ADH, eNULL
smtpd tls_keyfile = /etc/certificates/myservername.mydomain.com.longcodehere.key.pem
smtpd tlsloglevel = 0
smtpd use_pwserver = yes
smtpd usetls = yes
tls randomsource = dev:/dev/urandom
unknown local_recipient_rejectcode = 550
virtual aliasmaps =

what am I forgetting?
where is the mistake?
is a conf problem either I've got a MTU black hole as someone has suggested me?

the MTU of my cisco router seems to be 1464

any help?

MacBook Pro 17", Mac OS X (10.6.4), 4GB/250GB, iMac 27" 4/1T, iPad 64 3G, various peripherals

Posted on Sep 4, 2010 9:19 AM

Reply

Answer 1

santelia Author

Level 1

0 points

Sep 4, 2010 9:29 AM in response to santelia

Same result from Yahoo incoming messages:

here is the log:

Sep 4 18:26:23 myservername postfix/smtpd[75721]: connect from n23.bullet.mail.ukl.yahoo.com[87.248.110.140]
Sep 4 18:26:24 myservername postfix/smtpd[75721]: NOQUEUE: reject: RCPT from n23.bullet.mail.ukl.yahoo.com[87.248.110.140]: 450 4.7.1 <myaccountname@mydomain.com>: Recipient address rejected: Service is unavailable; from=<myaccountname@yahoo.it> to=<myaccountname@mydomain.com> proto=SMTP helo=<n23.bullet.mail.ukl.yahoo.com>
Sep 4 18:26:24 myservername postfix/smtpd[75721]: disconnect from n23.bullet.mail.ukl.yahoo.com[87.248.110.140]

What's happening?

Am I wrong in any configuration setting?

Thank you for giving me help, guys...

Reply

Answer 2

santelia Author

Level 1

0 points

Sep 4, 2010 9:36 AM in response to santelia

But from Yahoo, without any more action from me, so clearly after its automatic retry, that's the new result log:

Sep 4 18:29:25 myservername postfix/smtpd[75776]: connect from n23.bullet.mail.ukl.yahoo.com[87.248.110.140]
Sep 4 18:29:25 myservername postfix/smtpd[75776]: 73E88BA7F8: client=n23.bullet.mail.ukl.yahoo.com[87.248.110.140]
Sep 4 18:29:25 myservername postfix/cleanup[75784]: 73E88BA7F8: message-id=<longcodehere@web29116.mail.ird.yahoo.com>
Sep 4 18:29:25 myservername postfix/qmgr[59405]: 73E88BA7F8: from=<myaccountname@yahoo.it>, size=2744, nrcpt=1 (queue active)
Sep 4 18:29:25 myservername postfix/smtpd[75776]: disconnect from n23.bullet.mail.ukl.yahoo.com[87.248.110.140]
Sep 4 18:29:26 myservername postfix/smtpd[75787]: connect from localhost[127.0.0.1]
Sep 4 18:29:26 myservername postfix/smtpd[75787]: 57E3EBA809: client=localhost[127.0.0.1]
Sep 4 18:29:26 myservername postfix/cleanup[75784]: 57E3EBA809: message-id=<longcodehere@web29116.mail.ird.yahoo.com>
Sep 4 18:29:26 myservername postfix/smtpd[75787]: disconnect from localhost[127.0.0.1]
Sep 4 18:29:26 myservername postfix/qmgr[59405]: 57E3EBA809: from=<myaccountname@yahoo.it>, size=3205, nrcpt=1 (queue active)
Sep 4 18:29:26 myservername postfix/smtp[75785]: 73E88BA7F8: to=<myaccountname@mydomain.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=1, delays=0.36/0.01/0/0.66, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=59259-09, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 57E3EBA809)
Sep 4 18:29:26 newthor postfix/qmgr[59405]: 73E88BA7F8: removed
Sep 4 18:29:26 newthor postfix/pipe[75790]: 57E3EBA809: to=<myaccountname@mydomain.com>, relay=dovecot, delay=0.03, delays=0/0.01/0/0.02, dsn=2.0.0, status=sent (delivered via dovecot service)
Sep 4 18:29:26 newthor postfix/qmgr[59405]: 57E3EBA809: removed

Again, someone can explain me such a strange behavior?
Why at the first try the mail fromyahoo is rejected and at the second try it is accepted and delivered?

Why mail from mobileme is cut out?

It's a matter of what?

Reply

Answer 3

MrHoffman

Level 10

146,305 points

Sep 4, 2010 10:14 AM in response to santelia

The typical trigger for folks that have these error is that the DNS is misconfigured; incorrect MX or incorrect reverse DNS, most likely.

The use of dynamic IP and of misconfigured DNS are commonly considered reasonably reliable flags indicative of spam engines, and summarily rejected by many of the receiving SMTP servers.

Given the domain and SMTP server information is public (and the botnets know how to look this stuff up all by themselves), there's little effectiveness granted from obfuscation. That just means I can't check your DNS from here.

If you're incorrigibly shy about your domain identity, Google search for Cricket Liu's or other DNS-checking tools and sites, and confirm your DNS is valid; that your DNS names and host names and MX record all match the identity of your mail server.

Reply

Answer 4

pterobyte

Level 6

11,104 points

Sep 4, 2010 10:45 AM in response to santelia

The is caused by greylisting. See here for a solution: http://osx.topicdesk.com/content/view/144/45/

HTH,
Alex

Reply

Answer 5

santelia Author

Level 1

0 points

Sep 4, 2010 11:35 AM in response to MrHoffman

@MrHoffman

I don't think this has anything to do with my situation.
Myserver.mydomain.com is inside a public area of a network. It uses one public IP from our pool of 32. All the remaining servers in the same public reachable area don't have any problem with mail delivery. The Cisco battery of routers and firewall do perfectly their job since years. The DNS of myserver.mydomain.com and of course of all the A, Cname etc records of mydomain.com are configured as for our long time running policy which is in use for all the remaining servers and domains we have. Our primary and secondary DNS servers have large redundancy and a reaction time of less than 3'. Never used dinamic IPs for any server of ours, neither put them in any misconfigured network. So thank you for your suggestion but really believe this is not that case.

Reply

Answer 6

santelia Author

Level 1

0 points

Sep 4, 2010 11:40 AM in response to pterobyte

@ pterobyte

Nice nick... 🙂

Thank you for your suggestion.
I'd already heard about greylisting possible consequences such as delays and so on.
I'm wondering how much spam will be on the road to our server with greylisting disabled.
What's your opinion on that? Significant issue or not?

Reply

Answer 7

odaigle

Level 1

0 points

Oct 8, 2010 8:55 AM in response to santelia

I had the same issue as you, and removing the "check policyservice unix:private/policy" item from smtpd recipientrestrictions fixed my problem. I figure that everybody who has the "check policyservice unix:private/policy" option will see the NOQUEUE: reject: RCPT from message and experience delays in the delivery of the messages. Is that the case ?

My main problem with the NOQUEUE: reject message was not the delay it induced. I was afraid mail would be dropped or bounced by the remote server and not being delivered to my server. Does anybody experienced mail not being delivered because of the NOQUEUE: reject ?

As for the effect on the spam, so far so good. No more spam as before the change.

Reply

Answer 8

DCGOO

Level 3

769 points

Oct 13, 2010 7:36 AM in response to santelia

Again, someone can explain me such a strange behavior?
Why at the first try the mail fromyahoo is rejected and at the
second try it is accepted and delivered?

It is called "greylisting" and is on by default on 10.6 servers. See http://www.greylisting.org/

There has been numerous discussions of its merits and demerits right here in groups. Also discussions on why there is not an option selection in server admin to turn it on or off. To disable it you must manually edit the postfix config files, which you may or may not be comfortable doing.

Personally, I find it enormously useful. It completely removed the requirement to run client side filtering at all. The only problem is if subsequent attempts to deliver a message come from different IP address in a large pool of mail servers, the delay may be increased. I know that yahoo does that, and suspect me.com also does. But I get very little mail from me.com so I have not noticed. It does build a database on the fly of legitimate senders, so things improve over time. Other than the case above, it only adds a minute or few to the delivery of first messages.

If you turn up SMTP logging to "information" you should see the 450 series messages back to the sending server. 450 basically means "Not now, please try later"

Reply

Answer 9

UptimeJeff

Level 4

3,479 points

Oct 13, 2010 7:40 PM in response to odaigle

the 450 error does not cause a bounce, just a delay. The sending error will retry.

Reply

Answer 10

jaallen

Level 1

0 points

Oct 14, 2010 6:46 PM in response to santelia

Thank You very much for this fix, and the older post about greylisting. Fixed me up. Decided to hit the books and posts to leave it on, and work with it.

Message was edited by: jaallen

Reply