Another Option is UUCP for customers. I know a few ISP's (Including us) still support it. Thanks Craig Whitmore Orcon Internet ----- Original Message ----- From: "Don Stokes" To: Sent: Monday, October 21, 2002 11:31 AM Subject: Re: Any isps support ODMR - RFC2645?

Chris Wedgwood wrote:

...

CLEARnet had a product that did essentially what you want (not RFC2645 though): Mailbagging. Thirty seconds after connecting their system will start pumping your queued mail down to you... making sure it was delivered before removing it at their end.

- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Chris Wedgwood wrote:

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

Mark Foster wrote:

If you have two mail servers...

and MX records for

MX 10 dyndns.myhost.net MX 20 mail.isp.co.nz

But you have a pop mailbox on mail.isp.co.nz which is also configured to accept mail and drop it into a 'catchall' mailbox...

What's really yucky about that is that anyone sending mail to you has to try to deliver it to dyndns.myhost.net, and only when that times out can it then attempt to deliver it mail.isp.co.nz. This is a Bad Thing, as it means the mail sits clogging up the sender's outgoing queue for however long the sender's timeout is set to. You don't see this, but the sender's sysadmin does. If you're going to have a mobile service, it should be invisible to senders. SMTP is built on the premise that MXes are always up, and if they're down they'll be back Real Soon Now. Thus, if you want more than one way to deliver mail, you should accept it at the ISP server, and then make the decision there as to whether it can be delivered directly or queued. You shouldn't ask remote senders to make that decision for you by leaving them to time out. -- don - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Mark Foster wrote:

So yes a way of saying 'send me my queued mail please' would be a feature in my wishlist, definately.

That's precisely what the SMTP ETRN command does (if implemented, of course). -- don - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

On Mon, Oct 21, 2002 at 02:41:40PM +1300, Don Stokes wrote:

- the customers have to know what they're doing;

Yes. But at some point someone has to have some clue. The real issue seems to be a large number of people with no clues who think and pretend otherwise. Fortunately, the inane desire to use sExchange is a good giveaway here.

- they have to open port 25 to at least the mail server (which inevitably means it gets opened to everyone);

No it doesn't mean this... you could open it to just certain addresses. Anyhow, so what if it does get opened to everyone?

- there is wasted dialup time waiting for the connection to get going and establishing that it has stopped.

30s or so; big deal... maybe even 2 minutes. That's typically less time than it takes to order and receive a double-cheese burger with fries.

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.

POP does *NOT* work properly. There is no defined way to make it work properly and efficiently. Consider something like a 20M email to 10 people all in the same domain. This sort of thing is not uncommon. Various products have various hacks like parsing "To:" and "Cc:" headers, none of which work even remotely well.

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.

Where does it say for SMTP that the "server is always ready"? It would seem a lot of SMTP smarts and indeed MTA code is to deal with the fact this isn't the case always.

POP may not be the right protocol (and I did say it was yucky), but SMTP is not the right protocol either.

SMTP was designed for transporting mail; and this is what you want to do. It makes it pretty close to the right protocol.

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.

Usually, SMTP/ATRN is difficult to implement for other reasons. Some MTA products have a separation in logic (and often process and/or privileges) between the code that sends email and that which receives it. To implement ATRN, they need to violate this.

Basically, there is no right way to go about this. There is no well implemented recipient-initiated mail transport protocol.

Except, speaking from experience, not just some technically motivated idealistic view of the world, SMTP with an external trigger, in practice works extremely well.

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.

Few people put effort into making UUCP accessible to the masses (mostly work on easy of use), so it's more or less died off. --cw - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

* Paradise have a dsmtp service for emailing via. dynamic IP Addresses, but that's geared off their dialin radius, not ADSL radius, so can't work with ADSL connections. Don't ask me why...... If they did, they'd stand a much better chance to keep my business in the future.

Unless something has changed in the four weeks since I left, this is incorrect. Find someone there who actually knows that they're talking about and they should be able to sort you out. Tried emailing postmaster(a)paradise.net.nz ? Jamie - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog