How to deal with workstation status mails?

Gunnar Wrobel wrobel at pardus.de
Tue Jun 3 14:15:07 CEST 2008


ITSEF Admin <itsef-admin at brightsight.com> writes:

> Hi all,
>
> I ran into a little snag with our Kolab set-up here - I can't figure out how 
> to "properly" deal with status mails that are sent automatically from our 
> workstations. What I want is to let e.g. cron (or some cron-run scripts) send 
> mail to the administrator to get feedback on the working (or not working...) 
> of things like updates etc. Right now, our Kolab server is set up to accept 
> only authenticated connections, hence, the "ordinary" way of sending these 
> automated mails fails with "Relaying denied".
>
> I *can* set up the MTA (exim) on the workstations to use authentication, but 
> that raises another problem: If I choose to authenticate as user A, I cannot 
> send mails as user B. Most of the scripts will try to send mail 
> as "root@". "root@", however, is a distribution list, so I cannot simply 
> add "root@" as a delegate to the account I use to authenticate with. Ideally, 
>
> So far, I see two options:
> - Remove the default "root@" distribution list and add an internal account 
> for "root@" instead. Set this account to forward all mail to the admin 
> account. Either use the "root@" mailaccount directly to authenticate or 
> add "root@" as a delegate to the account I'm using to authenticate.
>
> - Allow relaying for our own network. This, however, would allow anyone to 
> ignore the whole "delegates" idea by simply sending mail directly - which is 
> not what I want.
>
> My question is thus: How do other people deal with this type of situation?
> And also: Is there something like a "master account", i.e. an account that is 
> allowed to send mail as anyone after being authenticated, despite everybody 
> else having to adhere to the delegate system?
>
> Thanks for any input!

Does this snippet from the FAQ in the Kolab Wiki help?

  I want to allow local services (like Mysql, Cron or Backup) to send mails to local kolab-accounts 

In this case the tiny application "nullmailer" can be helpful. It has
very low dependencies and it´s easy to configure. You have to set
localhost as smarthost in the configuration and optionally you can
define an admin e-mail address which acts as local catchall. Thats
all. (debian: /etc/nullmailer/remotes, /etc/nullmailer/adminaddr).

Cheers,

Gunnar

>
> Cheerio,
>
> Thomas
> -- 
> ==============================================================================
>            Thomas Ribbrock             |   brightsight             
>            itsef-admin at brightsight.com |   Delftechpark 1
>            +31-15-2692529              |   NL-2628XJ Delft  	
>
> _______________________________________________
> Kolab-users mailing list
> Kolab-users at kolab.org
> https://kolab.org/mailman/listinfo/kolab-users

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




More information about the users mailing list