[ On Sunday, November 21, 2004 at 09:42:37 (+0100), Marc Haber wrote: ]
> Subject: Re: [exim] about Sender: and envelope reverse-path in today's systems
>
> On Sat, 20 Nov 2004 17:30:42 -0500 (EST), "Greg A. Woods" <woods@???> wrote:
> >
> > In fact you cannot really run an MTA properly without having a proper
> > domain name. What would you tell the mailer to accept as a locally
> > deliverable domain when there is no private mail domain for the host?
>
> "localhost", or "foo.local", or "foo.example".
>
> That's fine for local delivery.
No, it's _not_ fine. For local delivery you can, and should, avoid
using any domain name. It's not necessary and when anyone does try to
use a bogus example domain they end up inevitably leaking that bogus
domain to the public Internet and that is just not acceptable.
IIUC Exim, and every other unix-based mailer, can work just fine for
local-only purposes with unqualified user-ids as mailbox names. Maybe
it doesn't work that way out of the box, but don't let that stop you! ;-)
> A very common configuration in Germany is that a site has a DSL line
> with dynamic IP address (forced to change every 24 hours) and has a
> simple NAT router to the outside.
Yup, sure -- similar configurations are common everywhere DHCP or PPPoE
is used for "broadband" connectivity.
Such services are of course intended _only_ for "network client only"
types of uses and so running a full MTA on a host with such a connection
isn't likely to ever be a "supported" configuration, and even using a
full-blown MTA such as Exim just for queuing and delivering mail to the
ISP's gateway from such a machine isn't necessarily a good idea either.
Full blown MTAs, even when they're configured to only forward mail to a
gateway hub, have this nasty habit of assuming a full-time Internet
connection and wanting to do DNS lookups at the "wrong" times, etc.
It's much smarter for system designers to just give their users a nice
full-featured IMAP-based MUA that has full off-line work modes and which
can do its own outbox "queueing" and to complete leave out the full MTAs
from their default installs.
> In these cases, the originating host
> does not know its public IP address and cannot set the message-ID and
> its HELO appropriately.
Well, that's not quite true -- i.e. a host on the inside can learn its
public IP and the hostname for that IP. There may not be an easy,
existing, mechanism to make that discovery, but don't let that stop you. ;-)
> Additionally, a message might be queued when the host has IP address
> a.b.c.d (having its message-ID generated appropriately), but might go
> out later after the dynamic IP has changed.
So? That doesn't really matter so much -- all that matters is that the
domain name be valid in the public DNS. At least with Exim (as with
most MUAs that generate their own message-id), the LHS value will be
unique and will hopefully give some hint as to the time it was generated
(which in an investigative scenario could be correlated with the ISPs
address assignment logs to corroberate who's machine generated the mail).
> > Local mail on the workstation should only be used for
> > system daemons and of course it should always be delivered locally by
> > default.
>
> If so, that mail is likely to be ignored by an inexperienced user.
If that is the case then local mail should not ever be generated in the
first place!!!!
If you're designing and building workstations for totally naive users
then you don't want to force them to be mucking around with stuff that
they will not get right without a very steep learning curve, and in some
of these silly NAT configurations you describe they CANNOT ever get it
right regardless (at least not without some other external support).
The possibilities for handling system management tasks without using
local e-mail are almost infinite -- pick one. :-)
This one-tracked "we must use e-mail" tunnel vision for unix-based
workstations is rather bogus.
I.e. if you're trying to mimic what users would use if they didn't use a
unix-like system then you need to do a better job at all levels, not
just at the GUI.
On the other hand maybe you _can_ use e-mail for local system daemon
reports but present them as a reports in some fancy system management
GUI instead of forcing the user to read local mail folders....
Of course such locally delivered system mail will _not_ be ignored by
any user, experienced or otherwise, if you, as the system designer, are
smart enough to arrange for it _all_ to be directed to their personal
local mailbox using aliases and you present them by default with a
mailer such as Mozilla Thunderbird (or Emacs VM, or Pine, or whatever)
which will by default "fetch" mail from both local spool files as well
as POP and/or IMAP accounts. (nobody should ever run an MUA as root in
the first place anyway)
E.g. when I read my mail my MUA (Emacs VM :-) will fetch mail from
/var/mail/woods (and any other local spool file I configure it to
recognize) and also fetch more mail from any number of POP or IMAP
accounts, and incorporate all the newly fetched mail into my default
INBOX folder.
Also my /etc/mail/aliases file maps all local system users, as well as
standard aliases such as "postmaster" to my own personal account.
Therefore all mail from cron jobs or other system daemons will be
delivered to my INBOX every time I fetch my new mail and I cannot easily
ignore it -- it's right in my face with all my other mail.
Have a look at how Mac OS X configures a workstation with a local user
account and learn how your system can do something similar to configure
the aliases file to deliver all local mail to that one primary user.
Also note that it's trivial to write simple wrapper scripts for even
brain-damaged old mail readers like BSD mailx and in such a script use
something like "movemail" or "fetchmail" to gather mail from multiple
spool files and multiple POP and/or IMAP accounts and present it all to
the user as one integrated message folder. People building shell
account servers at ISPs have been doing this kind of thing for over a
decade now. It's simple and it works and it allows users who want to
use even decrepit old pre-Internet MUAs to continue to (almost
transparently) use them with fancy new things like POP and IMAP.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
