On Wed, May 7, 2014 at 4:16 AM, Terry Reedy <tjre...@udel.edu> wrote: > If the prepend requirement is covered by > > "The email package is a library for managing email messages, including MIME > and other RFC 2822-based message documents. It is specifically not designed > to do any sending of email messages to SMTP (RFC 2821), NNTP, or other > servers; those are functions of modules such as smtplib and nntplib. The > email package attempts to be as RFC-compliant as possible, supporting in > addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC > 2047, and RFC 2231." > > and the current 3.4/5 version does not prepend and there is no existing > tracker issue, then a new issue would seem to be appropriate.
That's a bit tricky. RFC 2822 section 3.6.7 says the Received: headers are "strictly informational, and any formal interpretation of them is outside of the scope of this document", but it does reference RFC 2821. Should the addition of another Received header be part of building an RFC 2822 compliant message, or should you build up a message without that, and have one added at transport time? I would say that, even if this isn't considered a bug (as in, failure to comply with standards it claims to comply with), it would still be a viable feature addition. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
