[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Backbones, Hetrogenous Hubs and Zmailer: a Scenario



[This paper is being sent to both the Mail Backbones list
(mail-bbones@yorku.ca) and the Zmailer list (zmailer@ai.utoronto.ca),
primarily to start some discussion of ``multihubs'' on the backbone list.
The implementation vehicle is zmailer, and some of the earlier development
was through discussion on that list, so it is included.

  Please take note of which list(s) you want your replies to go to!

--dave]

	Backbones, Hetrogenous Hubs and Zmailer: a Scenario


			David Collier-Brown
			  30 August 1992





Introduction
  This is a note on supporting multiple logical domains
on a single machine running the zmailer MTA.  

  This is desirable at York for several reasons.  The most obvious
is that departments which desire to see their names mentioned in
email addresses may not be able to afford a full-time postmaster.

  It also allows near-transparent relocation of mailhubs if a machine
fails, by adding the mail-using community to an existing mailhub. 

  The obvious caveat is that the communities sharing a mailhub must 
not have two separate people with the same name.  As we are already
enforcing this informally, it is not an onerous burden.


Description
===========
What Does It Look Like?
-----------------------
  If someone sends mail to davecb@ccs.yorku.ca or davecb@dummy.yorku.ca, the
message will be directed to the same mailhub (by DNS entries), will be
processed identically and will be delivered to the mailbox of the same
person, myself.
  I can then pick it up (via POP) on either tess.ccs.yorku.ca or
hobbes.dummy.yorku.ca.

  If I reply to it from tess, the message will go to the same mailhub,
which will notice that it is responsible for the mail from tess.ccs, and
will rewrite the From: address to just davecb@ccs.yorku.ca before sending
it on to its destination.
  Similarly, if I reply from hobbes.dummy, the address will be rewritten
to davecb@dummy.yorku.ca and out it will go.

Implementation: Incoming Mail
-----------------------------
  Let us first consider incoming mail for davecb@ccs.yorku.ca or
davecb@tess.ccs.yorku.ca.  The message arrives at the mailhub because the
sending machine looked it up in the DNS and found an MX record that directed
it to send the mail to this particular machine.

  The mail router, part of Zmailer, looks at the address and says to
itself:

   	Hmmn.  This address is in yorku.ca, and I treat these specially.
   
   	Is this in the list of domains I handle?  Lets look it up.
   	The router selects only the first-level domain part of the
   	name, and so looks up ``ccs.yorku.ca'' in a small database.
   
   	Yup, it's my domain allright.  Now, is it going straight to me or to
   	some other machine in the same domain? If it's not\/ for me,
   	there will be an MX record for it, pointing to where it really ought
   	to go.  (How would it get here if it isn't for me?  Well, I might be
   	sending it out, or someone may have sent it here with a
   	source-routing by mistake.)
   
   
   	  If it's for me, I hand it to local delivery, which puts it in
   	/usr/spool/mail for the POP/IMAP program to do final delivery on.
   	If it isn't, I smtp it to where it really should go, according to
   	the MX record.
   

  Exactly the same scenario is followed for mail to hobbes.dummy.yorku.ca,
with the same mailhub recognizing the domain as one of its own,
double-checking for machine-by-machine exceptions in the DNS and then either
delivering locally or forwarding to the ultimate destination.

Implementation: Outgoing
------------------------
  Now, what if the mail is outgoing?  Either I posted the message on the
mailhub by POP ``xtnd xmit'' or I arranged for my MUA or MTA to ship it
the mailhub by smtp.  In either case, my From: address might contain almost
anything.

  If it is something silly, like ``davecb@bozotron.uucp'', nothing
particularly useful happens.  The message just leaves, usually with a
``Sender:  davecb@mailhub.ccs.yorku.ca'' header inserted to hint that I'm
lying.

  If it is any of davecb@ccs.yorku.ca, davecb@dummy.yorku.ca,
davecb@tess.ccs.yorku.ca or davecb@hobbes.dummy.yorku.ca, it's subject to
rewriting.  davecb@ccs.yorku.ca and davecb@dummy.yorku.ca are already
correct, so nothing special is done to them.

davecb@tess.ccs.yorku.ca and davecb@hobbes.dummy.yorku.ca are the
interesting ones. The router says to itself:

   	I wonder if I should trim the hostnames off and just leave the 
   	domain.  Well, this address is in yorku.ca, so
   	it's a candidate.
   
   	Is this in the list of domains I handle?  Lets look it up.
   	The router selects only the first-level domain part of the
   	name, and so looks up ``ccs.yorku.ca'' in the same small database
   	as before.
   
   	Yup, it's my domain allright.  Now, does this one get rewritten or
   	not?  If it has an MX record pointing somewhere else, I'd better
   	leave it alone. I don't want to interfere with somebody else's return
   	address.  If it doesn't have an MX record, or it points here, then
   	it should come back to me.  I'll rewrite it to remove the machine
   	name and leave just the domain.
   


Implementation: The DNS and Administrivia
-----------------------------------------
  To make this work, there are a number of prerequisites.  To make them
easy, they are localized in the DNS for the most part. 

 The only local configuration is a file which lists domains for which this
machine acts as a mailhub.  This does not actually duplicate anything in the
DNS, and so is a legitimate item for local selection.

  Everything else is done with A and MX records.  A records and MX records
exist for the mailhub of each domain.  The A record is there for MTAs that
don't honor MX records, and so that other mail-related things that don't
normally use MX records will function. The classical non-MX using program is
finger, which is often used to see if someone has read their mail, or to
see if they're the right person to send the mail to in the first place.

  Each machine that receives its own mail should have an MX record.  In our
model, it has to have one, to indicate that it's been seen by a
postmaster and is known to be capable of handling all its own mail.  We
are very reluctant to send mail to a machine which may discard it: we 
depend on the reliable delivery of SMTP mail for both administrative
and academic purposes, and can't afford to risk ``black holes''.

  We make this an administrative rule: if you don't have an MX record, we
assume you don't get mail.  And mail for an MX-less machine is treated as an
early warning of a problem, sending the postmaster off searching for the
machine's owner to help him set it up properly.


..EOF