On Sun, 17 Oct 2004, Frank Ellermann wrote:
william(at)elan.net wrote:
But despite my offer to work with them towards common goal:
http://www.imc.org/ietf-mxcomp/mail-archive/msg05147.html
they have shown no interest in this so far.
Actually I still haven't got the idea of your draft. If I understand
it correctly (?), you've invented a new identity SUBMITTER, together
with all technical details like a new ESMTP capability (EHLO response),
a new MAIL FROM parameter, and a new spf2.0/submit scope.
I've not invented it, the SUBMITTER identity came out of MARID as an
RFC2821 representation of PRA. I do not believe the RFC2821 identity
linked to multi-header PRA will work well and I think it goes against
current RFC2822/RFC2821 data separation. In my opinion it should be the
other way around that RFC2821 is primarily identity which can be brought
into RFC2822 world at the time of mail delivery (like Return-Path which
is a MAIL FROM data or Delivered-To: which is RCPT TO).
As far as I can judge it, it would work perfectly as soon as
it's implemented, No technical problems (much unlike PRA,
which is a collection of half-baked patented ideas intended to
generate false positives and completely new vulnerabilities).
Correct.
But I still don't understand why we need a SUBMITTER identity
at all, in addition to the known MAIL FROM identity. Where
would I need or want an additional identity, as a normal user ?
The actual identity represents sender of email at each step of SMTP
transmission, and is basicly a "from" address unlike "mail from"
which is actualy bounces-to address. This is somewhat similar to
"Sender:" but for the RFC2821 world.
It's certainly another solution for forwarders, an alternative
to SRS or similar schemes, let alone 551. But it's not really
simpler than trusted-forwarders.org - IMHO quite the contrary,
because it works only with updated MTAs on both sides of a
forwarding hop.
Trusted-forwarders.org is centralized solution. Many people believe
that central-authority system would not be acceptable for email
(although reputation authority is basicly exactly that, but I'm
hoping pgp-like reputation web of trust can be created that would
serve as an alternative to centralized approach)
And for this scenario Meng's idea "local white list + HELO" is
better, because it should work with existing MTAs. Or at least
with MTAs supporting SPF at all.
HELO overriding Mail-From is sidestep idea in my view. I think if
something overides mail-from it should be an email address that can be
recorded and at some point displayed to end-user to show as address
of where the email supposedely came from (so in this I agree with MS,
I disagree with how they wanted this done however).
So what other applications do you have in mind for SUBMITTER ?
Is it also an alternative to PRA or Wayne's 2822-From-scope ?
PRA can be built on top of SUBMITTER but Microsoft wants it the
other way around and I disagree (in fact I disagree with checking
2822 identities as part of session based authentication).
SUBMITTER is not an alternative to 2822-From, again see above why
I don't think 2822 from checking by SPF MTAs will work.
MTAs can make determination what draft to use based on the
SPF scope record
So it's either spf2.0/pra or spf2.0/submit, but never both at
the same time (as in spf2.0/pra,submit), is this correct ?
On the contrary, it can easily be both spf2.0/pra,submit - in fact for
those publishers that do not have problem with SenderID it would be.
SPF2.0/PRA means the publisher tries to have his 2822 headers in the way
microsoft likes and does not mind having their algorithm used for checking
emails with those domains in 2822 data. SPF2.0/SUBMIT means the publisher
provides same kind of data in 2821 session by means of SUBMITTER extension
and if its not present he does NOT want the email rejected based on RFC2822
headers alone. SPF2.0/SUBMIT,PRA means the publisher does both and expects
emails to be checkd based on SUBMITTER data and then expects that to be
compared to header derived PRA (which is in my view is not technically wise)
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net