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.
Ok.. I learnt this by accident and maybe ive missed the point... but... 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... Then whilst the Pri MX up it takes all delivery... When Pri MX is down Sec MX takes delivery and puts all the mail into a single mailbox.. With appropriate multidrop software this can be distributed to people after being POP'd conventionally.. right? Had this happen by accident with one ISP I was with back when I ran a private companies mail server.. I may have missed the boat but it seems similar? So is the conventional 'Pri MX on a mobile host, Sec MX correctly housed' not a good enough arrangement? Failing that whats wrong with just having Pri and Sec MX specified and having Sec MX Deliver to the primary when its up? ( I accept that asking for, instead of being force fed, the MX feed would be more elegant... but this still works? ) - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog