spf-discuss
[Top] [All Lists]

Re: HELO/EHLO Check Processing Limits (was: New draft (was: query format, load, and stunt servers, oh my))

2005-03-29 09:54:56
Scott Kitterman wrote:

Things planned for draft -01:  Remove "zone cut" everywhere.
Replace "MAY check HELO" by "SHOULD check HELO".  Add a
proper IANA template for the Received-SPF header field.

This reminds me, previously we discussed the idea that the
results for HELO/EHLO ought perhaps to be treated
differently, because there really was no reason for a valid
NEUTRAL reponse for HELO/EHLO.

Yes, and the "rough consensus" (as far as I can judge it) was
that it's almost always possible to arrange things this way,
without new tricks like op=helo.

Definitely another point for Andy's "advanced SPF cookbook" or
a future "best common SPF practice".

I am wondering similarly, if HELO/EHLO should have different
processing limits?

For v=spf1 that won't fly with my KISS-religion, it's already
bad enough that op=helo tries to redefine SPF results.  But for
spf2.0 it's possible, we could define abstract limits in the
"protocol"-document, with different values in the individual
documents for spf2.0/mfrom and spf2.0/helo.

I'm not convinced that Harry and Jim would update spf2.0/pra
only because we say so, so we better define default limits, and
override these defaults explicitly in the sp2.0/helo document.

Minor problem, there was never a separate spf2.0/helo document,
that's only one of William's ideas.

The most common record encountered during HELO/EHLO checks is
"v=spf1 a -all".  Unless some is using the same HELO/EHLO for
all their mail servers (as, IIRC, Hotmail), there should be
no need for a more complex record than that.

Do you define "complex" by the number of mechanisms, here one ?

Don't forget the few cases where a domain owner cannot arrange
things for HELO as we like it, because he's limited to exactly
one TXT RR.  Or maybe more TXT RR, but all with the same FQDN.
The sad op=helo cases.

Part of the reason that I'm think the limit should be smaller
is that even if an MTA only accepts connections that wait for
server response, it would be much less expensive to trigger a
response at HELO/EHLO that it would based on MAIL FROM:

It's always good to get a FAIL a.s.a.p.  With new HELO limits
you get a new PermError a.s.a.p., that's not exactly the same.

                        Bye, Frank




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