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 giampaolo.rodola
Recipients alfmel, barry, giampaolo.rodola, josiah.carlson, r.david.murray
Date 2010-05-17.23:06:41
SpamBayes Score 6.862641e-07
Marked as misclassified No
Message-id <1274137603.27.0.89406169907.issue8739@psf.upfronthosting.co.za>
In-reply-to
Content
> It is not, but just seemed like good practice to advertise the limit in 
> EHLO and enforce it.  My patch doesn't do a good job of enforcing it 
> since it enforces it before doing process_message.  The problems with 
> 2518 and 1745035 are still there.

Then I doubt it would be a good idea, also because the following comment added in issue 1745035 should still stand:

> The patch does not work as Giampaolo intends.  If the patch were 
> applied as-is, no emails longer than 998 bytes could be sent.

Personally I think there's no other way to gracefully solve this other than using a tempfile to store the data, but since I'm not a user of the module I'm going to let someone else comment about this.

> RFC 5321 doesn't specify it must accept arguments, but I agree it is 
> a good idea.  I'll work on that and submit a new patch.

If there's no RFC which states that, then I would provide arguments for HELP *only* if that is a common practice amongst smtp servers.
History
Date User Action Args
2010-05-17 23:06:44giampaolo.rodolasetrecipients: + giampaolo.rodola, barry, josiah.carlson, r.david.murray, alfmel
2010-05-17 23:06:43giampaolo.rodolasetmessageid: <1274137603.27.0.89406169907.issue8739@psf.upfronthosting.co.za>
2010-05-17 23:06:41giampaolo.rodolalinkissue8739 messages
2010-05-17 23:06:41giampaolo.rodolacreate