Mercury Suggestions
ESMTP Support of Pipelining and DSN

I really do think it's time for Mercury to support the proper DSN ESMTP mechanism and format (it's nearly there!) in both server and client code, and in Pegasus Mail as "Confirm Delivery" instead of using the now obsolete Return-Receipt-To that many mailers don't even listen to anymore.  Also, see Disposition-Notification-To for "Confirm reading" for the same reasons.  It'd bring Mercury in line with the big players and make parsing errors it generates easier for mailing list software.  Added points for getting the list server to do same.  See these standards documents:

* Hansen, T., Ed., and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004.
* Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
* Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
* Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
* Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
* Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.

You may want, but I think it essentially optional, to also implement this while you're about it:

* Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.

And now, ESMTP command pipelining.  Again, for speedy handling of mailing lists especially.  This depends on how you do things, of course, and there are some issues to be aware of, but from experimentation your server is already there and need only advertise the extension to permit clients to blast - even if you won't return the favour, you at least handle it and, thanks to TCP_NODELAY not having been set, may even be already doing it yourself!  The client, well, that's over to you.  If you can connect to a host and blast a load of recipients that the host is supposed to handle, you should!  For instance, a non-VERP list, for which the return address is software you've written to handle DSNs and pass the rest onto the Postmaster (or handle MTA-specific bounce formats like QSBMF as well if you fancy) gains both the throughput advantages of SMTP and yet in many instances the automatic ability to identify offending bouncers!

 

Here's the reference:

* Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.

In your own time.  And thanks for Mercury!

 

 Cheers,

Sabahattin

 

<P>I really do think it's time for Mercury to support the proper DSN ESMTP mechanism and format (it's nearly there!) in both server and client code, and in Pegasus Mail as "Confirm Delivery" instead of using the now obsolete Return-Receipt-To that many mailers don't even listen to anymore.  Also, see Disposition-Notification-To for "Confirm reading" for the same reasons.  It'd bring Mercury in line with the big players and make parsing errors it generates easier for mailing list software.  Added points for getting the list server to do same.  See these standards documents:</P> <P>* Hansen, T., Ed., and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004. * Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. * Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003. * Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. * Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. * Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008. </P> <P>You may want, but I think it essentially optional, to also implement this while you're about it:</P> <P>* Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. </P> <P>And now, ESMTP command pipelining.  Again, for speedy handling of mailing lists especially.  This depends on how you do things, of course, and there are some issues to be aware of, but from experimentation your server is already there and need only advertise the extension to permit clients to blast - even if you won't return the favour, you at least handle it and, thanks to TCP_NODELAY not having been set, may even be already doing it yourself!  The client, well, that's over to you.  If you can connect to a host and blast a load of recipients that the host is supposed to handle, you should!  For instance, a non-VERP list, for which the return address is software you've written to handle DSNs and pass the rest onto the Postmaster (or handle MTA-specific bounce formats like QSBMF as well if you fancy) gains both the throughput advantages of SMTP and yet in many instances the automatic ability to identify offending bouncers!</P> <P mce_keep="true"> </P> <P>Here's the reference:</P> <P>* Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000. </P> <P>In your own time.  And thanks for Mercury!</P> <P mce_keep="true"> </P> <P> Cheers,</P> <P>Sabahattin</P> <P mce_keep="true"> </P>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft