Author lpolzer
Recipients barry, lpolzer, r.david.murray, richard, vstinner
Date 2013-11-20.15:02:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1384959762.57.0.564114093266.issue19662@psf.upfronthosting.co.za>
In-reply-to
Content
Since this is my first contribution I'm not entirely sure about the fine details of backwards compatibility in Python, so please forgive me if I'm totally missing the mark here.

There are facilities in smtpd's parent class asynchat that perform the necessary conversions automatically if the user sets an encoding, so smtpd should be adjusted to rely on that and thus give the user the opportunity to choose for themselves.

Then it boils down to breaking backwards compatibility by setting a default encoding, which could be none as you suggest or latin1 as I suggest; either will probably be painful for current users.

My take here is that whoever is using this code for their SMTP server and hasn't given the encoding issues any thought will need to take a look at their code in that respect anyway, so IMHO a break with compatibility might be a bit painful but necessary.

If you agree then I will gladly rework the patch to have smtpd work with an underlying byte stream by default, rejecting anything non-ASCII where necessary.

Later patches could bring 8BITMIME support to smtpd, with charset conversion as specified by the MIME metadata.
History
Date User Action Args
2013-11-20 15:02:42lpolzersetrecipients: + lpolzer, barry, richard, vstinner, r.david.murray
2013-11-20 15:02:42lpolzersetmessageid: <1384959762.57.0.564114093266.issue19662@psf.upfronthosting.co.za>
2013-11-20 15:02:42lpolzerlinkissue19662 messages
2013-11-20 15:02:41lpolzercreate