[exim] Re: Received-SPF, :spf_received: -> :at_start_rfc: ?

Top Page
Delete this message
Reply to this message
Author: Axel Thimm
Date:  
To: Bill Hacker
CC: exim-users
Subject: [exim] Re: Received-SPF, :spf_received: -> :at_start_rfc: ?
On Sun, Feb 27, 2005 at 06:10:53PM +0800, Bill Hacker wrote:
> Axel Thimm wrote:
> > the exiscan spec was suggesting to use
> >
> > warn message = :spf_received:$spf_received
> >
> > "Exim introduced selectable header positions in Version 4.43.
> > One option allows you to add your header after all Received:
> > headers. For optimal SPF draft/RFC2822 compliance, exiscan-acl
> > adds one other option, called "spf-received". It adds your
> > header before the first header which is NOT Received: or
> > Resent-*:, seen from the top of the header stack."
> >
> > :spf_received: seems to have gone in 4.50, but there is
> > :at_start_rfc:, which seems to add "immediately before any line that
> > is not a Received: or Resent-something: header."
> >
> > This looks even correcter to me (skipping Resent-* headers as well).
> >
> > So, is
> >
> > warn message = :at_start_rfc:$spf_received
> >
> > the new suggested method of adding Received-SPF?


> Possibly the most commonly suggested method of using SPF seems to be
> 'not at all', or at least 'only with specific correspondents, and
> then only with customization' (and a grain of salt?).
>
> Aside from lack of universality, implementation variances, and
> several known cases of major ISP's with downright *useless*
> implementations, SPF simply does not / cannot do what was intended
> consistently and securely. Not even on good days.
>
> Best left alone until something better appears *AND* sees thorough
> testing, debugging, and wide adoption.


Well, isn't adding a header on SPF results exactly what you are asking
for, testing and debugging?

Anyway, the question was on _how_ to do it (properly), I didn't want
to discuss pros and cons of the method itself.
--
Axel.Thimm at ATrpms.net