Let me put out a proposal here...
But first, some background.
My site runs several mailing lists. Everything works just fine.
The problem comes up, quite regularly, with several subscriber
sites. To put it simply, they are either very badly configured
or the admin staff hasn't graduated yet (these are invariably,
but not always, *.edu sites).
The more glaring example is a subscriber who apparently receives
mail on a desktop machine. From looking at the mail logs, it
seems that machine is turned off outside of regular local business
hours. From what we've been able to figure out, there are no
MX records outside those of the admin staff (we think that's who
it is... it could be a clueful student/employee...). They seem
to understand A records, and that's about it.
What happens with the mailing list traffic, is that things land
in the retry queue, until that particular desktop machine gets
turned on at the start of the day. Then the backed-up email
starts to flow normally until the end of the day.
To avoid spending useless effort in trying to connect to a machine
that isn't there, and slowing down (slightly) other email processing,
it would be very useful to have some means to bracket the retry
times. The normal retry mechanism doesn't seem to be capable of this.
So, the proposal...
Borrowing an idea from MMDF, having traffic for particular sites
be queued up until explicitly processed by a queue runner cron job.
>From what I can tell of exim, this would require something that
I'll describe as a defer-smtp transport. The regular domainlist
router would feed the transport. When a message is to be sent to
one of these problem sites, the router gives it to the defer-smtp
transport which simply drops the message into a queue without any
additional processing. The defer-smtp transport could be given a
name, akin to an MMDF channel. Then a cron job kicks in, say at
9:30am in the timezone for the problem site, and runs that defered
queue name as a normal smtp transport. This continues until 14:30,
Monday thru Friday. Don't even think about connecting on weekends.
If there are any problems encountered, they don't retry, but a
simply returned to the defered queue. After some length of time,
or number of queue runs, there should be some manner of timeout,
and the message bounces.
It's possible to kludge something like this using a pipe transport
with bsmtp feeding a standalone specially configured exim that is
run on a cron. I haven't tried that yet, though it seems to be
making its way on my list of things to do.
Comments?
--
Randall Raemon
rlr@???
--
* This is sent by the exim-users mailing list. To unsubscribe send a
mail with subject "unsubscribe" to exim-users-request@???
* Exim information can be found at http://www.exim.org/
