Re: [exim] Maildir Quota excluding Trash folder.

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: W B Hacker
Ημερομηνία:  
Προς: exim users
Αντικείμενο: Re: [exim] Maildir Quota excluding Trash folder.
listrcv wrote:

> Philip Hazel wrote:
>
>
>>It's the sysadmin who creates the string expansions and presumably
>>controls the contents of lookups. Or am I misunderstanding what you are
>>saying?
>
>
> I'm not sure --- Exim offers so much flexibility that an admin setting
> these things up may either be unaware of possible security issues or may
> wish he had better means of setting limits that allow what he wants to
> do and at the same time keep things safe.
>
> It's hard to explain ... If I wanted to set up a kind of default
> filtering for mail from within the configuration of Exim, like
> delivering SPAM mails to designated folders, I would have to spent
> thought on the creation of such folders. I would find out that Exim can
> create the folders and try to choose a way that appears safe enough to me.
>
> That's fine for environments that don't need much complexity, but when I
> imagine more complex setups that maybe do different types of filtering,
> using lookups in SQL databases, with database content that can be
> administered by others, the story can take on such a great complexity
> that it becomes very hard to make it failsafe. That would make we wish I
> had good control on the creation of directories ...
>
> But I can be totally off because such a situation may be unlikely to
> occur, or there may already be sufficient control.
>
>
> GH
>


Two days ago I would have said there was little risk.

Then I did something intuitive, but wrong - and so documented:

- In a 'neatness' attack, I removed the blank line between the
end of an SQL lookup condition and the next line - which was:

maildir_create = yes

Puzzled as to why messages seen to have been delivered in the
~/mainlog I was tailing at the time were not showing up in my
inbox, I hit the storage directories with 'lynx'.

....And found that Exim had created, under the Maildir's
affected, a new subordinate Maildir with /new /cur /tmp, all
proper and Bristol-fashion.

...and had delivered the messages into:

~/{domain}/{user}/Maildir/Maildir_create = yes/new

There is no practical way to prevent mistakes like that and
still retain the flexibility needed. One just has to check
stuff...

The good news is that humans are not likely to be obsolete
anytime soon... Confused, maybe - but not obsolete..

;-)

Bill