Philip Hazel <ph10@???> probably said:
> 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... :-))
Thats why I sent the list now, so some things might make it into the
next release :)
> 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...
Agreed on that one.
> Problem: It forks the subprocess and sets the uid/gid before it runs the
> transport. So this wouldn't fit easily in the code.
Not even as a special case a'la :blackhole: ?
> > 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
I wasn't very clear.
I'm talking about header verification, and the case of denying a message
because one or more headers are invalid but nothing clearly telling you
_which_ header was invalid and caused the rejection.
> 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.
This would obviously let you test later what gives a problem, but I
meant more information in the existing rejectlogs.
An example:
------------------------------------------------------------------------------
1998-02-25 00:09:03 0y7Z5b-00004V-00 rejected from agranat.com
(firewall.agranat.com) [198.113.147.2]: can't currently verify any
sender in message headers (please try again later): return path is
<ezdiet@???>
[headers]
------------------------------------------------------------------------------
In some cases the return path mentioned here is not the address that is
causing the address to fail.
I'd like the logged headers to be marked in some way to show exactly
which header caused the rejection.
> > 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.
The file could be chowned to the user first, or copied and then coied back
(but that doesn't make much sense for huge messages ... so don't edit
huge messages :)
> We are still on 2.5.1 round here. Thanks for the warning.
I'm running exim for production on 2.5.1, but have it running (and delivering
mail for me personally) on 2.6 with no problems.
> cat /var/spool/exim/input/<message-id>*
If you don't have split_spool_directory on.
> ? (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 use a script that calls $PAGER and takes the letter out of the message
id for the sub directory.
Yes, this is simple, but when you do it on 30 or 40 messages in a row
on a machine where the spool is just too big to use eximon (because it
is _not_ optimised for large spool machines. Hangs for a long time every
time the queue updates) you rapidly want to automate it.
> 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.
Fair enough.
> 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 messages get on the queue because our relays are backup mx records
for many many customer machines, lots of which are intermittently
connected that then connect and start a queue run (either by ETRN or
a finger command running exim -R domain).
> 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.
That sounds very useful ....
Thanks,
Peter.
--
Peter Radcliffe | pir@??? | Shore.net systems administrator.
--
*** Exim information can be found at
http://www.exim.org/ ***
