ned(_dot_)freed(_at_)mrochek(_dot_)com writes:
actually I'd call it a nonstarter in its current form.
I would have to agree.
...
In addition to these valid concerns I'd add that various sorts of
autoforwarding exist that don't change the MAIL FROM. These would also
tend to break if such a scheme were implemented.
i apologize for being such a poor writer. what the "draft" actually says is:
3.2. Transport-level e-mail forwarding must be more explicit under this
specification. For example if VIXIE(_at_)NETBSD(_dot_)ORG's account has a
".forward" file pointing at VIXIE(_at_)ISC(_dot_)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.)
I'm also concerned about the management aspects of having lists of
authorized "multistage relays" and all that implies.
then you probably would not want to insert a MAIL-FROM MX in your domain.
Perhaps the real problem here isn't the use of MAIL FROM but rather the
assumption that binding ipsource to the MAIL FROM domain is a useful
validation check. A specific ipsource is just not a property a legitimate
user of a given domain can be expected to have. Although I am reluctant
to suggest anything involving public key crypto, another approach would
be to put a public key in the MAIL-FROM DNS record and add a new header
field containing a signature covering the message's MAIL FROM and the
current date.
i love that plan. we all know that ip source addresses make poor passwords.
however, it has to be an envelope thing, not a header thing, since it's hop
by hop. perhaps "MAIL FROM:<$address> $sig" as an ESMTP thing?
--
Paul Vixie