I want to see the contents of the email log, I find it convenient if viewing the contents of the email was sent
Thanks you4 votes
There's currently no direct way to assign recipient variables for batch sending using Node/Meteor. I'm using the sendRaw method, and I can assign other fields like "to" and "subject," of course, but I can't assign "Recipient-Variables."
I did some googling and found that other devs have the same issue. It can be done with other languages, but it's desperately needed for Node and Meteor.10 votes
For url based unsubscribes you can either do: all, mailing list, or tag. With email unsubscribes there is only an option for all. It would be nice to have mailing list and tag based unsubscribes (ex: %tagunsubscribeemail% and %mallinglistunsubscribe_email%).2 votes
Most of my emails are sent to users in Sweden. The geographic coverage is not very useful for me since it only shows statistics for countries.
I would like to see more details here. I would like to see an estimated city for the recipients. I know the data will not be 100% accurate but it is way better than nothing.2 votes
From the Logs, be able to have MailGun reprocess an existing message through a configured route. This would help debug messages that are posted to routes on incoming mail.2 votes
When parsing meeting requests with mailgun, the ical part comes back as a body-calendar property on the JSON. It would be nice to have mailgun accept the same parameter to construct a message containing a meeting invite3 votes
It would be really helpful if there were a way to specify webhooks at the message level as well as the domain level. (Perhaps the message-level webhook, if present, would override the domain-level webhook.)
I send some emails from one server, and some emails from another. It would be really nice to be able to have the postbacks go to the right place. I can emulate the functionality by querying Mailgun about each message at intervals, but that's awfully inelegant.2 votes
it should be easy to support "One-Click Actions" and "Go-to actions" and would be a really nice feature imo.3 votes
Please consider providing the timestamp, token and signature as http headers. Some frameworks such has JAX-RS provide the ability to validate an incoming request via interceptors. This is difficult to do with form data as it is processed later in the request.
Ideally this would be done similar to Twilio https://www.twilio.com/docs/security
Based on this we could verify the request before actually decoding the form data.3 votes
Most Serial to Ethernet server devices use a POST method similar to the following:
Serial.println ("POST: http://domain.com HTTP/1.0");
Serial.println ("Host: domainhost");
I have used this method to post data to data logging web sites and would like to use the same method for emailing. Thanks.3 votes
Some gateways can track when a customer deletes an email. This is an important indication of the recipient's attitude towards the email received, especially for marketing emails, but also for other types.2 votes
Right now, Mailgun will send the exact same email to our customers if the message ID is different. Some of our customers have received more than 150 copies of the exact same email, each within seconds of the last, because the message ID# for each is different, even though the subject line and content of the email is identiical. There ought to be a way for Mailgun to notice when it is sending the same email to the same person over and over again.2 votes
wouldn't it be a nice possibility to receive inbound Emails via forwarding? We mostly cannot point to mailgun mailserver via MX record. But we could configure the Email addresses in question to be forwarded to email@example.com.
Greetings from Germany,
Tobias Jamin2 votes
The account disable process as currently defined is somewhat user-hostile. There are a couple small items that would make the actual experience less disruptive and easier for everyone to resolve. First and foremost, disabling the logs page on the impacted domain seems to be counter productive. I was hoping to be able to investigate for malicious behavior via those logs. Disabling the page means that I had to waste the time of the support staff to help root cause the problem (thanks again Raquel!). Secondly, the quick-pass onboarding process doesn't call out that inbound messages can impact the operation of the domain. In my case a spam email sent to my domain and forwarded via a mailgun route caused lead to my domain being disabled. At best this is going to lead to the situation that happened on my account, at worst it could be leveraged as a denial of service attack against users that host their domains on your platform. The smallest possible change to rectify this is to make the default account settings safe -- in this case that means that the spam filter must be enabled to block mail by default. There are a variety of user-centric ways that behavior could be improved, but I'd argue that the current defaults are nonsensical for most users. I understand what you've configured the system policies the way that they're currently setup, but it seems like they're likely to drive a negative customer experience at best and could lead to malicious attacks at worse.
The account disable process as currently defined is somewhat user-hostile. There are a couple small items that would make the actual experience less disruptive and easier for everyone to resolve. First and foremost, disabling the logs page on the impacted domain seems to be counter productive. I was hoping to be able to investigate for malicious behavior via those logs. Disabling the page means that I had to waste the time of the support staff to help root cause the problem (thanks again Raquel!). Secondly, the quick-pass onboarding process doesn't call out that inbound messages can impact the operation of…3 votes
I'm happy to help and I'm glad you open sourced this library, but please let pull requests in and ship it to production :)6 votes
- mailing list recipients
- logs3 votes
I find the failed reason value passed to webhook and classfied in Mailgun event log are different.
e.g. we just can get the reason value like "hardfail" or "old" from webhook, but we use Event api can get "bounce", "suppress-bounce", "old", "suppress-Complaint", .... these many reasons. so we want Mailgun can make the reason values are consistent in both ends.2 votes
This would be a useful safety feature in the event that something goes wrong in user code that is pushing messages thru mailgun.4 votes
Currently, Mailgun re-signs emails using DKIM and modifies mail headers when forwarding incoming mail. This causes Gmail, and possibly other spam filters, to give the email more trust than it should have. Could an option be provided to forward the existing envelope, without re-signing?2 votes
The time of the event is important to us and if the event time is only available from the Event API, then we will have to make additional calls to the Event API for EVERY single notification(delivered, failed, open, click etc), which may add significant load to our (and probably yours) server and network.2 votes
- Don't see your idea?