 |
 |
Your best bet would indeed be to whitelist mail.msu.edu (you may recall my MSUNAG plea to do this back in December of 2008, you were even one of the respondents :-) If you would like to take this approach, we have the entire 35.9.75.x subnet (denoted as 35.9.75.0/24). Furthermore, the way mail.msu.edu systems work are that each host holds onto its own queue. We do not mix our queue up amongst other servers. So if a message from the outside came into our servers, to mx01.mail.msu.edu and forwarded off to your servers, and you temporarily rejected it (which should be a 400 level error, not a 500 level permanent error)... mx01.mail.msu.edu and only mx01 will hold onto it and retry every 5 minutes for 15 minutes, then every 10 minutes for 1 hour, and so on (we follow the SMTP RFC "SHOULD" on retry strategies). We run greylisting using OpenBSD's spamd and toss out 451 Temporary failure, please try again later. If the sending hosts are properly configured to RFC (should) standards, then we really don't have any problems. Just sometimes we have people who are impatient. We also have a way to configure it to throw 500 level messages, but that is for a blacklisting mode only, as you would probably expect because the 550 we can give is a permanent rejection. I keep mentioning this error because I'm concerned about the 553 you specified below. Then again, I have no idea how greylisting works on the M+Guardian. Anyway, if you have any more questions or need some more help you know where to find me. I apologize if I missed something, I'm working on very little sleep and its starting to catch up to me. ./brm On 4/8/2010 3:39 PM, Doug Nelson wrote: > Seems like your best bet would be to whitelist the mail.msu.edu servers. > > Doug > > > > On Thu, Apr 08, 2010 at 03:19:33PM -0400, Steve Bogdanski wrote: > > >> Quick question: >> >> A few years ago I had to turn off the greylisting feature of our email firewall appliance (M+Guardian), because of issues with email forwarded from our users mail.msu.edu accounts to our email system. Problem was as follows: >> >> - mail exchange for mail.msu.edu, lets say mx01.mail.msu.edu, tries to forward message to @cvm.msu.edu >> - IP address for mx01.mail.msu.edu is not in greylisting database so @cvm.msu.edu replies back with 553 temporary >> - next attempt to send message from mail.msu.edu is picked up by different mail exchange, let's say mx02.mail.cvm.msu.edu >> - IP address for mx02.mail.msu.edu is not in greylisting database so @cvm.msu.edu replies back with another 553 >> - the above cycle continues until a mail exchange that is in the greylisting database actually tries to send the message (many times with great delay) or message delivery just fails >> >> The only solution I found to the above was to completely disable the greylisting feature on our appliance. Luckily the product we use does a great job without it, but I'd really like to enable it again and was wondering if the above is still going to cause trouble. Thanks in advance. >> >> >> -Steve Bogdanski >> >