Message105943
| 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. |
|