Bernd wrote:
> Yes, that's my current setup.
> As I said, it's kind of a race condition.
> - User breaks it
> - spammer spams
> - courier bounces
> - spamcop lists us
> This procedure takes less than a minute and is sufficient for being
> blacklisted for 24 hours.

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.

I presume that you're using courier to check the spam blacklists and reject 
spam from known spammers? Thats got to reduce the probability of this 
happening dramatically.

> What exactly does a nightly or hourly cronjob fix in this situation?

Well, run as root you can reset the privs :-)

>> 1) I don't think this is a huge problem, so the solution is, when it
>> happens, explain to the user that if they want 700 privacy then to do
>> it on a sub folder of their home directory if they want mail also.
>
> 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.

> I just can't get why courier accept everything by default (with "by 
> default" =
> if nothing else can be figured out). QMail sucks for about 10 years 
> because
> of that problem. Courier fixes this *IF* user mail has correct permissions
> but not if they're wrong.

Courier doesn't accept everythign by default. If the domains that don't like 
receving the bounces from forged addresses which were addressed to a 
legitimate local account, then its up to them to implement SPF to resolve 
that issue. It is perfectly valid to return bounce messages when 
appropriate, and if that is being returned to a forged address, then resolve 
the ability for anyone to forge addresses at your domain.

> 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.

> 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.

>> 2) If it is something that occurs frequently and is most annoying,
>> switch to a setup where the mailboxes are stored outside of the users
>> homedirectory, ie, twig the system so that authtest's home directory
>> output isn't your users homedirectory and build their mailbox in this
>> remote location at account creation time.
>
> That would mean that I throw away half of courier's core features. 
> Obviously,
> the reason why I've choosen courier as MTA is this feature to give the 
> users
> all delivery-possibilities that they don't have on just another webhosting
> account.

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.

> Well, if noone supports this suggestion, I think my hourly cron-job is the
> best solution for the moment. Perhaps I will have a look at the code if 
> this
> is fixable locally.

You'll be implementing a bug which will cause you BIG problems. But hey, go 
for it.

 -Enda. 


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

Reply via email to