Home / server / Questions / 370234
In Process
Magd
Asked: 2012-03-16 12:38:09 +0800 CST

sendmail is using return-path instead of from address

  • 772

I have a customer that is complaining about emails marked as spam.

I'm looking at the header. It shows the correct From: [email protected]

However, it doesn't like the return-path.

Return-Path: <[email protected]>
Received-SPF: neutral (google.com: x.x.x.x is neither permitted nor denied by domain of [email protected]) client-ip=x.x.x.x;
Authentication-Results: mx.google.com; spf=neutral (google.com: x.x.x.x is neither permitted nor denied by domain of [email protected]) [email protected]

How do I configure sendmail to use the From address for the Return-Path?

linux spam sendmail return-path

2 Answers

  1. From the bat book (page 1165):

    The Return-Path: header is intended to show the envelope address of the real sender as opposed to the sender used for replying (the From: and Reply-To: headers). In posting Usenet news, for example, the Return-Path: shows “news” and the From: shows the address of the posting user. But in general, Return-Path: should never be used for replying to mail. It is intended to be used solely for notification of delivery errors.

    Your client is not having problems with the Return-Path: header. Neither with SPF since the result is neutral as the headers tell us. You client must accept the fact that the intended recipients consider what he sends as spam.

    If this is indeed a false positive consider setting up proper SPF and DKIM records for the domain and see if the situation improves.

    • 6

  2. It looks like you email is from an automated sender which is sending using one of Google's server. It may be connecting to GMail to send the message. Your server appears to have an SPF record, which neither includes the Google SPF list nor indicates that it should be enforced. Including a Sender header for [email protected] may help.

    There are a number of factors that will make you email look like Spam before you even start sending it.

    • Do you have a static address with a PTR record returning your hostname, or name on another A record for the address? (Does reverse DNS validation work?)
    • Does your mail server announce itself using the same name the PTR record returns?
    • Does you mail server have a SPF record permitting itself to send email?
    • Is your address listed in list.openwl.org?

    Failing the first two tests are strongly indicative of Spam, or an automated mail source. Person to person e-mail almost always pass these tests, while Spam often fails. The next two tests are indicative of non-Spam.

    Once you have started sending the email there are other tests that apply.

    • Both the return path address (envelope address) and From address should have an MX record pointing to a working mail server.
    • The return path address should match the From or Sender address header.
    • Both domains (if different) should have a working postmaster address.
    • Both domains (if different) should have SPF records permitting mail from the sending server.
    • Previous history of both email addresses and their domains may be considered (autowhitelisting / autoblacklisting).
    • Does the message have a valid DKIM signature.
    • Any other rules that the email administrator deems appropriate.

    I find I get a relatively high failure rate on DKIM signed documents from automated senders. This is mainly related to the public keys not being available from DNS.

    • 3