spam reporting over IMAP, release process / Re: FOSDEM Report - Saturday

[Дилян Палаузов]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dilyan_palauzov.vcf
Type: text/x-vcard
Size: 380 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20120210/a5fc5e8e/attachment.vcf