Opened 4 months ago

Closed 4 months ago

#30911 closed defect (fixed)

sending email to unknown recipient @tpo gets transient error instead of permanent?

Reported by: catalyst Owned by: anarcat
Priority: Medium Milestone:
Component: Internal Services/Tor Sysadmin Team Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


One common error that people make in addressing email is sending to instead of This ends up bouncing after a delay of a few days (with a 4xx transient error, which the sending MTA retries). It should probably either bounce immediately with a 5xx permanent error, or maybe automatically forward to The delayed bounce will prevent timely receipt of the email (when later correctly addressed), and might cause email to be lost completely (when the sender forgets to resend it).

I'm not sure whether this is a more general MTA config issue, or if it only affects lists.

Excerpt from bounce:

** Delivery incomplete **

There was a temporary problem delivering your message to Gmail will retry for 46 more hours. You'll be notified if the delivery fails permanently.

The response from the remote server was:
450 4.1.1 <>: Recipient address rejected: unverified address: User unknown in virtual alias table

Complete raw bounce message, with headers at
Original message at
Original was sent via gmail's SMTP server, with headers

From: Taylor Yu <>


Date: Thu, 13 Jun 2019 22:36:02 -0500

Child Tickets

Change History (4)

comment:1 Changed 4 months ago by anarcat

Owner: changed from tpa to anarcat
Status: newassigned

thanks for the detailed report cohosh! I'm looking into this now.

comment:2 Changed 4 months ago by anarcat

First off, I want to confirm that I have also suffered the same fate: you're not alone! :) I found it weird that my mail didn't get through first, then realized my mistake when looking at the headers, then wondered why the message didn't bounce, then resent the message, and *then* received the bounce, a week later. It's rather strange. ;)

I think I found out why this happens. In the Postfix server, we use the reject_unverified_recipient smtpd_recipient_restrictions, which, by default, will fail with a temporary error code (450) at first, which means it will stay in the queue for 7 days.

I believe there are two possible fixes for this problem:

  1. add reject_unlisted_recipient to the list of restrictions, which will immediately refuse emails with an unknown recipient, on submission, without queuing it
  1. change the unverified_recipient_reject_code to 550, but that says: "Do not change this unless you have a complete understanding of RFC 5321." ... which I'm not sure *anyone* can truly claim to have.

I'm running with the former at home. I'll check with my colleagues to validate the former is the right approach and we should be able to deploy this fix shortly. I won't do that today, unfortunately, because it's the weekend and I want to have tomorrow off. ;) But soon next week, hopefully.

comment:3 Changed 4 months ago by weasel

Status: assignedneeds_review

I think setting unverified_recipient_reject_code to 550 is the Right thing to do here, and I've made that change.

This will also mean that if any forward target rejects mail with a 5xx, we immediately reject things instead of telling the client to retry later. (If the forward target says 4xx, we stay with 450.)

comment:4 Changed 4 months ago by anarcat

Resolution: fixed
Status: needs_reviewclosed

confirmed as fixed by catalyst over IRC

Note: See TracTickets for help on using tickets.