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 alfmel
Recipients alfmel, barry, giampaolo.rodola, r.david.murray
Date 2010-05-17.21:48:23
SpamBayes Score 1.2914669e-12
Marked as misclassified No
Message-id <201005171548.26700.alberto@byu.edu>
In-reply-to <1274130745.73.0.511398745991.issue8739@psf.upfronthosting.co.za>
Content
> Giampaolo Rodola' <g.rodola@gmail.com> added the comment:
> 
> Some comments:
> 
> Is RFC 5321 completely implemented? Otherwise I would turn this in "as
> defined in RFC 821 and part of RFC 5321".

RFC 5321 obsoletes RFCs 821, 974, 1869 and 2821.  I don't think we should 
make reference to them anymore.  Perhaps say something like "implements RFC 
5321 which supersedes RFC 821."

As to how complete the implementation is, section 4.5.1 of RFC 5321 
specifies the following as the minimum set of commands that should be 
supported in a conforming specification: EHLO, HELO, MAIL, RCPT, DATA, RSET, 
NOOP, QUIT, VRFY.  The only gray area is VRFY which is supposed to see if a 
mailbox exists for a particular user.  Since that function cannot be easily 
performed in this proxy smtpd server, section 3.5.3 states a 252 reply code 
should be returned.  My patch returns code 252 if self.__getaddr returns 
true, or 502 if it returns false.

> > - Implement DATA size limit (32 MiB by default)
> I couldn't find any reference to this in RFC 5321. Is it recommended
> somewhere else maybe? Also, issue 2518 and issue 1745035 are somewhat
> related with this specific problem.

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.

> Since you implemented HELP command in the first place it would be good to
> do it completely.

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.

> Too bad smtpd currently lacks a test suite.
> Before going any further with this issue I would recommend to write tests
> first. I have a patch for adding a basic test suite for smtpd module I
> hope I'll be able to submit within this week.

It would be great if you could implement a test suite.
History
Date User Action Args
2010-05-17 21:48:25alfmelsetrecipients: + alfmel, barry, giampaolo.rodola, r.david.murray
2010-05-17 21:48:23alfmellinkissue8739 messages
2010-05-17 21:48:23alfmelcreate