spam reporting over IMAP, release process / Re: FOSDEM Report - Saturday
dilyan.palauzov at aegee.org
Thu Feb 9 19:30:40 EST 2012
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
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
> - 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:
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 380 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20120210/a5fc5e8e/attachment.vcf
More information about the Cyrus-devel