 |
 |
The grey-listing method that MSU has implemented fully implements the RFC for SMTP E-Mail. There should be no blockage of legitimate email, only possible delays of up to 4 hours. Mail servers are required to re-try sending the email every 4 hours until the message goes through, up to 24 hours (although the 24 hour mark can be configured to be longer). Because most spam is generated from 'spam-bots' which often do not implement the RFC spec of email, this is a very effective way to block spam and other malformed email from entering our system. Most corporations and commercial email providers (including Gmail and Yahoo) have implemented greylisting as a form of spam protection. (I might be speaking without authority on this, but... )The way that MSU has implemented Greylisting is system-wide. They greylisting happens before it actually hits our mail-servers, and cannot be opted-out of. If you are having so many difficulties, there is always the option to run your own mail server, or have AIS host an Exchange instance for you... -Nick Kwiatkowski MSU Telecom Systems -----Original Message----- From: MSU Network Administrators Group [mailto:[log in to unmask]] On Behalf Of Laurence Bates Sent: Wednesday, October 24, 2007 9:30 AM To: [log in to unmask] Subject: Re: [MSUNAG] E-mail Issues I am not convinced that blocking the first instance of an email until a second arrives from the same source within four hours reflects the best interests of doing business on campus. It is trivial for a spammer to send multiple emails from the same source within a four hour period but almost impossible to get legitimate email sources to do the same thing. I really think that this practice should be thought through in conjunction with administrative units on campus since it affects their operations in very significant ways. Quite frankly, now that I know how this spam filter works, I don't see how I can justify using my MSU email address to do MSU business and will need to migrate to some form of alternate. Is there a way of option out of this portion of the spam filter? -----Original Message----- From: Edward R Kryda [mailto:[log in to unmask]] Sent: Tuesday, October 23, 2007 10:20 PM To: [log in to unmask] Subject: Re: [MSUNAG] E-mail Issues John Valenti writes: > > On October 23, at 5:18 PM October 23, Laurence Bates wrote: > >> In addition, I regularly have problems getting security codes for >> software that I purchase off the Internet and need to use immediately. > > Laurence, this is probably from the greylisting... email from a new > sender is automatically rejected the first (few?) times, just to help > make sure it is a valid smtp server. > > I have noticed this issue too, but felt that it was a worthwhile tradeoff > to reject more spam using this method. > > As I recall, a second message from the same sender goes thru immediately. > So if there is some means of getting the remote end to send any sort of > message to you first, the important message should come thru right away. > Maybe someone from the mail team could comment on this? After the second attempt at delivery, in under a 4 hour time period, the server is then trusted for approximately 36 days. (The process must be repeated afterwards) Unfortunately there are web apps which don't use an email server to send out confirmations, etc from their pages. They attempt at sending only 1 message without worrying about delivery errors. Please submit a problem ticket with the ACNS Help Desk at http://help.msu.edu if you're having an issue like this. If possible we try to see if a sending host is able to be RFC complaint with retrying delivery. If this fails and the server doesn't appear to be a potential large source of spam, then we can add its IP address to an exception list. > > >> I don't blame ACNS for the email delays since they are clearly related >> to the SPAM spikes that we typically get just before Fall and Spring >> breaks. > > Not sure where you are getting the spam spikes related to breaks? I > thought it was 24x7 problem, about 97% of messages are spam. Yeah, Spammers unfortunately don't rest. We do see overall system spikes that correspond to the University academic schedule. (I'm sure many other services do as well) Today's performance issues aren't related to Spam, but due to our issues with performing backups. More information is posted at: http://servicestatus.list.msu.edu -Ed __________ NOD32 2611 (20071023) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com