sendmail -t -i and -bs: What the Flags Do

Which sendmail binary are you actually running?

The first check is the program behind sendmail. On many Linux servers, applications call a path such as /usr/sbin/sendmail even though the actual mail system is Postfix or Exim.

This compatibility layer lets software written for a Sendmail-style submission interface keep working after the server administrator replaces the MTA. The path can stay unchanged while recipient handling, queue tools, logging, and some command-line behavior change underneath it.

This becomes easy to miss after a VPS migration. PHP still launches /usr/sbin/sendmail, the script itself has not changed, yet mail handling is different because the old host used one MTA and the new host uses another. That is not a DNS problem yet. First find out what the path executes.

Start with:

command -v sendmail
ls -l "$(command -v sendmail)"
readlink -f "$(command -v sendmail)"

A server may return a direct binary, a symbolic link, or an alternatives-system path. If the resolved filename already points into Postfix or Exim components, the answer may be obvious. If it does not, query the likely MTA directly.

For Postfix:

postconf mail_version

For Exim:

exim -bV

For a server that really runs Sendmail, version/debug output from Sendmail itself can help:

sendmail -d0.1 -bv root

Do not expect every command above to work on every host. A missing postconf does not prove that the server runs Exim, and an executable named sendmail does not prove that it is the original Sendmail implementation. Package-manager information can provide another clue if the path remains ambiguous.

The path you are debugging is roughly:

application
    |
    v
/usr/sbin/sendmail
    |
    v
Sendmail, Postfix, Exim, or another compatible MTA
    |
    v
mail queue and delivery system

The executable name is only the front door. The implementation behind it determines the details discussed below.

What does sendmail -t do with To, Cc, and Bcc?

sendmail -t tells the sendmail-style submission interface to obtain recipient addresses from recipient headers inside the message. The caller can therefore submit a message without listing every destination address after the sendmail command.

A minimal message might look like this:

To: alice@example.net
Cc: bob@example.net
Subject: Test message

Hello from the application.

It can then be passed as standard input:

sendmail -t < message.eml

A common support case looks simple at first: the raw message contains the correct To:, but the queue shows another or an additional recipient. The header looks fine. The envelope does not. At that point, stop reading the MIME source and inspect how the MTA built the delivery envelope.

With classic Sendmail, -t scans recipient headers such as To:, Cc:, and Bcc:, and the Bcc: header is removed before the message is transmitted. Compatible MTAs implement the same broad idea, but the exact behavior becomes more interesting when the command line also contains recipients.

For example:

sendmail -t extra@example.net < message.eml

Postfix documents that recipients extracted with -t are added to recipients supplied on the command line. Exim can behave differently: by default, its command-line address arguments can be treated as addresses to remove from the list extracted from the headers, and Exim configuration can change that behavior.

This matters in legacy scripts. A script may have used -t for years while also appending a recipient argument "just to be safe." After moving the application to another VPS, the same invocation can build a different envelope even though the source message has not changed.

What about Bcc-only messages, missing recipient headers, and Resent-* headers?

A message can use Bcc: as the only source of recipients for -t. The MTA can extract the Bcc recipient for the envelope and then remove the Bcc: header, leaving the delivered copy without that address in its visible headers. An application may add something like To: undisclosed-recipients:; for presentation, but that is separate from the delivery envelope.

If there is no usable To:, Cc:, or Bcc: recipient and no other recipient source accepted by the implementation, -t does not invent an address. Expect submission to fail or produce no deliverable recipient rather than assuming the From: header will somehow be used.

-t does not set the envelope sender from From:. Recipient extraction and sender selection are separate operations. This distinction is easy to lose when a message contains both visible sender and recipient headers.

Exim also documents special handling for Resent-* recipient headers when it processes a resent message. If a migrated application generates Resent-To: or Resent-Cc:, test that message separately instead of assuming the normal To:/Cc: path covers it.

Use the queue tools for the MTA to see what actually happened. With Postfix:

postqueue -p
postcat -q QUEUE_ID

With Exim:

exim -bp

Check both sides: recipient headers in the raw message and recipients recorded in the queue. The queue is the useful evidence here, with one caveat: aliases, forwarding, and later routing can expand or rewrite recipients after initial submission. A local queue recipient and the final external mailbox are not always identical.

What does sendmail -i do when the message contains a line with only a dot?

-i prevents a single-dot line from terminating ordinary non-SMTP message input. This matters when a complete message is being read from a file, pipe, or application's standard output.

Consider this body:

Line one
.
Line three

That middle line is not a period at the end of a sentence. Its entire content is one dot. In traditional sendmail-style input, such a line can act as an end-of-message marker unless the relevant dot handling is disabled.

With Postfix's sendmail-compatible command, ordinary input can end at EOF or at a line containing only .. The -i option tells the interface not to treat that line as the end of the message. Exim describes -i as equivalent to -oi for an incoming non-SMTP message. Classic Sendmail also documents leading-dot behavior as part of this option's semantics.

That makes this pattern useful for file or pipe submission:

sendmail -t -i < message.eml

Do not verify this only with an exit code. Put a control line after the dot and inspect the queued body. If Line three survives, you have checked the behavior that matters.

A single dot is different from a line beginning with a dot

These input lines are not equivalent:

hello
.
.hello
..hello

The line containing only . is the special terminator case in ordinary sendmail-style input. A line such as .hello contains actual message data. Classic Sendmail's historical dot processing also covers leading dots, which is why its documentation for -i/-oi is broader than the simple phrase "ignore a line containing one dot."

Do not assume every sendmail-compatible implementation copies all of those leading-dot details exactly. If your application genuinely emits body lines beginning with dots and the distinction matters, submit a minimal test to the installed MTA and inspect the stored message.

That separation explains a useful diagnostic symptom. If a message submitted from a file is cut off exactly before the line that follows an isolated dot, look at local input framing first. SPF, DKIM, MX records, and remote spam filtering cannot truncate a message before it has even entered the queue.

You can reproduce the distinction with controlled input:

sendmail -t < message-with-dot.eml
sendmail -t -i < message-with-dot.eml

Use a local test mailbox, a staging VPS, or another controlled recipient. Inspect the queue copy rather than sending deliberately malformed experiments to customer addresses.

What does sendmail -bs expect on stdin and stdout?

sendmail -bs expects an SMTP conversation on standard input and returns SMTP replies on standard output. The caller must behave like an SMTP client.

If you run:

sendmail -bs

and then paste only:

To: user@example.net
Subject: Test

Hello

the process is receiving the wrong protocol. In -bs mode, the conversation starts with SMTP commands:

EHLO localhost
MAIL FROM:<sender@example.com>
RCPT TO:<recipient@example.net>
DATA
From: sender@example.com
To: recipient@example.net
Subject: sendmail -bs test

Hello
.
QUIT

The server side replies between those commands with SMTP status lines such as 220, 250, or an error code. A real SMTP client reads those replies and decides whether it can continue. It does not blindly write an entire transcript into the pipe.

The envelope is explicit in this mode. MAIL FROM proposes the envelope sender and each RCPT TO proposes an envelope recipient. Only after a successful DATA command does the client send the message headers and body.

-bs does not mean any of the following:

• connect to localhost:25;
• connect directly to the recipient domain's MX server;
• open a TCP connection to port 587;
• take a raw RFC-style message and automatically turn it into an SMTP session.

The process is local. SMTP is simply being carried over stdin and stdout instead of the usual network socket.

A program that only creates MIME content cannot switch to -bs by changing one command-line flag. It needs SMTP client logic: send a command, read a reply, handle rejection, issue DATA, perform dot-stuffing, terminate the message correctly, and process the final SMTP result.

Exim provides another reason to keep the description precise. For a local -bs caller, whether the sender supplied in MAIL FROM is trusted can depend on the calling user and Exim configuration. A syntactically valid SMTP command is not a promise that the MTA will accept every requested envelope value unchanged.

If the application's first protocol words are EHLO, MAIL FROM, and RCPT TO, -bs is plausible. If its input begins with From:, To:, or Subject:, you are looking at ordinary message submission.

Why are sendmail -t -i and sendmail -bs not interchangeable?

sendmail -t -i accepts a complete message in sendmail-style submission mode. sendmail -bs accepts an SMTP transaction over process pipes. Both can eventually place mail into the same queue, but the caller must speak the correct interface.

How to tell which interface an application actually uses

When an integration breaks, the useful question is not "which flag looks more correct?" It is "what does the application send to the child process?" Three checks usually answer that quickly.

First, inspect the application configuration. A setting named sendmail_path, "sendmail transport," or local MTA command usually points to raw message submission. A configuration that contains an SMTP host, port, TLS mode, username, and password is describing network SMTP instead. A library specifically configured to run a local SMTP-over-stdio transport can use -bs, but that is a different interface again.

Second, inspect the actual process invocation. On a staging system, strace can reveal which executable and arguments are launched:

strace -f -e execve your-command-here

This will not decode the whole mail transaction, but it can show whether the application executed /usr/sbin/sendmail -t -i, sendmail -bs, another wrapper, or no local sendmail binary at all.

Third, look at the input signature. Raw message submission normally starts with headers:

From: app@example.net
To: user@example.net
Subject: Test

An SMTP client starts with protocol commands:

EHLO localhost
MAIL FROM:<app@example.net>
RCPT TO:<user@example.net>

The wrong mode can produce confusing symptoms. A raw-message application pointed at -bs may receive an SMTP greeting and then send To: or Subject: where the process expects SMTP commands. An SMTP-speaking application pointed at a raw submission interface may wait for replies that will never arrive in the expected form.

Do not debug delivery until this boundary is clear. If the caller and the local MTA are not even speaking the same input protocol, MX records and remote mail policy are several layers too far downstream.

Can -t, -i, and -bs be combined safely?

-t, -i, and -bs are not three generic "mail options" that become safer when combined. -t and -i belong to ordinary message-submission behavior; -bs selects an SMTP-speaking mode.

The familiar combination is:

/usr/sbin/sendmail -t -i

It makes sense when an application supplies a complete message, expects recipients to be extracted from headers, and should not have ordinary input terminated by an isolated dot. PHP's Unix mail configuration is a common place to see exactly this command.

You may also encounter:

sendmail -ti

Exim explicitly supports this as the equivalent of combining -t and -i. Do not automatically standardize that compact form across every Sendmail-compatible implementation without checking its documentation.

These combinations need more scrutiny:

sendmail -bs -i
sendmail -bs -t

Once -bs is active, SMTP defines how the caller supplies the envelope and frames DATA. Do not rely on options intended for ordinary submission to change SMTP protocol behavior unless the installed MTA explicitly documents the combination.

If you inherit an unfamiliar combination, use a short verification sequence instead of guessing:

1. Resolve the actual binary behind sendmail.
2. Read the sendmail man page or official command-line documentation for that MTA.
3. Determine whether the caller writes a raw message or SMTP commands.
4. Submit a controlled test message using the exact flags.
5. Inspect the queue envelope, stored body, and log entry.

Exit status alone is not enough. A command can successfully hand a message to the local MTA while still producing an envelope you did not intend.

The legacy combination that deserves the most attention is -t plus explicit recipient arguments. Postfix and Exim do not necessarily construct the recipient list the same way. If that command survived from an old server, reproduce it before migration rather than assuming compatibility from the binary name.

How do Sendmail, Postfix, and Exim differ in sendmail-compatible mode?

Sendmail, Postfix, and Exim support familiar sendmail-style options, but compatibility does not guarantee identical behavior in every edge case. The most important difference for this article is -t combined with command-line recipients.

Sendmail

Classic Sendmail is the reference point from which many of these command-line conventions came. With -t, it scans recipient headers and removes Bcc: before delivery. Its -i behavior also reflects Sendmail's historical handling of lines that begin with dots.

If the system actually runs Sendmail, use documentation for that installation rather than assuming a behavior observed on Postfix or Exim.

Postfix

Postfix supplies a sendmail(1) compatibility interface so existing applications can submit mail without being rewritten. Its normal sendmail-style submission reads a message from standard input and arranges for it to enter the Postfix queue.

Postfix adds recipients extracted by -t to recipients supplied on the command line. For example:

sendmail -t additional@example.net < message.eml

If a script migrated from another MTA, inspect the resulting recipient list instead of assuming the same envelope will be built.

Postfix -bs runs a stand-alone SMTP server mode through Postfix SMTP server logic. Its operational context is not identical to an Internet client connecting to the normal listening smtpd; Postfix documents different access-policy behavior for stand-alone operation.

Exim

For locally generated non-SMTP input, Exim -t obtains recipients from To:, Cc:, and Bcc:. If relevant Resent-* headers are present, Exim applies its resent-message rules when choosing recipient headers.

If address arguments are also present on the command line, Exim's documented default can treat those arguments as addresses to remove from the list extracted from the headers. The extract_addresses_remove_arguments setting can change this so argument addresses are added instead.

This is where migrations become deceptive: /usr/sbin/sendmail is still present, the script still starts, but the envelope changes.

How to compare behavior after a VPS or MTA migration

Do not compare only configuration files. Compare the actual submission path on the old and new systems:

1. Resolve /usr/sbin/sendmail on both servers.
2. Record the exact command-line arguments used by the application.
3. Submit the same minimal .eml file to both systems.
4. Compare the envelope recipients recorded by each MTA.
5. Compare the queued message body and submission log entries.

If the same input produces a different envelope, you have a local compatibility issue to investigate. If the envelope and queued content match but final delivery differs, move further down the delivery chain. Do not mix those two problems.

How can you test -t, -i, and -bs safely from the shell?

If a framework hides the transport, bypass it. Submit a minimal message directly to the same binary and inspect what reaches the queue. That removes PHP, the CMS, the framework, and most MIME-library behavior from the first diagnostic pass.

Use a staging server, a local mailbox created for diagnostics, or another recipient you control. A local alias such as root is not automatically isolated because administrators often forward it to an external mailbox.

Test 1: Verify recipient extraction with -t

Create a small message file:

cat > /tmp/sendmail-t-test.eml <<'EOF'
To: test-recipient@example.net
Subject: sendmail -t test

recipient extraction test
EOF

Submit it:

sendmail -v -t < /tmp/sendmail-t-test.eml

For a real test, replace the example address with a controlled local or staging recipient. Then inspect the queue and mail log. A successful process exit is not the main result. Confirm which envelope recipient the MTA stored.

Postfix:

postqueue -p
postcat -q QUEUE_ID

Exim:

exim -bp

Sendmail installations commonly provide:

mailq

If the message enters the queue and the recipient matches the address extracted from the header, you have verified the basic -t path on that implementation.

Test 2: Verify single-dot handling with -i

Create the file explicitly so the test is reproducible:

cat > /tmp/dot-test.eml <<'EOF'
To: controlled-recipient@example.net
Subject: sendmail dot test

before-dot
.
after-dot
EOF

Then compare the two submission forms on a controlled system:

sendmail -t < /tmp/dot-test.eml
sendmail -t -i < /tmp/dot-test.eml

Inspect the queued body. The line after-dot is your marker. If it disappears from the first submission but remains in the second, you have directly demonstrated the behavior -i is meant to change.

Give the two test messages different subjects or another identifying marker if both enter the queue. Otherwise it is surprisingly easy to inspect the wrong queue ID and draw the wrong conclusion.

Test 3: Verify -bs interactively

Start the process:

sendmail -bs

You should now be dealing with an SMTP-speaking process. Type commands one at a time and read the reply after each stage:

EHLO localhost
MAIL FROM:<sender@example.net>
RCPT TO:<controlled-recipient@example.net>
DATA
From: sender@example.net
To: controlled-recipient@example.net
Subject: sendmail -bs test

SMTP stdio test
.
QUIT

The exact replies depend on the MTA and configuration. A 250-class reply normally indicates acceptance of the corresponding command, while a 4xx or 5xx reply tells you where the SMTP transaction was deferred or rejected. If RCPT TO already failed, there is no reason to debug the message body yet.

Mail logs may be available through journalctl, /var/log/mail.log, /var/log/maillog, or an MTA-specific log path. Do not assume one location across every distribution. systemd service names and rsyslog layouts vary.

Useful starting points include:

journalctl -u postfix
journalctl -u exim4

tail -f /var/log/mail.log
tail -f /var/log/maillog

Use whichever commands match the server. The evidence you want is the same: accepted sender, accepted recipients, queue ID, stored message content, and any submission-time rejection.

A tiny shell reproducer often tells you which side is wrong. Either the MTA accepts exactly what it should and the bug sits higher up in PHP or the framework, or the application is handing valid input to a compatibility wrapper whose behavior differs from the one you expected.

Which sendmail mode should PHP, a script, or an SMTP-speaking application use?

Choose the sendmail mode from the format the application actually sends to the local process. A program that writes a complete email message needs a sendmail-style submission interface; a program that sends SMTP commands needs -bs. A program that opens a TCP connection to an SMTP host uses a different transport.

For a script that generates:

From: app@example.net
To: customer@example.net
Subject: Notification
Content-Type: text/plain; charset=UTF-8

The job has finished.

and writes it directly to a child process, sendmail -t -i is a common fit when recipients should be extracted from the headers.

PHP makes this combination especially familiar. On Unix-like systems, PHP documents a default sendmail_path of:

/usr/sbin/sendmail -t -i

Check what the local PHP CLI reports. If you are troubleshooting a Windows host instead, see Sendmail Windows.

php -i | grep -i sendmail_path

Why PHP CLI and PHP-FPM can show different sendmail settings

A common hosting symptom is that php -i shows the expected sendmail_path, yet WordPress or another PHP site still behaves as if a different command is configured. PHP CLI and the web SAPI may be reading different configuration. That happens with different php.ini files, additional scanned INI directories, PHP-FPM pool settings, Apache-specific configuration, or hosting-panel overrides.

Start by locating the CLI configuration:

php --ini

That tells you what the command-line interpreter loads. It does not prove that PHP-FPM uses the same files.

For a web application, inspect the configuration seen by the actual web SAPI. A temporary administrative phpinfo() page can show the loaded configuration file, scanned INI files, SAPI, and effective sendmail_path. Remove that page immediately after the check because it exposes detailed server information.

On managed hosting, the control panel may also expose the effective PHP version and per-site settings. If CLI says one thing and the website does another, confirm the web SAPI before changing the mail server. First reproduce it outside PHP.

If the application instead performs:

EHLO localhost
MAIL FROM:<sender@example.net>
RCPT TO:<recipient@example.net>
DATA

then -bs may be appropriate because the caller already implements SMTP over process pipes.

A configuration like this is different again:

SMTP host: smtp.example.net
Port: 587
Encryption: STARTTLS

That application is opening a network SMTP connection. The local /usr/sbin/sendmail command may not participate at all. Replacing an SMTP host configuration with sendmail -bs is not a like-for-like change. If the issue is the authenticated SMTP layer rather than local submission, the separate guide to VPS mail server authentication covers that configuration path.

What does successful local submission actually prove?

A zero exit status, successful SMTP reply, or queue ID proves only that the message reached a particular local submission stage successfully. It does not prove that the recipient's mail server accepted the message, that DNS resolution will succeed, or that the final message will reach the inbox.

This boundary saves time during diagnosis. If the queue contains the expected envelope sender, recipients, and complete body, the local sendmail interface probably did its part. From there, investigate routing, aliases, DNS, remote SMTP responses, authentication policy, or spam filtering as appropriate.

If the message never makes it into the queue, stay local. If it reaches the queue with the wrong envelope, stay local. If the body is already truncated in the queue, stay local. SPF and DKIM cannot fix any of those three problems.

Ten-minute checklist before changing sendmail flags

• Resolve the actual executable behind sendmail.
• Identify whether the server uses Sendmail, Postfix, Exim, or another compatible wrapper.
• Determine whether the application writes a complete message or SMTP commands to stdin.
• If -t is used, compare recipient headers, command-line recipient arguments, and the queue envelope.
• If -i matters, reproduce the input with a single-dot line and a control line after it.
• If -bs is used, confirm that the caller really performs an SMTP conversation and processes replies.
• After an MTA migration, submit the same minimal message to both systems and compare envelope recipients.
• For PHP, verify sendmail_path in the same SAPI that runs the site, not only in CLI.
• Reproduce the submission outside the CMS or framework.
• Inspect the mail queue and local logs before moving on to remote-delivery troubleshooting.

The flags are small; the interfaces behind them are not. Once you separate raw message submission, SMTP-over-stdio, the message headers, and the delivery envelope, most sendmail flag problems stop looking mysterious. You can see exactly which layer is wrong and test it directly.