Arvid Ephraim Picciani wrote:
> On Saturday 14 June 2008 19:38:09 Dave Evans wrote:
>> OK, so it was message 1K64UQ-0001VB-F6 that bounced. Please grep for that
>> in the main log too. Don't forget to go back through old log files,
>> assuming your logs are rotated, until you find the "1K64UQ-0001VB-F6 <="
>> line.
>
> /var/log/exim/mainlog:2008-06-14 16:06:34 1K64UQ-0001VB-F6 ==
> einkauf@??? R=spam_router T=spam_delivery defer (-6):
> mailbox /var/mail/catchall has wrong uid (1004 != 1010)
>
> aaaah! thanks alot!
>
> 1010 is "einkauf", which is the original receipient and 1004 is "catchall"
> i need those two different users or no pop server will read the files.
? I'm puzzled by that, but nevermind..
> so can i tell exim to ignore the user rights?
>
>
Hopefully not 'ignore'.. Rather either 'match' or 'manage' in a
predictable manner.
There are two (and a half) ways to go about making use of privileges:
- IF each user has a *n*x shell account & UID:GID (even if no usable shell)
-- THEN said UID *may* be switched to by router/transports, AND ALSO
(usually) by your POP/IMAP daemon. You *could* have a bespoke user for
'catchall', for example.
- The 'half' way is to make all such users also members of a common
group (ex: 'mail') that includes the daemons for Exim and POP/IMAP
(optionally post-smtp scanning and filtering daemons of the class that
need r/w to the mailstore).
Under either scenario, the 'group' r/w privs are enough to place
messages into mailstore, (Exim) and recover them (POP/IMAP).
This all presupposes that each daemon was originally invoked by root -
(the usual case if only so they can bind to the privileged ports
needed), then drops privileges and su's or chroots to the UID:GID under
which they run their daemons and any child processes.
Ergo they can (usually) still su to another UID:GID except, in Exim's
case, the fixed' never_users', usally root and the exim daemon itself,
optionally the POP/IMAP daemon and perhaps also the DB daemon if you run
one as well. The paranoid may add ALL daemon ID's to 'never users'.
The careful want to be sure their POP/IMAP daemon is comparably
well-behaved. Not all of them are, and webmail warrants even more care.
JMNSHO, but I don't believe in mixing shell users and MTA or POP/IMAP
identities. Safer and easier to handle by virtualizing *everyone* as far
as mail goes. Single point of admin, if nothing else, and usually safer
as far as protecting the rest of the box.
So - virtualizing:
- The MTA and POP/IMAP can each run under their own UID, but share (at
least one) GID - and neither UID nor GID need belong to any other system
user.
In this instance, the 'user' actually has NO direct rights to even his
own messages in mailstore. Instead, they rely on Exim or the POP/IMAP to
put and fetch those files on his behalf.
Upside is very simple management of rights.
Downside is you must be *very* careful that the login process is
end-to-end secure, and that particularly the POP/IMAP daemon is
configured and locked-down to insure that ONLY the storage area assigned
to a given user can be accessed with their login - and no other.
I.E - neither switching dirtrees, 'browsing', or ability to change the
path to the mailstore in any manner not set out in your user table or DB.
BTW - if using IMAP rather than POP, *even if ponly* fro a shared
function, it is a trivial exercise to shunt the 'quationables' that a
catch-all might intercept (hopefully not all-comers spam!) into a
bespoke 'folder'.
Each person of potentially 'very many' who is assigned the duty of the
day or hour, can have that ID as a supplementary IMAP account in their
MUA - same login and PWD for all hands.
IMAP sync and MUA settings that place a copy of 'Sent'messages in..<a
shared folder>) do the rest as far as insuring no message is left unread
by *someone*, and that any replies are visible to all.
Just what the Doctor ordered for an inquiries or support function or
where losing a message just because the sender's mx is not polite has
high value. Messy to do with POP, easy with IMAP.
Finally, Exim can happily mix and match not only POP and iMAP, but also
the above (and other) UID:GID schemes, AND ALSO use a mix of Maildir,
mbox, or DB-backed mailstore. That's part of the beauty of
router/transport sets.....
HTH,
Bill
