[BlueOnyx:22545] Re: suspending e-mail accounts

[Michael Stauber]

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 <XXXXXX at 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