 |
 |
True, which is why I often have the user use rules, rather than a simple forward. You could, for example, have the mail.msu.edu system tag the subject line when it detects SPAM, and then have a rule that states that all messages are forwarded. This will create a longer queue as the mail.msu.edu system does more processing, but the offset is that it has more information. +-------------------------------------------+ | Michael Surato | | College of Arts and Letters | | Michigan State University | | 320 Linton Hall | | East Lansing, MI 48824 | | Voice: (517) 353-0778 Fax: (517) 355-0159 | +-------------------------------------------+ > -----Original Message----- > From: MSU Network Administrators Group > [mailto:[log in to unmask]] On Behalf Of Adam McDougall > Sent: Friday, May 02, 2008 9:45 AM > To: [log in to unmask] > Subject: Re: [MSUNAG] Mail Forwarding > > I would like to mention that if the mail comes directly to > your mail server (mx) without forwarding, more original > information is preserved that is useful for AntiSpam > processing, and also you can chose to do more/less/different > blacklist or greylist rejection/delaying of email. > Basically, the original mail server accepting the request has > the most information available regarding the mail's source, > while mail servers down the line have less, and have to base > their Spam decisions on the content of the mail. Aside from > less accuracy at detecting Spam, some corner cases could > cause the opportunity for false positives to rise. > I've seen this happen. > > > On Fri, May 02, 2008 at 09:32:10AM -0400, Jon Galbreath wrote: > > You understood perfectly. And it sounds like we were on > the same page as > far as the outcome. Perhaps I'll leave it up to the end > user whether or not > to designate the @isp.msu.edu address on business cards or > correspondence, > since that would eliminate the potential forwarding delays, > despite them > being rare. > > Thanks for the info! > > Jon Galbreath > MCSA/MCSE/Security+ > Network/Systems Administrator > International Studies and Programs > Ph: 517-884-2144 > [log in to unmask] > > > -----Original Message----- > From: MSU Network Administrators Group > [mailto:[log in to unmask]] On > Behalf Of Brian Martinez > Sent: Friday, May 02, 2008 9:13 AM > To: [log in to unmask] > Subject: Re: [MSUNAG] Mail Forwarding > > Jon Galbreath wrote: > > > > All, > > > > We are moving forward with our move from mail.msu.edu to > an in-house > > Exchange installation. During the most recent Q&A session > I suggested > > that we leave everyone's address as the standard @msu.edu > address and > > just forward it into Exchange to make it easy if you ever > leave our > > unit and also to keep from having to update distribution > lists with > > new email addresses. > > > > One person asked about what happens when mail.msu.edu has another > > hiccup like the one that happened a couple weeks back where mail > > clients and the web interface were both offline. Would mail still > > forward on? > > > > My best recollection was that messages weren't bouncing > and were just > > queuing on the servers but we couldn't access them. If > that were the > > case, would a mail forwarder (not a filter, just a > straight forward) > > still pass mail on even if mail.msu.edu were down? > > > > Thanks for your help! > > > Jon, > > If I'm understanding what you are asking correctly the > answer is, yes > mail will still forward on, but only when mail.msu.edu is > back up. In > the situation where everything is down, the original > sender's will queue > up the message on their end as "Host unreachable" and their SMTP > software will attempt to retry every so often (it all > depends on what > their config is). > > If mail is up and running but just being hammered down and > "unreachable" > to our users, chances are pretty great that we will be the > ones queuing > up the emails waiting to forward them on when the > queue-runners get to it. > > To sum up, email should always (eventually, heh) be coming > through. Let > me know if I misunderstood. > > Regards, > ./brm > >