[afnog] Collection Engine

[Brian Candler]

On Sun, Oct 02, 2005 at 01:45:56PM +0200, Mark Tinka wrote:
> > OK. Probably the solution you would prefer to have is
> > ATRN. It's on my list of things to investigate, and
> > perhaps write a daemon for courier (it would be quite
> > similar to the POP3 daemon internally)
> 
> Brian, I'm curious, how different is this from ETRN 
> (Extended Turn)? 
> 
> Understand ATRN is the same as ODMR (On-Demand Mail 
> Relay). 

With ETRN: client A connects to server S and issues command "ETRN <domain>".
Server S then opens a fresh SMTP connection to wherever it thinks is the
correct IP address for delivering mail for <domain> and squirts mail to it.

Since there's no need for client A to authenticate, S can't use client A's
IP address as the destination. In any case, maybe client A would disconnect
and a new client be assigned the same IP address before server S makes its
connection to that address, and so the wrong person would receive your mail.
So the only way this can be done securely is if the server which is the
target for <domain> has a fixed IP address which S always connects to.

With ATRN client A connects to server S, authenticates, then issues ATRN.
The connection is then turned around, and SMTP delivery takes place back
down the *same* TCP connection. If the client disconnected from the Internet
and a new client took over the same IP address, the TCP connection would be
reset.

I guess you could make ETRN secure if you use certificate authentication. I
don't think anyone does this.

> What is the most scalable solution for this situation 
> that doesn't require on-demand customers, i.e., dial-up, 
> to have static IP addresses, but allow ISP's to provide 
> the service while maintaining dynamic IP address 
> assignment?

I think ATRN would scale best, but it needs a decent server implementation.
In principle you could write a gateway between ATRN and POP3, as long as the
POP3 server was keeping the envelope in well-known headers.

UUCP over TCP/IP works OK, but generally doesn't scale well to thousands of
mailboxes (large uucp config files, lots of spool directories etc)

Regards,

Brian.