Subject: [spfbis] Dealing with Multiple Transactions

From: Hector Santos <[email-masked]>
Date: Tue, 07 Aug 2012 17:11:45 -0400

Scott et al,

While it might be implicit, maybe some text is warranted that points 
out the ideas of dealing with multiple transactions.  A past 
discussion in IETF-SMTP considered how/what state information is kept 
and cleared per transaction vs per SMTP session.

This began when I pointed out a loophole is possible if a transaction 
is rejected but the client can try a different transaction and bypass 
the rejection.   In this case, the real example provided was with 
greylisted transactions where the client did not QUIT (or drop), 
waited X minutes or seconds enough to get around the greylisted block 
tracking time.

For our software, we now have an option (default ON) to track a 
GREYLISTED rejected transaction permanently for the entire SMTP 
session. Once rejected, new transactions are disabled.

Reviewing a session in our logs this morning, I was reminded of this 
possibility for SPF as well with an facebookmail.com session.

C: EHLO facebookmail.com
S: 250-winserver.com, Pleased to meet you.
S: 250-SIZE 10240000
S: 250-8BITMIME
S: 250-SUBMITTER
S: 250-ETRN
S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
S: 250-AUTH=LOGIN
S: 250-HELP
S: 250 STARTTLS
C: MAIL FROM: <[email-masked]> BODY=7BIT
S: 250 <[email-masked]>... Sender validation pending.
Continue.
C: RCPT TO:<[email-masked]>
** WCX Process: wcsap ret: 550 (156 msecs) (Rejected by WCSAP SPF Fail)
S: 550 Return Path not verifiable.

Our software does the Sender verification suite of testing after a
valid RCPT TO is issued.  The testing includes SPF and it failed here
with a non-valid IP SPF address for facebookmail.com.

C: RSET
S: 250 Reset State #1
C: MAIL FROM: <[email-masked]> BODY=7BIT
S: 250 <[email-masked]>... Sender validation pending.
Continue.
C: RCPT TO:<[email-masked]>
** WCX Process: wcsap ret: 550 (63 msecs) (Rejected by WCSAP SPF Fail)
S: 550 Return Path not verifiable.

Here, the sender tried a new transaction in the same session. Again
failed with SPF.

C: RSET
S: 250 Reset State #2
C: MAIL FROM: <[email-masked]> BODY=7BIT
S: 250 <[email-masked]>... Sender validation pending.
Continue.
** connection drop - error: 10053 state: tMail lastcmd: MAIL
** Completed. Elapsed Time: 55599 msecs

Finally, it tried a third time, but did not issue a RCPT TO to trigger
the SPF check and it failled dropped after a near minute.  Side
indirect point: That could be our 1 minute since we do have logic to
minimize the session/CPU waste time with clients holding channels for
extended minutes (3-5).  In our case, it starts with an initial SMTP
wait of 5 minutes, but after a 2nd transaction is attempted the
timeout drops to 1 min.

Anyway, I am not show what ample text may be appropriate for 4408BIS, 
if any, but an improved optimized logic and simple text could be:

     For SPF results that would not change in subsequence same session,
     multiple transactions, the receiver MAY use the same results without
     calling the check_host() function.  [This can help minimize DNS calls
     and also close possible security loopholes.]

The above is just starter text for any consideration.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 07 Aug 2012 17:51:09 -0400

> The above is just starter text for any consideration.

How is that different than caching the SPF result, which is already OK?

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 08 Aug 2012 03:24:04 -0400

The common factor in all (same session) transactions is a constant IP 
address and theoretically, the same machine name for EHLO/HELO.  The 
only variable would be the MAIL FROM.

If the MAIL FROM is the same, then there is no need to do any SPF 
shim, hook, call since  the result will be the same. Yes, the cache 
could produce the same (unless there was a timeout in between 
transactions). The dynamic protocol should work without this, so its 
probably more to point out the concept and optimizing value for 
implementations when dynamic functionality is at play.

I guess the question is whether a sender is SPF valid (or SPF invalid) 
for an entire SMTP session/connection or per transaction.

Here's a thought, if a rejection is permanent (55z), could that be 
considered for the entire session vs temporary 45z) for the transaction?

-- 
HLS

Scott Kitterman wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
>