I am currently using Mandrill service for our transactional email without using this module. I just use the SMTP module to route things through mandrill servers.

Perhaps this is not the best way to do things? The user account and invoices and all are being delivered just fine this way, but the contact form uses the "From" based on what the user of the contact form enters as his or her email address. I believe this is going to be a problem going forward since Mandrill will require SPF and DKIM on all sending domains.

Should I be using this Mandrill module? Will this module address this kind of complication?

Thanks for any advice you can provide.

Dan

Comments

royerd created an issue. See original summary.

_paul_meta’s picture

I had been using this module for the contact form and it was ok. By putting in a sender email and sender name in the mandrill module settings, this was used as the contact form emails 'from' settings. The email of the person who sent the email became the 'reply-to'.

However, this stopped working recently. All my sending domains are verified and have SPF and DKIM setup correctly.

When I do a test email from the contact form with an email like myname@gmail.com .. the email reaches mandrill with that gmail as the sender, and it is rejected due to SPF and DKIM missing.

I guess the module might need an update to suit how things are working at the mandrill side of things.

Any help appreciated.

Best wishes,

Paul

brunodbo’s picture

I'm having the exact same issue with Mandrill and the Drupal contact form. Wondering how to best solve this.

@_paul_meta: Did you merge your Mandrill and Mailchimp already? I did, so I'm wondering if the problem could be related to that.

brunodbo’s picture

Status: Active » Fixed

https://www.drupal.org/project/contact_reply_to seems to resolve this issue for me. That module changes the (user and site wide) contact forms' 'From' email address to the email address set in 'Site information', instead of using the email address of the user sending the message through the form. The 'Reply' address will still be the sending user's address. This way, the only DKIM and SPF records that matter are the ones for the domain your site uses (and which you ideally control).

ruscoe’s picture

Status: Fixed » Active

  • ruscoe committed aa41a45 on 7.x-2.x
    Issue #2689201 by brunodbo, royerd, _paul_meta: This module and the...
ruscoe’s picture

Status: Active » Fixed

Thanks for bringing this up. We have a fix in the 7.x-2.3 release.

_paul_meta’s picture

Just did the update and I can confirm it works fine for me now with the contact form.

@brunodbo .. yes i have merged my mandrill account to mail chimp. although i think this issue may have been there before, and it was due to mandrill tightening some things in their sender policies.

thanks very much for the fix !!

brunodbo’s picture

Fix in 2.3 works for me. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

mrpauldriver’s picture

That's a fix. Thank you

ao5357’s picture

Version: 7.x-2.2 » 7.x-2.3
Component: Miscellaneous » Code
Status: Closed (fixed) » Active

The #6 patch prevents any message on the site from using a From: name and address other than the ones specified on the Mandrill settings page. While it certainly would have fixed the contact form issue, it breaks other, legitimate uses of the generic MandrillMailSystem class (such as sending a message using a Rules action with parameters).

It's not clear why a secondary solution like #4 wouldn't be a better idea. After all, the issue at hand is that the contact form sets the From: address to an unsafe value; not that the Mandrill class improperly handles From: values.

vinmassaro’s picture

Status: Active » Needs work

Chiming in also here to say that this commit breaks the previous commit: https://cgit.drupalcode.org/mandrill/commit/?id=92f2555

The change made in #2287993: Support custom "from" addresses allows webform to set the from header to something other than what is defined on the Mandrill settings page.