I am receiving some error messages like this:

Jan 28 17:20:47 halk postfix/smtpd[29413]: NOQUEUE:
    reject: RCPT from mail.m2osw.com[]:
    504 5.5.2 <SRS1=R3xB=m2osw.com==hj4N=ZL=lime.ocn.ne.jp=@com>:
    Sender address rejected: need fully-qualified address;
    to=<secret@valid.domain.tld> proto=ESMTP helo=<m2osw.com>

I'm not too sure I understand the "email" address found between the angle brackets:


That looks like crap to me, but maybe it's a form of envelop?

The original From looks like this:

From: western union <"westernunion1."@lime.ocn.ne.jp>

(which is a clear spam email, but that happens with non-spam as well.)

As far as I know my setup worked fine before, but I upgraded one of my mail servers to the newest postfix (well Ubuntu 16.04 instead of 14.04). The archive server was upgraded a while back.

This error happens when I send myself an email from gmail. Then gmail receives a bounce.

The setup is something like this:

+------------------+    +------------------+
|                  |    |                  |
| Client           |--->| Main Server      |
|                  |    |                  |
+------------------+    +------------------+
                        |                  |
                        | Archive Server   |
                        |                  |

On the Main Server, the email works as expected. The error occurs when the email reaches the Archive Server.

Is there something that could have changed that "breaks" the email address in such a way when forwarding from one postfix MTA to another?


I don't think so, the log that you shared shows that everything looks OK and postfix working good. If you need to have more information about what is going on, add the following to main.cf:

error_notice_recipient = postmaster@yourdom.com
delay_notice_recipient = $error_notice_recipient
bounce_notice_recipient = $error_notice_recipient
2bounce_notice_recipient = $error_notice_recipient
#The list of error classes that are reported to the postmaster
notify_classes = bounce, delay, policy, protocol, resource, software

The rejection is because one of these lines:


I hope this helps

| improve this answer | |
  • Well... the error said "reject". I'm not saying that the email looks good, but it works just find on the "Main Server" with the correct email. But by the time it reaches "Archive Server", it is transformed as shown above. The original was "westernunion1.@lime.ocn.ne.jp" (i.e. perfectly valid!) – Alexis Wilke Jan 29 '17 at 7:45
  • @Alexis.Wilke I saw the setup image thats why I sent you the lines so you can get more info and trace the error so put it on both server maybe somthing will come out. Or maybe it's filter from some sort that is broken after your uograde – Talal Al-Khalifa Jan 29 '17 at 7:53
  • Okay, I found it. It's the SRS (which is what appears at the start of that funky email address...), an extension used to support SPIF. sender_canonical_maps = tcp: and sender_canonical_classes = envelope_sender do the tweaking. I wonder how I can undo/avoid that when forwarding to the archive system. – Alexis Wilke Jan 29 '17 at 21:19

Okay, I found the culprit. These "weird" email addresses start with SRS, which points to the SPIF support that postfix can use through postsrsd. There are four entries that the postsrsd daemon author suggests to do in your postfix/main.cf file:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes= envelope_recipient,header_recipient

Clearly, that generates an envelope of the email address. The specification of that envelope is:


The problem in my case was that the domain name after the @ was being generated dynamically. This meant taking the full computer hostname and removing the first name. So if I have m2osw.com as the hostname, postsrsd ends up using com as the domain name. In other words, I would end up with email addresses that looked like:


Obviously, @com is not a valid domain name.

The postsrsd daemon uses some definitions found in file:


There we find a variable named SRS_DOMAIN. By setting that variable with the correct domain name:


Emails get enveloped as expected and the errors are gone. (i.e. we had that setup properly on our old "Main Server". We missed that while doing our transfer.)

| improve this answer | |
  • @Alexis.Wilke email configuration gets you every time lol! Good Job on finding it. and good info – Talal Al-Khalifa Jan 30 '17 at 2:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.