ned.freed@mrochek.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@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.) > 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