Hi. Am Donnerstag, 1. November 2007 schrieb Enda Cronnolly: > Funny, I've had "unavailable" mailboxes on my system and they didn't bounce > immediately like that, merely got deferred. I presume they would have > bounced eventually if I hadn't been keeping an eye on the logs.
You have had mail to 'user-foo' without a file named .courier-foo or .courier-default (or any appropriate alias-magic) and it did not get bounced but locally deferred? I don't talk about maildrop or filter-stuff but only plain delivery based upon .courier-files. The regular way is (AFAIK): courier accepts mail, the courierlocal-process does SetUID to the user (and then can read the homedir) and then decides to deliver or bounce the message. > > What exactly does a nightly or hourly cronjob fix in this situation? > Well, run as root you can reset the privs :-) Yes, from time to time. But if just about a minute is enough to cause trouble, such a cron job will always be too late (and IMHO a crappy solution). > > As this user also blocked access for the web server, I think this was an > > accident. But whatever I tell him, that does not mean that he does so. :) > Simple, his actions are causing problems for everyone, so the solution is > to cause problems for him. Delete his mail access until he puts it back. > While people won't always listen, they do learn from mistakes when there > are consequences, and he can't moan about it because his actions are > causing problems for everyone. That's _exactly_ what I suggest: Don't accept mail for a user that locks out the esmtp-daemon's useraccount (until he fixes the issue). This is not possible atm, is it? > > In the modern Internet, bounces should be avoided wherever possible, I > > think. > > This was differend decades ago, when QMail was modern, but things have > > changed. > Bouces for non existent mailboxes, yes, but if there is a local delivery > problem, the mta can try over and over again, and after a period of > failures can resolve that its unable to deliver this message and then > bouncing is highly appropriate in any aged internet. What has that to do with this? Bounces about local delivery problems not realizable whilst the SMTP dialog, sure, they are perfect and the only way to go. But: Bounces for non-existent mailboxes should be avoided. That's what I said. Nothing else. > > So my real suggestion would be that courier never accepts anything that > > possibly cannot be delivered. I can think of setups where user mail > > should not have access to all home folders, so I suggested an option. > Heh.... so a user can't edit their mailfilter file without locking it, or > else run the risk of not having their mail accepted. Thats a dumb > suggestion. I don't get it. Perhaps there is a chapter that I did not look at 'till now (maildrop filters), but in a scene with only .courier-files around, this situation should not occur. On the other hand: When it's right what you said, does courier accept all and every message for a user if his maildrop-filter is locked? I said, I did not look at maildrop filters, but this seems to be the same problem. I think mail should be temporarily rejected whenever courier does not know if there's a destination for the message. > I don't see why you'd loose features in a virtual setup, you can link the > remote maildir location to the users account and have it viewed as a local > without the user being any the wiser or the user having the ability to > change the privs. Either the user can control which addresses do what (.courier-foo calls a spamfilter, .courier-bar calls a mail-processing binary from OTRS, ...) *AND* has the ability to break things up or he uses virtual accounts (predefined features, a mailbox per address, things like that), no matter where the actual maildir is located. It's the .courier-files, that makes it so powerful. > You'll be implementing a bug which will cause you BIG problems. But hey, go > for it. I still don't think so. cu, Bernd -- Es genügt nicht, keine Meinung zu haben. Man muß auch unfähig sein, sie auszudrücken
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
