Hi Meaulnes, > But: isn't the Procmail bump message a bit too verbose? Why is the > full path of the user displayed?
There is nothing I can do about that. And you already get these kind of detailed error messages elsewhere. Like when a user is over quota or the vsite he belongs to is over quota: ----- Transcript of session follows ----- procmail: Quota exceeded while writing "/home/.sites/28/site1/.users/88/XXXXXX/mbox" 550 5.0.0 <xxx...@xxxxxx.net>... Can't create output > I would prefer that the message would read «no such user here». > Can I achieve this? I have to look at the whole suspension issue also from a "cost effectiveness" perspective in terms of execution time, service restarts and ease of undoing the changes upon unsuspension. A chown on a user directory costs me little. It's one command, finishes instantly and doesn't require service restarts. And it gets the job done. Setting a CODB object to remove the Email-Alias that maps "john.doe" to "jdoe" to remove any aliases that the user might have had? That costs, because it involves rewriting /etc/mail/virtusertable, a run of "newaliases" and a Sendmail restart. If we really would drop all aliases for suspended users, then what happens if you suspend a Vsite with 200 Users? You guessed it right: We run this in a loop for 200 times. Some users have more than one email alias. So figure between 200-500 edits of /etc/mail/virtusertable and at least 200 runs of "newalias" and Sendmail restarts. Which is totally unacceptable. The "newalias" and Sendmail restart would need to be taken out of the handler and put into something else that runs at the end of this mayhem. That breaks expected behavior for a couple of other functions and that "simple" fix turned into a major heart surgery. The easiest way to stop email delivery to a Vsite in general is to go to "Services" / "Email" of that Vsite and to tick the checkbox "Disable Email for Domain". Other than that: Bounces are costly for you as well. Someone SPAMs this user from fake sender addresses and your server bounces that email "back to sender", smacking an innocent bystander in the head. Or they sit undeliverable in your queue for several days until they get purged. There is also the option to just pass unwanted emails to /dev/null instead. I hear it's a good listener and doesn't talk back. ;-) -- With best regards Michael Stauber _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx