Re: [EXIM] A looong list of comments/suggestions/requests.

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Philip Hazel
Fecha:  
A: exim-users
Asunto: Re: [EXIM] A looong list of comments/suggestions/requests.
On Wed, 25 Feb 1998, Peter Radcliffe wrote:

> I have, however, put together a long list of wishes and comments ....


It's funny. Always when I think "I've been working on developing Exim
for a couple of months. It must be time to start thinking about getting
a new release out" somebody sends me a loooong list... :-))

> A difference between the spec and reality:
> 'exim -qR<address>' fails - the actual format accepted seems to be
> 'exim -qR <address>'. This breaks the sendmail compatability (sendmail
> has no space there, as the spec says).


Oh, mutter. (I see that the spec does have a space for -R.) I do find so
much inconsistency in the way programs make use of command line
options...

> Suggestions:
> If an appendfile filename is /dev/null deliver to nowhere even if no
> user has been set for that delivery ? We had a few failures due to this
> until I changed them all to :blackhole:.


Problem: It forks the subprocess and sets the uid/gid before it runs the
transport. So this wouldn't fit easily in the code.

> Can we have in the log entry for the end of a -R queue run to have the
> -R string there, as the queue run start log entry does ?


Noted.

> Can exim log the IP address in reject log when rejected due to invalid
> HELO/EHLO ?


Already done in next release.

> Return the address sender verification actually rejected in SMTP and
> rejectlog errors ? I've spent a lot of time in the last few weeks working
> out what exim actually complained about in headers in reject logs
> (either in the bounce message, or marking all the rejected addresses in
> the rejectlog).


Not sure what you are actually asking for here. What I *have* done for
the next release is invent a new option called -bh to which you give an
IP address. It then goes through the motions of "accepting" a message
from that address (with you typing the SMTP) and in addition to SMTP
responses, it outputs comments about what tests have failed. This is
something which could probably be developed further once I see how it
goes in practice.

> exim -Meb runs the editor as the exim user in my configuration, since
> I run exim as the user 'exim'.
> This breaks my personal configuration for emacs (the editor I happen to
> use) and the X authentication. Can it be changed to (assuming exim is suid)
> run the editor as the user ?


Only makes sense if the user can read *and write* the spool files.

> I'd suggest changing delay example to:
>   delay_warning_condition = "\
>     ${if match{$h_precedence:}{(?i)bulk|list|junk}{no}{yes}}"
> 'junk' is quite commonly used as well as bulk and list.


Noted.

> An option for eximstats to display a summery of relayed messages (delivered
> X messages to/from domain N) without all the details.


Noted.

> A full eximstats on a day's relaying is really silly :)
>
> The build scripts make no differentiation between 2.5.1 and 2.6 Solaris.


We are still on 2.5.1 round here. Thanks for the warning.

> Can we have command line options for exim or a support script to display
> the message body, headers and log.


Isn't that just

cat /var/spool/exim/input/<message-id>*

? (I see your point about where the spool is, but this is *so* simple to
set for yourself...) Actually, I wouldn't use cat - big messages...

> I really, really want lockfiles on queue runs so you can only have one
> queue run running for a particular string at any given time.


Noted.

> Bug:
> Start eximon with no queue entries, wait until something appears on the
> queue, shift-click item on the queue (don't do anything to it) and release,
> wait until queue is empty, shift click on empty queue. eximon hangs solid.


Will investigate.

> Oddities:
> exim doesn't seem to be sending EHLO out even when the other end has
> advertised ESMTP, in many cases ... any suggestions for what I should be
> checking to debug this ?


Nothing. I've just, this very day, added code to make it send EHLO if it
sees "ESMTP", and take some notice of SIZE. There didn't seem any point in
sending EHLO when it wasn't going to make use of what came back, and
when, prior to the "ESMTP in the banner" convention, you had to play
lots of nasty games to cope with broken old MTAs.

> When doing delivery for the same domain in a queue run uses individual
> connections - why ? Might this be related to the HELO/EHLO comment above ?
> In my reading the spec it should check the hints database to see if there
> are any waiting deliveries for the same host once one delivery has suceeded ?
> Might it be because they are for a different MX record host ?
> (I'm seeing this on domains that have only one MX record below our relays,
> though :/ ).


How did the messages get on the queue? If it was with -odq or
queue_remote or something, the routing won't have been done, so the
waiting database won't have been updated. Only if you used queue_smtp,
or the messages previously failed, will it know which hosts they are
for.

The next release has an option to cause queue runs to happen in two
stages: first it goes through and routes everything (and updates the
hints) and then it does actual job. This is intended for intermittently
connected hosts that use queue_remote when not connected.


-- 
Philip Hazel                   University Computing Service,
ph10@???             New Museums Site, Cambridge CB2 3QG,
P.Hazel@???          England.  Phone: +44 1223 334714



--
*** Exim information can be found at http://www.exim.org/ ***