[SA-exim] Re: Bug#246715: sa-exim: network checks are failing
because headers are incomplete
Marc MERLIN
marc at merlins.org
Thu May 6 10:25:13 PDT 2004
[Cc Philip]
On Thu, May 06, 2004 at 08:01:47AM +0100, Tim Jackson wrote:
> Hi Marc, on Wed, 5 May 2004 19:21:53 -0700 you wrote:
>
> > On Fri, Apr 30, 2004 at 07:06:31PM +0200, Sander Smeenk wrote:
> > > Someone else wrote:
> > > > I discovered that the top Recieved: header (the one that is added by
> > > > Exim on my machine) is not being sent to spamc.
> > > Well, I remember something similar being reported recently about
> > > Exiscan on the exim4 mailinglist. Hmm. It could be...
> > I got a report that Exim 4.32 was modified to not send the last received
> > line to local_scan.
> > I have no idea why and it really sucks as far as plugins are concerned.
>
> The relevant ChangeLog entry (4.31) which explains the reasoning is:
>
> "66. The generation of the Received: header has been moved from the time
> that a message starts to be received, to the time that it finishes. The
> timestamp in the Received: header should now be very close to that of the
> <= log line. There are two side-effects of this change:
Thanks, I hadn't had the time to go through those yet.
> I can see the reasoning here (though that's not to say it was necessarily
> a good change), but it's unfortunate that the knock-on effect on
> Exiscan/SA-Exim wasn't predicted.
>
> Tom gets round it in Exiscan by generating his own temporary "fake"
> Received header before passing the mail to SA.
Yep, I now remember a mail from Nigel warning me of this.
This is annoying in Tom's case, but he can at least work around it because
he's directly inside the exim code.
As a local_scan plugin, I don't have the same access to the exim internals.
The worst part is that SA-Exim would now have to duplicate the exim Received
line generation code (and track it), but only run it if it's dealing with
a version of Exim that doesn't generate the last line in time for local_scan
so it'd have to somehow bypass the API and query Exim directly to find the
version number (I'm guessing it's possible, but...)
All this to say that I'd much rather that this unfortunate exim API change
be reverted, which in real life means that it becomes an option so that
local_scan plugins can get the original (wanted) behaviour again.
Philip, does that sound like a reasonable request?
In the meantime, I'm going to recommend that sa-exim users do not use
any version of exim past 4.30 until this gets figured out somehow
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f at merlins.org for PGP key
More information about the SA-Exim
mailing list