Hey Mark. I've changed the subject now - this is quite different from the original topic). Thanx for that Mark, couldn't remember the reasoning. Things are quite different now (and yet, strangely the similar...) With all the changes, and likelihood of more providers blocking smtp port(s) in the future, I still think that there is a market for a service where the client (or server acting as a client) connects, authenticates and then has email delivered over the outbound connection from the customer to the ISP. There doesn't seem to be a shortage of ODMR clients now, and the implementation of an industry standard for this functionality might actually be useful. As it behaves like a client, ISP's (Telecom) should have less of a problem with people running them behind cheap ADSL plans. I had heard a rumour that Exchange can act as an ODMR client, but haven't seen anything to verify that and recent searches on ms.com suggest otherwise. I did investigate some mail bagging options (of paradise I think, but don't quote me on that, may have been ICONZ), but they weren't available on DSL..., only dialup. One of my collegues had such a setup (paradise I think), and there were so few customers left on it, that support became a lot more problematic. In the end, Paradise lost his account, which is now a static IP with another provider on DSL, and mail delivered via. smx (www.smx.co.nz). I have no problem with using mailbagging (providing it's reasonably priced and works over DSL), and DDNS would work fine for everything else I need. But, last time I looked, it wasn't generally available. DDNS (and in particular DSL routers with DDNS client support) is great, and a fantastic help, but there are still problems; 1) If you reconnect on a different IP, someone else may get your previous IP. If this type of usage became more prevalent, then there is a greater chance that the next person (admittedly still only a small chance) will be running a mail server, and may get your email until the TTL expires. The minimum TTL window is around 5 minutes (for the DDNS providers that I've checked/used), so there's potentially a 5 minute window where someone else will be getting your mail. 2) If there is an outage, your mail queues up somewhere (if you are lucky, or have configured a backup mx). If not, the sender(s) may get undeliverable warnings, which many end users will mis-interpret. 3) If you have an ultra reliable connection (and your DSL router isn't sending frequent enough updates), you risk your DDNS setting expiring, and being removed. You may get a warning, but many may not interpret this correctly, or it may be considered spam. 4) If your DSL router doesn't have DDNS support (or you use a connection type who's routers/firewalls don't support DDNS), then you still need to install some software. DDNS clients are possibly simpler than ODMR clients, but you still have to install something. Sure, ODMR is done at the client, and there is overhead with that, but it's transport layer agnostic - it doesn't care whether it's DSL, Dialup, leased line or anything. I still like the concept, a lot. Anyone want someone to test/trial their ODMR service? Cheers - Mark GOLDFINCH wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Steve,
The reason why paradise.net said it was not possible at the time was because for two reasons:
1) Our MTA at the time did not support OMDR or any similar features to achieve delivery of mail using OMDR or other features to acheive the same means.
2) Later we developed our own Dynamic SMTP MTA which delivers mail to customer's dynamically assigned IP address after verifying that we indeed have the correct customer on the expected RAS port.
OMDR requires quite a bit of compliance from the customer point of view. Our own Dialup SMTP solution required very little support from the customer's point of view other than having an SMTP server listening on their dialup connection.
I'm thinking that this day in age with DDNS and broadband connections becoming far more relevant that SMTP delivery to dynamic IP addresses is becoming less of an issue. But then perhaps I'm mistaken.
- -- Mark Goldfinch Senior Systems Administrator IS: Unix Systems TelstraClear Ltd
-----Original Message----- From: Steve Lang [mailto:steve(a)spl.co.nz] Sent: Wednesday, 19 April 2006 20:59 To: Simon Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Port 25
Dare I suggest something worth talking about amongst the recent flaming.... but....
Some time ago, I was asking about ISP's that provided ODMR services. RFC 2645 (http://www.rfc-archive.org/getrfc.php?rfc=2645). Can't recall where that thread went - someone from paradise saying something about them not wanting to do it 'cause it would make them insecure or something... Didn't make sense at the time.
In any case, this would appear to be to be a good solution. The RFC has been around for a long time (1999), and it appears that there may be more than just a couple of clients/servers.
But, I still can't find anyone that supports it. Any clues who might? Anyone from ISP land that want's to create an ODMR service? Don't need a static IP, should work with everyone etc. etc.
Cheers -
Simon wrote:
Just a quick email to the list to find out what other service providers are doing regarding XTRA blocking port 25 when
your company
does not provide internet connections, so many of your customers are using xtra as a service provider but not for other services wuch as mail.
Many of my customers are XTRA customers, but are also vodafone etc etc, so an external autheticated mail server is a huge
bonus for them.
Use secure port?
Regards,
Simon
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.5 (Build 5050)
iQEVAwUBREwdjFJxzSk14MzBAQi77wf7BTyKlx1UQra8IlLVzx38PIZtdaEkPWIb ZKfXGNQRsEhoUkTfAm3oZE0gkdmAoa3uBHzWl9ITFBiiS8OAqSmBokNack2lpN1z ZIVFuSHvFDR+S8OGMp9C27QSLz0QFb0972ikIzvVUGPXttkLe9ywlUpqJHIjQbTh RfW1DzpYbC6olVb7wizksT9ZIravDzgDOUmKXXUMfTcKPNXiQvrhT3uXhJX+XIJk l1da+ttyh6JYRTDJTvwAq4rx4ICr1F8RbdcTpnkoSnXC9zlqXxp+ZLhIek8NJVga tFvamDlSG6BD2DJXJ0w1V7FUhPSI5eKc9U4YCcX8CjZDes4Lnz0U4Q== =XQZ1 -----END PGP SIGNATURE-----