starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 16:35:53 +02:00

[GH-ISSUE #265] SMTP server error occurs when 'Content-Type' header is not present #205

New issue

Closed

opened 2026-05-07 00:21:25 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

2026-05-07 00:21:25 +02:00

Owner

Originally created by @dmbonsall on GitHub (May 21, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/265

I encountered an error whenever an email is sent to NTFY without a 'Content-Type' header. This error was found in docker image v1.23.0. Error was discovered while setting up email notifications from a pfsense appliance --> ntfy.

I believe that I have found the root cause of the problem, and I have proposed a solution below. I wanted to start off submitting an issue since I don't know go, but if nobody has time to address it, I can see if I can get a dev env up and running to submit a PR with a fix. Just let me know :)

Steps to reproduce:

Create test email file without 'Content-Type' header:

EHLO other.example.com
MAIL FROM: user@other.example.com
RCPT TO: topic@ntfy.example.com
DATA
Subject: Test email

Test message for NTFY
.
QUIT

Send to server with NC:

nc ntfy.example.com 22 < temp.txt

Server response:

220 ntfy.example.com ESMTP Service Ready
250-Hello other.example.com
250-PIPELINING
250-8BITMIME
250-ENHANCEDSTATUSCODES
250-CHUNKING
250-AUTH PLAIN
250 SIZE 1048576
250 2.0.0 Roger, accepting mail from <user@other.example.com>
250 2.0.0 I'll make sure <topic@ntfy.example.com> gets this
354 2.0.0 Go ahead. End your data with <CR><LF>.<CR><LF>
554 5.0.0 Error: transaction failed, blame it on the weather: mime: no media type
221 2.0.0 Bye

Diagnosis

In ntfy/server/smtp_server.go::readMailBody, the problem is with the line:

contentType, params, err := mime.ParseMediaType(msg.Header.Get("Content-Type"))

If 'Content-Type' header isn't set on the message, then msg.Header.Get("Content-Type") with return "". According to the mime library source, the function ParseMediaType returns an error if mediatype argument is "". Approximate stack trace is something like:

src/mime/mediatype.go:143 in ParseMediaType: https://cs.opensource.google/go/go/+/refs/tags/go1.18.2:src/mime/mediatype.go;l=143

    err = checkMediaTypeDisposition(mediatype)
    if err != nil {
        return "", nil, err
    }


src/mime/mediatype.go:103 in checkMediaTypeDisposition: https://cs.opensource.google/go/go/+/refs/tags/go1.18.2:src/mime/mediatype.go;l=106
    if typ == "" {
        return errors.New("mime: no media type")
    }

The error there is consistent with the SMTP server log message and error code above.

Proposed solution

Update ntfy/server/smtp_server.go::readMailBody to check if 'Content-Type' is set, and if not, default it to "text/plain" or some other, sensible default. This will ensure that any notification systems who do not set "Content-Type" will still have their notifications accepted.

Originally created by @dmbonsall on GitHub (May 21, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/265 I encountered an error whenever an email is sent to NTFY without a 'Content-Type' header. This error was found in docker image v1.23.0. Error was discovered while setting up email notifications from a pfsense appliance --> ntfy. I believe that I have found the root cause of the problem, and I have proposed a solution below. I wanted to start off submitting an issue since I don't know go, but if nobody has time to address it, I can see if I can get a dev env up and running to submit a PR with a fix. Just let me know :) ### Steps to reproduce: Create test email file without 'Content-Type' header: ``` EHLO other.example.com MAIL FROM: user@other.example.com RCPT TO: topic@ntfy.example.com DATA Subject: Test email Test message for NTFY . QUIT ``` Send to server with NC: ``` nc ntfy.example.com 22 < temp.txt ``` Server response: ``` 220 ntfy.example.com ESMTP Service Ready 250-Hello other.example.com 250-PIPELINING 250-8BITMIME 250-ENHANCEDSTATUSCODES 250-CHUNKING 250-AUTH PLAIN 250 SIZE 1048576 250 2.0.0 Roger, accepting mail from <user@other.example.com> 250 2.0.0 I'll make sure <topic@ntfy.example.com> gets this 354 2.0.0 Go ahead. End your data with <CR><LF>.<CR><LF> 554 5.0.0 Error: transaction failed, blame it on the weather: mime: no media type 221 2.0.0 Bye ``` ### Diagnosis In `ntfy/server/smtp_server.go::readMailBody`, the problem is with the line: ``` contentType, params, err := mime.ParseMediaType(msg.Header.Get("Content-Type")) ``` If 'Content-Type' header isn't set on the message, then `msg.Header.Get("Content-Type")` with return `""`. According to the `mime` library source, the function `ParseMediaType` returns an error if `mediatype` argument is `""`. Approximate stack trace is something like: ``` src/mime/mediatype.go:143 in ParseMediaType: https://cs.opensource.google/go/go/+/refs/tags/go1.18.2:src/mime/mediatype.go;l=143 err = checkMediaTypeDisposition(mediatype) if err != nil { return "", nil, err } src/mime/mediatype.go:103 in checkMediaTypeDisposition: https://cs.opensource.google/go/go/+/refs/tags/go1.18.2:src/mime/mediatype.go;l=106 if typ == "" { return errors.New("mime: no media type") } ``` The error there is consistent with the SMTP server log message and error code above. ### Proposed solution Update `ntfy/server/smtp_server.go::readMailBody` to check if 'Content-Type' is set, and if not, default it to "text/plain" or some other, sensible default. This will ensure that any notification systems who do not set "Content-Type" will still have their notifications accepted.

BreizhHardware

2026-05-07 00:21:25 +02:00

closed this issue
added the
🪲 bug

server
labels

BreizhHardware commented

2026-05-07 00:21:26 +02:00

Author

Owner

@binwiederhier commented on GitHub (May 21, 2022):

That has to be the most detailed bug report I have ever received. Thank you!! Will have it fixed in no time.

@binwiederhier commented on GitHub (May 21, 2022): That has to be the most detailed bug report I have ever received. Thank you!! Will have it fixed in no time.

BreizhHardware commented

2026-05-07 00:21:26 +02:00

Author

Owner

@binwiederhier commented on GitHub (May 22, 2022):

Had to read the MIME RFC to see if emails without content type are allowed, and that looks to be the case:

From https://datatracker.ietf.org/doc/html/rfc1521#page-13:

Default [RFC 822](https://datatracker.ietf.org/doc/html/rfc822) messages are typed by this protocol as plain text in
the US-ASCII character set, which can be explicitly specified as
"Content-type: text/plain; charset=us-ascii".  If no Content-Type is
specified, this default is assumed.

I fixed the issue here just like you proposed (github.com/binwiederhier/ntfy@2abd6a57ee), and it'll be in the next release.

Thank you for reporting the bug!

@binwiederhier commented on GitHub (May 22, 2022): Had to read the MIME RFC to see if emails without content type are allowed, and that looks to be the case: From https://datatracker.ietf.org/doc/html/rfc1521#page-13: Default [RFC 822](https://datatracker.ietf.org/doc/html/rfc822) messages are typed by this protocol as plain text in the US-ASCII character set, which can be explicitly specified as "Content-type: text/plain; charset=us-ascii". If no Content-Type is specified, this default is assumed. I fixed the issue here just like you proposed (https://github.com/binwiederhier/ntfy/commit/2abd6a57ee768806756c43a2832030776f826388), and it'll be in the next release. Thank you for reporting the bug!

BreizhHardware commented

2026-05-07 00:21:26 +02:00

Author

Owner

@dmbonsall commented on GitHub (May 22, 2022):

Happy to help, thanks for such a quick turn-around on this! Good find on the RFC docs, it's good to know the fix complies with the spec.

@dmbonsall commented on GitHub (May 22, 2022): Happy to help, thanks for such a quick turn-around on this! Good find on the RFC docs, it's good to know the fix complies with the spec.

BreizhHardware commented

2026-05-07 00:21:26 +02:00

Author

Owner

@ColonelThirtyTwo commented on GitHub (May 26, 2022):

The swaks testing tool sends such emails.

@ColonelThirtyTwo commented on GitHub (May 26, 2022): The swaks testing tool sends such emails.