Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

Mon Aug 26 21:47:28 UTC 2002

David Van Duzer <dvanduzer at 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 at NETBSD.ORG's
         account has a ".forward" file pointing at VIXIE at 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.