spf-discuss
[Top] [All Lists]

RE: For SPF council review: Syntax error = Perm error= Message should be rejected?

2005-05-03 00:08:47

-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of wayne
Sent: dinsdag 3 mei 2005 5:57
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] For SPF council review: Syntax
error = Perm error= Message should be rejected?

Rejecting messages based on a syntax error makes SPF
deployment much more risky.

Instead of SHOULD reject, it should be treated as None.


(...)

Besides RECOMMENDING doing an SMTP reject (5xx code) for a PermError,
I could see RECOMMENDING that a SMTP temp fail (4xx code) be given for
a PermError.

Temp-failing PermErrors (now there'a contradiction in terms) is not as
benign as it may seem, as typically, 4.x.x. errors remain out of
administrative purview; and for good reasons: it would be silliness to
contact an administrator every time a temp error occurs in a mail
transaction. So, is it likely anyone would even see these TempErrors?
(until after 4 days, or so, when the MTA finally gives up) I certainly
wouldn't, unless I specifically went looking for it.

One problem with SMTP temp fails is that spam can build up, with
continual retrying.

Exactly. But not just spam, ANY mail! Assigning a temporary (error)
condition to a situation which really should be considered 'permanent' (in
the sense that the machine checking the faulty SPF record should not leap
to the awfully optimistic conclusion that the record will be fixed any
time soon) will only result in a waste of bandwidth: the connecting MTA
trying and retrying...

Also, issuing a TempError (4.x.x) on the receiving MTA is, in a way,
actually quite misleading; because you lead the connecting MTA to believe
there is a 'transitory error' (something along the way, or perhaps a
temporary error condition on the receiving MTA, like virus scanner down,
or something), while, in fact, the DNS error is not due to net outtage,
but simply the result of a local misconfiguration (on the connecting MTA).

2) Treat PermError as "Fail"

This would definitely be misleading: there is no relay which "FAILs" the
authorization test -- there is simply no syntactically valid authorization
record.

3) RECOMMEND PermError be rejected via SMTP 5xx responses

Good. ;)

- Mark 
 
        System Administrator Asarian-host.org
 
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx


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