At 08:33 PM 5/21/2005 +0200, Frank Ellermann wrote:
David MacQuigg wrote:
> Sender ID has added a SUBMITTER parameter:
> MAIL FROM:<bob(_at_)sales(_dot_)some-company(_dot_)com>
SUBMITTER=bigforwarder.com
Sender-ID: draft-katz-submitter-submitter-01
spf2.0/submit: draft-leizon-responsible-submitter-00 (expired)
> SPF uses SRS to "rewrite" the MAIL FROM command:
> MAIL FROM:<bob#sales(_dot_)some-company(_dot_)com(_at_)bigforwarder(_dot_)com>
SRS: draft-mengwong-sender-rewrite-01 (expired)
op=trusted: draft-spf-6-3-options-06 (Council lock)
5.3.6 (a): RfC 1123 (STD 3)
error 551: RfC 822 (STD 10)
global white list: trusted-fowrder.org (Wayne)
per user white list: forwardmaster plan (Radu)
Nice list of references. Thanks.
> Neither of these can serve as a neutral ID declaration, due
> to restrictions in each specification. SUBMITTER must be
> used with Sender ID and SRS must be used with SPF.
But STD 3 and STD 10 are full Internet standards. Sender-ID
is somewhat irrelevant here for various technical reasons, e.g.
because I'll kill it if insists on its "SHOULD abuse v=spf1".
Is there somewhere buried in this long history an abandoned neutral ID we
could resurrect? Would that be easier than a new service extension, free
of any legacy semantics?
> All information in SMTP commands can be forged. Any ID must
> be authenticated, whether it is provided as a SUBMITTER
> value, embedded in the MAIL FROM command, or provided in a
> separate command. There is no difference in the security of
> one syntax versus another.
Separate commands are impossible (SMTP does not support this),
an ESMTP extension is allowed. Won't work with SMTP of course.
I'm planning on making it an ESMTP extension. That will ensure we don't
send an ID command to an older SMTP server. When we fall back from EHLO to
HELO, ID is out, along with any other extensions we might have
wanted. That is OK, because I assume nobody in their right mind would
update an old HELO server just so they could check authentication. They
should switch to EHLO, and follow the new extension model.
> If SRS is to be supported, then SPF records must be provided.
Huh ? SRS is independent of SPF, and vice versa. Receivers
are free to check SPF, CSV, Sender-ID, hashcash, SES, and what
else, they're free to support all of these simultaneously. Bye
So SRS could provide a neutral ID? Interesting. I wonder if the SPF
haters will let this happen?
I still like the clean and simple ID syntax better, but I'll go with
anything that works, and that includes SUBMITTER, if the Sender ID folks
will remove the frivolous PRA-only restrictions.
Here's another problem. Overloading the SRS domain name with the ID
function may generate the same kind of conflict we are having now with
trying to overload one or another of the SMTP fields. The example at
http://www.libsrs2.org/overview.html shows a re-written address like
<bob+ann#orig(_dot_)com(_at_)bounce(_dot_)alias(_dot_)com>. The bounce.alias.com domain appears
to have a purpose in conflict with the purpose of choosing the best domain
to locate authentication records and accumulate reputation.
I would like to get the ID proposal to the IESG before they start
considering SUBMITTER as a standard. If they know a neutral ID is
possible, they will hesitate to standardize anything that is un-necessarily
restricted to one method.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *