TZUTC: 1000   
   MSGID: 1198.fido-ipv6@3:633/410 21698cbd   
   REPLY: 2:203/2 5d03c30e   
   TID: SBBSecho 3.03-Linux r3.65 Dec 31 2017 GCC 4.6.3   
   -=> On 06-14-19 17:53, Bj”rn Felten wrote to mark lewis <=-   
      
    BF> really??? i've always done that as long as i've had a public IP   
    BF> address... it was a simply matter of updating my DDNS entry and that   
    BF> was done by running a tool that stayed in the background and handled   
    BF> the updates automatically... yes, i ran servers on my dialup... most of   
    BF> the time, the new IP spread through the network within minutes... no   
    BF> problem and it worked quite well...   
      
   For intermittent connections like binkp mailer sessions, this would work   
   perfectly well, providing the DDNS record TTLs were sufficiently short   
   (typically, 60 seconds is used, which is a good value for this application),   
   because by the time a DNS lookup is attempted, odds are that the DNS will be up   
   to date and any cacheing has expired, which is what you want.  The odds of an   
   IP change happening in the middle of a binkp session is fairly low, because the   
   sessions are generally short lived.   
      
   Where this sort of system falls down is long lived sessions, so it's more   
   likely to affect telnet users than mailers.  User sessions will get interrupted   
   and eventually time out, and ghosts may be a problem for a while after the IP   
   change.   
      
   So, it may or may not be "acceptable", depending on your particular   
   circumstances.   
      
      
   ... "It appears to be a tagline of unknown origin." - Spock   
   === MultiMail/Win v0.51   
   --- SBBSecho 3.03-Linux   
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)   
   SEEN-BY: 1/123 15/2 226/17 229/354 426 1014 240/5832 249/206 317 400   
   SEEN-BY: 280/464 317/3 322/757 342/200 393/68 633/0 267 280 281 410   
   SEEN-BY: 633/412 509 640/1384 712/848 3828/7   
   PATH: 633/410 280 229/426