spf-discuss
[Top] [All Lists]

Re: a "never relays" parameter

2004-06-09 04:45:44
On Wed, 9 Jun 2004, Mark Shewmaker wrote:

Imagine any particular SPF "exists" *modifier* resulted in one of the
following results:

127.0.0.1 :  Pass (+)
127.0.0.16:  Softfail (~)
127.0.0.32:  Fail (-)
127.0.0.64:  Error   (Also return this if the DNS query itself fails.)

127.0.1.2 :  Neutral (?)
127.0.1.4 :  None
127.0.1.8 :  Unknown

Yes, this would avoid having multiple exists queries to get multiple
results - plus be much cleaner to program at the sender.

The only fly in the ointment is getting all SPF receiver implementations
upgraded.

To get the same result with current SPF1 (albeit uglier and less efficient),
you can use multiple exists queries.

In any event, it looks to me like all the advantages of the new spf
could exist (haha) in old-spf world using an exists modifier and extra
macro variables.

Even in a new-spf world, the permitted-senders concept can work, *if*
there's an exists modifier and extra macro variables.

Yes, the the idea of caching key "after DATA" variables before DATA
and verifying them later is a good one.  But it requires enhancing
ESMTP to provide the additional MAIL FROM parameters as well as 
adding more macros to SPF1.  When either MTA doesn't support the
new ESMTP parameters, the value of the new SPF macros will be unavailable.
So this enhanced system will need to handle optional macros.
It will be a while before all this is in place.

An XML based layer 2 can also handle cryptographic and reputation
systems.

-- 
              Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


<Prev in Thread] Current Thread [Next in Thread>