RE: [Exim] Sharing Experience

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: S. Yoder
Fecha:  
A: exim-users
Asunto: RE: [Exim] Sharing Experience
Responding to two replies in one email...

On Thursday, February 13, 2003 6:16 PM, Kirill Miazine wrote:
> S. Yoder wrote:

[snip]
> > users will ignore the warning message and I know that if I prohibit
> > receiving and a critical email is bounced I'll spend more time
>
> Critical email will be defred if user is over quota. For a while at
> least. Finally it will bounce.


Well, depending on how you have your retry rules set. [grin] In our case it would be better to bounce, if you assumed there was no way to do the prohibit send quota. Situation: Vendor sends time critical information to a user. User is over quota. If set to defer all sorts of phone calls ensue between the user and the vendor trying to figure out what happened to it (and more emails are sent). Then I'm called to find out what I did to "mess up the system" and have to go through the logs to find out the user is over quota (small company, I do many things besides IT). With a bounce the vendor gets the email back instantly and makes the call to the user. Now, unfortunately, I'm still called in to solve the problem, but it's a quick "What did the bounce say?". With a bounce less time would be lost (theoretically).

[snip]
> > So... is there anyway to do or add in the future something like:
> > quota_send = 50M
> > quota_receive = 80M
>
> It is possible to do, no need to add special options for that.


I knew there had to be a way, since it seems with Exim that most anything is possible. The problem has been wraping my mind around doing things this way or that. I managed to come up with a solution to another problem, which I'll include at the end.

[snip]
> How is mail stored? Mbox? Maildir? Cyrus' mailstore?


Maildir.

> Some generic option for quota_send is impossible to have.
>
> > Quota_receive would work just like quota does now. That's about the
>
> Why do you need a special quota_receive then?


I don't. I was just thinking that if something like quota_send was implemented then it might be wise to rename quota to quota_receive. Just to make it obvious the difference between the two. That's all.

On Thursday, February 13, 2003 6:11 PM, Nico Erfurth wrote:
> S. Yoder wrote:

[snip]
> This doesn't really fit into exim's way of handling messages, BUT! ;)
> You could create a router that acts like this.

[snip]
> getquota.pl should exit with 1 if the user if over quota and with 0
> otherwise. And you need to run sender verification on all mails.


That's the direction my mind was starting to stray. Guess it's time to dust off my limited perl skills. Luckily perl is a language I can grasp. With C all bets are off.

[snip]
> How about donating some money to run a two-day exim conference? :)))


Oh, I wish we had that kind of money. Just a small 10 to 15 person shop here. I'm trying to switch most of our stuff over to open source/GNU software. To which I know the authors do not live by 'thank you's alone.

Ok, here's a problem I had (or maybe I should say a feature I needed) and the solution:
For now we are going to keep our NT 4 PDC, so I'm using winbind to get user information. One problem with using winbind is if the server goes down Exim doesn't realize I want this to be a "defer" situation instead of a "fail". Now there is some caching going on, but I don't want to rely on that. I tried using smbmount and doing require_files, but it locks up if the NT server is down and doesn't work when it comes back up.

Here is how I check for the NT server and, if it is not up, I send a temporary error instead of an outright fail. If I had both a PDC and a BDC I would not worry about this, not to mention this solution can only check one server. I probably wouldn't use this if we averaged around say 100 emails per hour, but we average around 50 per day.

I created this router in the router section:

# A way to detect if the NT server is up or not
# so as to avoid winbind lookup problems.
server_down_defer:
driver = redirect
allow_defer
condition = ${run{/bin/ping -c 1 -w 5 -q 192.168.1.1}{no}{yes}}
data = :defer: Temporary server problem

Note: the '-w' option means 'wait for response' for x seconds. If you have a slow network, you might want to increase this. If you have a fast one, you can decrease it. The '-c' option means number of times to try and '-q' means quiet.

I would suggest placing it below 'domain_literal' and 'dnslookup' at the very least. After 'system_aliases' is fine as well, but remember that as soon as it hits this router it won't deliver. In my setup, where I have a 'shared_folders' router for Courier-imap, which is not dependant on a winbind lookup, my routers order looks like:
begin routers
# domain_literal:
...
dnslookup:
...
system_aliases:
...
shared_folders:
...
server_down_defer:
...
userforward:
...
localuser:
#end routers

This allows me to continue to accept what would go into the shared folders and use /etc/aliases to redirect to shared folders. Yet if the NT server is down everything else is defered. Since I don't have any local users on the Linux box I want to deliver to, this is not a problem.

Stephanie



--
mailto: yodersj@???