spf-discuss
[Top] [All Lists]

Re: What else to go into the pot?

2004-07-08 09:49:44
In <F8613B5F9C388242BDABF11AF6ED123F04FB58(_at_)MAIL1(_dot_)dcsl(_dot_)local> 
"Gary Levell" <gary(_at_)exclaimer(_dot_)net> writes:

My take is that newer publishers working from the SPF spec are entitled to 
place the modifier whereever they like (so that Hectors' implementation will 
need to be upgraded anyway).

Yes, Hector's implementation needs to be upgraded, and all SPF
implementations will probably need to be upgraded sooner or later.

That said, with the exception of the macro variables, the current SPF
format is very simple.  Adding position dependant modifiers really
does increase the complexity of the SPF mini-language.  Right now,
there are no relations between the various mechanisms/modifiers that
have to be kept track of.

Are all modifiers going to be position dependant?  If not, is there
going to be some way for the SPF implementation to know which ones are
so it can return the appropriate modifiers for further processing by
the caller?  One of the "important" things that some folks wanted with
XML was the ability to easily tag mechanisms as to their accreditation
or bulk mailing status.  That is, they wanted to be able to do
"include:newsletter.bulkmailer.com/status=bulk" but, of course, such a
syntax would be invalid with the current SPF parsers.

Should modifiers be tied to the mechanism on the left or on the right?
Most people here seem to like "scope=<blah> mx", but most commands
take the arguments on the right, which would imply "mx scope=<blah>".
I can see strong cases for either choice and which one you naturally
choose may depend a lot on what programming languages and such you are
used to.  This is a problem:  Even if we mandate one choice, that
mandate will probably not be known by more casual users of SPF (mail
admins, domain owners, etc.) and it will cause confusion.


All in all, I don't like position dependant modifiers very much.


Other suggestions are:

Change the syntax of mechanism to allow for position dependant
modifiers.  Something like "mx,scope=<blah>:domain.tld".  Note that
this would currently parse as a modifier and thus would be ignored by
existing SPF implementations.

Use tags in the mechanisms, such as "mx.helo:domain.tld".

Use a global modifier, such as "helo-reject=?~- 2821.from-reject=-~
2822.pra-reject=-".  This isn't as powerful as position dependant
modifiers, but this would require no changes to the SPF parsers.


Also, harking back to a previous post, can the %{p} macro please not return 
the first domain, but the {responsible-domain} if present, otherwise the
first 
domain?

I like this idea!

Meng:  What do you think?



I'd also like to see mandatory statements concerning the max # of DNS queries
that can reasonably be performed to enforce a policy, so:

      Infinite loop in include/redirect MUST return "unknown"
      More than 10 DNS mechanisms per scope policy MUST return "unknown"
      More than 10 redirected/included scope policies MUST return "unknown"
           (Not recursion depth)
      (Total 100 scope mechanism tests - should be enough don't you think?)
      More than 30 seconds elapsed time MUST return "unknown"

Well, I keep throwing the following language at Meng, but it hasn't
stuck yet:

6.2 Processing Limits
   
   During process, and SPF client may perform DNS lookups and
   additional SPF subqueries due to the "include" mechanism and the
   "redirect" modifier.

   In order to prevent Denial-of-Service attacks, the total DNS
   lookups must be limited.  The subject of a Denial-of-Service attack
   can be either the SPF client directly, or some third party domain
   that is referenced in the SPF record.  For example, a malicious
   person could create an SPF record with many references to a victim
   domain, send many emails to different SPF clients and the SPF
   clients would create a DoS attack.  In effect, the SPF clients are
   being used to amplify the attacker's bandwidth by using few bytes
   to send the email than is generated by the DNS queries.

   As a result, limits that may seem reasonable for an individual mail
   server can still allow an unreasonable amount of bandwidth
   amplification.  Therefore the processing limits need to be quite
   small. 

   SPF implementations MUST limit the number of mechanisms that do DNS
   lookups to at most 20.  For example, the "mx" mechanism requires a
   DNS lookup, so will count against this limit, while the "ip4"
   mechanism does not require any DNS lookups.

   When evaluating the "mx" mechanism, there MUST be a limit of no
   more than 20 mail looked up and checked for matching IP addresses.

   When evaluating the "ptr" mechanism or the %{p} macro variable,
   there MUST be a limit of at most 10 PTR DNS records looked up and
   checked for a validated hostname.

   SPF implementation SHOULD limit the total amount of data obtained
   form the DNS queries.  For example, when DNS over TCP is available,
   there may need to be an explicit limit to how much data will be
   accepted to prevent excessive bandwidth usage or memory usage.

   MTAs or other processors MAY also impose a limit on the maximum
   amount of elapsed time to perform an authentication.  Such a limit
   SHOULD allow at least 20 seconds.  If such a limit is exceeded, the
   result of authentication SHOULD be "error".

   Domains publishing records SHOULD try keep the number of DNS
   lookups to less than 20.  Domains publishing records that are
   intended for use as the target of "include" or "redirect"
   directives SHOULD keep the number of DNS lookups to less than 10.
   Domains should list "ip4" and "ip6" mechanisms ahead of other
   mechanisms where possible.
   

These limits are based on my attempts to actually try and create a DoS
attack via SPF.  It turned out that my gut feel for the limits were
smaller than they needed to be, but I don't think they can be much
larger than what I quote above.



-wayne