On Wed, Jan 21, 2009 at 1:28 AM, Timo Sirainen <t...@iki.fi> wrote:
> On Tue, 2009-01-20 at 23:18 +0100, Maciej Uhlig wrote:
> > Timo Sirainen:
> > > 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
> > 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
PostLoginScripting<http://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
