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 == > [EMAIL PROTECTED] 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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
