This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients Anthony.Kong, Juhana.Jauhiainen, alfmel, barry, catalin.iacob, fruitnuke, geoffreyspear, giampaolo.rodola, hynek, josiah.carlson, maker, r.david.murray, richard, tshepang
Date 2012-03-15.03:49:47
SpamBayes Score 1.110223e-16
Marked as misclassified No
Message-id <1331783389.67.0.206406242095.issue8739@psf.upfronthosting.co.za>
In-reply-to
Content
OK, I've gone through Dan's update (thanks very much for the tests!).  I'm uploading a revised patch.  The major differences are:

I've refactored the parsing.  Now it is a three step process: peel off the extra keyword (FROM:, TO:) if there is one, then pull off the address, then parse the remainder as parameters, doing a best-effort parse (that is, ignore tokens that don't parse as parameters rather than failing the entire parse if one is bad).  This fixed a bug where a space between the : and the address would break command parsing.  When the RFC5322 parser from email6 lands, it will almost be a drop in replacement for _parseaddr.  (Oh, yeah, I took the opportunity to eliminate the last __ methods.  There's no reason for those parsing methods to be __ methods.)  I say almost because it will allow us to correctly implement the difference in the syntax of the address for VRFY verses MAIL and RCPT by using two different functions from that parser.

I've removed the 8BITMIME support.  It was not implemented correctly per its RFC, and the server as it exists does not, in fact, support receiving binary data (it decodes what it receives using the utf-8 codec...which means it will raise a decode error on binary data).  It would be possible to add 8BITMIME support, but since it is non trivial we'll leave that to another issue.

I reworked the extended command length support to facilitate adding additional extension support.  What I did may not be the most useful refactoring, though.  I considered just making the limit "large enough", but decided to keep the current behavior since it allows smtpd to be used to test clients handling smtp servers that enforce the limits.  Given that, a nice future feature would be to make the max command length limit settable as well.

I renamed max_message_size back to data_size_limit in order to maintain backward compatibility.

I updated the general help output to reflect the HELO/EHLO state.  I don't know what typical servers do for that (since HELP can be issued before them), but I think I've seen it work that way on other servers.

I've added a few more tests.

Unless someone wants to add tests for the smtpd command line, I think this patch is done.  Reviews welcome.
History
Date User Action Args
2012-03-15 03:49:50r.david.murraysetrecipients: + r.david.murray, barry, richard, giampaolo.rodola, josiah.carlson, maker, alfmel, catalin.iacob, tshepang, geoffreyspear, Anthony.Kong, hynek, fruitnuke, Juhana.Jauhiainen
2012-03-15 03:49:49r.david.murraysetmessageid: <1331783389.67.0.206406242095.issue8739@psf.upfronthosting.co.za>
2012-03-15 03:49:49r.david.murraylinkissue8739 messages
2012-03-15 03:49:47r.david.murraycreate