Ticket UUID: | 652140 | |||
Title: | HELO and EOL cumulative patches | |||
Type: | Patch | Version: | None | |
Submitter: | gionco | Created on: | 2002-12-11 16:58:16 | |
Subsystem: | smtpd | Assigned To: | patthoyts | |
Priority: | 5 Medium | Severity: | ||
Status: | Closed | Last Modified: | 2002-12-14 06:35:33 | |
Resolution: | Rejected | Closed By: | patthoyts | |
Closed on: | 2002-12-13 23:35:33 | |||
Description: |
I've noticed a small bug in smtpd triggered by MS Outlook. Sometimes, when you send a PDF file attached to a message, Outlook sets the MIME type to "quoted-printable" and the file is not base-64 encoded. Since we read one line at a time, lines ending with CR+LF will be converted by TCL in LF only; this causes errors with both Acroread and ghostview. The patch splits the DATA section on LF only; CR is considered a normal character; includes (and thus obsoletes) the previously submitted patches for hostname in HELO, QUIT, etc... | |||
User Comments: |
patthoyts added on 2002-12-14 06:35:33:
Logged In: YES user_id=202636 The hostname display part of this patch has already been applied to the source code in handling your previous patch. The new part - changing the DATA handling - is not permitted by the SMTP RFC given our current implementation. Section 2.3.7 explicitly states that lines end with CRLF (or "\r\n" in Tcl terms). This includes the DATA section if no extensions are enables. The current implementation only supports the miminal SMTP protocol. In particular we do no implement the 8BITMIME extension which is what I think you are really asking for here. I stongly suspect that outlook is ignoring our non-support and using 8 bit mime anyway. I'm looking into this - we certainly should be able to support this but I am not certain that this is the correct way to do this. gionco added on 2002-12-12 00:00:34: File Added - 37381: smtpd_CRLF_HELO_patch__diff |
Attachments:
- smtpd_CRLF_HELO_patch__diff [download] added by gionco on 2002-12-12 00:00:34. [details]