Date: Thu, 3 Jun 1999 09:16:42 +1200 From: Joe Abley <jabley@clear.co.nz> To: Leif Neland <leifn@neland.dk> Cc: current@FreeBSD.ORG, jabley@clear.co.nz Subject: Re: SMTP to dynamic ip's Message-ID: <19990603091642.E25988@clear.co.nz> In-Reply-To: <Pine.BSF.4.05.9906022301090.87049-100000@arnold.neland.dk>; from Leif Neland on Wed, Jun 02, 1999 at 11:03:05PM %2B0200 References: <19990602191911.A15558@clear.co.nz> <Pine.BSF.4.05.9906022301090.87049-100000@arnold.neland.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 02, 1999 at 11:03:05PM +0200, Leif Neland wrote: > > When it comes down to it, there is very little justification for a static > > address. The one I most commonly hear is "so we can do SMTP mail delivery > > to the customer", but even that doesn't mandate use of static addressing -- > > we support SMTP mail delivery (we call it "mailbagging" for some reason) > > to dynamically-addressed dial-up clients, and it works just fine. > > Would you care to explain how? > > Very interested. Inbound mail to "mailbagging" customers is not queued normally by sendmail, but is delivered through a local-like mailer to a separate per-user queue directory. When users authenticate, radius uses a back-end RPC service to register users as connected from a particular IP address. This IP address is dynamically assigned. When we receive a stop record from radius (indicating that the user has disconnected) a similar RPC removes the record. Inserting this record triggers an SMTP delivery attempt after a few seconds' delay. The per-user queue directory (the "mailbag") is emptied as messages are sent to the connected user. A periodic job (every ten minutes, I think, to give people a chance to idle out their automatically-dialled connection) checks for connected mailbagging customers for whom a queue run is not in progress. For each of these users, the mailbag is delivered by SMTP to the registered, connected address. The main thing to be careful on all this is to do paranoid checking at every stage to try to ensure that the user hasn't disconnected and been replaced by someone else (who should not get their mail). Incidentally, ETRN is still accepted (some people like to do it) but it doesn't do anything. We rely on mail being delivered regularly enough for ETRN not to be necessary. Calling the RPCs is very cheap, and we have experienced no load issues with scaling this to "large" numbers of customers. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990603091642.E25988>