The code already throws TempFail and PermError exceptions.
(Perhaps there are some cases missed.) The only change
should be to the result codes returned. Existing callers
are still expecting the obsolete 'unknown' and 'error'
results. TermFail and PermError are both mapped to 'error'
(and distinguished by suggested SMTP code).
While you are at it, remove the even more obsolete 'deny'
result code.
When changing the result code list, we need to warn clients.
We can change __version__ to "1.7: ..." to signal the
incompatible API change for those clients that bother to
check it.
I think the only client is pymilter - but I could be wrong.
In any case, updating clients to use the new result codes
should be straightforward - and there are only two results
to fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you want to go ahead and update the milter to accept the
new codes too? If you accept either, then I can just do
this when ready (next two weeks are going to be a bear for
me, so not sure how much I'll get done).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have no problem updating milter to use the new API we come
up with. I'll ask on the mailing list whether anyone else
is affected. One advantage of changing the size of the
returned tuple (to remove the SMTP code) is that old apps
will get a clean Traceback early.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I download Wayne's new test suite 2.1. It still expect
'unknown' and 'error' for result codes rather than
'permfail' and 'tempfail'. spfquery.py will have to be
adjusted to match your new API with the test suite.
Also, the test suite doesn't like how spf.py accepts common
errors (like ipv4 instead of ip4 or prt instead of ptr).
Clearly, there needs to be a 'strict' flag to control
whether we accept sloppy records. We should handle it the
same way as processing limits. Return a PermError primary
result, but continue processing to compute an "extended" result.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this done? Is it acceptable for the library result codes
to be 'unknown' and 'error', with the understanding that
these correspond to 'permerr' and 'temperr'? I notice that
the TempErr exception is never used. We trap DNS errors
directly. We might want to trap DNS error in DNSLookup() or
dns() instead and translate to TempErr. Just for
consistency - that way we don't have to refer to DNS module
except in DNSLookup. Make selection of DNS implementation
very pluggable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No. It's not done. It's just about the next thing I want
to finish up. I am planning on adding another switch for
error type. It will default to the current API, so I don't
break the milter, but then can be altered to just report a
modern SPF result.
Also, I'll change the TempError exception to operate the
same way PermError does.
DNS Errors are the one thing that may take some additional
work (since they can be permanent or temporary). I haven't
studied that in detail yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't bother with compatibility. I'll just change milter
when I incorporate it. While the smtp code probably doesn't
belong in spf, the explanation certainly does. You will at
least need to return (result,message). Alternatively, you
could have explanation from last query available as an
attribute in the query object. Actually, I'd been wishing
that result was kept. That would be one less arg for
get_header().
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You know, I just reread the spec, and I'm going to campaign
for putting SMTP code back in the result. The reason is
that spec gives a SHOULD to a MUST recommendation for the
SMTP code for every result. The caller is free to ignore
it, but the SPF module should return the recommended code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ummm, maybe your looking somewhere I'm not... Here's what I
find:
2.5.1. None - No recommendation
2.5.2. Neutral - "MUST be treated exactly like the 'None'
result" - Hence, no recommendation
2.5.3. Pass - No recommendation
2.5.4. Fail - "The checking software can choose to mark the
mail based on this, or to reject the mail outright." There
are recommendations, but they all come after that conditional.
2.5.5. SoftFail - "Receiving software SHOULD NOT reject the
message based solely on this result, but MAY subject the
message to closer scrutiny than normal."
"For example, the recipient's MUA could highlight the
'SoftFail' status, or the receiving MTA could give the
sender a message using a technique called 'greylisting'
whereby the MTA can issue an SMTP reply code of 451 (4.3.0
DSN code) with a note the first time the message is
received, but accept it the second time."
The recommendation is listed merely as an example.
2.5.6. TempError - "...Checking software can choose to
accept or temporarily reject the message. If the message is
rejected during the SMTP transaction for this reason, the
software SHOULD use an SMTP reply code of 451 and, if
supported, the 4.4.3 DSN code."
There is a conditional here, but it's not controversial.
2.5.7. PermError - No recommendation.
So, when I read, I find strong recommendations only for Fail
and Softfail. How about this....
Give me a couple of days to finish my local policy module
that will return SPF result, MTA code, explanation. Then
your Milter impact will be limited to calling the new
functions in the new modules. No re-writing required to get
the MTA response code.
How about that?
Scott K
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the None, Neutral, Pass results the recommendation is to
accept the mail (possibly subject to further checks). This
SMTP code is thus 250 - although not explicitly stated. The
SMTP code is always 250, unless there is some kind of
exception. The recommended exceptional codes are spelled
out in the spec.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just noticed that the SPF spec also recommends extended
SMTP codes for exceptions. So returning just the SMTP code
is not good enough anyway. Perhaps we can have a separate
call or attribute to retreive the recommended SMTP code and
extended code for a result. The mapping is independent of a
specific query, so it could be a global function. Perhaps
something like:
# Recommended SMTP codes for certain SPF results. For
results not in
# this table the recommendation is to accept the message.
# The softfail result requires special processing.
OK. I guess my point is that none of those codes get hit
until after a local policy decision is made (e.g. am I going
to reject on fail or use it as a filtering option).
So, I think the MTA results are part of local policy. Give
me a couple of days to finish the local policy module and
you can integrate to that...
I agree with that construct, I just want to put it in local
policy...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that I'm going to add local policy processing within
SPF, this will take place in pySPF. I'll cover it under the
local policy RFE and close this one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=142072
The code already throws TempFail and PermError exceptions.
(Perhaps there are some cases missed.) The only change
should be to the result codes returned. Existing callers
are still expecting the obsolete 'unknown' and 'error'
results. TermFail and PermError are both mapped to 'error'
(and distinguished by suggested SMTP code).
While you are at it, remove the even more obsolete 'deny'
result code.
When changing the result code list, we need to warn clients.
We can change __version__ to "1.7: ..." to signal the
incompatible API change for those clients that bother to
check it.
I think the only client is pymilter - but I could be wrong.
In any case, updating clients to use the new result codes
should be straightforward - and there are only two results
to fix.
Logged In: YES
user_id=1300068
Do you want to go ahead and update the milter to accept the
new codes too? If you accept either, then I can just do
this when ready (next two weeks are going to be a bear for
me, so not sure how much I'll get done).
Logged In: YES
user_id=142072
I have no problem updating milter to use the new API we come
up with. I'll ask on the mailing list whether anyone else
is affected. One advantage of changing the size of the
returned tuple (to remove the SMTP code) is that old apps
will get a clean Traceback early.
Logged In: YES
user_id=1300068
I think this is the only thing to finish to have spf.py be
compliant with the latest ID. I'll work on this over the
weekend.
I went through the latest draft and the code today to look
for other things. I didn't find any.
Logged In: YES
user_id=142072
I download Wayne's new test suite 2.1. It still expect
'unknown' and 'error' for result codes rather than
'permfail' and 'tempfail'. spfquery.py will have to be
adjusted to match your new API with the test suite.
Also, the test suite doesn't like how spf.py accepts common
errors (like ipv4 instead of ip4 or prt instead of ptr).
Clearly, there needs to be a 'strict' flag to control
whether we accept sloppy records. We should handle it the
same way as processing limits. Return a PermError primary
result, but continue processing to compute an "extended" result.
Logged In: YES
user_id=142072
Is this done? Is it acceptable for the library result codes
to be 'unknown' and 'error', with the understanding that
these correspond to 'permerr' and 'temperr'? I notice that
the TempErr exception is never used. We trap DNS errors
directly. We might want to trap DNS error in DNSLookup() or
dns() instead and translate to TempErr. Just for
consistency - that way we don't have to refer to DNS module
except in DNSLookup. Make selection of DNS implementation
very pluggable.
Logged In: YES
user_id=1300068
No. It's not done. It's just about the next thing I want
to finish up. I am planning on adding another switch for
error type. It will default to the current API, so I don't
break the milter, but then can be altered to just report a
modern SPF result.
Also, I'll change the TempError exception to operate the
same way PermError does.
DNS Errors are the one thing that may take some additional
work (since they can be permanent or temporary). I haven't
studied that in detail yet.
Logged In: YES
user_id=142072
Don't bother with compatibility. I'll just change milter
when I incorporate it. While the smtp code probably doesn't
belong in spf, the explanation certainly does. You will at
least need to return (result,message). Alternatively, you
could have explanation from last query available as an
attribute in the query object. Actually, I'd been wishing
that result was kept. That would be one less arg for
get_header().
Logged In: YES
user_id=1300068
It's done. It returns result, message.
Logged In: YES
user_id=142072
You know, I just reread the spec, and I'm going to campaign
for putting SMTP code back in the result. The reason is
that spec gives a SHOULD to a MUST recommendation for the
SMTP code for every result. The caller is free to ignore
it, but the SPF module should return the recommended code.
Logged In: YES
user_id=1300068
Scott scurries to re-read the spec....
Logged In: YES
user_id=1300068
Ummm, maybe your looking somewhere I'm not... Here's what I
find:
2.5.1. None - No recommendation
2.5.2. Neutral - "MUST be treated exactly like the 'None'
result" - Hence, no recommendation
2.5.3. Pass - No recommendation
2.5.4. Fail - "The checking software can choose to mark the
mail based on this, or to reject the mail outright." There
are recommendations, but they all come after that conditional.
2.5.5. SoftFail - "Receiving software SHOULD NOT reject the
message based solely on this result, but MAY subject the
message to closer scrutiny than normal."
"For example, the recipient's MUA could highlight the
'SoftFail' status, or the receiving MTA could give the
sender a message using a technique called 'greylisting'
whereby the MTA can issue an SMTP reply code of 451 (4.3.0
DSN code) with a note the first time the message is
received, but accept it the second time."
The recommendation is listed merely as an example.
2.5.6. TempError - "...Checking software can choose to
accept or temporarily reject the message. If the message is
rejected during the SMTP transaction for this reason, the
software SHOULD use an SMTP reply code of 451 and, if
supported, the 4.4.3 DSN code."
There is a conditional here, but it's not controversial.
2.5.7. PermError - No recommendation.
So, when I read, I find strong recommendations only for Fail
and Softfail. How about this....
Give me a couple of days to finish my local policy module
that will return SPF result, MTA code, explanation. Then
your Milter impact will be limited to calling the new
functions in the new modules. No re-writing required to get
the MTA response code.
How about that?
Scott K
Logged In: YES
user_id=142072
For the None, Neutral, Pass results the recommendation is to
accept the mail (possibly subject to further checks). This
SMTP code is thus 250 - although not explicitly stated. The
SMTP code is always 250, unless there is some kind of
exception. The recommended exceptional codes are spelled
out in the spec.
Logged In: YES
user_id=142072
I just noticed that the SPF spec also recommends extended
SMTP codes for exceptions. So returning just the SMTP code
is not good enough anyway. Perhaps we can have a separate
call or attribute to retreive the recommended SMTP code and
extended code for a result. The mapping is independent of a
specific query, so it could be a global function. Perhaps
something like:
# Recommended SMTP codes for certain SPF results. For
results not in
# this table the recommendation is to accept the message.
# The softfail result requires special processing.
SMTP_CODES = {
'fail': (550,'5.7.1'),
'temperror': (451,'4.4.3'),
'permerror': (550,'5.5.2'),
'softfail':(451,'4.3.0')
}
Logged In: YES
user_id=1300068
OK. I guess my point is that none of those codes get hit
until after a local policy decision is made (e.g. am I going
to reject on fail or use it as a filtering option).
So, I think the MTA results are part of local policy. Give
me a couple of days to finish the local policy module and
you can integrate to that...
I agree with that construct, I just want to put it in local
policy...
Logged In: YES
user_id=1300068
Now that I'm going to add local policy processing within
SPF, this will take place in pySPF. I'll cover it under the
local policy RFE and close this one.