[SA-exim] Re: Bug#246715: sa-exim: network checks are failing because headers are incomplete

[Ross Boylan]

On Thu, May 06, 2004 at 09:25:13AM -0700, Marc MERLIN wrote:
> [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

Just to add another layer to this: all my mail from outside comes
through another system.  For that reason (among others) I haven't been
using any RBL tests.  I just realized that the behavior of omitting
the first received line actually means I could do RBL on the IP that
sent the message to the forwarding system.  I think.  I guess this
means that SA-Exim RBL tests would be effective, but exim ACL's would
not.

This perhaps suggests that, in general, the ability to recognize the
first "outside" address might be useful (though if that could be
spoofed, a bit risky).  Even if it's a good idea in principle, it may
be excessively baroque.  Just a thought.

I know in a perfect world the other system receiving my mail would
take care of everything.  But it's running sendmail, so I can't expect
too much :)