Re: [users] e-mail, the next level

[MaD dUCK <madduck@madduck.net>]

i have done this in two different ways. the first is straight forward,
but depending on how many users you have, it might be a pain (and a
security risk). the second works on the assumption that your ISP is
running a sensible MTA (postfix, qmail) and that you will not be down
for longer than 3 days.

(1) the router which handles the dial-up connection to the internet is
    also configured as a mail server, relaying mail for the internal
    subnet only. each user has a mail account on that system, which
    you make POP3 accessible. in my example, i actually have a
    separate mail server, but whatever. the canonical names are
    mail.home.madduck.net and smtp.home.madduck.net.

    now you block POP3 and SMTP at the router for all IPs (MAC
    addresses) other than the mail server. you tell your users to use
    these two mail servers exclusively (they won't succeed otherwise
    anyway).

    my relay server is running postfix, which i can configure to
    defer_transport for smtp. in /etc/ppp/ip-up.d, i have an
    mta-online script, which (1) calls sendmail -q, and (2) changes
    the defer_transport setting with postconf. /etc/ppp/ip-down.d
    reset that setting when the connection is down.

    i also have a crontab, connecting the system every hour. that's
    the SMTP side, and now users will think that mail is sent
    immediately, even though it will sit in the relay queue until (a)
    the next hour, or (b) someone connects the internal network (i am
    using diald for on-demand connection).

    the POP3 side of things is similar. while online, fetchmail
    retrieves all mail for the individual users, and stores them in
    their local accounts (daemon mode). in my scenario, i am
    madduck@home.madduck.net, and while i can send to
    madduck@madduck.net - which will leave the house via SMTP, and
    eventually return via fetchmail, i can also send mail to
    madduck@home.madduck.net, which is delivered locally immediately.

(2) the second method i like a whole lot better. postfix and qmail,
    unlike e.g. micro$oft exchange, do an IP lookup on the MX on
    *every* delivery attempt, not just once. therefore i configured my
    home router to update a remote Bind 9 server via TSEC nsupdate
    within a zone that has a TTL of 2 minutes. therefore,
    home.madduck.net points to the router's ippp0 interface whenever
    it is online.

    the ISP's postfix is configured to send mail e.g. for
    madduck@madduck.net to madduck@home.madduck.net, and
    someone_else@pantsfullofunix.net to
    someone_else@home.madduck.net. whenever the router is online, mail
    is delivered immediately.

    if the router is offline, mail sits in the ISP's queue for at most
    five days before it is bounced. i have at least 1 connect a day
    due to the debian_mirror rsync script i run, and other similar
    stuff, and when the router is online, it contacts the ISP with an
    ETRN SMTP command (fetchmail can do that), causing all queued mail
    to be delivered immediately.

    i like this approach a lot better, and if you wish, i can provide
    you with a TSEC nsupdatable hostname.

    outgoing SMTP is handled just like the above. i told my users that
    mail goes out every hour, but if something is urgent, all they
    need to do is surf the web afterwards for the mail to be sent.
    everything nowadays seems to be dynamic, so even the extensive
    squid proxy i use won't prevent a connection whenever someone
    opens IE (barf!).


i hope this was complete. i'll be happy to answer any questions...

martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
-- 
i'd give my right arm to be ambidextrous.