[26609] in North American Network Operators' Group
Selection of Appropriate Local SMTP Relay
daemon@ATHENA.MIT.EDU (Joe Abley)
Mon Jan 10 03:57:53 2000
Date: Mon, 10 Jan 2000 21:56:00 +1300
From: Joe Abley <jabley@patho.gen.nz>
To: nanog@merit.edu
Message-ID: <20000110215558.A13264@patho.gen.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Errors-To: owner-nanog-outgoing@merit.edu
Hi,
This occurred to me a long time ago -- as I'm sure it has occured
to other people. However, I've never seen any mention of it, so perhaps
it's time I told someone about it.
Selection of Appropriate Local SMTP relAy (SALSA :)
Background
When ISP customers dial into their home ISP infrastructure, they are
usually provided with a designated SMTP relay host which will relay
mail for them. These same relay hosts will usually refuse attempts to
relay from non-customers, in an attempt to cut down on the amount of
indescriminate, untargeted commercial garbage-by-email that we all
enjoy on a daily basis.
The SMTP relay host used by ISP customers is usually statically
configured into customers' mail client software, often by a setup
disk or CD provided by the ISP.
An ISP's customers will often have reason to connect to the internet
by other means than connecting to their ISP -- for example, they might
roam using iPass or GRIC, or plug in their laptop in a temporary office.
In this case, their mailer will probably not be able to relay mail
through the configured SMTP relay host, since the ISP cannot be sure
that they are a genuine customer, as opposed to relay-exploiting scum.
Common Approach
The normal approach to this seems to be to provide some means for the
customer to authenticate themselves to the ISP while they are away.
Common methods are a web form for password entry, or auth by POP3 from
the same address before attempting to relay (POP before SMTP), or the
SMTP AUTH option, as and when it becomes more widely deployed.
This approach works, but is slightly sub-optimal in some ways:
1. It often needs to be retrofitted to existing ISP mail infrastructure.
2. It requires customer education, and sometimes customers find it hard
to learn.
3. It makes helpdesk phones ring.
4. The home ISP mail relay is sometimes a bad choice of relay,
topology-speaking -- if I happen to be in Prague, dialled in to
a local iPass partner and authenticating to CLEAR Net (which is
in New Zealand), sending mail to (say) Canada via a NZ SMTP
relay is not necessarily going to be very efficient.
5. It makes helpdesk phones ring.
Alternative Approach
An alternative is to provide a method for a mail client to discover a
suitable local smart relay in some dynamic fashion. This requires some
ubiquitous, global, standard database which every operator uses...
... like the DNS.
It should be possible to find a suitable local relay from any point
on the network using DNS lookups for (say) MX records under
IN-ADDR.ARPA. If I am dialling into the ghost of Hookup Communications
in Toronto using iPass again to authenticate with my home ISP username
and password:
+ I get allocated the address 165.154.15.1 during PPP/IPCP, which
connects me to a terminal server in Toronto (well, Oakville);
+ I also get allocated some local nameservers to use, in the usual
fashion (although I can probably continue to use my normal NZ
nameservers if I want; access controls on recursive lookups don't
seem to be all that common these days);
+ I attempt to send some mail;
+ My feature-rich mail client looks for the following MX records:
1.15.154.165.in-addr.arpa. (which in this example does not exist)
15.154.165.in-addr.arpa. (which doesn't exist either)
165.165.in-addr.arpa. MX 10 noc.tor.hookup.net.
MX 20 vertex.tor.hookup.net.
+ The mail client first attempts delivery via noc.tor.hookup.net, then
vertex.tor.hookup.net, and if all fails (or no MX records were found)
it uses the statically-configured SMTP relay, smtp.clear.net.nz.
It's fairly likely that at least one of noc.tor and vertex.tor
will be alive and functioning correctly as relays at any time, so
the chances are I will never need to use any inconvenient
out-of-protocol authentication to CLEAR Net to register myself as
a roaming user, and hence to gain SMTP relay privileges on
smtp.clear.net.nz.
Advantages
1. You don't need to hook user authentication into your existing MTA.
2. You already support IN-ADDR.ARPA zones -- so to support this all you
need to do is add probably one or two MX records per zone.
3. Mail clients need to do DNS lookups anyway, to resolve an address for
a statically-configured SMTP relay. This just adds (potentially) three
more.
4. Mail clients that don't support this don't behave any worse than
they normally would with the in-addr.arpa MX records present, so
it doesn't do any _harm._
Comments welcome :)
Joe
