Extra dot added to message lines (dot-stuffing not unstuffed correctly since v1.4.5+)

[miaoz2001]

Hi ,

Starting from aiosmtpd v1.4.5 (and still present in v1.4.6), message bodies received by the SMTP handler are incorrectly dot-stuffed — each line beginning with a . in the DATA section gets an extra dot prepended (..) when accessed in envelope.content.

This behaviour was not present in v1.4.4.post2, where dot-unstuffing worked correctly.

---

Test Code

(Attached in the issue)

The test sends the following message body containing two dots on a single line:

msg = b"""this is a test of dot
..
"""

---

Results

✅ v1.4.4.post2 (correct behaviour)

data: (354, b'End data with <CR><LF>.<CR><LF>')
send: b'this is a test of dot\n...\n\r\n.\r\n'        <- dot-stuffed during send (expected)

b'this is a test of dot\n..\n\r\n'                    <- correctly unstuffed (2 dots)

❌ v1.4.5+ (incorrect behaviour)

data: (354, b'End data with <CR><LF>.<CR><LF>')
send: b'this is a test of dot\n...\n\r\n.\r\n'        <- dot-stuffed during send (expected)

b'this is a test of dot\n...\n\r\n'                   <- not unstuffed (3 dots) ❌

---

Thanks!

[miaoz2001]

1_server.py
2_client.py

[miaoz2001]

I could be wrong, but it seems the issue was introduced by this change in how message data is read.

In v1.4.4.post2, the code used readuntil() (default delimiter \n), which effectively read the message line by line, allowing proper dot-unstuffing:

the data received: send: b'this is a test of dot\n...\n\r\n.\r\n'

try:
    line: bytes = await self._reader.readuntil()
    log.debug("DATA readline: %s", line)
    assert line.endswith(b"\n")

Starting from v1.4.5, this was changed to explicitly read until \r\n:

try:
    # https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.8
    line: bytes = await self._reader.readuntil(b"\r\n")
    log.debug("DATA readline: %s", line)
    assert line.endswith(b"\r\n")

As a result, the reader now appears to consume the entire message body as a single chunk rather than iterating line by line, which likely prevents the dot-unstuffing logic from running correctly on each line.

This could explain why lines starting with . are no longer unstuffed — leading to the extra dot (..) in message content.

[miaoz2001]

I understand this change was introduced as part of the SMTP smuggling fix (RFC 5321 § 2.3.8 compliance), so technically it may not be a bug — but it does introduce a breaking change in behaviour.

Any thoughts on whether this was intentional or if backward compatibility could be considered?

Thanks!

[miaoz2001]

I’ve had a second thought — this might still be a bug 🙂.
After readuntil(b"\r\n"), the buffer would contain something like this is a test of dot\n...\n
The code should then check if the line following the newline starts with multiple dots and perform dot-unstuffing accordingly.