[Mimedefang] Integrating SPF...

[Mark]

> -----Original Message-----
> From: mimedefang-bounces at lists.roaringpenguin.com 
> [mailto:mimedefang-bounces at lists.roaringpenguin.com] On 
> Behalf Of David F. Skoll
> Sent: woensdag 30 maart 2005 0:20
> To: mimedefang at lists.roaringpenguin.com
> Subject: Re: [Mimedefang] Integrating SPF...
> 
> 
> Matthew.van.Eerde at hbinc.com wrote:
> 
> > I too would like to see a canned $Features{SPF}, with the guts
> > implemented in mimedefang.pl - of course, if SenderID wins, it's all
> > moot. :)
> 
> Another reason I'm reluctant to do this is that the Mail::SPF::Query
> module is supposed to be adding support for SenderID. Given the murky
> legal status of the SenderID patent, I don't want to put anything
> in MIMEDefang that might cause trouble.

Mail::SPF::Query is still considered the reference code for SPF
implementors.

There is no "adding support for SenderID" to it, as it does not work that
way. The 'query' calls to Mail::SPF::Query module take several parameters,
such as email address, HELO name, IP address, etc. The 'source' of the
email address is outside the scope of Mail::SPF::Query. Typically, and
according to the specs, the email address ('sender') is the MAIL FROM
entity (as received in the SMTP dialogue (or postmaster at HELO, in case the
former is empty).

You can feed Mail::SPF::Query any email address, of course, even something
taken from the mail headers, like the PRA (Purported Responsible Address).
Only in that sense could one misuse Mail::SPF::Query to try and do
Sender-ID.

There are no official plans, though, to make Mail::SPF::Query Sender-ID
compliant. We plan to add IPv6 support, though. :) And a better test-suite.

- Mark

Member of the SPF Council.