On Fri, 10 Nov 2017, Rich Shepard wrote:
On Fri, 10 Nov 2017, David Barr wrote:
Something I've thought about for when I have my domain host back under my
direct control is acting as a backup MX for friends (and at least one of
them returning the favor). My idea is to act as a spooler until the
Primary MX is back. I haven't seen much documentation out there about a
mail server that just spools messages until the primary MX is back on
line, though.
David,
I've no idea how this works. When Aracnet/SpiritOne was a working ISP I
set a higer MX number for their mail server (white.spiritone.com). Now that
I've escaped their clutches I'd like a new backup.
When you learn how functioning as a backup MX works please share with us.
No reason why any of us could not return the favor.
A backup MX is easy to implement. There are some key issues to
consider.
If the primary goes off-line for a long time (or disappears entirely),
the mail spool on the secondary will continue to function as long as
it remains listed in the domain's MX records. Remote users will have
been assured that their messages have been successfully delivered,
even though they never reached the primary. Also, the spool directory
on the secondary may fill up, a potential risk to the system serving
as secondary.
A lot of spammers target secondary MXs because they often don't have
the same sort of anti-spam (or anti-whatever) rules as the primary.
It's a tough call. The primary might not want the secondary to bounce
messages on its behalf, but once messages are spooled to the
secondary, the primary can't bounce them (because the sending address
is almost certainly spoofed). Any transaction-level scanning (e.g.,
milters) on the secondary should be fully supported by the primary's
admins, and the secondary should *always* be able to deliver mail to
the primary; bouncing those forwards makes for big headaches.
Another issue secondaries face is that they most often don't have a
list of users/aliases that are valid on the primary. The secondary
must accept them, and then the primary has a painful choice about
whether (and to whom) to send a user-unknown reply.
In short, make sure you understand the tradeoffs when agreeing to
secondary MX service. It's not nearly as clear-cut as it might appear.
--
Paul Heinlein
[email protected]
45°38' N, 122°6' W
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
