wayne writes:
The "mfrom" scope in SenderID appears to be almost identical to to
SPFv1 records. It describes both the 2821.MAILFROM and 2821.HELO
identities, just like SPFv1.
I believe this is not correct. The strings "helo" and "ehlo" with any
mix of case do not appear in either SenderID draft. The core draft
says in section 2: "... the MAIL-FROM version of the test seeks to
authenticate the mailbox that would receive Delivery Status
Notifications (DSNs, or bounces) for the message."
The core draft is ambiguous in that it defers description of the
MAIL-FROM test to your draft, but it does not say anything about the
HELO test from your draft being included, in spite of ample
opportunity to do so in various places in the core draft.
So, if you think combining the "mfrom and helo" scopes is ludicrous,
why do you think that SenderID's scopes are so good?
Because I believe the helo scope is not included in the mfrom scope.
If it is, then it's as ludicrous there as anywhere else.
SenderID's spf2.0 records allow domains to specify what scope(s) their
SPF records cover. If you don't want your MFROM scope used for PRA, you
can say so. Is there anybody who thinks this is not a big advantage?
I think it is nice that you can separate the PRA from the MFROM. I
don't think, as it is designed, is that big of an advantage. The
SenderID syntax requires lots of duplicate information to define two
different scopes that are very similar, but not identical. I think it
could have been designed *MUCH* better, but it was a bad hack slipped
in under Microsoft's nose at the very end of MARID. I don't think
MarkL could have done a better job without Microsoft noticing and
objecting, but that doesn't change much.
You're treading on murky ground. The SenderID core draft defers to
your draft for definition of the MFROM scope syntax, so presumably the
MFROM scope syntax by itself is not what you call a bad hack.
Most (all?) of that syntax is re-used for PRA scope policies. If the
scopes are similar and involve similar information (or similar types
of information), then re-using your syntax makes sense to me.
If the MFROM and PRA scopes are different, which I think everyone
agrees they are, then using different policies in different records
for them also makes sense to me. That this leads to repetition is a
consequence of the scope similarities, not poor design. You could, I
suppose, use a baseline plus two deltas design, but I can think of
multiple reasons not to do that, especially with a deployed base of
MFROM policies in an existing syntax.
Re-using most of the existing policy syntax while modifying it enough
to accommodate different policies for different scopes seems to me to
be one thing SenderID got right.
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com