Paul Smith wrote:
On 29/10/2011 21:10, John C Klensin wrote:Of course, this assumes you don't want the 'new' response before the negotiation.would be perfectly adequate to permit support for, e.g., 6yz or x7z codes. Whether it is a good idea or not is another question, but it seems to me that the protocol design is adequate.In the case of a 'wait' extension, it would be 'nicer' to have <connection> 421 Server in maintenance, try later wait:600 rather than <connection> 220 hi EHLO me 220-AUTH LOGIN 220 SMTPRETRY AUTH <stuff>220 OK (which may need to be faked if the real auth database is not available)EHLO me again 220 SMTPRETRY NEEDRETRYDATA 621 Server in maintenance, try later wait:600
We know you meant 250 above. Two comments.If the intent is know to issue a maintenance notice, then I would probably not activate AUTH. So it becomes:
<connection> S: 220 hi C: EHLO me S: 250 SMTPRETRY C: NEEDRETRYDATA S: 621 Server in maintenance, try later wait:600 QUIT NOW C: QUIT S: 221 see ya!Also, if this is one of the purposes, then maybe a service keyword, like perhaps ALERT can work do this:
S: 220 hi C: EHLO me S: 250 ALERT OIL CHANGE. QUIT NOW and WAIT:600 C: QUIT S: 221 see ya! and it can be extended to expose time left info: S: 220 hi C: EHLO me S: 250 ALERT SYSTEM GOING DOWN SOON. TIMELEFT=50 WAIT=600So now the client can decide if it can send the message(s) in 50 secs or hang up and try again in 5 mins. <g>
-- Sincerely Hector Santos http://www.santronics.com jabber: hector@xxxxxxxxxxxxxxx