[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: master's mail backlog and upgrade time

On Sat, Nov 19, 2005 at 01:56:25PM -0500, Stephen Frost wrote:
> * Ian Jackson (ian@davenant.greenend.org.uk) wrote:
> > So if I have my system say `250' to a piece of mail, I'm guaranteeing
> > that either I'll bounce it (and get a `250' on the bounce), or that
> > some human (me or someone else I know) will read it.
> Sure, so say '250' and then bounce it if you want to later.  That's
> basically the *point* here.  master's forwarding the mail for you, you
> should accept it

No, that's not what you should do.

I don't want to accept any random crap that a forwarding host might send
me just because I asked it to forward mail for me; my resources (in the
form of bandwidth, processing time, and disk space) are limited, and if
a mail is more than obviously not legitimate (i.e., because the envelope
from doesn't even exist), then *I* don't want to spend more CPU time,
disk space, or bandwidth handling the message; I'll just say "thanks,
but no thanks". If that creates problems for master, and there are ways
to avoid those problems (other than by creating more problems for my
systems) then I'll happily implement those; but you won't force me to
accept any random crap you might send me just because your policies
aren't strict enough.

To push your example to the limit, you're suggesting that I should
accept whatever master sends me -- even if that would result in it
sending a constant stream of data to my home server of, say, 100Kbit/s.
To accomodate for such an amount of data, however, I'd need to upgrade
my mail server's disk, processor, and my home Internet connection --
which I'm not willing to do.

Granted, the above example is over the top; but it doesn't even have to
be that extreme. I'm currently nearly out of disk space on my main mail
server; the extra amount of mail that dropping SMTP-time checks would
result in would probably make my mailserver's disk overflow--and I don't
want to buy another hard disk just yet.

> and then you can decide to either read it yourself or
> bounce it.  You do *not* need master to bounce it for you!

If master accepts a mail, it should be prepared to bounce it if the mail
wasn't legitimate after all. If it isn't prepared to do so, it shouldn't
have accepted it in the first place!

> > The only practical solution to this problem in the modern environment
> > is to never accept mail that you don't want.  Unfortunately master's
> > policies make it impossible for me to arrange to do that.  I can do
> > what I can, though, and try to push the problem closer to the place
> > where it can be solved.
> Blacklisting obviously has its own problems.

There are many more ways to rejecting mail at SMTP time than to start
blacklisting; additionally, provided one uses a serious blacklist,
blacklisting isn't likely to result in blocking one's own forwarding

.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/

Reply to: