Laurence,
I think your missing the point. Without grey-listing (amongst other spam countermeasures which can also delay email) you wouldn't really see much of a drop in email delivery times. That's because the system would end up being overloaded with incoming spam to the point that legitimate email would be delayed or possibly blocked (as mentioned earlier in this thread). So not only would you not necessarily remove the delays by disabling these systems, you could actually increase them and also end up flooding your users' mailboxes with a lot more spam.
As was also brought up earlier, you cannot compare email systems and delivery from 5-10 years ago to the present. Actually you can't even compare it to 1 or 2 years ago, there is just too much difference. With the increases in bot-driven spam networks and viruses, not to mention overall legitimate use and increasing use of email attachments, maintaining a email system has almost become a full-time job in itself (as opposed to just one responsibility of a network admin). The end fact is the RFC standard that is present day email wasn't designed for much of what goes on today.
As long as the preventative measures being put into place adhere to RFC specs that shouldn't be blamed. In my experience, many of the problems grey-listing (and reverse DNS also) have are to do with the remote site not having their system configured properly (according to RFC standards). It is this sloppy approach to setting up email systems on many receiving networks which causes most headaches. The only major problems I have ever had with our system receiving email from mail.msu.edu were on our side, and I can say that I am very glad that the folks at ACNS not only do such a great job, but that they are always willing help the rest of us out when needed.
--
Stephen Bogdanski
Network Support
College of Veterinary Medicine
Michigan State University
>>> On 10/25/2007 at 9:59 AM, <[log in to unmask]> wrote:
> The email system is essential for the types of pre-grant proposal
> collaboration. The final copy is probably Fed-ex'd but email forms the bulk
> of the transactions that take place in developing our grant proposals.
>
> All of which seems to me to be a mute point. Why on earth is anyone arguing
> that email should be slow? Ten to fifteen years ago the bandwidths between
> email sites were such that email was slow of necessity. Today, email is a
> drop in the bandwidth bucket and rather than expecting delays we should be
> much more in tune with the common expectation that email is close to
> immediate. CPU problems in filtering spam I can understand but intentional
> built-in delays are IMHO incompatible with 21st century organizational
> practices. This is the NOW generation, not the maybe-sometime crew and
> email for business, group scheduling and collaboration should be delivered
> NOW except in cases of exceptional technical constraint or equipment
> failure. Quite frankly, if I have to wait 30 seconds for some software
> company to send me a software activation code via email, that's already too
> long.
>
> -----Original Message-----
> From: Matt Holtz [mailto:[log in to unmask]]
> Sent: Thursday, October 25, 2007 8:57 AM
> To: Laurence Bates
> Cc: [log in to unmask]
> Subject: Re: [MSUNAG] E-mail Issues
>
> I can't speak for the College of Ed, but my wife is a PhD candidate in
> the Comm Arts department. She writes for grants all day. I asked her
> last night and she told me that regardless of the email system they
> never use email for grants. They use certified mail, fax, or telephone.
>
>
> Laurence Bates wrote:
>> In the College of Education there may be 30-40 faculty members working on
> 6
>> or 7 figure deals at any given time. I think that it is fair to say that
>> they are not aware that email is not a reliable enough transaction medium
>> for their activities. I think that it is also fair to say that certain of
>> them will "significantly perturbed" if their work turns out to be
>> jeopardized through email delays.
>>
>>
>> -----Original Message-----
>> From: Brian Martinez [mailto:[log in to unmask]]
>> Sent: Wednesday, October 24, 2007 2:43 PM
>> To: [log in to unmask]
>> Subject: Re: [MSUNAG] E-mail Issues
>>
>> Laurence,
>>
>> Firstly, the point to which you speak has never been an issue that we
>> have been made aware of. Secondly, I would be very afraid of doing
>> "major funding" strictly through email.
>>
>> How many people do you truthfully know who routinely run 7-figure deals
>> over email? I think your concern is placed at a higher matter that I
>> cannot address. The only thing I can comment on is that the greylisting
>> system has been in place for several months. We had the idea on the
>> table for several months before we wound up going live.
>>
>> Very few delays have stemmed from greylisting over the past months, but
>> we have done our best to see to it that they get fixed. Other delays
>> stem from numerous issues, our own email system not withstanding (for
>> example, yesterday's slowness due to problems with our NetApp). But I
>> have also seen problems on the sender's side, firewall issues, network
>> issues, and client wonkiness to boot.
>>
>> If you feel your concerns are not being met, I'm afraid you will need to
>> take them to some place higher than this list. I will continue to
>> advise against the impracticality of doing major business deals over
>> email without some other form of communication to be used as a backup.
>> I would never even buy something as little as $10 off the Internet
>> without knowing there was a phone number I could call in case there are
>> problems.
>>
>> If there are further questions anyone has about greylisting I will be
>> happy to do my best to answer them. It is a system that I play a large
>> part in because not too many of my other coworkers care to use OpenBSD.
> :-)
>>
>> ./brm
>>
>>
>> __________ NOD32 2614 (20071024) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>
>
> __________ NOD32 2617 (20071025) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
|
