We're currently switching our email sending from SMTP to the HTTP API and noticed that some attachments were being silently dropped.
The main problem seems to be twofold:
1) the HTTP API requires non-ASCII filenames to be encoded using the "newish" RFC 7578 and simply ignores filenames encoded using the older RFC 2231.
2) attachments sent without filenames (or whose filenames were ignored because of #1) are simply dropped without warning, causing broken content to be sent.

Some more technical info can be found in this github issue: https://github.com/anymail/django-anymail/issues/125 (including examples of how to replicate)

Ideally, we'd expect mailgun to be able to accept filenames in either of the RFC formats, to enable usage with a broader range of client libraries. If that's not feasible, other options include (in decreasing order of usefulness):
- generating a filename on-the-fly for the cases where the filename cannot be parsed but also cannot be empty.
- throwing an error during submission, so that client systems are at least aware that something went wrong (attachment was submitted, but dropped).
- at the very, very least, logging a warning that the attachment was dropped.

As background to this, I read somewhere somebody saying "it's not really any body else's business when someone opens and reads an email" and also that "the biggest lie in tech is 'we value your privacy'".

Those are just kind of moral background to this, but there's a technical reason too --- while I could follow the magic road and start building a distributed application using lambda functions (and I get that in theory using those may be a good fit for processing webhooks, all other unknowns simply presumed equal - which of course they can't be), the simplest option is to point webhooks at the existing "monolith" app.

Since I am not making any use of the opens beyond the first (am I missing something in terms of their true usefulness? - why are subsequent opens ever useful?), I had wondered whether those could simply be switched off at source to reduce pointless load.

I'm curious as to why I seem to be seeing this situation differently from the norm, for clarity I am not building a massive app, it's a medium volume but tightly engineered one and I don't use many external services --- that might be the reason I guess, maybe developers at my scale are ususally not bothering with webhooks at all... but as I say I'm building something that's pretty finely tuned but not at tremendous scale at this point.

Your assumption that all authenticator apps work the same way is in error.

You reference a paper 2fa code that is provided when 2fa is activated. I see no paper 2fa code provided in the web interface upon activation. I do not see any email with a paper 2fa code. This paper code is supposedly how we can deactivate 2fa if we lost our 2fa device or app. My authenticator app does not provide any "paper key" when I setup mailgun with 2fa. I use LastPass authenticator.

My point is to indicate the instructions, and requirements for deactivating 2fa using a paper key, are broken.It would save your support time, when I lose my authenticator app, if you fix your workflow for recovering from this situation. Assuming all authenticator apps work like the one you tested with is a poor user experience.

An enhancement to the current possibility to drop (e.g.) spam, which is set on the (entire) domain level.

It would be nice to
--> add a route-action of block or drop,
--> generates SMTP error "554" to sender
--> show up in the logs as dropped.

This enhancement would allow to drop spam for a more fine grained selection like mail headers, keywords or specific addresses;

• DROP spam tagged messages (X-Mailgun-Sflag: Yes) for an entire domain, but DON'T DROP mails possibly tagged as spam to specific addresses or having specific keyword in the subject.

E.g. this would ensure that certain automated messages which happened to be tagged as spam, will never be dropped.

• ONLY drop spam tagged messages (X-Mailgun-Sflag: Yes) for certain addresses.

E.g. Addresses which may have been hacked/powned/... may resulting in large amounts of spam targeted at only a few addresses. This would allow tagging at the domain level, but also drop spam for these few accounts which may have resulted in high amount of mails/traffic.

From a functional perspective this can already be achived by:
- setting up a route with the specific criteria, and don't specify an action.

Unfortunately this results in the logs as "Accepted", and doesn't generate a SMTP error "554" towards the spammer...

Make the mailing list recipient variables available within the sendMessage call so that when sending to a list, dynamic recipient data can be set within the message v:my-custom-data.

So when you create a user within a mailing list you can set custom recipient variables via 'vars' on the create and update mailing list recipient call.

But when you then send a message to the pseudo email address, you cannot tag that message with the dynamic recipient variables within the v:my-custom-data string on the sendMessage call.

If you could access the recipient.vars within the sendMessage call, then you could tag individual messages with custom data that can be digested from the webhooks after sending bulk emails via the mailing list feature. This feature is not currently available, but seems like it should be. Otherwise, we can only digest the granular success of a bulk mail in whole rather than in a user-specific context.

Meg Phillips

Hi,

When creating and uploading emails to the mailing list with a csv file, "only one name/title , one email" format is supported.
I wish it was possible to have "1 name/title , first email, second email, third email , ..."
per line to be added.
Some times we have excel files in which there are more than one email per company or person.
Therefore instead of adding another line in csv with "same names , different email" per line in csv, it would be great to be able to add multiple emails per name in one line...

I hope you find this applicable.
Best Regards,
Burak Ural

It would be nice if we could export the nice graphs and charts on individual tag analytics pages. specifically i'm talking about https://app.mailgun.com/app/analytics/DOMAIN/TAGNAME/overview

this would be a great feature because then you can export individual stats to pdf or csv - the way we use the tagging feature is by company name. so each of our clients that uses our sending system we built is tagged based on the company name we setup for them. as it is currently we cannot export any of this data and will need to build our own solution via API. You all have the data being filtered and displayed why not add the ability to export those pretty charts/graphs and stats to PDF and csv for deliverability failures. this would make it much easier to maintain my clients lists. currently on the suppression tab we can filter unsubscribes based on tag but on failed deliveries everything that goes through our account is mixed so its impossible to separate which emails bounced from a specific clients list.