james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@collab.net>
Subject Re: James as a Mailing List Delivery Agent
Date Tue, 10 Jun 2003 01:08:43 GMT

I'm not on james-dev@jakarta, so please CC me if you want me to see the
response.

On Mon, 9 Jun 2003, Noel J. Bergman wrote:
> > Also, is the queue database transactional?  Are we sure if the system
> > goes down that we won't lose mail?
>
> We may not be able to guarantee that the message won't be sent twice, if the
> system happens to go down at the wrong time, but the message is not removed
> from the queue until after it is confirmed to have been sent.

That's the failsafe position, that's fine.  Better to have a failure mode
of twice-sent than never-sent.

[VERP]
> Yes, for each recipient we need a unique MAIL FROM.  But both RFC 821 & 2821
> permit more than one MAIL FROM per connection (for that matter, my mail
> client expects it).  We wouldn't save anything on the data transfer, but why
> not reuse the connection, and save the connection establishment delay, when
> the remote MTA permits it and there are multiple mail messages to transfer?
> What am I missing?

You mean reusing connections?  Yeah, that should save a little bit of
bandwidth and timing.  DJB's position has long been that persistant
connections are bad because they favor the busy senders, reducing the
chances that a host with just a few emails will find an open slot to get
through (the same way that non-real-time OS's usually don't allow a
process to exclusively lock system resources for very long).  E.g., if
apache.org has 100K emails to send to aol.com, and consumes all 50 of
AOL's allowed incoming connections, it becomes an exclusive lock for
awhile.  Dunno if that is a realistic concern.

Anyone looked at QMTP?

> > Is there some web-based means for admins to cruise through the
> > pending delivery queue?
>
> Not a one.  Something to do.  What operations would you like to see
> supported?  The probable solution will use JMX.

I'm thinking of a web-based way to inspect the list of messages
not yet delivered, the equivalent of running qmail-qread.  Maybe web-based
isn't needed, but about once a week I hear "I've not seen any messages
from the lists, where's my mail" in which case I run qmail-qread and find
messages for that user queued up because their MX host is down or
something.  Command-line tools are OK, web-based would be better,
especially if the delivery queue were in the DB, and I could see whether
there are any pending messages for a given address, for example.

I should avoid getting carried away here.

	Brian


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


Mime
View raw message