spf-discuss
[Top] [All Lists]

Re: What else to go into the pot?

2004-07-08 20:21:01
In <F8613B5F9C388242BDABF11AF6ED123F04FB5B(_at_)MAIL1(_dot_)dcsl(_dot_)local> 
"Gary Levell" <gary(_at_)exclaimer(_dot_)net> writes:

Wayne wrote:

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

In your implementation, do you not scan the SPF policy left to right
to extract the modifiers & mechanisms?

Yes, position dependant modifiers certainly *could* be done.  It isn't
even that hard, but there are a large number of implemenations out
there and keeping this as simple as possible (but no simpler) is an
important goal for me.

I've said it many times:  "If you want Java in a sandbox, you know
where to find it."


Right now, I'm having a hard time finding really good reasons to need
scoping mechanisms at all, and if the cases are rare enough, I don't
care if using %{e} is slightly slower.



               It does this by re-ordering the mechanisms such that ip4
are processed first, then "a" then "mx" etc. (Don't panic this passes
all the tests, and the optimization is only done in mechanism clusters

Yes, this a perfectly valid optimization to do.  A bunch of us talked
about it on the #SPF IRC channel last fall.  It is also possible to
create a plugin for the name server that accepts normal, easy to
maintain SPF records and sends out optimized SPF records with many
lookups already resolved.  Lots of things that can be done.

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

And "a" mechanisms ?

The A:mechanism doesn't trigger further lookups, so it has to come
back in one packet anyway.  I can see a need for a limit here.



  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.

I'd worry that this can't be realistically achieved in some implementations. 

This suggested wording is there so that implementations are *allowed*
to place such restrictions and still be complaint.  If you don't want
to limit the size, then no problem.  Publishers, however, shouldn't
complain if their 30k SPF record doesn't work though.


  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".

Seth recons this should be user configurable and I kind of agree since 

Again, the suggested wording is so that implementations can freely
impose such restrictions and to tell publishers that they can't have
really slow name servers.




-wayne