Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not handling reject response correctly when multiple recipients #4125

popindavibe opened this issue Jul 24, 2019 · 0 comments


Copy link

commented Jul 24, 2019

Similar issues found


Root Cause

My mail server is enforcing a 'reject' rule on unknown recipient domain. So any email containing unknown domain will not be accepted.
It works with other MUA I tested, and indeed the 450 error is raised and no mail is sent until the list of recipients is sanitized.
In the case of K9-Mail, I end up with a mangled header missing multiple fields (From / Date) and with an 'unexpected end of header'.
For Googlemail, the server respond waving RFC 5322 and refuse to accept the email.
Others will discard and send a report to the recipient regarding the bad formatted email, and Outlook/Microsoft will accept it but it will be blank for the recipient.
On K9-Mail side, the email will be stuck forever in the Outbox, trying to resend the botched email every now and then, never succeeding (as expected).

Expected behavior

Whenever a recipient is rejected, the MUA should handle it gracefully. Testing with Thunderbird and SOGo, they both raise the error and do not try further attempts to deliver the email until the 'bad' recipients have been removed from the list.

K9-Mail should do the same and stop all attempt on receiving the reject from the mail server until the list of recipients has been sanitized.

Actual behavior

Mail server rejects the email, with and from=<> as per bouncing standards, however K9-Mail basically integrate that bad-formatted header and use it to try sending the email to the rest of the recipients.

Steps to reproduce

  1. Enforce reject rule on unknown recipient domains on your mail server (before any permit rule)
  2. Prepare an email to multiple recipients with at least one 'bad' recipient (ex: unknown domain. Ex:
  3. Send it from K9-Mail
  4. Check your Outbox in K9-Mail and your logs on the mail server


K-9 Mail version: 5.500

Android version: 8.1.0

Account type (IMAP, POP3, WebDAV/Exchange): IMAP

Please take some time to retrieve logs and attach them here:

Logs from the mail server:

Jul 23 09:44:35 myhost postfix/smtpd[26369]: connect from[XXX.XXX.XXX.137]
Jul 23 09:44:35 myhost postfix/smtpd[26369]: Anonymous TLS connection established from[XXX.XXX.XXX.137]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Jul 23 09:44:35 myhost postfix/smtpd[26369]: CEC231003:[XXX.XXX.XXX.137], sasl_method=PLAIN,
Jul 23 09:44:35 myhost postfix/smtpd[26369]: CEC231003: reject: RCPT from[XXX.XXX.XXX.137]: 450 4.1.2 <>: <b>Recipient address rejected: Domain not found</b>; from=<> to=<> proto=ESMTP helo=<[XXX.XXX.XXX.119]>
Jul 23 09:44:36 myhost postfix/cleanup[26374]: CEC231003: message-id=<>
Jul 23 09:44:36 myhost opendkim[32642]: <b>CEC231003: can't determine message sender; accepting</b>
Jul 23 09:44:36 myhost opendmarc[619]: CEC231003: RFC5322 requirement error: missing From field; accepting
Jul 23 09:44:36 myhost postfix/qmgr[26269]: CEC231003: from=<>, size=213, nrcpt=2 (queue active)
Jul 23 09:44:36 myhost postfix/smtp[26375]: Untrusted TLS connection established to[2a00:1450:400c:c0a::1b]:25: TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
Jul 23 09:44:36 myhost postfix/smtpd[26369]: disconnect from[XXX.XXX.XXX.137] ehlo=2 starttls=1 auth=1 mail=1 rcpt=2/3 data=1 quit=1 commands=9/10
Jul 23 09:44:36 myhost postfix/smtp[26375]: CEC231003: to=<>,[2a00:1450:400c:c0a::1b]:25, delay=0.99, delays=0.4/0.01/0.16/0.43, dsn=5.7.1, status=bounced (host[2a00:1450:400c:c0a::1b] said: 550-5.7.1 [2a01:4f8:10a:2493:b827:a8ff:fe4b:b71c      11] Our system has 550-5.7.1 detected that this message is not RFC 5322 compliant: 550-5.7.1 'From' header is missing. 550-5.7.1 To reduce the amount of spam sent to Gmail, this message has been 550-5.7.1 blocked. Please visit 550-5.7.1 550 5.7.1 and review RFC 5322 specifications for more information. y4si40902182wrr.356 - gsmtp (in reply to end of DATA command))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
1 participant
You can’t perform that action at this time.