Claws-Mail-3.7.3cvs2 I forward multiple messages, as attachments, to SpamCop. These attachments feature a Received-SPF: header which is formatted as a single long line of text. Viewing the headers of a received message shows the Received-SPF: header word wrapped on the screen (which I guess is OK) but when such a message is forwarded to SpamCop the header is word wrapped in the outgoing attachment also. Disabling all Claws-Mail Wrapping options appears to have no effect on the header being word wrapped so I conclude this behaviour must be a bug. It seems sensible, to me, that word wrapping should only apply to a message body and not to accompanying headers or attachment content.
Mail headers are subjective to rules. A header line must only hold up to 1000 characters according to the RFC, if I remember currect.
I understand the 1000 character limit for headers exists but the header that is being wrapped is considerably shorter than that.
I haven't seen your header line so my information was more an information to you what could have been the cause to your wrapped line.
1000 characters is the utter maximum limit. But, quoting RFC 2822 2.1.1 Line Length Limits "Each line of characters SHOULD be no more than 78 characters" 2.2.3 Long Header Fields "The field body portion of a header field can be split into a multiple line representation" Re-wrapping headers to make no line longer than 78 characters is RFC-compliant, standard compliant, and MUST NOT (to speak in RFC terms) change anything on the receiving side, or the receiving side isn't RFC-compliant. I don't think rewrapping the Received-SPF header confuses SpamCop in any way... Of course, if this header is rewrapped incorrectly, instead of "folded" (that is, subsequent lines don't start with a space or tab), then please reopen the bug.
I believe it is the case that the Received-SPF header is not correctly folded. SpamCop submissions from Claws Mail result in an "Unable to parse head" error and the header is shown wrapped (without a leading space/tab on the second line) but submissions from KMail on Linux parse correctly and SpamCop shows a horizontal scrollbar to permit viewing of the header. The fact that both my clients (Claws Mail on Windows and KMail on Linux) are configured identically to submit messages to SpamCop but only show errors for the Claws Mail case would suggest that my trnasmission chain isn't modifying the header in any way but there is cause for further investigation of Claws Mail. The Received-SPF header is generated, on my server, by postfix-policyd-spf-perl and this has already been investigated as generating < 1000 character single-line headers. One additional piece if information relating to my Claws Mail/Windows setup, which may be of relevance, is that I PGP/MIME sign my submissions to SpamCop using the Claws Mail PGP core plugins (all from the gpg4win latest Colin snapshot).
Can you attach one of the forwarded mails (by Claws) ?
Do you want the message before forwarding (saved with Export selected to mbox...) or a copy-and-paste of what SpamCop received?
I want the one in your Sent box :)
Created attachment 742 [details] Message submitted to SpamCop (from Sent Folder) The header of interest is Received-SPF which looks OK here but see accompanying SpamCop submission transcript.
Created attachment 743 [details] SpamCop View Full Message result The header of interest is Received-SPF: which is mangled. SpamCop reports an error of "Can't parse head". Submissions made using KMail under Linux don't result in this error so, unless SpamCop is broken, the problem appears Claws-specific although the Sent Folder copy appears to suggest the header is OK.
Thanks ! It looks like the sent message has the Received-SPF header unwrapped... The problem may be introduced by some mail server between yours and SpamCop. From Kmail under Linux, is the smtp server you use the same as with Claws on windows ?
Yes, I operate my own SMTP and IMAP services. Claws and KMail are configured to access the services identically i.e. SMTP-Auth+STARTTLS and submissions appear to go directly to SpamCop (IronPort). I might as well add that Outlook Express submits messages to SpamCop also without error (although they're not PGP/MIME signed) so Claws submissions appear to be the only ones affected. Is it possible that the Sent Folder copy of the forwarded mail isn't indicative of what was actually happening during the SMTP session?
No, that's not possible... or unheard of. Can you forward me a spam like you do to spamcop ? (colin@colino.net) Thanks!
Information only: Spam forwarded as requested on 30/10/2009.
I have been running Thunderbird 3.0 for Windows for several days now and made dozens of submissions to SpamCop - none of which have failed. I am now sure that this problem is related to Claws-Mail on Windows. There are occasional successful submissions but the large majority fail.
I'm experiencing a similar issue. Basically, if there are several recipients in e.g. the To field, the corresponding line will be wrapped in the forwarded message (which is ok) but the following header line will appear on the same line as the previous one instead of in a new line. As far as I can tell, this seems to be related to the "auto wrapping" option since, if not activated, headers are printed correctly in forwarded messages. I'm using Claws-Mail 3.7.9 under Debian GNU/Linux.
Created attachment 982 [details] test message and forwarded copies A test message with multiple recipients and forwarded copies with and without auto wrapping. All message were saved as drafts. When auto wrapping is on, the To header is wrapped in the forwarded message and the Subject header (which here follows the To one) does not start on a new line.