David Van Duzer <dvanduzer@infidels.org> writes: [...]

The presumably appropriate topic for discussion on this list is why a system such as this would be a problem for network operators who choose not to implement such a callback feature. So far the only objection I've seen is "It won't make any difference" and that seems to be a flimsy argument. Please correct me if I'm missing something.

The problems with it are clearly laid out within the document itself: 3.2. Transport-level e-mail forwarding must be more explicit under this specification. For example if VIXIE@NETBSD.ORG's account has a ".forward" file pointing at VIXIE@ISC.ORG, then e-mail sent to the former will be received by the latter, but with no change in the payload of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be configured to implicitly add NETBSD's outbound mail relays as "multistage inbound relays." This could scale poorly and may add pressure toward transport remailing (with a new envelope) rather than transport forwarding (reusing the old envelope.) No real solution is proposed for the above; if you remail with a new envelope, how does the original sender get the bounce? And if you don't, the proposal isn't workable without refusing to support forwarding at all, which would just encourage mail service providers to enforce an annoying restriction. 3.3. Roaming hosts such as laptop computers will probably not be able to be listed in the MAIL-FROM MX RR for their return address domain name, and may be forced to use an intermediary for outbound e-mail. STARTTLS or an SSL/SSH tunnel back "home" may become a necessary first hop for mobile e-mail. The problem that this deals with is the user who needs to dial in to AOL and send mail from their corporate account. The proposed solution is to tunnel mail through the corporate server, by proving your right to relay via SMTP AUTH or else via a VPN. To make this work well requires support for SMTP AUTH and probably STARTTLS (unless the company implementing this proposal wants cleartext passwords flying over AOL's network) for all domains which want to support Paul's proposal. This isn't necessarily all that unreasonable, but should be spelled out more clearly, and makes implementation much more involved. ----ScottG.