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

Inizio della pagina
Delete this message
Reply to this message
Autore: Bill Hacker
Data:  
To: exim-users
Nuovi argomenti: [exim] [OT] SPF ranting (was: Received-SPF, :spf_received: -> :at_start_rfc: ?)
Oggetto: Re: [exim] Re: Received-SPF, :spf_received: -> :at_start_rfc: ?
Axel Thimm wrote:

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


At the point 'something better appears' (or SPF gets a major revamp).. yes.

The current implementation has already been rather widely found wanting,
and efforts to agree something (allegedly) better (with MS 'contributing')
broke down, and even the working group disbanded itself.

Don't misunderstand - a 'workable' and spoof-proof way of universally
authenticating a sender would find happy adopters, myself included.

But even with a trusted, global 'big brother' database, (oxymoron?
SPF - as it stands - just isn't it.

>
> Anyway, the question was on _how_ to do it (properly), I didn't want
> to discuss pros and cons of the method itself.
>


Perhaps a review of the archives would be worth your time - there is
quite a lot there,
- IIRC around October 04 thru December 04 was the heavy discussion period.

Good luck with it...

Bill