Error when using Exim "sendmail"

[ioquatix]

I get the following error:

A message that you sent using the -t command line option contained no
addresses that were not also on the command line, and were therefore
suppressed. This left no recipient addresses, and so no delivery could
be attempted.

------ This is a copy of your message, including all the headers. ------

Date: Wed, 09 Jun 2010 00:22:26 +1200
From: samuel.williams@NOSPAM
To: samuel@NOSPAM
Message-ID: 4c0e360234e31_3554241c2728745db@NOSPAM
Subject: Website Contact: Moo
Mime-Version: 1.0
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit

Testing

[paulschreiber]

I ran into the same problem with my host (site5). They were able to tweak their exim config to make this work. It would be good if the mail gem's default behaviour was compatible with exim (or if it detected exim and adjusted).

[fusco]

Have You an issue ?

Exim log :

2010-11-24 14:34:44 1PLFUi-0002H2-PQ <= <> R=1PLFUi-0002H0-OI U=mail P=local S=16076 T="Mail failure - no recipient addresses" from <> for user@NOSPAM

app log :

Sent mail to contact@NOSPAM (160ms)
Date: Wed, 24 Nov 2010 14:39:15 +0100
From: my_name contact@NOSPAM
Reply-To: my_name contact@NOSPAM
To: your_name your_name@NOSPAM
Message-ID: [email protected]
Subject: Your account are created
Mime-Version: 1.0
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: quoted-printable

[vit]

You can insert this line into Exim configuration file:
extract_addresses_remove_arguments = false

[fusco]

it's ok, i read exim man for more specifics.

Thks

[kritik]

have the same problem, can it be solved soon?

[fusco]

with
extract_addresses_remove_arguments = false
yes it's solved, but i dont know impact for mail server security.

[kritik]

No, I meant how can this bug be solved in mail function. I tried PHP's mail function and it works perfectly.

[graaff]

The ssmtp wrapper (ftp://ftp.debian.org/debian/pool/main/s/ssmtp/) issues a similar warning. Given that all the information is already in the generated mail and -t is used I'm not sure why the default should be to also provide them on the command line. My preference solution would be to just remove the recipient addresses from the sendmail command line, but if that's not possible there should be an option to control this behaviour.

[jess]

I was having same problem on cpanel server with exim. I added extract_addresses_remove_arguments = false
and it worked fine...hope there's no recourse :-)

[demotera]

Monkey patch for this very unfortunate issue. Could easily be fixed upstream by providing an alternate sendmail class (like below) or by removing the list of recipients from the command line. Thx !

module Mail

  class Exim  < Sendmail

    def deliver!(mail)
      envelope_from = mail.return_path || mail.sender || mail.from_addrs.first
      return_path = "-f \"#{envelope_from.to_s.shellescape}\"" if envelope_from
      arguments = [settings[:arguments], return_path].compact.join(" ")
      self.class.call(settings[:location], arguments, mail)
    end

    def self.call(path, arguments, mail)
      IO.popen("#{path} #{arguments}", "w+") do |io|
        io.puts mail.encoded.to_lf
        io.flush
      end
    end

  end
end

# then ....

Mail.defaults do
  delivery_method Mail::Exim
end

[adamhooper]

For Rails users who experience this:

Add current/config/initializers/xxx_fix_sendmail.rb with these contents:

module Mail
  Sendmail.class_eval do
    def deliver!(mail)
      envelope_from = mail.return_path || mail.sender || mail.from_addrs.first
      return_path = "-f \"#{envelope_from.to_s.shellescape}\"" if envelope_from

      arguments = [settings[:arguments], return_path].compact.join(" ")

      Sendmail.call(settings[:location], arguments, mail)
    end

    def self.call(path, arguments, mail)
      IO.popen("#{path} #{arguments}", "w+") do |io|
        io.puts mail.encoded.to_lf
        io.flush
      end
    end
  end
end

And watch this bug so you'll know when to remove the monkey-patch or when it breaks.

[paul-r-ml]

Please fix this upstream, the fix provided by demotera is correct.
We are surprised that stock rails 3 can't send mail on most debian box ...

[parndt]

Oh man I just spent 2-3 hours debugging this issue.
The exim conf fix did it for me:

extract_addresses_remove_arguments = false

@mikel any idea if these fixes will go into the core gem? Thanks!

[timsjoberg]

Hi, just thought I'd add my 2c. From the exim man page:

-t When Exim is receiving a locally-generated, non-SMTP message on its standard input, the -t option causes the recipients of the message to be obtained from the To:, Cc:, and Bcc: header lines in the message instead of from the command arguments. The addresses are extracted before any rewriting takes place and the Bcc: header line, if present, is then removed.

If the command has any arguments, they specify addresses to which the message is not to be delivered. That is, the argument addresses are removed from the recipients list obtained from the headers. This is compatible with Smail 3 and in accordance with the documented behaviour of several versions of Sendmail, as described in man pages on a number of operating systems (e.g. Solaris 8, IRIX 6.5, HP-UX 11). However, some versions of Sendmail add argument addresses to those obtained from the headers, and the O'Reilly Sendmail book documents it that way. Exim can be made to add argument addresses instead of subtracting them by setting the option extract_addresses_remove_arguments false.

The easiest way to fix this in rails is simply to

config.action_mailer.sendmail_settings = {
  :arguments => "-i"
}

However in the long run, mail should either remove the -t option, or not specify the recipients on the command line. I think removing them from the command line is the better choice as we don't want them added, nor removed.

[timsjoberg]

add pull request #296

[kedarmhaswade]

Thank you, timsjoberg. This is really a difficult-to-track bug. You don't know what to suspect when there are several possible culprits. Just to confirm, both extract_addresses_remove_arguments = false in exim's configuration and arguments => "-i" is what is needed for it to work. I really was nuts on this one.

[mikel]

Hi all, I have added an Exim deliver manager in commit 632c05e This is currently in master.

Please let me know if this handles your issues as I don't use Exim.

[mfn]

I was hit by this yesterday and spent hours figuring out the problem; pretty daunting if you just want to install some random RoR app and emails don't work because of this (even more so if you have no clue about developing with RoR ...). I know #70 (comment) suggest a new driver, but I'd like to point out timsjoberg excellent analysis at #70 (comment) , a conclusion to which I ultimately came to, too.

Maybe there's a easier way to have a Sendmail transport configuration which is more compatible out there?

thanks for considering

[mikel]

@mfn did you see my comment immediately above yours? I have added a separate Exim driver in the latest Mail gem.

[mfn]

@mikel : yes I did; I wasn't ignorant, sorry if that sounded so.

My stance is: I'm wondering if it really needs it's own "driver" when it's just about, maybe (needs thorough investigation), the order or about the parameter which could be changed to work with exim and still be compatible with sendmail and others (I was under the assumption that exims' sendmail link is meant to be compatible).

Because whether it's a configuration like timsjoberg suggested or a new driver: the user will be surprised it doesn't work out of the box. Why the surprise? Usually the application on the system "just work" with the local MTA without special handling.

Just wanted to better describe my point, I'm not arguing against your fix.

thanks

[mikel]

@mfn Oh OK, that makes sense.

What would actually be cool is an update to the README describing how to set up with Exim. Would you be able to craft this?

[ppetr]

👍
I had the same problem with exim after installing. It took me a few hours to discover the cause. I think it's important that sending mail doesn't rely on sendmail's -t option, if different implementations treat it differently. Or at least, please add a notice into the installation manual.

[jeremy]

Note that #477 eliminates reliance on -t entirely by taking over responsibility for the SMTP envelope.