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
>
>
|