[bug] Mail to support@ gets SMTP 550 saying, “Please contact support...”

[impurify]

Context: I was previously in a discussion with support@ about a payment question. It didn’t seem too urgent, so I dallied a few days in reply; it took me time and effort to gather some info for the message that I tried to send to support@ yesterday. I prefer not to discuss that further in a public venue. Please excuse the narrative format; I seek to explain the issue as completely as I can within its scope.

On 2025-01-04T03:00:58Z, in the ordinary course of use, smtp.purelymail.com gave me the following transient SMTP 4yz error:

450 4.3.2 Your account has hit sending rate limits. Please wait to send more emails, or contact support for a rate limit increase.

In the prior 7 days, I had sent 13 mails (three of which were tests addressed only to myself). I’ve never done any high-rate sending.

On 2025-01-04T14:25:13Z, I tried to send a message to a custom domain alias that routes to support@[a service that is purely mail and nothing else],[my-account]@purelymail.com for reasons explained in the message. smtp.purelymail.com gave me a permanent SMTP 550 5.3.2 error that included the words, “Please contact support”.

I had neither sent, nor attempted to send any mail in the interim.

On 2025-01-04T14:36:43Z, I got the same 550 when attempting to send v2 of the same message to support@ bcc myself. “Please contact support...”

On 2025-01-04T14:44:24Z, I got the same 550 when attempting to send v3 of the same message to support@ (only). “Please contact support...”

It took me another day or so to get here. I’m sorry, I have not used Microsoft Github in years, and I didn’t have an active account here. I had to find an available username—something meaningful, which will make me proud if I use this account for other purposes in the future. Then, I had to make a spiffy avatar! Then, I tried in good faith to read the Terms of Service and all other documents thereby invoked. I earnestly tried. (Did you?) After the user’s brain melted from an overdose of legalese (and I saw things that I definitely do not agree to, and I ran out of time anyway), I gave up and decided that I exigently need to report this issue by means other than purely mail.

If your email is broken, please email support is an old classic. I think it’s a bug. The service is in beta, so bugs are not unexpected—I just seem to have a talent for hitting the weird ones. 🥲

Again, I prefer to discuss my account with support@. Please keep the scope of this ticket to the issue that users should always be able to send mail to support@, even if their accounts have been limited for some reason.

[impurify]

After over three days without being able to send any mail, I eventually needed to move my domain elsewhere on 2025-01-07 (yesterday). That’s not a rejection of your service, @ScottPeterJohnson; I just needed to be able to send mail! Perhaps I may want to move it back—perhaps. In any case, I’m interested in straightening out this account, and I’d like to support independent mail services in today’s world of a centralized mail oligopoly.

Since support@ doesn’t have a PGP key (#263), please direct any correspondence to my @purelymail.com address; that way, as we discussed before, at least everything stays on the local server. For the same reason, I prefer not to mail support from another service.

Note for the record: I have not attempted to send any mail with this service since the SMTP 550 rejections noted in OP.

Thanks in advance.

[impurify]

support@ fixed up my account and contacted me today (2025-01-10). Thanks.

This is still a bug, insofar as users with an account on a service should always be able to send mail to support@ on the same service. I wasn’t merely talking about my account, but reporting the issue in the same spirit as I may report some much smaller beta-testing buglets I’ve encountered. Therefore, I will leave this issue open.

[ScottPeterJohnson]

It is a bug, yes. I remember intending to code it that way at some point such that you could always email support.

The major obstacle to just fixing it at the moment is I'll need to shuffle checking around, as currently ability to send is checked at the AUTH stage and not the RCPT stage, and it would need to be at RCPT to check if you're emailing support (but possibly that would make some clients think the problem is recipient specific).

[impurify]

Ah, I didn’t notice the difference of stages. My bad; my logs do reflect this. Perhaps start where it’s easiest.

In the SMTP 450 4.3.2 rejection at 2025-01-04T03:00:58Z (log timestamp on my machine, not necessarily yours), I reached the RCPT TO stage. The message was intended to be sent to three addresses: [0] Another individual in a public mailing list discussion, [1] the mailing list address, and [2] a self-bcc. Insofar as my log tells me, rejection happened at [0]. I don’t mind disclosing the recipient address, because the entire message was intended to be public.

Semi-rhetorical questions, answers to some of which you may not want to state publicly:

1. When the server gave me that 450, would it have accepted the message if the recipient was support@? (Side suggestion: Also always allow mail sent within the same account, such as self-bcc.)

2. What triggered the robot to change from blocking me with 450 at RCPT to 550 at AUTH?

The SMTP status line instructed me, “Please wait to send more emails, or contact support for a rate limit increase.” But waiting only resulted in the 550 at the AUTH stage.

(but possibly that would make some clients think the problem is recipient specific).

If a user’s MUA does not inform the user of SMTP status lines and diagnostic advice, that’s an MUA issue. If the user ignores this information, PEBKAC.

Not sorry to sound elitist... Your server does provide helpful diagnostic messages to the user. IIRC, even Microsoft Outlook Express bundled with Windows 98 would have showed those diagnostics in a window that popped up on failure. Any MUA that hides this information is faulty.

...but sorry for the delayed reply.

I decided to let these loosely-disconnected identities be linked, and use this Github account for other purposes. Thus, it needed upgrades before anything else.

[ScottPeterJohnson]

When the server gave me that 450, would it have accepted the message if the recipient was support@? (Side suggestion: Also always allow mail sent within the same account, such as self-bcc.)
What triggered the robot to change from blocking me with 450 at RCPT to 550 at AUTH?
The SMTP status line instructed me, “Please wait to send more emails, or contact support for a rate limit increase.” But waiting only resulted in the 550 at the AUTH stage.

Basically there's a rate limit that applies to all accounts, which is set to a low cap and nonrenewable for trial accounts. This gives you a 450 if it's hit. It applies at the RCPT stage (because it uses one from the cap for every recipient address).

Since this confused people with trial account, there's logic to notice this rate limit was hit on a trial account and set a flag that disables email sending for the account entirely and gives a special message. The check for the account being able to send email at all happens at the AUTH stage, and probably just needs to be moved to RCPT.