Using email tracking with SSL website prevents user to perform the action with Google Chrome.
If you use SSL with HSTS, it triggers big warning in Chrome when the user click on the link http://cl.ly/image/0A373O2r3539

Email tracking in mailgun is performed by replacing links in email by a custom subdomain setup in the admin panel, ie email.domain.com which as to be configured as a CNAME for mailgun.org.

Chrome will try to access httpS://email.domain.com which will fail because the underlying server is mailgun.org and not domain.com's server.

Proposed Solution:
Instead of pointing email.domain.com => mailgun.org, configure your server for https://email.domain.com and redirect every request (with parameters) to https://mailgun.org/$requestedURI.
Then the usual mailgun tracking system can track click and redirect to the right domain.com url.

This could be easily done if there was a way to override the mailgun admin panel check for the CNAME record, ie a checkbox "I've setup a forwarding subdomain to mailgun.org"

A degrated version would be to have links replaced by https://mailgun.org/click?ID but this would probably harm deliverability for mail coming from domain.com (and not mailgun.org)

More info on SSL HSTS: http://en.wikipedia.org/wiki/HTTPStrictTransport_Security

Hello,

I think it would be interesting (from a stats perspective) if you can provide another API endpoint to get the current stats by domain and credentials.

An example:

Imagine the domain.com has 3 SMTP login:
- postmaster@domain.com
- newsletter@domain.com
- autoresponse@domain.com

Now we can get stats from domain.com (so we can get the domain has sent 300 messages), but we don't know if we have sent these messages using the autoresponse@domain.com account or using newsletter@domain.com or any other account that we can create.

If you can consider this new feature I think will be nice from a Stats and Marketing perspective, to know how the company is in touch with the registered users.

Thanks for your time.

Cheers,

If something happens to my DNS records and the domain gets un-verified, I need to know about it. Because of the 300 daily messages allowed on unverified domains, I have time to fix the problem before being cut off completely, but only if I KNOW about it!

Maybe this isn't common, but it's happened to me more than once now. Sometimes it's an issue with my DNS provider. Sometimes an included SPF record changes, causing the "too many DNS lookups" error.

I get an email if you automatically verify one of my domains, so why not also one when you un-verify?

Mailgun provides an excellent service. However, a recent change was made to the API: 400 Bad Request is returned if the address is not valid.

The validation is a deep check that is not commonly performed (in my experience), including checking the domain for a MX record and effective TLD names (using https://publicsuffix.org/list/effectivetldnames.dat).

The issue with this is

1) There are no clear distinction between an invalid API request and invalid content. E.g. you get a 400 bad request if a required parameter is missing and if the email address is invalid

• Currently the documentation states: "Bad Request - Often missing a required parameter" (https://documentation.mailgun.com/en/latest/api-intro.html#errors)

2) The API message (HTTP body) contains no error codes. Which makes it less suitable for containing a vast amount of different poorly related errors

3) Implementation making the request to the API gets mixed with implementation handling bounces and dropped messages

• In my case, we have a stable implementation that uses the API. A bad request is not expected and a serious indication of a breaking change to the API, since the usage of the API is stable




• Now we need to parse strings such as "'to' parameter is not a valid address. please check documentation" to detect problems with the content, even though we also have API hooks established




• The lack of separation of issues is a problem

The suggested solution

a) Accept the message (200 OK from the API)

• Keep the distinction clear: a bad request is only about the API (the abstract meta only) - never about content itself

b) Drop the message immediately and invoke API hooks

• Please note that this is not about "drop immediately or wait and retry"




• The only difference is: how is a immediate drop communicated? It should be communicated via the established API hooks (single channel with single purpose) and not via API response codes "just because the API connection is still active"




• Compare this to suppressions: whether an address is suppressed or not is something known when the API is called. But it's not communicated via a 400 Bad Request or a 418

Finally, quoting RFC 7231 (https://tools.ietf.org/html/rfc7231#section-6.5.1)

"The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)"

Please keep the layers separated.