This one time, at band camp, Mike Bird said:
> On Sun, 2006-04-30 at 16:31, Stephen Gran wrote:
> > This one time, at band camp, Mike Bird said:
> > > You are arguing against providing a safety net. We hold inbound
> > > messages in a queue for several days (space permitting) just like
> > > outbound messages. This is an added-value service which helps to
> > > prevent people from losing email when some twit has filled their
> > > mailbox and someone else is sending from an ISP with a retry
> > > timeout less than a typical human's sleep cycle.
> >
> > The sender gets a DSN saying "Sorry, your mail didn't get delivered"
> > either way, right? Do you really think that creating the bounce
> > message yourself is better in some way than having the sending MTA
> > create it?
>
> Yes, because our timeout is longer than that of some ISPs. Some ISPs
> are using two or four hour timeouts. I'd rather not have to tell our
> clients that they need to wake up every 90 minutes and empty their
> mailboxes to avoid losing messages.
And you attempt to ameliorate every brain dead MTA on the planet? I
feel very sorry for you.
> > > > Creating backscatter because you can't configure your
> > > > organizations mail spool so that the left hand knows about the
> > > > right hand is still bad form.
> > >
> > > This thread has already mentioned numerous cases where backscatter
> > > is unavoidable. Please post your Exim config which handles such
> > > cases without backscatter. If it's that good, I'll even switch
> > > our combination of Postfix, QMail, and custom SMTP code over to
> > > Exim.
> >
> > Since exim can do arbitrary lookups in a number of backends, it
> > would be trivial to store quota information in sql, ldap, flat files
> > or cdb on shared storage, or whatever other signalling mechanism you
> > can think of to communicate state. As for config file snippets, the
> > first hit on google for 'exim quota sql' takes you to a discussion
> > of how to implement it. I look forward to another qmail
> > installation disappearing. It seems to be one of the primary agents
> > of backscatter spam on the public internet.
>
> If Exim can do it then so can a Turing machine. Claiming that a
> solution exists is not the same as providing a solution.
Pointing to an answer to your question is roughly equivalent, however.
I can't help you if you're unwilling to do some research and think out
the basic design issues, or at least I won't help you without the
standard consulting fee my company charges for setting up things like
this.
> We're look forward to seeing your Exim config that avoids all of the
> potential causes of backscatter previously identified in this thread.
> Then we'll see if the reduced performance and/or functionality are
> worthwhile tradeoffs.
So far, the backscatter you are attempting to justify is beacuse the
front end has accepted a message that the backend doesn't like, either
due to unknown address, quota, or content. User verification is trivial.
Content scans properly belong on the front end, and if your backend is
rejecting spam that the front end has already accepted, you've got a
broken design. Implementing quota is slighlty more complicated, but
not by much.
How do you want to implement the quota signalling? Shared storage? SQL?
LDAP? DNS? I suggest if you're serious, send an email to exim-users
asking for help with your environment. You'll find there are almost as
many ways to fix it as you can think of.
That being said, the simplest is an acl of the form:
defer
condition = ${if eq ${USER_OVER_QUOTA}{yes}{no}}
message = Over quota
And a one line addition to the standard delivery router for your users
of the form
condition = UPDATE_QUOTA_INFORMATION
Where USER_OVER_QUOTA and UPDATE_QUOTA_INFORMATION are macros that
handle querying and updating depending on the backend you've decided on.
Admittedly, there is a small race condition where the front end can
successfully run a query before the back end has finished the update, and
so a user can go over quota and get one more message. But again, your
current arrangement would have accepted all such messages, so accepting
one message is hardly more of a burden. If you want to be idempotent,
your UPDATE_QUOTA_INFORMATION macro should include a lock on the data, so
the front end can't query mid update, and will have to wait for the lock.
If you can be more specific about which backend you'd like, I am happy
to help you with your problems (although I suspect the people on
exim-users will be more knowledgeable than I am). If you want me to
design an MTA farm for you, then you'll have to call me on my work
number.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature