SMTP error 504 5.5.4: command parameter not implemented

SMTP error 504 5.5.4 means the server recognised the base command you sent but does not

support one specific parameter attached to it. This is narrower than 502 ("command not

implemented" - the whole verb is unsupported) or 500 (the command could not even be parsed).

Here, MAIL FROM or a similar command was understood, but an optional ESMTP parameter riding

along with it - SMTPUTF8, BODY=8BITMIME, AUTH=, a vendor-specific extension - was not.

Fault: sender, specifically assuming a parameter the destination server never advertised

support for in its EHLO response.

Why it happens

• `SMTPUTF8` sent to a server that does not support internationalised addressing. This

extension is still not universally implemented; sending it to a server whose EHLO never

listed it produces exactly this error.

• `BODY=8BITMIME` sent to a server that only supports 7-bit transport. Older or minimal MTAs

may advertise basic ESMTP support without 8-bit MIME body handling.

• A client library hard-codes a parameter it assumes is universally supported, without

checking the destination's actual EHLO response first.

• A vendor-specific or proprietary ESMTP parameter sent to a generic or different vendor's

server that has no knowledge of it at all.

• A client library upgraded to a newer version that enables a parameter by default, where the

previous version never attempted it and the upgrade silently changed outbound behaviour against

destinations that have not changed at all on their own side.

• Testing against a modern, fully featured server during development, then deploying against

production destinations that include a mix of modern and considerably older mail systems - a

parameter that worked throughout testing can still fail against a subset of real-world

recipients the test environment never included.

Each of these points to the same underlying lesson: a parameter's availability is a property of

the specific connection, not a property of your client configuration in isolation, and treating it

as a fixed, global setting is what produces this error against an otherwise unremarkable

destination.

The transcript

$ swaks --to test@mailpilots.in --server legacy-relay.example.net \
        --from sender@yourdomain.com
-> EHLO sender.example.com
<- 250-legacy-relay.example.net
<- 250 SIZE 10485760
-> MAIL FROM:<sender@yourdomain.com> BODY=8BITMIME
<- 504 5.5.4 Command parameter not implemented

The EHLO response listed only SIZE - no 8BITMIME - and the server's reply is exactly

consistent with that: it understood MAIL FROM, just not the BODY=8BITMIME parameter attached

to it.

How the big three word it

Diagnose it

$ swaks --to test@mailpilots.in --server legacy-relay.example.net --quit-after EHLO
-> EHLO sender.example.com
<- 250-legacy-relay.example.net
<- 250 SIZE 10485760

The EHLO response is authoritative. If a parameter you plan to send is not in this list, it

will fail with 504 5.5.4 on this destination specifically, regardless of whether it works

against every other destination you send to.

The fix, in order

1. Check the destination's `EHLO` response before sending any optional ESMTP parameter,

rather than assuming universal support.

1. Drop the unsupported parameter for this specific destination - most mail libraries have a

setting to disable individual ESMTP extensions per-connection or globally.

1. For internationalised addresses specifically, fall back to an ASCII-compatible (Punycode)

representation when sending to a destination that does not advertise SMTPUTF8 support.

1. For 8-bit content sent to a 7-bit-only destination, ensure your MIME encoding uses

quoted-printable or base64 rather than relying on 8BITMIME transport.

1. Maintain a per-destination capability note if you repeatedly send to a mix of modern and

legacy mail systems, so the same sending code path does not need to renegotiate blind every

time.

What not to do

• Do not assume this is a content or authentication problem. It is purely a

parameter-support mismatch, unrelated to message content or credentials.

• Do not strip the parameter globally across all destinations just because one legacy system

does not support it - that needlessly degrades sending to every destination that does support

it.

• Do not keep retrying with the same unsupported parameter. The destination's capabilities

will not change between attempts.

• Do not confuse this with `502`. 504 means the base command worked and only a parameter

failed; 502 means the whole command was not recognised at all - different diagnoses, same

general family.

MailPilot checks each destination's actual advertised capabilities before applying any optional

ESMTP parameter, which avoids sending a parameter a specific receiving system never claimed to

support in the first place.