messages on IMAP server are marked as read after retrieving

I'd posted it, but (RANT) Charles rejected it and my post on the arrogant assertion he knew best what suited his users and the lame excuse he was loathe because he didn't know if it worked (where he usually rubs RFCS in, and this is RFC 3501 compliant) -- only to have the same question asked on his list less than four weeks later. OK, SOEP. (END RANT)

Rant aside, the patch is against getmail 4.20 and I've tested it against Exchange 2003, various Cyrus IMAP and Dovecot IMAP versions, against the IMAP servers that GMX.net and web.de use, and it uses the same IMAP4r1 commands that fetchmail has been using for years.

I think the patch should also be forwarded upstream for inclusion in Debian so they can stuff unstable/testing with it, and not discussed further since it's too trivial and what's been written about and around it is orders of magnitude more than code already.

To justify the need and at the same-time the non-chance of upstream adoption: the earlier support request/discussion was http://marc.info/?t=129830724900001

I consider this not as a bug but as a feature request. It is also inapprorpiate to put it here into Ubuntu as a bug, when it is abundantly clear that the developer does not consider it a bug, has stated that he has no intentions to change the code - however trivial it might seem - and has given technical reasons for why he considers his opinion as the better one.

The rantiness of the poster above is not helpful.

The original author has not presented a single technical argument - but the behaviour is unspecified, astonishing, thus a bug. Read on.

Charles Cazabon made emotional/personal arguments on the patch per se (fear it might break things when in fact I had tested successfully against all IMAP servers I have accounts on), and he stated reasons why he considers making it optional excess effort. The latter argument I'd support, the former is the author's lack of resources, but not a technical argument.

About technical arguments:

1. the original software getmail 4.20 is not documented to alter the IMAP \Seen flags,

2. the IMAP protocol offers retrieval commands that implicitly set the \Seen flag, and commands that don't. Refer to RFC-3501 for details, section 6.4.5 p. 57.

3. Section 2.3.2 p. 11 documents the meaning of the \Seen flag, "Message has been read". Transferring the message to a different computer does not imply that it has been read by the user.

Thus, the setting of the flags is a behaviour that isn't documented, IOW, a bug. Note that it doesn't suddenly turn into a non-bug because the author of the software refuses to change it. And also note that "INVALID" is a decision of the maintainer, https://launchpad.net/ubuntu/+source/getmail4, not yours.

My patch is evidence that solving the problem presented in this bug is technically possible without ill effect.

I'd seek you to provide technical arguments, too, if you drive that point.

FWIW, I never saw this (the marking as "read" as a bug but as a feature. It does what it says on the tin - the mail is donwloaded/"read". It tells me when I am absent from home that the downloader runs just fine. There are sure other ways of learning of downloader failure, but this is kind of an obvious one, requiring no additional infrastructure.

It is obvious to anyone who uses it - i.e. at the very latest from the first run, so the need to document it is probably neither here nor there. The bug would then anyway only be lack of documentation rather than buggy behaviour. Your patch introduces different behaviour which in its own right could be considered buggy/undesirable. Both behaviours appear perfectly valid, technically, and the desirability of one over the other is debatable.

Given that some want something different, the appropriate request is still a feature request - and again, not a feature request to change previous behaviour but the ability by users to change behaviour as per their own wishes, in short a configuration option.

This was raised on the mailing list and has been declined as the developer has no desire to create new features he does not need. Which is his prerogative.

This leaves you with the option to fork.

Hi,

I too am getting quite a few issues with Getmail marking retrieved messages as read, before I've read emails in my inbox.

Whilst I can understand what refdoc is saying regarding it not being a bug as such, however I do not see it as feature either. I cannot think of a scenario where a user would want to use a utility like Getmail (which _retrieves_ mail, not _reads_ mail) to mark their emails as read, before they have actually seen the message, just as a way of seeing whether the utility has completed. I appreciate, though that this issue is really down to original author, and complaining here is of no benefit. I am merely supporting the OP's view on the issue.

That aside, I am very interested to find more info on the patch which was posted earlier by Matthias Andree as an adaptation of Getmail's developer's code, which would seem to work perfectly for me, and satisfy what I need.

Matthias Andree: Would you be able to advise me how to apply the patch you have posted to the version of Getmail that is currently provided in the Ubuntu repos? Unfortunately, I am not experienced enough, nor can I piece the info together to work out how to patch Getmail with the patch you have provided. I am sorry to inconvenience you.

Kind regards,

Joe

This seems to be a fairly common request so I've scratched my own itch and put up a patched version of Getmail on github that adds a configuration parameter "use_peek" to the imap and imapssl retrievers. This leaves the end user in control of whether or not to risk using body.peek against a potentially non-compliant imap server.

The patch set is trivial and based on a patch that was submitted for inclusion in the Freebsd getmail port. If an Ubuntu or Debian maintainer wanted to hoover up the patches and make them part of the official package my feelings certainly wouldn't be hurt.

Upstream released a new version yesterday which seems to address this issue:

http://marc.info/?l=getmail&m=133444619906070&w=2

From the changelog:

Version 4.26.0
14 April 2012
    -switch to using BODY.PEEK in IMAP retrieval; I no longer see problems with
    this feature in my testing. If users experience incompatibility with any
    IMAP servers where 4.25.0 worked, please let me know.

There was a debian package uploaded today:

http://packages.qa.debian.org/g/getmail4.html