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)
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".
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.
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