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