X-Git-Url: https://git.netwichtig.de/gitweb/?a=blobdiff_plain;f=src%2Fsrc%2Fverify.c;h=6fef314fc848ac20632c847b8d8d56ce1becfc55;hb=b6040544759110aa97f93e9ba0dd8232cd5e5188;hp=f263060bef84445a403893206d82a49dd4306fd4;hpb=e9166683487c860e0b817153531cb1b2b0485347;p=user%2Fhenk%2Fcode%2Fexim.git

diff --git a/src/src/verify.c b/src/src/verify.c
index f263060be..6fef314fc 100644
--- a/src/src/verify.c
+++ b/src/src/verify.c
@@ -761,6 +761,23 @@ tls_retry_connection:
       addr->address = string_sprintf("%s@%.1000s",
 				    random_local_part, rcpt_domain);
       done = FALSE;
+
+      /* If accepted, we aren't going to do any further tests below.
+      Otherwise, cache a real negative response, and get back to the right
+      state to send RCPT. Unless there's some problem such as a dropped
+      connection, we expect to succeed, because the commands succeeded above.
+      However, some servers drop the connection after responding to an
+      invalid recipient, so on (any) error we drop and remake the connection.
+      XXX We don't care about that for postmaster_full.  Should we?
+
+      XXX could we add another flag to the context, and have the common
+      code emit the RSET too?  Even pipelined after the RCPT...
+      Then the main-verify call could use it if there's to be a subsequent
+      postmaster-verify.
+      The sync_responses() would need to be taught about it and we'd
+      need another return code filtering out to here.
+      */
+
       if (smtp_write_mail_and_rcpt_cmds(&sx, &yield) == 0)
 	switch(addr->transport_return)
 	  {
@@ -771,7 +788,8 @@ tls_retry_connection:
 	    new_domain_record.random_result = ccache_reject;
 
 	    /* Between each check, issue RSET, because some servers accept only
-	    one recipient after MAIL FROM:<>. */
+	    one recipient after MAIL FROM:<>.
+	    XXX We don't care about that for postmaster_full.  Should we? */
 
 	    if ((done =
 	      smtp_write_command(&sx.outblock, FALSE, "RSET\r\n") >= 0 &&
@@ -795,22 +813,7 @@ tls_retry_connection:
 	    goto tls_retry_connection;
 	  }
 
-      /* If accepted, we aren't going to do any further tests below.
-      Otherwise, cache a real negative response, and get back to the right
-      state to send RCPT. Unless there's some problem such as a dropped
-      connection, we expect to succeed, because the commands succeeded above.
-      However, some servers drop the connection after responding to  an
-      invalid recipient, so on (any) error we drop and remake the connection.
-
-      XXX could we add another flag to the context, and have the common
-      code emit the RSET too?  Even pipelined after the RCPT...
-      Then the main-verify call could use it if there's to be a subsequent
-      postmaster-verify.
-      The sync_responses() would need to be taught about it and we'd
-      need another return code filtering out to here.
-
-      Remember when we last did a random test
-      */
+      /* Remember when we last did a random test */
 
       new_domain_record.random_stamp = time(NULL);