mqueue.in and mqueue

[paddy]

Chris,

My apologies for being a bit flip, and thanks for being so understanding.

On Thu, Jan 27, 2005 at 02:27:54PM -0500, Chris Conn wrote:
> >
> >I should have so much RAM :)
> >
> >If you're happy running your mail spool on a tmpfs (not that I'm
> >encouraging you, mind you) why not put mqueue there as well ??
>
> Actually, I already do =)
>
> Only problem is when you want to reboot the box.  And you have to keep a
> close eye on free RAM since if someone were to hose the box with email
> it could theoretically be a problem.  It has not even come close so far,
> but still.

You could look at the various throttles to limit incoming traffic.

> From what I read here, I might as well put it back on disk since
> consensus seems to be that the allocation table is modified and no
> actual copying of files occurs.

It's efficient, given that having it on disk is about reliability.
I would worry that VM/swap type arrangement would not scale as well
as an explicit write to disk, assuming you're going to write to disk in
the end, because the move would not then be cheap.

> I will look for other methods to make
> things more efficient.
>
> Thanks for the info,

As I understand it, the usual worry with the configuration you describe
is that you might lose the mail.  Since losing the mail is generally
considered to be the worst thing you can do, the idea is to avoid it.

When your mta (sendmail?) receives the mail, it can write it to disk
before it finally says "ok, i've got it".  Obviously no medium is
entirely safe, but ordinary RAM is called 'volatile' for a reason.
In the event of a crash, where is the mail ?

These considerations may not apply to your setup, but if they do,
then the above is the answer to "why not?".

I would imagine that you might be able construct a system that keeps the
sender waiting as long as possible in the hope of passing the mail
along to someone else without having to write it to disk, and _only then_
confirms receipt to the sender, but I don't know about the following
sequence:

  Sender: mail ... rcpt ... data ... blah,blah,blah ...
          . (the dot on its own!)
  Server: (goes and delivers to next recipient gets a 2xx)
  Sender: hangs up before Server can send 2xx
  Server: now what ?

Simply taking delivery seems like a simpler approach.

I saw the slashdot of coyotos, the successor to eros, go past the other
day, so that kind of thing is still fresh in my mind.  Its interesting
to think that rather than blocking on a specific write, you could
just block on the next system checkpoint, and that if stages further
down the pipeline complete in the time available, then you get that
"for free".

Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall

------------------------ MailScanner list ------------------------
To unsubscribe, email jiscmail at jiscmail.ac.uk with the words:
'leave mailscanner' in the body of the email.
Before posting, read the MAQ (http://www.mailscanner.biz/maq/) and
the archives (http://www.jiscmail.ac.uk/lists/mailscanner.html).

Support MailScanner development - buy the book off the website!