[milters] Archive

Lists Index Date Thread Search

Article: 1782
From: Anthony Howe
Date: 2007-10-15 04:52:26 -0400
Subject: Re: Header placement for milter-spiff

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support
--------------------------------------------------------

Jim Hermann - UUN Hostmaster wrote:
> Is there some way to move the Received-SPF: Headers to above the Received:
> Header?

No. RFC 2821 section 3.8.2 "Received Lines in Gatewaying" says that 
Received headers are always prepended to the message. Sendmail handles 
that the prepending of headers AFTER any milter modifications, therefore 
a Received header will come before added Received-SPF.

> Otherwise, Mail::SpamAssassin::Plugin::SPF does not recognize the
> Received-SPF: Headers as being Internal Headers.

Report this as a bug to SpamAssassin.

> According to http://www.openspf.org/RFC_4408#header-field
> 
> "The Received-SPF header field is a trace field (see RFC 2822 Section 3.6.7)
> and SHOULD be prepended to the existing header, above the Received: field
> that is generated by the SMTP receiver. It MUST appear above all other
> Received-SPF fields in the message."

It is my view that RFC 2821 has historical precedence and has a stronger 
MUST requirement and that the most recent Received header will be first. 
Resent header blocks are also prepended and might by interleaved with 
Received headers RFC 2822 3.6.6 "Resent Fields". Would SpamAssassin 
handle multiple Received-SPF headers when interleaved with Received 
headers and Resent header blocks? Bet it breaks.

> Also, FWIW, milter-spiff is ignoring the Maximum DNS-interactive terms limit
> which defaults to 10.  

Correct. It does a circular reference detection instead. From the source:

	/* Circular references with include: or redirect=, see
	 * budgetdialup.com and expedia.com. Ignore already visited
	 * entries.
	 *
	 * The SPF Internet draft in section 10.1 places a limit
	 * on the total number of DNS lookups at 10 after which
	 * PermError should be returned. By returning Neutral for
	 * already included/redirected domains, we can allow the
	 * remainder of the mechanisms to be processed.
	 *
	 * Consider the following case:
	 *
	 * example.org says my users might be roaming on foobar.net
	 * foobar.net says their users might be roaming on example.org
	 * where both are legit.
	 */
	qualifier = SPF_NEUTRAL;

This behaviour was requested by Derek Balling and discussed with Meng 
Weng Wong very close to the finalising of the RFC. I agree with Derek's 
reasoning about two or more different domains, under different 
management, might specify one another as a source of their mail. As I 
recall Meng concurred that this behaviour (roaming agreements between 
networks) hadn't been considered and would be useful. Derek might be 
able to recall in more detail the conversation. However, since the draft 
was so close to being approved, Meng opted not to delay it any further 
as it had been dragging on for a long time.

> According to
> http://search.cpan.org/src/JMEHNLE/Mail-SPF-v2.005/lib/Mail/SPF/Server.pm

Mine is an independent implementation of the spec. with one or two 
deviations. For example the other deviation is:

	switch (DnsGetReturnCode(dns)) {
	/* This result code is not to spec. but treats
	 * broken DNS servers as Neutral (not None),
	 * instead of TempError. This allows include: of
	 * non-exsistant/broken domains to be ignored.
	 */
	case DNS_RCODE_SERVER:
		qualifier = SPF_NEUTRAL;
		break;

> =item B<max_dns_interactive_terms>
> 
> An I<integer> denoting the maximum number of terms (mechanisms and
> modifiers)
> per SPF check that perform DNS look-ups, as defined in RFC 4408, 10.1,
> paragraph 6.  If B<undef> is specified, there is no limit on the number of
> such
> terms.  Defaults to B<10>, which is the value defined in RFC 4408.
> 
> A value above the default is I<strongly discouraged> for security reasons.
> A
> value below the default has implications with regard to the predictability
> of
> SPF results.  Only deviate from the default if you know what you are doing!
> 
> For example, try ebay.com at http://www.kitterman.com/getspf.py

The reference SPF record generator used during development was the 
original one provided by Meng via pobox.com or someone on the SPF 
mailing list several years ago and is now found here:

	http://old.openspf.org/wizard.html

> SPF records should also be published in DNS as type SPF records. This is new
> and most implementations do not support it yet.

SPF resource records (code 99) have to be supported in DNS 
implementations and supporting tools, such as Bind, dig. Such changes to 
infrastructure take a long time to roll out. At the time I couldn't even 
test SPF RR and not even sure I could now.

-- 
Anthony C Howe          Skype: SirWumpus                    SnertSoft
+33 6 11 89 73 78         ICQ: 7116561          BarricadeMX & Milters
http://www.snert.com/                 
     http://www.snertsoft.com/

Lists Index Date Thread Search