On Tue, 2009-01-20 at 23:18 +0100, Maciej Uhlig wrote:

...

What exactly are they? I guess a global file that is served as a message for all users? Right. With POP3 it is served once - after first user login after the message was placed in bulletin database (just a plaintext file in a

Timo Sirainen: directory, for instance).

...

That's more difficult to implement with IMAP than with POP3. You know better, but... just place incoming (bulletin) mail in INBOX.

Well, okay, I was thinking about a way to not duplicate the message to everyone's mailbox. And I guess with virtual mailboxes there's the problem that users can't then delete the message (or it gets deleted for everyone).

So what you want is a mailing list for your users without actually going through MTA. Shouldn't be too difficult to implement as a plugin I guess. You'd mainly just need to somehow keep track of what messages have been delivered to the user. You could maybe even implement this as a shell script with http://wiki.dovecot.org/PostLoginScripting although of course then users who have long running imap sessions won't see the bulletins until they reconnect.

On Tue, 2009-01-20 at 17:39 -0500, Charles Marcus wrote:

On 1/20/2009, Timo Sirainen (tss@iki.fi) wrote:

...

Well, okay, I was thinking about a way to not duplicate the message to everyone's mailbox. And I guess with virtual mailboxes there's the problem that users can't then delete the message (or it gets deleted for everyone).

A shared mailbox named 'Bulletins' that has unique seen flags would accomplish this... except for being able to actually delete them... no?

Or being visible to POP3 users.

Charles Marcus:

no?

Should work with both IMAP _and_ POP3.

Best regards,

MU

On Wed, Jan 21, 2009 at 1:28 AM, Timo Sirainen tss@iki.fi wrote:

On Tue, 2009-01-20 at 23:18 +0100, Maciej Uhlig wrote:

...

...

What exactly are they? I guess a global file that is served as a message for all users? Right. With POP3 it is served once - after first user login after the message was placed in bulletin database (just a plaintext file in a

Timo Sirainen: directory, for instance).

...

That's more difficult to implement with IMAP than with POP3. You know better, but... just place incoming (bulletin) mail in INBOX.

Well, okay, I was thinking about a way to not duplicate the message to everyone's mailbox. And I guess with virtual mailboxes there's the problem that users can't then delete the message (or it gets deleted for everyone).

So what you want is a mailing list for your users without actually going through MTA. Shouldn't be too difficult to implement as a plugin I guess. You'd mainly just need to somehow keep track of what messages have been delivered to the user. You could maybe even implement this as a shell script with http://wiki.dovecot.org/PostLoginScripting although of course then users who have long running imap sessions won't see the bulletins until they reconnect.

Just to chip in with my $2 cents... I used tpop3d for a long time before switching to Dovecot and we had Bulletins functionality using some perl hooks. Below is the perl script that Chris Lightfoot (R.I.P), provided for this:

<QUOTE>

#!/usr/local/bin/perl

use GDBM_File;

#Implementing POP3 server bulletins using tpop3d #$Id: README.bulletins,v 1.1 2003/08/01 12:11:38 chris Exp $

# At many large sites it is useful to be able to distribute a `bulletin' message # to all mail users. tpop3d can provide this functionality by having user login # trigger delivery of any outstanding bulletin messages via the onlogin # handler mechanism, as for POP-before-SMTP.

# This is new and untested functionality, but the basic idea is that you specify

# onlogin-child-wait: yes

# in tpop3d.conf, then write an auth-perl or auth-other onlogin action to handle # bulletin delivery. Here is a sketch of a perl subroutine that could be used # for this:

# onlogin_bulletins_handler REQUEST # Deliver any bulletins which are pending for the authenticated user # identified in the REQUEST. This subroutine is called by tpop3d, which # will set REQUEST->{local_part} and REQUEST->{domain} to the proper # values. Bulletins should be complete RFC822 messages stored in flat # text files under /etc/mail/bulletins, each with the extension .msg. # This function will use a GDBM database for each bulletin to record the # addresses of users to whom it has been delivered, so as to ensure that # each user receives only one copy of each bulletin. Bulletins are # delivered to user mailboxes using the local mail transport agent, though # this behaviour could be changed if required.

sub onlogin_bulletins_handler ($) {
my $req = shift;
my $resp = { };

# # Iterate over list of bulletins. # foreach my $bull (glob("/usr/local/etc/tpop3d/bulletins/*.msg")) { my $recips = $bull;

# Obtain and tie delivery database, creating it if it does not # already exist.

$recips =~ s/msg$/db/;
my $r = $req->{local_part} . '@' . $req->{domain};
my %rr;
tie(%rr, 'GDBM_File', $recips, &GDBM_File::GDBM_WRCREAT, 0600);

# Attempt delivery if this user has not already been sent a copy # of this message.

if (!exists($rr{$r})) {

# Invoke sendmail. There are better ways of doing this, but # this is simplest. Note that it wouldn't usually be safe to # call sendmail in this way, but tpop3d has already # authenticated somebody using the given local-part and # domain, so they're presumably safe strings.

 system("sendmail -oi '$r' < $bull");
 if ($? == 0) {

# Sendmail exits with code 0 on success.

 $rr{$r} = 1;
  } else {

# Sendmail (or system(3)) failed. There's not a whole lot # we can do here, but we log a message and abort sending # any other bulletins to this user for the moment.

 untie(%rr);
 return { logmsg => "sendmail failed; error code $?" };
    }
 }
 untie(%rr);

}

# Don't log anything in case of success; we might want to note how # many bulletins were delivered or something, of course.

return { }; }

</QUOTE>

The configuration end of tpop3d (tpop3d.conf) required the following:

# Enable authentication via an embedded perl interpreter. auth-perl-enable: true # auth-perl-start: perl code # Specify a line of perl code to be executed at startup. auth-perl-start: do '/usr/local/etc/tpop3d/bulletins.pl'; # auth-perl-finish: perl code # Specify a line of perl code to be executed when the authentication driver #auth-perl-finish: # auth-perl-apop: subroutine name # Specify the name of a perl subroutine which will be called when #auth-perl-apop: # auth-perl-pass: subroutine name # Specify the name of a perl subroutine which will be called when #auth-perl-pass: # auth-perl-onlogin: subroutine name # Specify the name of a perl subroutine which will be called after auth-perl-onlogin: onlogin_bulletins_handler

Perhaps someone can easily adapt that to Dovecot using PostLoginScriptinghttp://wiki.dovecot.org/PostLoginScripting . In worst case scenario, one could run tpop3d for POP3 and Dovecot for IMAP to get the functionality.

PS: tpop3d was licensed under GNU GENERAL PUBLIC LICENSE.

-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223

"The only time a woman really succeeds in changing a man is when he is a baby." - Natalie Wood