 |
 |
But the Internet IS made up of lots of tubes! I have photographic evidence: http://archives.obs-us.com/obs/german/books/wiggins/cover.gif /rich On 10/25/07, Kwiatkowski, Nicholas <[log in to unmask]> wrote: > I would have just blamed it on the "tubes" :) > > Sorry, bad political joke. > > -Nick Kwiatkowski > MSU Telecom Systems > > -----Original Message----- > From: MSU Network Administrators Group [mailto:[log in to unmask]] On > Behalf Of Vasquez, Timo > Sent: Thursday, October 25, 2007 8:52 AM > To: [log in to unmask] > Subject: Re: [MSUNAG] E-mail Issues > > I have been in a similar situation with a clearing house email because > of a customers infrastructure upgrade and their lack of that knowledge. > > I was the network manager and being put on the spot to answer why it > took several hours for a simple mail with one attachment only 230kbs (if > memory serves me). Then I was expected to track the message as if it > were a fedex package. > > The only thing I could do was prepare a simple visio diagram of our mail > system, then show how it went out our building using a tracert command > result that I included in a graphic representation. I then requested > that I be in touch with this companies IT staff to provide the same kind > of document so I could represent the "start to finish" This clearing > house is international so it was like pulling teeth, and it was done > after a week and 5 more days of late emails. > > Turned out two reasons for delay. They had a new spam filter called Spam > Assasin that had not been fully "tweeked" to suit their big organization > yet. The mail my user was sending had a html type signature that > referenced an image that pointed to our corporate web site. So it was > being examined and then sent through in plain text style with > attachment. > > From that day forward I requested that diagram for all our client base, > and if some of them had emails from yahoo, hotmail, Comcast and aol for > their desired reciving account, I had a disclaimer that I can not > control the paths for public venues so delays; though unfortunate were > not the fault of (my old company). > > So that is the three angles: > 1.our environment (which can be the cause but is the only tangible part > we control) > 2.the isp between us and the recipient, and > 3.the recipient environment (where everything from their ISP, Network > based Spam Filters, and Desktop Solutions are usually the problem and > kept from us doing the technical troubleshooting) > > If I ran the network equipment here and controlled the mail server you > send from I would go out of my way to get you your answer... Good luck > to you and I am sure some of the people here on this list will help you > settle your issue. > > Timo > > -----Original Message----- > From: MSU Network Administrators Group [mailto:[log in to unmask]] On > Behalf Of Laurence Bates > Sent: Wednesday, October 24, 2007 2:12 PM > To: [log in to unmask] > Subject: Re: [MSUNAG] E-mail Issues > > Yes, but what do you tell upper level administrators when they find that > a > major funding source is being jeopardized by untimely email > communications? > Relying on what you hear from people is convenient but not very > sensitive to > their real concerns. > > -----Original Message----- > From: Brian Martinez [mailto:[log in to unmask]] > Sent: Wednesday, October 24, 2007 1:40 PM > To: [log in to unmask] > Subject: Re: [MSUNAG] E-mail Issues > > All, > > I would like to point to my original in-depth thread on the matter of > greylisting: > > http://list.msu.edu/cgi-bin/wa?A2=ind0704&L=MSUNAG&P=R995&I=-3 > > Furthermore, I would like to go even more in-depth and touch upon > several things to make sure we are all on the same page about this. > There are going to be lots of numbers, so please read closely: > > ------ > * A sender only needs to send 1 message, not 3 messages. > * A sender does not a receive a flat out rejection, merely a 451 > Temporary Error. > * A sender not in our database has to go through the greylisting delay, > sender's who have passed the test should get through without exception > * With a properly configured SMTP server, most senders can get through > the greylisting process in well under one hour. > * Our SMTP daemons at mail.msu.edu are configured to respond to 451 > Temporary Errors as such: retry sending the message every five minutes > for fifteen minutes. Failing that, retry the message every ten minutes > for one hour. Failing that retry sending the message every two hours > for 16 hours, and so on... > * As I write this there are currently 1,109,396 hosts who we "trust" > Naturally, some of them are spammers, but most of them are not. > * The above number grows every single day/hour/minute. > ----- > The following should give you an idea of the exceptions we make. > These folks completely bypass the greylisting process: > * We maintain a list of exceptions for nearly all .gov addresses in the > United States (we generate it based off of our logs), currently at 4,242 > > listings > * We maintain a list of exceptions for every host here at MSU that > carries a valid MX record, currently at 341 listings > * We maintain a list of miscellaneous hosts of people who were privy > enough to go through our Help Desk and make sure their email goes > through as expected. We have helped a few hosts reconfigure their mail > servers to meet the RFC spec., currently at 151 listings > * We auto-generate a list of larger domains who carry SPF records, AOL, > Google, Amazon, Hotmail, Microsoft and more recently Fidelity > Investments, currently at 129 listings > * The website greylisting.org provides a list of hosts who have > difficulty bypassing anybody's greylisting setup. Including Southwest > Airlines, MoveOn.org, lists.mysql.com, and ameritradeinfo.com to name a > few. This only has 22 entries. > ------ > > You'll note from our stats page: > http://project.mail.msu.edu/~rrdtool/spam.php That we have easily > dropped 600,000 pieces of spam PER DAY since we implemented > greylisting!! Of course spam still does come through, and some > legitimate email does get dropped. But with folks knowing that they are > > expecting a piece of email and it hasn't come through, they know to hit > up our Help Desk and we work through to resolve the problem. > > I have not heard a single complaint about greylisting until just > recently, so I hope this helps put things in perspective and helps clear > > things up a bit. As Nick noted earlier, greylisting is system-wide. It > > sits as a transparent-bridge between the Internet and mail.msu.edu. The > > vast majority of people sending to us (nearly 1,110,000 different hosts) > > do not even know they have gone through greylisting. > > If there is email _not_being received, the best method for finding out > is testing with outside sources first, such as Gmail/Yahoo/Hotmail/etc. > > Then calling our Help Desk and providing them with full headers from the > > successfully received message at whatever 3rd party address that was > used. We will then investigate the issue and determine if its > greylisting or not, and if it is, we will see if it is possible to have > their mailer reconfigured properly. If that is outside of the scope of > the person attempting to mail us, we will work to add them to our > exceptions list (which also seems to grow weekly as of late). Of > course, if the issue is not greylisting, we will work to find the > appropriate area to move the issue into. > > If people are so inclined, then anyone is obviously free to migrate > elsewhere. I wanted to make sure as many facts as I could recall were > clear before anyone decides to go anywhere else. It is a very > trustworthy system and the majority of people I hear from swear by it > and are quite happy it is in place. > > Regards, > ./brm > > > __________ NOD32 2614 (20071024) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com >