Skip Menu |

This queue is for tickets about the Mail-SPF CPAN distribution.

Report information
The Basics
Id: 46334
Status: resolved
Priority: 0/
Queue: Mail-SPF

People
Owner: JMEHNLE [...] cpan.org
Requestors: d.stussy [...] yahoo.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: v2.007



CC: julian [...] mehnle.net
Subject: SPF Issue with local submissions (loopback address sourced)
Date: Sun, 24 May 2009 14:18:49 -0700 (PDT)
To: bug-Mail-SPF [...] rt.cpan.org
From: - <d.stussy [...] yahoo.com>
Package: Mail-SPF-v2.006 - 17 Aug 2008 Perl Version: 5.10.0 OS: Linux Kernel 2.6.29.4 Perhaps a bug; perhaps not, but at minimum definently an issue that needs a special note: Messages which originate locally appear to be checked (in some cases) by some perl-based milters, including MimeDefang. I noted an actual rejection in the code of my filter_sender() routine, caused by passing the localhost's loopback address ("127.0.0.1" or "::1") to the Mail::SPF routines (Server, Request, then (request)->process). I noted this when I saw in my logs: http://www.openspf.org/Why?s=mfrom;id=....;ip=127.0.0.1;r=localhost (Mechanism '-all' matched) Technically, this is a correct answer as there was no mechanism in the SPF string that authorized a loopback address as a valid sender. The LOOPBACK addresses are not exempt and if not listed on the SPF record, they will result in the default answer (which may be "(hard)fail" if "-all" is used. Other implementations of SPF checking libraries I have seen exempt the two loopback addresses. Since this implementation does not, it should either be changed to exempt these addresses, or a warning should be added to direct the user that the addresses are not specifically exempt, and that his code should bypass SPF checks when they are used. It may have been unforseen that an SPF check might be performed on locally originated mail (as it really applies to mail coming in from outside the host). However, as it has happened, it is a case that should be accounted for. For reference, here is my (unmodified) version of MimeDefang's filter_sender() routine. I have since changed it to bypass the SPF check for loopback addresses. My routine: -------------------------------------------------------------------- sub filter_sender { my ($sender, $ip, $hostname, $helo) = @_; if ($sender =~ /@([^>]+)/) { my $domain = $1; my @bogushosts = md_get_bogus_mx_hosts($domain); my $i = scalar(@bogushosts); return('REJECT',"Domain $domain has $i bogus MX record" . (($i < 2)? '' : 's') .': '. join(' ',@bogushosts),'550','5.4.4') if ($i); } else { $sender = "<postmaster\@$helo>" unless ($sender =~ /[^<>]+/); } read_commands_file(); return('CONTINUE','OK - SASL Authorized','235','2.7.0') if ($SendmailMacros{'auth_authen'}); my $id = ($sender =~ /<(.+)>/) ? $1 : $sender; my $spfserver = Mail::SPF::Server->new(max_void_dns_lookups => undef, hostname => $SendmailMacros{'if_name'} ); my $spfrequest = Mail::SPF::Request->new(versions => [1], scope => 'mfrom', identity => $id, ip_address => $ip, helo_identity => $helo); my $r = $spfserver->process($spfrequest); my $spfrec = $spfrequest->record; my $result = $r->code; my $text = $r->text; my $local = $r->local_explanation; my $auth = ($result eq 'fail') ? $r->authority_explanation : ''; my $label = ($sender eq "<>") ? 'helo' : 'mailfrom'; md_syslog('info',"$QueueID: SPF=$result From=<$id> ($text)"); action_insert_header('Authentication-Results', $SendmailMacros{'if_name'} . "; SPF=$result smtp.$label=$1", 0) if ($id =~ /@([^>]+)/); return('REJECT', "SPF Forgery: $local. ($auth)",'550','5.7.7') if ($result =~ /^(hard)?fail$/); return('REJECT', "SPF Error: $local (\"$spfrec\")",'550','5.7.4') if ($result eq 'permerror'); return('TEMPFAIL',"SPF Temp-Error: $local",'451','4.4.3') if ($result eq 'temperror'); return('REJECT', "SPF Failure: $local",'550','5.7.1') if ($result eq 'softfail'); return('CONTINUE',"OK - SPF=$result ($local)"); } -------------------------------------------------------------------- Note also that the sender's identity passed in for MimeDefang includes '<' and '>' while Mail::SPF::Request requires that they be stripped before the call. This is another "gotcha" that's easy to miss. I am also aware that the milter interface doesn't support 2xx codes nor a DSN code of 2.X.Y, but I include it because this could change in the future and the MimeDefang perl module does pass this information on to its milter interface program.
On Sun May 24 17:19:17 2009, d.stussy@yahoo.com wrote: Show quoted text
> Perhaps a bug; perhaps not, but at minimum definently an issue that > needs a special note:
I consider this a documentation omission. Read on for why. Show quoted text
> The LOOPBACK addresses are not exempt and if not listed on the SPF > record, they will result in the default answer (which may be > "(hard)fail" if "-all" is used.
This was a conscious design choice. The rationale is that the set of addresses to exempt is anything but clearly defined. {127.0.0.1,::1} may seem like the obvious set of, but there's nothing stopping anyone from setting up, e.g., an additional 127.0.0.2 loopback address on their machine. Furthermore, there are usually more addresses (not loopback ones) that need to be exempted but are known only to the owner of the MTA running Mail::SPF, such as secondary MXes and other trusted forwarders. Thus it is always the responsibility of the administrator to explicitly configure exemptions for all of those. Show quoted text
> Other implementations of SPF checking libraries I have seen exempt > the two loopback addresses.
True. They also usually exhibit far too magical behavior in various aspects, intending to provide convenience but in the end causing confusion. Mail::SPF::Query is a prime example. Mail::SPF goes the other route, providing only the pure SPF logic per the specification, and leaving all the whitelisting to the caller. This is what should be documented in the Mail::SPF man pages. Show quoted text
> For reference, here is my (unmodified) version of MimeDefang's > filter_sender() routine. I have since changed it to bypass the SPF > check for loopback addresses.
This seems like the best approach to me. Show quoted text
> Note also that the sender's identity passed in for MimeDefang includes > '<' and '>' while Mail::SPF::Request requires that they be stripped > before the call. This is another "gotcha" that's easy to miss.
Well, I think the Mail::SPF::Request man page makes it pretty clear that this is either a domain name or an e-mail address. "<x@y.com>" is neither. Have you reported this as a bug to the MimeDefang authors? -Julian
Subject: Re: [rt.cpan.org #46334] SPF Issue with local submissions (loopback address sourced)
Date: Sun, 24 May 2009 17:02:40 -0700 (PDT)
To: bug-Mail-SPF [...] rt.cpan.org
From: - <d.stussy [...] yahoo.com>
--- On Sun, 5/24/09, Julian Mehnle via RT <bug-Mail-SPF@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=46334 > > > On Sun May 24 17:19:17 2009, d.stussy@yahoo.com wrote: >
> > Perhaps a bug; perhaps not, but at minimum definently an issue that > > needs a special note:
> > I consider this a documentation omission.  Read on for why.
I don't have a problem with that as long as it's "a big warning" section, perhaps: "Unlike other implementations of SPF, this version does not exempt the loopback addresses '127.0.0.1' or '::1' by assuming they are authorized. Locally generated messages should generally bypass SPF checking." Show quoted text
> > Note also that the sender's identity passed in for MimeDefang includes > > '<' and '>' while Mail::SPF::Request requires that they be stripped > > before the call.  This is another "gotcha" that's easy to miss.
> > Well, I think the Mail::SPF::Request man page makes it pretty clear that > this is either a domain name or an e-mail address. "<x@y.com>" is > neither.  Have you reported this as a bug to the MimeDefang authors?
I don't believe that it is a bug as far as MimeDefang is concerned, as it literally is the parameter specified on the "MAIL FROM:" command (even in RFC 5321). It is needed to distinguish "<>" from no parameter at all. Perhaps another warning (or "user note") is in order?
Mail::SPF's stance has been documented in the README file as of 2.007.