Envelope emails rejected

Asked by Horia Miclea

Hi,

I am running the latest version 2.010 and I get rejections like http://www.openspf.org/Why?s=mfrom;id=0000015062af93ba-bdba1642-4e08-4953-91ff-1cca053a8fa3-000000%40mailer.netflix.com;ip=54.240.5.1;r=DiskStation

In the postfix logs I see: Oct 13 21:31:30 DiskStation postfix/policy-spf[19713]: SPF none (No applicable sender policy available): HELO/EHLO: a5-1.smtp-out.eu-west-1.amazonses.com, IP Address: 54.240.5.1

Is this a bug or a configuration issue?

Thanks, Horia

Question information

Language:
English Edit question
Status:
Solved
For:
postfix-policyd-spf-perl Edit question
Assignee:
No assignee Edit question
Solved by:
Horia Miclea
Solved:
Last query:
Last reply:
Revision history for this message
Scott Kitterman (kitterman) said :
#1

The openspf.org Why message you sent relates to the Mail From address of the message. The postfix log snippet relates to the HELO identity (SPF can check both Mail From and HELO). Please provide the full logs of a relevant message as this isn't enough information to reliably evaluate the situation.

Revision history for this message
Horia Miclea (hmiclea) said :
#2

Here is the full log:

Oct 13 21:31:27 DiskStation postfix/smtpd[19707]: connect from a5-1.smtp-out.eu-west-1.amazonses.com[54.240.5.1]
Oct 13 21:31:27 DiskStation postfix/smtpd[19707]: Anonymous TLS connection established from a5-1.smtp-out.eu-west-1.amazonses.com[54.240.5.1]: TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
Oct 13 21:31:30 DiskStation postfix/policy-spf[19713]: SPF none (No applicable sender policy available): HELO/EHLO: a5-1.smtp-out.eu-west-1.amazonses.com, IP Address: 54.240.5.1, Recipient: <email address hidden>
Oct 13 21:31:30 DiskStation postfix/policy-spf[19713]: SPF fail (Mechanism '-all' matched): Envelope-from: <email address hidden>, IP Address: 54.240.5.1, Recipient: <email address hidden>
Oct 13 21:31:30 DiskStation postfix/policy-spf[19713]: SPF fail (Mechanism '-all' matched): Envelope-from: <email address hidden>
Oct 13 21:31:31 DiskStation postfix/policy-spf[19713]: handler sender_policy_framework: is decisive.
Oct 13 21:31:31 DiskStation postfix/policy-spf[19713]: Policy action=550 Please see http://www.openspf.net/Why?s=mfrom;id=0000015062af93ba-bdba1642-4e08-4953-91ff-1cca053a8fa3-000000%40mailer.netflix.com;ip=54.240.5.1;r=DiskStation
Oct 13 21:31:31 DiskStation postfix/smtpd[19707]: NOQUEUE: reject: RCPT from a5-1.smtp-out.eu-west-1.amazonses.com[54.240.5.1]: 550 5.7.1 <email address hidden>: Recipient address rejected: Please see http://www.openspf.net/Why?s=mfrom;id=0000015062af93ba-bdba1642-4e08-4953-91ff-1cca053a8fa3-000000%40mailer.netflix.com;ip=54.240.5.1;r=DiskStation; from=<email address hidden> to=<email address hidden> proto=ESMTP helo=<a5-1.smtp-out.eu-west-1.amazonses.com

Revision history for this message
Scott Kitterman (kitterman) said :
#3

Unfortunately, I don't have a great answer for you. The openspf.org Why service and postfix-policyd-spf-perl use the same SPF library (Mail::SPF) to get the SPF result, so I doubt it's a bug.

The mailer.netflix.com SPF record is v=spf1 include:amazonses.com -all. That means that they've authorized whatever is in the amazonses.com SPF record. It currently says:

"v=spf1 ip4:199.255.192.0/22 ip4:199.127.232.0/22 ip4:54.240.0.0/18 -all"

The connect IP for this message (54.240.5.1) matches ip4:54.240.0.0/18, so this should have been an SPF pass based on the current records.

I think it's most likely that on the 13th their SPF record was broken and between when the rejection was logged and when you checked the Why URL it had been fixed so it (correctly) showed the SPF pass. There's no way to know for sure.

Given all the above, my diagnosis is most likely sender misconfiguration that's already been addressed.

If you want to experiment, https://launchpad.net/pypolicyd-spf is a more developed implementation of an SPF policy server with more options to do different things with. I have no reason to believe it would have gotten a different result in this case, however.

Revision history for this message
Horia Miclea (hmiclea) said :
#4

Hi Scott,

I noticed this issue several times over long time (months). It didn't bother me untilI I saw the same on twitter emails with similar logs from postfix. The behaviour remains consistent as long I keep the postfix configuration to check and reject on SPF.

What intrigues me is this part of the log: Oct 13 21:31:30 DiskStation postfix/policy-spf[19713]: SPF none (No applicable sender policy available): HELO/EHLO: a5-1.smtp-out.eu-west-1.amazonses.com, IP Address: 54.240.5.1, Recipient: <email address hidden>

Are there other reasons that don't allow the Mail::SPF lib to fetch the policy? I can see the spa-policyd code is attempting to fetch both.

Here is the twitter log, with the same issue, missing SPF policy for the envelope.
t 16 15:21:19 DiskStation postfix/smtpd[15029]: connect from spruce-goose-bb.twitter.com[199.59.150.97]
Oct 16 15:21:19 DiskStation postfix/smtpd[15029]: connect from spruce-goose-bb.twitter.com[199.59.150.97]
Oct 16 15:21:19 DiskStation postfix/smtpd[15029]: Anonymous TLS connection established from spruce-goose-bb.twitter.com[199.59.150.97]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Oct 16 15:21:19 DiskStation postfix/smtpd[15029]: Anonymous TLS connection established from spruce-goose-bb.twitter.com[199.59.150.97]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Oct 16 15:21:21 DiskStation postfix/policy-spf[15039]: SPF none (No applicable sender policy available): HELO/EHLO: spruce-goose-bb.twitter.com, IP Address: 199.59.150.97, Recipient: <email address hidden>
Oct 16 15:21:21 DiskStation postfix/policy-spf[15039]: SPF none (No applicable sender policy available): HELO/EHLO: spruce-goose-bb.twitter.com, IP Address: 199.59.150.97, Recipient: <email address hidden>
Oct 16 15:21:21 DiskStation postfix/policy-spf[15039]: SPF fail (Mechanism '-all' matched): Envelope-from: <email address hidden>, IP Address: 199.59.150.97, Recipient: <email address hidden>
Oct 16 15:21:21 DiskStation postfix/policy-spf[15039]: SPF fail (Mechanism '-all' matched): Envelope-from: <email address hidden>, IP Address: 199.59.150.97, Recipient: <email address hidden>
Oct 16 15:21:21 DiskStation postfix/policy-spf[15039]: SPF fail (Mechanism '-all' matched): Envelope-from: <email address hidden>
Oct 16 15:21:21 DiskStation postfix/policy-spf[15039]: SPF fail (Mechanism '-all' matched): Envelope-from: <email address hidden>
Oct 16 15:21:21 DiskStation postfix/policy-spf[15039]: handler sender_policy_framework: is decisive.
Oct 16 15:21:21 DiskStation postfix/policy-spf[15039]: handler sender_policy_framework: is decisive.
Oct 16 15:21:21 DiskStation postfix/policy-spf[15039]: Policy action=550 Please see http://www.openspf.net/Why?s=mfrom;id=b07244c5940sebastian%3Dmiclea.net%40bounce.twitter.com;ip=199.59.150.97;r=DiskStation
Oct 16 15:21:21 DiskStation postfix/policy-spf[15039]: Policy action=550 Please see http://www.openspf.net/Why?s=mfrom;id=b07244c5940sebastian%3Dmiclea.net%40bounce.twitter.com;ip=199.59.150.97;r=DiskStation
Oct 16 15:21:21 DiskStation postfix/smtpd[15029]: NOQUEUE: reject: RCPT from spruce-goose-bb.twitter.com[199.59.150.97]: 550 5.7.1 <email address hidden>: Recipient address rejected: Please see http://www.openspf.net/Why?s=mfrom;id=b07244c5940sebastian%3Dmiclea.net%40bounce.twitter.com;ip=199.59.150.97;r=DiskStation; from=<email address hidden> to=<email address hidden> proto=ESMTP helo=<spruce-goose-bb.twitter.com>
Oct 16 15:21:21 DiskStation postfix/smtpd[15029]: NOQUEUE: reject: RCPT from spruce-goose-bb.twitter.com[199.59.150.97]: 550 5.7.1 <email address hidden>: Recipient address rejected: Please see http://www.openspf.net/Why?s=mfrom;id=b07244c5940sebastian%3Dmiclea.net%40bounce.twitter.com;ip=199.59.150.97;r=DiskStation; from=<email address hidden> to=<email address hidden> proto=ESMTP helo=<spruce-goose-bb.twitter.com>

Thanks, Horia

Revision history for this message
Scott Kitterman (kitterman) said :
#5

To answer your first question, a5-1.smtp-out.eu-west-1.amazonses.com doesn't have an SPF record, so there's nothing to retrieve.

I agree that given it's happened with multiple domains there is an issue somewhere.

It would be interesting to me to see if you still see the same problem with the Python implementation I referenced earlier.

Revision history for this message
Scott Kitterman (kitterman) said :
#6

The Mail::SPF library includes some command line tools for testing. What happens if you run this on the server in question:

spfquery --id bounce.twitter.com --ip 199.59.150.97

Revision history for this message
Julian Mehnle (jmehnle) said :
#7

Horia, I'm the author of Mail::SPF and a co-author of postfix-policyd-spf-perl. Please run the command Scott suggested and let us know the result. This is almost certainly not a problem specific to postfix-policyd-spf-perl, but with one of the underlying libraries. What version of Mail::SPF do you have installed?

Revision history for this message
Horia Miclea (hmiclea) said :
#8

Julian, Scott,

The library version is 2.9 and spfquery report is wrong. My system is a Synology NAS, and while I raised a support case, I can't replace the SPF policy module with the python implementation. I updated the support team about our thread, and I am pretty sure they will issue an update for the Mail package as soon you fix the library, if the issue is really there.

Below the details, thanks, Horia

DiskStation> /usr/bin/perl -I /var/packages/MailServer/target/share/perl5/vendor_perl /var/packages/MailServer/target/bin/vendor_perl/spfquery --id bounce.twitter.com --ip 199.59.150.97
fail
Please see http://www.openspf.org/Why?s=mfrom;id=bounce.twitter.com;ip=199.59.150.97;r=DiskStation
bounce.twitter.com: Sender is not authorized by default to use 'bounce.twitter.com' in 'mfrom' identity (mechanism '-all' matched)
Received-SPF: fail (bounce.twitter.com: Sender is not authorized by default to use 'bounce.twitter.com' in 'mfrom' identity (mechanism '-all' matched)) receiver=DiskStation; identity=mailfrom; envelope-from=bounce.twitter.com; client-ip=199.59.150.97

DiskStation> more /var/packages/MailServer/target/share/perl5/vendor_perl/Mail/SPF.pm
#
# Mail::SPF
# An object-oriented Perl implementation of Sender Policy Framework.
# <http://search.cpan.org/dist/Mail-SPF>
#
# (C) 2005-2012 Julian Mehnle <email address hidden>
# 2005 Shevek <email address hidden>
# $Id: SPF.pm 63 2013-07-22 03:52:21Z julian $
#
##############################################################################

package Mail::SPF;

=head1 NAME

Mail::SPF - An object-oriented implementation of Sender Policy Framework

=head1 VERSION

2.009

Revision history for this message
Scott Kitterman (kitterman) said :
#9

With the same version, I get a correct result. Mail::SPF uses Net::DNS, Netaddr:IP, and URI. What versions of these modules do you have installed?

Revision history for this message
Horia Miclea (hmiclea) said :
#10

Hi Scott,

I just learned that Synology support discovered issues in the rest of the perl package on my ppc platform and that an update fixes the issue.

I understood this impacted the NetAddress handling as you suspected.

I think we can close this question, thanks to you and Julian for the assistance and apologies if I wasted your time.

Thanks, Horia

> On 21 Oct 2015, at 07:21, Scott Kitterman <email address hidden> wrote:
>
> Your question #272463 on postfix-policyd-spf-perl changed:
> https://answers.launchpad.net/postfix-policyd-spf-perl/+question/272463
>
> Status: Open => Needs information
>
> Scott Kitterman requested more information:
> With the same version, I get a correct result. Mail::SPF uses Net::DNS,
> Netaddr:IP, and URI. What versions of these modules do you have
> installed?
>
> --
> To answer this request for more information, you can either reply to
> this email or enter your reply at the following page:
> https://answers.launchpad.net/postfix-policyd-spf-perl/+question/272463
>
> You received this question notification because you asked the question.

Revision history for this message
Horia Miclea (hmiclea) said :
#11

The problem is in other perl packages and the vendor identified the fix. Closing the question.