[Gllug] Rejecting mail at backup MX

Bruce Richardson itsbruce at uklinux.net
Wed Feb 11 13:18:50 UTC 2004

On Tue, Feb 10, 2004 at 08:36:15PM +0000, Alistair wrote:
> Mail is most easily delivered to final users from a single machine. Mail is 
> most easily accepted from remote hosts when there are multiple machines. As a 
> practical matter, getting mail from multiple machines onto one single machine 
> is most easily accomplished by using the backups to channel legitimately 
> addressed email to the primary where it can be handled appropriately.

Oh, all right, then.  Look, this is bloody irrelevant.  Yes, many
organisations will have a single mailstore but there's absolutely no
reason for that machine to be one of your primary mail exchangers.  In
fact, there are any number of good reasons for all of your mail
exchangers to be relays and to keep your mailstore hidden from the
public Internet.  Here are just a couple:

	1.  Security.  Do I really have to explain why it is more secure
	for your iternal pop/imap store not to be visible to the outside

	2.  Performance.  It allows you to separate the load of dealing
	with incoming mail from the load of serving up mail.  This means
	that a sudden influx of huge powerpoint attachments doesn't make
	your mailstore or webmail system slow to a crawl.

I could go on, but those are two pretty good reasons.  Of course, maybe
I'm just completely barking, along with the mail admins at Google and
other such organisation.  Oh, and let's ignore the fact that many
organisations are large enough to need multiple mailstores just to cope
with their staff load, because obviously they should be made to
shoe-horn into this "one mailstore to rule them all" philosophy.

> What you seem to be suggesting is that you use backups and primaries as a 
> single zone where everyone legitimate is "local".

No, I'm not.  What you are trying to do is describe my way of doing
things in your very arbitrary and (imo) entirely bogus terminology.
Deeply bogus.  Internet mail protocols and the ip protocol suite make it
very easy to create any number of flexible mail networks to cope with
the needs of individual organisations.

I'm not even sure that you have a solid grasp of the issues involved,
since the various posts in this thread have clearly shown a) that there
are any number of policy reasons why a mail may be rejected, it's not
just a matter of who has an account and b) it's quite easy to configure
relays to support the policies of multiple final destinations.

> Admins can do whatever they like inside their own networks -- without heed to 
> the RFCs. 

And yet you feel able to say "That's not what backups are for and you
are wrong to do it".

> Doing so considerably eases administration for me, though.

If you said "I run a small network where this model makes sense", that I
would accept.  If you said "I'm a lazy bastard and this is as much work
as I want to do", that would have its own logic.  "You have
misunderstood what a backup is for, stop rejecting invalid mail, you
naughty administrative  person, you." makes no sense and has no logic.


I am now a little wary of bananas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20040211/b3a3871e/attachment.pgp>
-------------- next part --------------
Gllug mailing list  -  Gllug at gllug.org.uk

More information about the GLLUG mailing list