This is really the only way to reject AMP4Email: Refuse to allow it, so that companies wanting to reach their customers can't implement it. However, it's unlikely large mail providers would choose to do this, I can't imagine Microsoft or Yahoo taking such a stand.

My own provider FastMail, has said they of course, can't promise they won't support AMP4Email since compatibility is a major goal of theirs, and I can't fault them for that. (And I significantly appreciate the contribution their blog has made to the discussion on the topic.) I'd love if I had the option to opt into behavior like this though, at least on a personal level.

But if only a few percent of users (or more than likely, a fraction of a percent) are rejecting the mail, it won't dissuade anyone. Companies will pick up AMP4Email so they can push dynamic advertising directly in people's inboxes.

If you run Amavis you can add a MIME type to the $banned_filename_re in a conf file (on debian based derivatives you'll normally find that in /etc/amavis/conf.d/20-debian_defaults).

  qr'^application/amp+html$'i,

is what I use.

If you want to put it in a separate file (such as a local config file) then you can just

  push(@$banned_filename_re,qr'^application/amp+html$'i);

Isn't the plus sign a special character in Perl regexes? That is, wouldn't you need to use this instead:

    qr'^application/amp\+html$'i,

You're right, thanks!

I still forget sometimes the differences between BRE, SRE, and ERE (mostly due to vim defaulting one thing and perl the other).

Me too, but ultimately this will mean not using services that decide to implement AMP. Most services will just see one or two weird customers creating issues for them. Also, unless you complain, they'd have to check their server logs, to even notice the deliverability issues.

You can just as well receive the e-mail and just complain if it's AMP only, or they don't pay attention to the plaintext part, causing issues for you.

A 501 return will cause an email bounce, so the sender will know that it has been refused. If you for example use "501 5.6.1 AMP format email messages not supported, please use a mail system that doesn't use AMP" then the sender will get that as the reason the mail was not sent.

I know, but AMP will be used mostly for automated email, and I'm not holding my breath many services that send me e-mail check their mailserver logs, if they even know such a thing exists. Bouncing to no-reply address will not help much either. And I need to receive e-mail from services I've registered to anyway, that's why I whitelist anything sent to a random email address that I assign to each service.

Better to just complain over channels where someone is actually listening.

>Bouncing to no-reply address will not help much either.

If someone does that, it's a good method to land on basically any spam blacklist out there.

Most larger providers like mailgun will tell you if you're bouncing a lot of mails and reduce your reputation. Same for gmail even.

Hmm, so if more people do this, anti-amp email blocking would reduce reputation of amp-email senders? Nice.

Indeed, atleast for most popular email providers that should be the case.

it also helps if you report senders that repeatedly bounce that way to spamlists. That usually gets a lively reaction.