On Tue, 17 May 2005 17:16:59 EDT, Hector Santos said:
Whoa! Do you know what you just did? You just gave me
encouragement and hope to maybe finish my ESMTP email authentication
proposal. It is fundamentally based on these "optional
enforcement" backward compatibility support level concepts.
Well, if you have some scheme you'd want to write up, it can have room on
the ID line right next to SPF1, SPF2, and CSV. ;)
Good point. I was thinking as a "submitter" replacement to handle
transition points. But yes, by default, SPF1 would apply to the
current email and/or optionally client domain depending in the
implementor.
ID SPF1 [responsible-domain]
Non-starter unless you require this to match where SPF1 usually checks - and
at that point, the only value is the information "It's worth checking SPF1".
Which is why I dropped the identifier off...
I always thought SUBMITTER was vulnerable for the reasons you
pointed out, so the same applies here I believe. The only way I
saw around this is with HOP analysis.
Fortunately, that's a separate issue. ;)
Ahhh, I see, sorta like a PPP LCP negotiation? Gosh, I think
you are going to force me to finish me work. :-)
Exactly. I was actually thinking Telnet Will/Wont, but I suspect the LCP
guys were thinking about that too..;)
I don't have all the answers of course, and nothing would tickle
me pink to get an honest open discussion on the possibilities.
But how to best handle rejection is important and needs to be
discussed as I see this as the major key in addressing backward
compatibility. The growth of "greylisting" has made these type of
proposal more possible.
There's a number of ways to approach this one. Personally, I prefer
"Client send an ID, server replies with 2XX, 4XX, or 5XX, client does
what it would do on a 2/4/5XX on a MAIL FROM: (basically, continue, queue
for retry later, or give up and either RSET or QUIT as appropriate).
The basic idea behind optional enforcment modifier is to begin
offering an backward compatible changing of the mindset the
industry so desperately needs. Of course, early implementators
would not be so restricted. They will have atleast one method
that is optional, thus allowing a non-compliant clients to
continue.
That again is out-of-scope. But at least *this* part will give client
and server a framework to discuss how either end is/isn't compliant..
The goal is to gradually and eventually eliminate the non-SMTP
compliancy issues that the spammer industry relies on to a very
large degee.
The problem is that most spam is currently fairly SMTP compliant. I think what
you *meant* to say was that "we would address the lack of additional *out of
band* authentication and authorization issues that spammers rely on".
And yes, it will involve out-of-band checking of some sort. (The only proposal
I've seen that doesn't is HashCash, which has its own issues which are,
ironically
enough, based on the fact it isn't out-of-band...)
pgplzbVGP0XzL.pgp
Description: PGP signature