Can't receive mail

Please open terminal and post the unmodified output of postconf -n. Also have a look at /var/log/mail.log for clues.

I'm having a slightly different problem; the mail server seems to reject the message with "recipient address rejected, service unavailable" -- only later to accept it (the same message -- usually about ten minutes later) -- does anyone know what may be going on?

Matt, it's called "greylisting" (en.wikipedia.org/wiki/Greylisting) and it's turned on if you choose "Spam detection" mode in Server Admin. Can be turned off using postfix configuration files.

You're right, sorry about that -- I didn't realize it was enabled by default...

Is there any good documentation in terms of how the triplet behavior with the Dovecot install works?

if I turn on spam filtering, how do I whitelist my domains... it doesn't seem to allow delivery of any of my hosted domains even though they are configured in postfix.

I had the same problem, and for me it wasn't greylisting.

It looks like the 10.6 server upgrade borks the virtual hosting checks and denies mail sent to virtual mail host domains.

I just reapplied the osx.topicdesk.com webpage's directions on setting up postfix style virtual domains and that fixed the problem.

It took me half a day in testing and searching until I finally found your post saying this is "normal behavior" of 10.6 due to greylisting.

But why couldn't I find a word about it in the Mail Service Administration Guide, and why is there no control for greylisting in Server Admin? And why is there not a hint in the logfile, that the rejection of the incoming mail was done on purpose due to greylisting?

_Apple please:_
*Add a gralisting control to Server Admin*
*Explain the functionality in Mail Service Administration Guide*
*Add a reference to the logfile, if a mail was temporarily rejected due to greylisting*

PS: Could someone please explain, what exactly had to be done to disable graylisting. Thank you!

To disable greylisting edit /etc/postfix/main.cf

$sudo pico /etc/postfix/main.cf

from

smtpd recipientrestrictions = permit saslauthenticated permit_mynetworks reje ct unauthdestination check policyservice unix:private/policy permit

to

smtpd recipientrestrictions = permit saslauthenticated permit_mynetworks reje ct unauthdestination permit




Then restart the Snow Leopard Server.

Message was edited by: Robert LaRocca

Just to clarify, the original posters issue has nothing to do with greylisting. Matt's problem (which should not have been posted into this thread), is related to greylisting.

Furhtermore, SMTP logging should always be increased to "Information". This helps in finding the cause of an issue.

Also, after disabling greylisting it is enough to issue:
sudo postfix reload
No need to reboot the server.

HTH,
Alex

pterobyte wrote:
Just to clarify, the original posters issue has nothing to do with greylisting. Matt's problem (which should not have been posted into this thread), is related to greylisting.

You are right. We should have a separate thread about graylisting. But since Matt had posted his helpful hint here, I thought it would be appropriate to add my question and my suggestion for improvement here.

Furhtermore, SMTP logging should always be increased to "Information". This helps in finding the cause of an issue.

I have switched it already to "Debug" but in this case it wasn't very helpful.

+Sep 2 21:57:36 server postfix/smtpd(1647): NOQUEUE: reject: RCPT from mail.example.com(123.123.123.123): 450 4.7.1 <me@mydomain.com>: Recipient address rejected: Service is unavailable; from=<you@yourdomain.com> to=<me@mydomain.com> proto=ESMTP helo=<mail.example.com>+

There is no hint, that the rejection was done intentionally due to graylisting. At least "Recipient address rejected: Service is unavailable" doesn't sounds to me like that 😉

Also, after disabling greylisting it is enough to issue:
sudo postfix reload
No need to reboot the server.

Thank you, Alex

There is no hint, that the rejection was done intentionally due to graylisting. At least "Recipient address rejected: Service is unavailable" doesn't sounds to me like that

Indeed not very helpful. Hadn't realised the postgrey policy server used did not give a proper message. This will also be a problem when senders try to find out why mail is not being delivered immediately.

I have done the suggested fix for the greylist and that seemed to get rid of one of the problems I am having. thankyou!

When I send a new email from .mac from my Iphone not on LAN it is lightning fast, but if I forward an email with an attachment it chokes anywhere from and hour to about 5 hours the mail.log says "timeout after DATA" (default setting 600s). Is there a setting that deals with attachments? Or any ideas why it would delay just forwarded mail or mail with attachments?

postfix/smtpd[75416]: timeout after DATA (7097 bytes) from asmtpout012.mac.com[17.148.16.87]

or should i start a new thread?

The behavior you are describing sounds like an MTU mismatch between your computer and your DSL router-- and the server you're talking to on the other side. The symptoms you describe make me suspect that's the place to go next.

Did you have the server working prior to SL server, or did you upgrade your network hardware during or prior to the upgrade?

Incidentally, if this is the cause, you may want to turn greylisting back on after it's fixed-- in my testing, I get an 80% spam reduction. Once the server trains itself to your true senders (give it a day) mail delivery is fast.

changed back to the default configuration...have not noticed much difference I think you are right in leaving it on. all of my hardware is the same as far as the network hardware. the only problems i am having are from the .mac servers---gmail works fine after it is "learned" in the "greylisting feature" (for lack of a better term) the logs just stall for exactly 600s or 5min then it disconnects the host could the virus filters or spamassasin be causing this and where would i look?

thanks again

This thread has become a mess. There are a handful of unrelated issues. Future readers will not be able to understand which solution applies to which problem.

May I suggest that anybody needing help, open a new thread with as much detail as possible describing the issue.