On 8/22/07, Rense Buijen <[EMAIL PROTECTED]> wrote:
>
> Thanks a lot all, it's all clear to me now!
> I though that the trusted networks mean that the message will just be
> passed it it came from that source.
> I didnt know it will skip to the next "Received" IP. Thanks a lot.
>
> One question about the "backscatter" problem though, if I understand
> correctly it is always my Exchange server (the machine inline with SA)
> who will send out "user does not exist" messages, right? The backup MX
> will merely try to forward it and the Exchange server decides if that
> mail address exists or not. I think Exchange is configured the right way
> in such a way that it knows what users it has on the system..


Older Exchange servers will accept any message to a domain they are
responsible for, and then generate a new NDR message to the "sender" if the
user does not exist.  This is pretty retarded and leads to tons of
undeliverable NDRs clogging up your outbound queues, innocent people
gettings NDRs from spam they didn't send, etc.  At some point (I don't
remember the exact Exchange version, but definately 2003 and 2007, probably
2000) MS started allowing you to make Exchange reject mail for unknown users
during the SMTP transaction, which is a much better way to go about
things.   In your situation, that would just make your SA machine have to
send NDRs instead of your Exchange box, since it accepted the message.  This
is where you need to add recipient verification to your SA servers.  When
Exchange is in the "reject unknown" mode, that works fine and you can reject
unknowns before they enter your network at all.  This way you do not need to
mess with LDAP or expose any active directory to dmz/outside servers, and
you never have any NDR responsibility for spam.


> I would really like to drop the second mx altogether but policy forbids
> it :)



Backup MXs are a good thing, just have to configure them correctly and they
are don't require much maintenance after that.

Thanks for all the help guys!
>
> Rense
>
> Bowie Bailey wrote:
> > Rense Buijen wrote:
> >
> >> Mathhias,
> >>
> >> The problem is that when the mail enters the backup MX, we dont know
> >> if that mail is blacklisted at for instance spamcop.
> >> So if the backup mx accepts the mail (because it's dumb and it will
> >> accept it), and my primary mx (SA) has set the backup mx as trusted
> >> network/source, the mail will be delivered while it should not have
> >> been. You see the problem? SA cannot see if the mail that has been
> >> forwarded by my backup MX is valid (black/whitelisted) or not because
> >> it cannot check the IP against the RBL, it will lookup the wrong IP.
> >> And it should do this because there is NO rbl checking on the backup
> >> MX itself...
> >>
> >
> > You are making assumptions about what trusted_networks implies.  Just
> > because mail comes from a machine in your trusted_networks doesn't mean
> > that it will not be scanned.  The ONLY thing that trusted_networks means
> > is that you trust those machines to put valid header information in the
> > message.  It does NOT mean that you trust them not to forward spam.
> >
> > For your configuration, you need to put your backup MX into
> > trusted_networks in order for the RBLs to work properly.
> >
> > The real problem with this setup is that once your backup MX starts
> > forwarding messages to the primary and spam is rejected, then your
> > backup is in the bad position of having to issue a delivery notification
> > to the sender.  This is bad because most spam and viruses fake the
> > sender information.  So most of your bounces will be going to the wrong
> > person.  This is called "backscatter" and is another form of spam.  A
> > mailserver should not accept mail that it will not be able to deliver.
> >
> > I would suggest that you either configure your backup the same as your
> > primary, or just drop the backup altogether.  Without the backup, the
> > sending MTAs will still retry the message (usually for at least a couple
> > of days), so you don't lose anything unless your MX is down for an
> > extended period of time.
> >
> >
>
>
> --
> Met vriendelijke groeten,
>
> Rense Buijen
> Chess Service Management
> Tel.: 023-5149250
> Email: [EMAIL PROTECTED]
>
>

Reply via email to