ietf-mxcomp
[Top] [All Lists]

Re: Why we should choose the RFC2821 MAIL FROM/HELO identities

2004-04-05 13:05:37

Alan DeKok wrote:
Marshall Rose 
<mrose+internet(_dot_)ietf(_dot_)mxcomp(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
 wrote:

regardless, certainly the current smtp architecture is based on a
store-and-forward model, and while many sites are configured such that
domains are reachable in one hop, other sites are legitimately
configured otherwise.

  e.g. sites with temporary/flaky connectivity.

  e.g. Backup MXs.

  e.g. Roaming users.

I agree with the above, but you forgot the case of the final destinations pointed to by forwarding sites. They are basically forced to use rewriting. (Note, I don't see this as a problem, just so lon as wel acknowledge it.)

  Q: Who would apply LMAP when receiving mail from backup MXs?
  A: People who want to do pointless work.

  Q: Who would use SMTP to submit mail when SUBMIT exists?
  A: People who haven't yet upgraded.

Agreed on this point.

setting aside the architectural issues, it is clearly worthwhile to
discuss whether disenfranchising these sites is a possibility, and, if
so, whether it is worthwhile.

  I don't see how LMAP disenfranchises sites which get messages via
store & forward.  If you know your mail is being stored on another
server and forwarded to you, it's pointless to require that site to
have an LMAP record for your domain.  And even if a domain does
require it, the domain aministrators can add LMAP records to their own
DNS.

Then you disenfranchise people who don't have administrative control over their inbound email.

  Similarly, LMAP doesn't disenfranchise sites which deliver mail via
store & forward

But that's a problem that only the sender has and can resolve. Most sites don't receive mail through store-and-forward except by prearrangement, but many sites are forced to send that way, and have little choice in the issue.

Philip Miller

  This isn't a solved problem.  It's not even a problem.

  Alan DeKok.