 |
 |
The tubes are now in the ground --- not hanging in the sky. Maybe it is time for a revised edition? ;-) -Tom Richard Wiggins wrote: > 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 >> >>