On Mon, 27 Sep 2004, Jim Lyon wrote:
William,
Regarding draft-leibzon-responsible-submitter-00, please pick a name
other than SUBMITTER for the SMTP extension and parameter. It will be a
real mess if we have two competing documents specifying different
definitions for the same extension.
1. Its actually quite easy to make marid-submitter draft to be
compatible with my responsible-submitter draft. Major thing
that is necessary is to require double-checking on if SUBMITTER
value is same as your PRA (derived from headers) ONLY IF there
is spf2.0/pra policy record available for domain part of SUBMITTER.
In such a case, you can assume that known that on his network all
servers that use SUBMITTER also comply with Sender ID and added
whatever headers you like, where as if they published spf2.0/submit
scope records you can assume they might not have done so.
The only other issue of some importance is that in my
responsible-submitter draft, the recomendation for smtp proxy
servers (as in hotel "Guest E-Mail Service" example) is to add
Sender header where as in marid-submitter it said that Resent-From
is to be used. For all other cases I conviniently avoided specifying
what exactly are supposed to be headers added (although you'll
see a definitive recomendation about that in my next draft).
2. As per above my recomendation in regards to resolving difference
between marid-submitter and responsible-submitter is to have you
rewrite your concept to reference responsible-submitter instead
of marid-submitter. You can do it by rewriting new core+PRA
draft so that it requires checking of RFC2822 headers PRA value
only if SPF2.0/pra policy record is published. In such case you
can write also that such PRA MUST be equivalent to SUBMITTER when
it is present during SMTP session and make recomendation for MTAs
to verify SUBMITTER parameter value based on either SPF2.0/pra or
SPF2.0/submit policy record during SMTP session.
Basicly what I'm asking is for you to consider rewrite of
Sender ID concept where it references submitter-draft instead of
submitter referencing marid-core and pra. Both are equivalent
ways of doing the same concept and should be able to coexist.
3. Unless you make changes to SenderID drafts as I recommended above,
I would have absolutly no problem in giving IETF directorate and
implementors a choice between what they want to accept and use:
- an encoumbered solution that is based upon incorrect use of existing
RFC2822 concepts and has IPR requirement that does not allow to be
used in open-source SMTP servers OR
- a solution that is entirely within RFC2821 framework and does not
break existing SMTP standards and does not have patent problems
(as long as we assume that SPF classic which is also RFC2821 does
not have have similar patent issues)
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/