Hello, thanks Bron for the detailed report.
Spam Reporting via IMAP: - Alexey mentioned that there's talk of adding a command to IMAP to report a message as spam/non-spam rather than setting flags. This would be used to actually take action based on the report. - Google and Yahoo are both involved in this effort.
How is this exactly supposed to work? I mean, currently the web-clients of mailbox providers support reporting of spam messages, and this functionality shall be moved to desktop clients, too. Now, the desktop clients shall provide interface to the users to report emails as spam. Those emails shall be reported to the operators, who delivered the message to the user. The provider of the IMAP service is one of those, who shall be informed that the user marked the message as spam. In the case, when the message was delivered via (affinity) alias on an external service/domain, that provider shall be informed, too, so that the provider offering mail aliases can learn from user experience and, apart from other things, offer per recipient spam filtering. This means, that the desktop client shall be able to report spam messages with the IMAP-function, or by sending an ARF-report (abuse reporting format) or both, unifying both functions in the same user interface.
I know the reporting with ARF messages, is not really cyrus/imap related, but I was thinking on this in the last weeks, and here somebody else opened the topic, so I want to share my thoughts.
How do you intend to offer the interface between cyrus-imapd and the spam-proceeding programme, once the user reports the message as spam (via IMAP)?
I was thinking, that an unified system, that proceeds spam reports, arriving both via IMAP (synchronous) or ARF-messages (asynchronous), would be the best approach, meaning practically that I wanted to extend cyrus imap (in the very long term, but probably this year), to proceed ARF-messages and make some actions. The ARF-messages (a kind of, since I get the reports from a company, that does not use exactly ARF) I currently proceed are basically from emails sent over mailing lists. So if the email address reporting the message is subscribed to a mailing list, then user is notified about her removal from the list and proceeding of the spam-report is completed successfully (the message shall be moved for a special IMAP folder and marked as read => that can be programmed in Sieve), otherwise I check manually what is wrong.
Now, I think the resulting architecture shall consider that spam reports can arrive both over IMAP or as ARF-messages, unify them, and finally proceed them.
- Release process - simplify to save the repeated typing involved. I wind up writing the changelog, the website release note and the email release note, plus manually changing a bunch of things in the website PHP every time I do a release.
Okay, as you know I said that I will rewrite the Makefiles of cyrus imap to make use of Automake and I will do it (I hope really soon). I was working on 2.4, Bron said, that he wants the changes for 2.5, Jeroen said, that it is a good idea to manage the changes over Git, but I have not used git before. I hope soon to review what changed in the build process between 2.4 and 2.5 and move the automake files there.
Currently, the name of the project, the version and git version are fixed in Makefile.in:
PACKAGE = cyrus-imapd
VERSION = 2.4.13
GIT_VERSION = $(VERSION).git$(shell date +'%Y%m%d%H%M')
with Automake, the first two details can be moved to configure.ac:
AC_INIT([cyrus-imapd], [2.4.13],
[http://bugzilla.cyrusimap.org],,[http://www.cyrusimap.org])
I do not know, how git behind git.cyrusimap.org is currently set up, but I think some git-hook could be installed, that substitutes the version of those variables, when they are exported and new tarballs are made. This would simplify extra typing with new releases.
Greetings Dilian
<<attachment: dilyan_palauzov.vcf>>
