[Top] [All Lists]

Re: new draft: draft-santos-smtpgrey-01

2011-10-28 06:18:07

Tony Finch wrote:

How do we fix the silly configs?  With suggestions for values?

Firstly by contacting the postmaster at the other site with which you are having interop problems.

You are serious? Contacting people en masse?

If you can point to an rfc like Murray's that may help.

What RFC?

I don't see how your draft reduces the need for this kind of liaison or how it can help with your example of a silly one day greylist blocking period.

It eliminates contacting anyone because there is automated solution which doesn't required alerting the protocol cops on anyone. Here is real proof of its working:

Attempt #1:

Wildcat! ESMTP Server v6.4.454.1
SMTP log started at Wed, 26 Oct 2011  20:00:14
Connection Time: 20111026 20:00:14  cid: 00000000 tid: 0000031C
SSL Enabled: NO
Message Queue: \spool\santronics\smtp\43285W
Destination: nbhoener(_at_)pcisys(_dot_)net
Mail Host IP: (
Attempt #1 LastAttempt: n/a
20:00:14.433 ** Opening Connection to host: ip: 20:00:16.321 S: 220 ESMTP Sendmail 8.13.6/8.13.6; Wed, 26 Oct 2011 18:00:15 -0600 (MDT)
20:00:16.321 C: EHLO
20:00:16.399 S: Hello [], pleased to meet you
20:00:16.399 S: 250-PIPELINING
20:00:16.399 S: 250-8BITMIME
20:00:16.399 S: 250-SIZE
20:00:16.399 S: 250-DSN
20:00:16.399 S: 250-ETRN
20:00:16.399 S: 250-AUTH LOGIN PLAIN
20:00:16.399 S: 250-DELIVERBY
20:00:16.399 S: 250 HELP
20:00:16.399 C: MAIL FROM:<listadmin(_at_)winserver(_dot_)com>
20:00:16.633 S: 250 2.1.0 <listadmin(_at_)winserver(_dot_)com>... Sender ok
20:00:16.633 C: RCPT TO:<nbhoener(_at_)pcisys(_dot_)net>
20:00:16.883 S: 451 4.7.1 Greylisting in action, please come back in 00:10:00
20:00:16.883 C: QUIT
20:00:16.961 S: 221 2.0.0 closing connection
20:00:16.961 ** Completed. Elapsed Time: 2589 msecs

Under normal circumstance, our MTA has a retry frequency with:

   2nd attempt 1 min
   3rd attempt 4 mins
   4th attempt 15 mins
   all the rest omitted

and without reading the hint from the server, our MTA will deliver the mail at the 4th try and in 20 minutes.

Here is the real result, at the 2nd attempt 10 minutes later:

Wildcat! ESMTP Server v6.4.454.1
SMTP log started at Wed, 26 Oct 2011  20:10:25
Connection Time: 20111026 20:10:25  cid: 00000000 tid: 00000D18
SSL Enabled: NO
Message Queue: \spool\santronics\smtp\43285W
Destination: nbhoener(_at_)pcisys(_dot_)net
Mail Host IP: (
Attempt #2 LastAttempt: 10/26/2011 20:00:16
20:10:25.840 ** Opening Connection to host: ip: 20:10:29.023 S: 220 ESMTP Sendmail 8.13.6/8.13.6; Wed, 26 Oct 2011 18:10:25 -0600 (MDT)
20:10:29.023 C: EHLO
20:10:29.085 S: Hello [], pleased to meet you
20:10:29.085 S: 250-PIPELINING
20:10:29.085 S: 250-8BITMIME
20:10:29.085 S: 250-SIZE 52500000
20:10:29.085 S: 250-DSN
20:10:29.085 S: 250-ETRN
20:10:29.085 S: 250-AUTH LOGIN PLAIN
20:10:29.085 S: 250-DELIVERBY
20:10:29.085 S: 250 HELP
20:10:29.085 C: MAIL FROM:<listadmin(_at_)winserver(_dot_)com>
20:10:29.475 S: 250 2.1.0 <listadmin(_at_)winserver(_dot_)com>... Sender ok
20:10:29.475 C: RCPT TO:<nbhoener(_at_)pcisys(_dot_)net>
20:10:29.631 S: 250 2.1.5 <nbhoener(_at_)pcisys(_dot_)net>... Recipient ok
20:10:29.631 C: DATA
20:10:29.709 S: 354 Enter mail, end with "." on a line by itself
20:10:29.912 S: 250 2.0.0 p9R0APdB024107 Message accepted for delivery
20:10:29.912 C: QUIT
20:10:29.990 S: 221 2.0.0 closing connection
20:10:29.990 ** Completed. Elapsed Time: 4244 msecs

This is clear proof of concept and potential for significant reduction in overhead and faster delivery. It works without calling anyone, yelling or cursing anyone out. Totally surprise you expect people to be contacting all these sites, You know it isn't realistic.

2 tries, 10 minutes. Not 4 tries, 20 minutes and before you say anything about my retry frequencies, they work fine against against sites with shorter delays. But we expect to be mandating that across the board and throwing Murray's RFC at them.

Ok, I bite, what are your recommendations for:


  Blocking Time:  ___ secs/mins

Short. There's little point in sending more than one 450, to prove the sender 

How short?  30 secs, 1 minute? 5 minutes? 10 minutes?

  Record (sender recording) Expiration Time:  ____ secs/mins/hours/days

Something like a week.


Client:  Retry Frequencies

RFC 5321 has guidelines. You need to try many more than four times!

I wasn't going to write 60-72 lines to fill you. You got the idea. But even then, going over 2 or 4 times contradicts the short and only blocking once. No?

We have no idea what the blocking times are. The MTA retry tables people use vary and they are working blindly against the GL servers.

and I presume the fix means that EVERYONE has to use the same values at all servers and clients?

Of course not.

So it wouldn't be consistent nor a fix when the world is not running a single setup like yours or mines or the one modeled on Murray's RFC. Wouldn't it?

Less traffic and faster delivery. A BCP can't offer that. It can try but the MTA will still be working in a blind.


Hector Santos