Chris Wedgwood
On Mon, Oct 21, 2002 at 11:31:55AM +1300, Don Stokes wrote:
Yeah, but both ETRN and connection mailbagging have the disadvantage that they initiate the connection from the ISP end, which is messy from a firewall / NAT point of view.
I would argue for *most* people it's preferable as almost everything supports this mode of operation.
All that it requires is that you can do something intelligent with tcp/25 inbound, which pretty much is a no-brainer for anyone who is capable of running a mail-system (as opposed the average conslutant who installs exchange and buggers of, several hundred dollars richer, to leave the customer to suffer).
It works. But: - the customers have to know what they're doing; - they have to open port 25 to at least the mail server (which inevitably means it gets opened to everyone); - there is wasted dialup time waiting for the connection to get going and establishing that it has stopped.
RFC 2645 ATRN is "better" in that the connection is managed from the client end
Except so few pieces of software support this verses plain old SMTP which almost everything supports.
Too true.
POP is a terrible way to do this. POP != SMTP. They solve different problems. I should have you beaten for even mentioning it.
Yes, but POP at least has the protocol the right way around, with the client initiating the connection at the appropriate time, rather than requiring an SMTP client to get prodded by an external agent, e.g. the Radius server in the case of Clear Net's mailbagging or the SMTP server with ETRN. The biggest problem with POP is getting everyone to agree what headers carry the envelope addresses, so they can be taken out when an MTA receives the message. Otherwise, it's an ugly hack that works. SMTP is built around a model whereby the client can transmit on demand, and the server is always ready, and that is simply not the situation you have when you need to receive mail to dialup or mobile mail server. POP may not be the right protocol (and I did say it was yucky), but SMTP is not the right protocol either. SMTP/ATRN is sorta the right protocol, but I'd argue that adding client functionality to a server is the wrong way to do things -- you're asking the SMTP server to do something utterly un-SMTP-server-like. Basically, there is no right way to go about this. There is no well implemented recipient-initiated mail transport protocol. The stupid thing about this is that uucp mail systems had solutions to these problems in production mumbleteen years ago. It's not as if the dialup model went away. Heck, for a while I even ran uucp over TCP with a dialup net connection, before getting a permanent home connection... I won't say it was pretty (running a data link layer protocol over a transport layer one is generally a bad idea), but it did work. -- don - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog