2

I have a public mail server (Linux + postfix) and some clients using it. The server is properly configured, included DKIM and SPF validation. But emails from only a few of my clients are being marked as SPAM, because the client-ip doesn't match with allowed senders' IPs and the SPF validation fails:

Received-SPF: fail (google.com: domain of xxxxx@xxxxxx.com does not designate 217.125.48.20 as permitted sender) client-ip=217.125.48.20;

Of course, 217.125.48.20 is not the IP of my server.

I don't know the reason, because they are sending mails from properly (AFAIK) configured Outlooks. Even though, the DKIM validation pass, so, the email pass through my server before is sent.

Has anybody experienced similar issues and could tell me any possible reasons for that mismatch?

Here are the headers (mailboxes have been replaced by xxxxx):

Delivered-To: xxxxxxx@gmail.com
Received: by 10.194.70.103 with SMTP id l7csp1376984wju;
        Fri, 2 Sep 2016 04:49:17 -0700 (PDT)
X-Received: by 10.28.154.208 with SMTP id c199mr2895670wme.102.1472816956397;
        Fri, 02 Sep 2016 04:49:16 -0700 (PDT)
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of xxxxxxx@afanascadiz.com does not designate 217.125.48.20 as permitted sender) smtp.mailfrom=xxxxxxx@afanascadiz.com;
       dkim=pass header.i=@cydsur.com
Received-SPF: fail (google.com: domain of xxxxxx@afanascadiz.com does not designate 217.125.48.20 as permitted sender) client-ip=217.125.48.20;
Received: by 10.28.127.2 with POP3 id a2mf7718962wmd.1;
        Fri, 02 Sep 2016 04:49:16 -0700 (PDT)
X-Gmail-Fetch-Info: xxxxxxx@staffgrupom.es 1 ns.cydsur.com 995 xxxxxxxx@staffgrupom.es
Return-Path: <xxxxxxx@afanascadiz.com>
Delivered-To: xxxxxxxx@staffgrupom.es
Received: from DANIEL (20.red-217-125-48.staticip.rima-tde.net [217.125.48.20])
    (Authenticated sender: xxxxxxxx@afanascadiz.com)
    by ns.cydsur.com (Postfix) with ESMTPSA id 1D985330D3F1;
    Fri,  2 Sep 2016 13:45:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cydsur.com; s=mail;
    t=1472816717; bh=8OGFi38ZIKFm+jXd0aJbg6pZnAOtjZMC4U8yHU+Tpm4=;
    h=From:To:Cc:Subject:Date:From;
    b=OaGmCrOIBLREC3z5kJt4Z91CTK7caJY0FQvYtTQBiJjrAiK4HQw1/LotUW9g7DuZQ
     SOchVeXw7Filp0smGGOdVnJWrSdHEWT74SwqWTULmpYxIHOds68HOIWwJJKR8rxLOe
     a+TidmwP93Zua4ETN51zqU/QVtB9I1oefxd0W0B0=
From: =?iso-8859-1?Q?XXXXXXXXXXXXXX?= <xxxxxxx@afanascadiz.com>
To: <xxxxxx@cydsur.com>,
    <xxxxxxx@staffgrupom.es>
Cc: "'XXXXXXX'" <xxxxxxxr@afanascadiz.com>
Subject: RV: ctas de usuarios.
Date: Fri, 2 Sep 2016 13:45:16 +0200
Message-ID: <000301d2050f$7a7d3540$6f779fc0$@com>
MIME-Version: 1.0
Content-Type: multipart/related;
    boundary="----=_NextPart_000_0004_01D20520.3E060540"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdHjLl7+vxyBNVQdQIWvJApRimDm9gh3o/5Q
Content-Language: es
X-Spam-Status: No, score=-0.7 required=5.0 tests=ALL_TRUSTED,BAYES_00,
    HTML_MESSAGE,TVD_RCVD_SINGLE,T_KAM_HTML_FONT_INVALID,URIBL_BLOCKED
    autolearn=no autolearn_force=no version=3.4.0
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ns.cydsur.com
X-Virus-Scanned: clamav-milter 0.98.7 at ns.cydsur.com
X-Virus-Status: Clean
  • domain of xxxxx@xxxxxx.com does not designate 217.125.48.20 as permitted sender) - They need to designate your email server in the SPF record in their DNS zone. – joeqwerty Sep 3 '16 at 2:44
  • Yes, I know that. The DNS zones are perfectly defined. Only some PCs (some Outlooks, or perhaps, smartphones), send emails from a different IP. Other users of the same domain send emails perfectly. – Peregring-lk Sep 3 '16 at 3:12
  • 3
    They either send through your server and IP or not. It can't be a senseless mix and match. If you really want help troubleshooting, show us actual email headers that fail validation. 90% of email problems require actual data to troubleshoot. – Julie Pelletier Sep 3 '16 at 3:36
  • Done. The header of an actual SPF failed email. – Peregring-lk Sep 3 '16 at 16:04
  • This appears to be Google's fault. They should not be attempting to check SPF records for messages they fetch via POP3. – Michael Hampton Sep 3 '16 at 16:45
2

Spam because of unsuccessful SPF validation is common operational procedure. If that validation is failing when it should not be, the SPF records in DNS are suspect and should be examined carefully. Blaming the client-ip for the failure "should" only matter to the receiving server MTA.

Looking at the headers provided, follow the path of the message.

It appears that xxxxxxxx@afanascadiz.com wrote a message, connected from (20.red-217-125-48.staticip.rima-tde.net [217.125.48.20]) and authenticated to host ns.cydsur.com to send their message out. Out could be an endpoint in the cydsur.com domain or require additional relay, but once accepted by the MTA (postfix) on cydsur.com, it is that MTA that must deliver/relay the message to it's destination or next hop. In your case, that endpoint is all local, and a user in one of the hosted domains POPped their mailbox from a google mail (gmail) account.

The name server (NS), mail exchanger (MX), and address (A) record for afanascadiz.com are all at ns.cydsur.com, as are the target address domains in the TO and CC fields of the message envelope. This can be verified with dig or nslookup commands.

The sender permitted framework (SPF) applies to the message's FROM address.

  • afanascadiz.com text = "v=spf1 include:cydsur.com -all"

could be better written as;

  • afanascadiz.com text = "v=spf1 mx include:cydsur.com -all"

or even better as;

  • afanascadiz.com text = "v=spf1 mx -all"

since the mx is actually ns.cydsur.com anyway.

Alternatively, the -all could be changed to ~all to relax the restriction, but may not change the end result you are seeing at gmail. Test carefully to verify this does not defeat the original purpose of your SPF setting if you do use ~all.

None of the SPF settings explain why google is examining them when acting as a POP3S (noting port 995) client. SPF was designed for the SMTP protocol, not for POP. Considering there is only a single "Received:" line in the SMTP header of the message prior to POP retrieval of that message, this may be the only data gmail has to work with to identify spam. This is the most likely, or at least one possible, reason for the mismatch.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.