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: 216.229.32.113:25 (smtp1.pcisys.net)
Attempt #1 LastAttempt: n/a
20:00:14.433 ** Opening Connection to host: smtp1.pcisys.net ip:
216.229.32.113:25
20:00:16.321 S: 220 smtp1.pcisys.net ESMTP Sendmail 8.13.6/8.13.6;
Wed, 26 Oct 2011 18:00:15 -0600 (MDT)
20:00:16.321 C: EHLO mail.santronics.com
20:00:16.399 S: 250-smtp1.pcisys.net Hello groups.winserver.com
[208.247.131.9], pleased to meet you
20:00:16.399 S: 250-ENHANCEDSTATUSCODES
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 smtp1.pcisys.net 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: 216.229.32.234:25 (mx4.pcisys.net)
Attempt #2 LastAttempt: 10/26/2011 20:00:16
20:10:25.840 ** Opening Connection to host: mx4.pcisys.net ip:
216.229.32.234:25
20:10:29.023 S: 220 mx4.pcisys.net ESMTP Sendmail 8.13.6/8.13.6; Wed,
26 Oct 2011 18:10:25 -0600 (MDT)
20:10:29.023 C: EHLO mail.santronics.com
20:10:29.085 S: 250-mx4.pcisys.net Hello groups.winserver.com
[208.247.131.9], pleased to meet you
20:10:29.085 S: 250-ENHANCEDSTATUSCODES
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 mx4.pcisys.net 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:
Server:
Blocking Time: ___ secs/mins
Short. There's little point in sending more than one 450, to prove the sender
retries.
How short? 30 secs, 1 minute? 5 minutes? 10 minutes?
Record (sender recording) Expiration Time: ____ secs/mins/hours/days
Something like a week.
Ok.
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.
--
Sincerely
Hector Santos
http://www.santronics.com