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 saviosena
Recipients BreamoreBoy, barry, giampaolo.rodola, jafo, jcea, josiahcarlson, saviosena
Date 2010-11-21.07:22:22
SpamBayes Score 1.5253871e-05
Marked as misclassified No
Message-id <1290324143.83.0.00798333106969.issue1745035@psf.upfronthosting.co.za>
In-reply-to
Content
The definite (and only?) solution would be to implement 'Message Size Declaration[1]' Service Extension[2]. We can limit the size of commands and text lines, but not the message size as a whole[3]. RFC1870 was created exactly with the purpose of solving DoS issues[4].

[1] RFC 1870
[2] RFC 1869
[3] RFC 2821, 4.5.3.1
[4] RFC 1870, 9.0

I'm willing to implement a fix (actually, I'm already working on that :-)) --- but I'd make good use of advices since I'm new to this project.

The minimalistic fix to this issue would be to implement Message Size Extension alone and apart from subclasses awareness --- without any changes to the interface, not even to allow changes in the default maximum message size [once SMPTServer is fully-RFC1869-compliant changing these values will be straightforward].

A second (extensive!) approach is to implement a complete ESMTPServer. That's a way bigger task though. It would be wise in this case to implement all the standard extensions, plus support (parsing/error handling) to all RFC1869.

Any thoughts?
My best regards.

NOTE: In my opinion there's no bug, really. All non-extented SMPT servers are vulnerable to resource exhaustion. Maybe we should take this as a feature request not a bug-fix request.
History
Date User Action Args
2010-11-21 07:22:23saviosenasetrecipients: + saviosena, barry, jafo, jcea, josiahcarlson, giampaolo.rodola, BreamoreBoy
2010-11-21 07:22:23saviosenasetmessageid: <1290324143.83.0.00798333106969.issue1745035@psf.upfronthosting.co.za>
2010-11-21 07:22:22saviosenalinkissue1745035 messages
2010-11-21 07:22:22saviosenacreate