Subject: TECH-OMISSION: failure action is too restrictive in -core

From: Daniel Quinlan <[email-masked]>
Date: Mon, 23 Aug 2004 16:14:40 -0700

In section 5.3, this specification assumes all SPF checking will be done
at SMTP time which is not realistic.  Some examples: some
implementations may retest a message later to either verify Sender-ID
results, because the load was too high when the message was received,
because the SPF checking was done after-SMTP (SpamAssassin).

This section should also leave open other authentication methods such as
POP before SMTP, SMTP AUTH, etc.

In addition, when done at SMTP time, other actions may be desirable on
the MTA such as a temp fail, throttling, teergrubing, etc.

I recommend changing the paragraph to read:

   An SMTP server receiving this result SHOULD NOT treat the message as
   authentic.  However, it MAY treat the message as authentic or not
   authentic based on other authentication methods.  If the message is
   rejected during the SMTP session, the SMTP server SHOULD reject the
   message with a "550 5.7.1 Sender ID xxx - yyy" SMTP error, where
   "xxx" is replaced with the additional reason returned by the
   check_host function and "yyy" is replaced with the explanation string
   returned by the check_host function.

Section 5.5 has the same assumptions, but because "MAY" is used there,
it's not an issue for implementors.

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

---

From: "Steven G. Willis" <[email-masked]>
Date: Tue, 24 Aug 2004 15:08:01 +0000

It hath once been written:

>...

Sorry, but I do think this should be the case. The SPF checks are not
excessively intensive in almost all cases.

Now, given, I did say in _almost_ all cases. Of course, excessive loads may be
an issue to have to consider. But, considering the SPF checks are RFC 2821
checks, it would be much better for all SPF checks to be done during the
envelope exchange.

If you are having a load issue, would it not be better to defer the connection
with a 4XX response? Having the remote MTA try the connection again at a later
time would allow for an abatement to the the heavy load the receiving MTA may be
experiencing.

This seems much preferable as it would alleviate the need for any DATA to be
transmitted during the session.

Cheers!

================================================================
Steven G. Willis     [email-masked]       772.794.9494
Deep Sky Technologies, Inc.          http://www.deepskytech.com/
http://www.badchickens.com/         http://www.store-secure.com/
AIM-iChat: dstisgwillis
================================================================
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
================================================================