Summary: | Make setting an X-Mailer header optional | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Claws Mail (GTK 2) | Reporter: | Fabian Keil <fk> | ||||||
Component: | Other | Assignee: | users | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | enhancement | CC: | cwallace | ||||||
Priority: | P3 | ||||||||
Version: | 3.7.10 | ||||||||
Hardware: | PC | ||||||||
OS: | FreeBSD | ||||||||
Attachments: |
|
I don't see why that would be an enhancement, but anyways .. you can just add a custom X-Mailer header and leave it empty. It's an enhancement for users who prefer not to sent a non-standard header whose use is "not in general recommended" (RFC2076). Overwriting the header's value with an empty value might be a work-around to prevent Claws-Mail from disclosing unnecessary information, but the header still appears in the message. It's also my impression that header values aren't optional (RFC822). Fabian, Why is it that you don't want this header to appear? > It's also my impression that header values aren't optional (RFC822).
That's a bit like saying "It's my impression that eating ice cream is forbidden (see the law)". I.e.: If you want to support your claim with a RFC, it'd be useful to give more detail.
Paul, I think the question should be: Why would I want the header to appear? It's neither required nor recommended and by default it discloses unnecessary information. If you redact it as much as possible you end up with an value-less header and sending an value-less header seems pointless so you might as well not set it at all. I'd actually consider not setting the header a great default, but as I had no illusions that a patch for that would be accepted, I didn't bother to submit one. Holger, looks like I misread section 3.2, sorry. Given that the patch has already been rejected and that there are other patch and bug submissions deserving attention discussing the patch any further seems like a waste of time. I'll just keep it in my custom patch set. Thanks for your time. +1 to this patch. Claws-mail doesn't need to be adware. Fabian, Countering a question by another question isn't really an answer! But from what I understand, you want to remove everything which is not 'required' and not specifically stated as 'recommended'. Am I right that it is everything or just this header? Chad, I think calling it 'adware' is not only harsh, but also a total misuse of the term 'adware'. It is clearly not this. There are indeed other unnecessary information "leaks" I intend to eventually address (and probably some more I'm not aware of), but I don't think they are relevant here. FWIW I share the feeling that a X-Mailer (or for the case any other X-<something>) header which the user has set an empty value explicitly should not be generated at all. And that would solve the problem, if I didn't read wrong. On the other side making this a per-account option is a bit overkill ;-P Would everyone be happy if empty custom headers were not inserted ? It's a neat solution Colin, if there is no information in the header there's no point inserting it. Adding a header so that the header doesn't get added doesn't quite make sense to me. I agree just a checkbox "Disable X-Mailer header" makes probably more sense, and that also solves the problem, but requires more code ;-) I just tried to find the quickest way with the existing codebase. Agreed on not inserting empty custom headers, it makes senses and IMO that's how users will undertand it. I agree that having to add an empty header so the header isn't actually added is a bit non-intuitive, but I think any mechanism that gives the user control over setting or not setting the X-Mailer header would be an improvement. BTW, default header removal also works this way in curl which is why I tried the same in claws-mail before writing the patch. Changes related to this bug have been committed. Please check latest CVS and update the bug accordingly. You can also get the patch from: http://www.colino.net/claws-mail/ 2011-08-29 [colin] 3.7.10cvs4 * src/compose.c Don't insert custom headers that have empty values. Allows not inserting X-Mailer if it's set to nothing. Fixes bug #2471, "Make setting an X-Mailer header optional". 2011-08-29 [colin] 3.7.10cvs3 * src/image_viewer.c * src/textview.c * src/gtk/gtkutils.c * src/gtk/gtkutils.h Handle EXIF orientation in images (both in textview's preview and image viewer) Changes related to this bug have been committed. Please check latest CVS and update the bug accordingly. You can also get the patch from: http://www.colino.net/claws-mail/ 2011-08-29 [colin] 3.7.10cvs5 * src/account.c * src/compose.c * src/prefs_account.c * src/prefs_account.h Revert cvs4 which is rather illogical and instead use Fabian's patch from bug #2471 Created attachment 1005 [details] Do not suppress the 'Generate X-Mailer' option for new IMAP accounts As Okra Son reported on users@lists.claws-mail.org, the patch didn't properly deal with IMAP accounts (because, as Colin pointed out, I used the wrong code as example). This has been partly addressed by Colin in 3.7.10cvs7, but the option still seems to be suppressed for new IMAP accounts. The attached patch (against 3.7.10cvs15) fixes this and also removes the apparently redundant gtk_widget_show() calls. After the patch the code should be similar to the one used for the "Send account mail address in Message-ID" option which is probably a more fitting example. Looks like 3.8.0 is missing the "Do not suppress the 'Generate X-Mailer' option for new IMAP accounts" patch, which still applies cleanly. It's there. See the 'Send' page of the IMAP account prefs for the 'Generate X-Mailer header' option Ok, i was too quick - you are right: the option does not appear in the options on the initial new account That's now fixed at v.3.8.0cvs7 Thanks, Paul. |
Created attachment 994 [details] Add a per-account option to set the X-Mailer header The attached patch makes setting an X-Mailer header optional. The option is enabled by default so if the option isn't touched claws-mail's behavior shouldn't change. It's already possible to overwrite the header with a custom value, but it doesn't seem to be possible to set no X-Mailer header at all. The patch contains an IMAP-only code path which I didn't test as I don't use IMAP.