Oh and FYI, this patch is well tested on our own variant of SMTP.pm, but that variant is slightly forked, and this version is itself not specifically tested. I'm fairly positive it'll work though :)
> Hi, > > We got a bug report from someone using IBM's Lotus suite (I think for both > their MUA and MTA). Their users would often send messages where all the > content was in the subject and they didn't bother sending any message > content. I'm not sure if it's due to an apparently uncommon behavior for > their particular MUA or their MTA, but every one of these messages was > coming through with data in a form that looked like this: > > "Subject: howdy\r\n.\r\n" > > Rather than including the blank line that one might expect to follow > headers, since it's required in the event that a message body is present: > > "Subject: howdy\r\n\r\n.\r\n" > > The customer reported these messages were having their subjects stripped; > additional testing indicted all existing headers were being stripped. It > looks like this is because the loop that processes message data in > Qpsmtpd::SMTP::data_respond() and creates a Mail::Header object which is > later used to write out the header in delivery, only works if a blank line > exists after the header, e.g. the second form above. The following is all > I could find in RFC 5322 that elaborated on this blank line, which > obviously must exist if a message body is included: > > "A message consists of header fields (collectively called "the header > section of the message") followed, optionally, by a body. The header > section is a sequence of lines of characters with special syntax as > defined in this specification. The body is simply a sequence of > characters that follows the header section and is separated from the > header section by an empty line (i.e., a line with nothing preceding the > CRLF)." > > I read this as implicitly allowing the exclusion of this blank line if > there is no message body: the specification for the blank line is only > mentioned in the description of the body, which is itself described as > optional. Considering we haven't run into this bug in years of usage, I > assume it's unconventional to exclude the blank line, but it looks like it > is legitimate syntax. > > At any rate this was effecting multiple legitimate end users so we put > together the attached patch, which pulls the header building into its own > sub which is then called inside the loop if we reach the blank line > indicating the header section is complete; otherwise, it's called outside > of the loop if we have no more message data, indicating the header section > is complete. Sorry I'm not putting this on a github fork, I still don't > have my git stuff together, I may never get around to it but I thought you > guys might find this useful. > > -Jared