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

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: exim-users, Nigel Metheringham
Subject: Re: [EXIM] A looong list of comments/suggestions/requests.
On Wed, 25 Feb 1998, Peter Radcliffe wrote:

> Thats why I sent the list now, so some things might make it into the
> next release :)


You just made it under the wire...

> > 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: ?


On Wed, 25 Feb 1998, Nigel Metheringham wrote:

> Looks like right up in the generic stuff you would be doing things
> like
>    if ((transport == appendfile) &&
>        (local_part == "/dev/null"))
>        blackhole();


Something similar occurred to me last night (in fact I think there is a
better detailed check, but in principle the same). This would catch the
cases where aliases or forwardfiles generated /dev/null. It would not
catch the case where appendfile had file=/dev/null (maybe generated from
some lookup) but I think it would be useful and I'll see if it can
easily be done.

On Wed, 25 Feb 1998, Peter Radcliffe wrote:

> 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.


Indeed not. This is failing because of problems in the headers, not in
the envelope.

> I'd like the logged headers to be marked in some way to show exactly
> which header caused the rejection.


In that particular case, it is *all* the "sender" headers (From,
Reply-To, Sender), since the check has failed to find a verifible sender
in any of them. I suppose I could replace "message headers" with "From,
Reply-To or Sender headers".

> The file could be chowned to the user first, or copied and then coied back


Would require retaining root privilege. Exim current gives it up
permanently when doing these operations.

> 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.


Noted.

> 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).


Hmm. That *should* cause the hinting stuff to work, provided Exim can route
the messages when the customer machines are not connected.

On Wed, 25 Feb 1998, Nigel Metheringham wrote:

> [how often do you edit messages - I must admit I have *never* used this]


Regularly. User on PC configures sender address incorrectly, but not so
badly that it doesn't validate. Message fails. Error report can't get
sent back. I edit the recipient and put a note in the body.

> Need to be careful. There are still boxes that curl up and die when
> they see this - hence the convoluted code in smail (if other end dies
> when you say EHLO then reopen connection immediately and only use
> HELO).


Yes, but this should not happen if the other end says "ESMTP" in its
greeting line, and Exim now sends EHLO *only* in that case. I didn't
want to have to bother with the convoluted code.

> [Has anyone noticed my domain - good-thing.tm ??]


You've moved to Turkmenistan?

-- 
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/ ***