spf-discuss
[Top] [All Lists]

RE: Possible New Mechanism Prefix

2004-06-25 08:58:50
Clearly my last idea wasn't so popular, so let me try it this way and see if
it feels any better...

Currently, the possible prefixes are:

       +   pass
       -   fail
       ~   softfail
       ?   neutral

Pass is interpreted to mean the the e-mail is not a forgery.  For those of
us that don't run our own MTAs, there is always the possibility of someone
else forging our domain using that same MTA (it's not just statistics, we've
told everyone where to go to try and do the forgery).  For example, if I use
the Verizon (not picking on Verizon here, just an example) smtp
infrastructure:

verizon.net.    86400   TXT     "v=spf1 ip4:206.46.170.0/24 ip4:206.46.128.33
ip4:206.46.128.101 ip4:209.84.13.21 ip4:209.84.13.20 ?all"

I will have include:verizon.net in my spf record.

Now, anyone who is also a Verizon customer can successfully forge my domain
and get an SPF pass.  I can avoid this risk by doing ?include:verizon.net,
but I would like the ability to assert something beyond neutral.

Neutral means "The SPF client MUST proceed as if a domain did not publish
SPF data."  If the message came from a permitted sender (Verizon in this
example), then that says something positive about the message.  If there was
another prefix (I'll call it "permitted" this time) we could do something
about it, particularly in combination with the reputation services that seem
to be the next hurdle to jump.

So, now we add "Permitted".

     Permitted (>): the message was sent from a sender permitted by the
domain.  MTAs
     proceed to apply local policy and MAY accept or reject the message
accordingly.

Then once we get to reputation services, the receiver can look at this and
say:

Well, the sender is permitted and that sender has a good reputation as not
being a spam source, I'll accept that as probably legitimate.

or

Well, the sender is permitted, but that sender has a poor reputation as
sending a lot of spam.  I am uncertain of the legitimacy and I'll subject it
to {insert local policy here} additional tests.

Of course, many groups will use a mix of the two.

So then for SPFv2 (or MARIDv1), this prefix list becomes:


       +   pass
       -   fail
       ~   softfail
       ?   neutral
       >   permitted

I think this added level of granularity would strengthen SPF and make it
significantly more useful for those of us who are (and will remain)
dependent on outsourced MTA services.

Scott Kitterman