Sender Rewriting Scheme, to rewrite envelope sender, as required for delivery of forwarded messages

Discuss Advanced use case
1

On an instance of Yunohost, I have configured some accounts for mail forwarding.

Due to limitations on the local network of the host, I am relying on an SMTP relay for delivery.

Following its security policy, the relay would not accept messages from the host until domain ownership had been verified.

Since verification, messages have been delivered remotely if originating on the host, which uses the verified domain, but not if forwarded by the host from an external sender.

After I reported the discrepancy to the operator, I was sent the following explanation:

Our relay checks the envelope sender, the address in the SMTP MAIL FROM command, and not only the From header. It accepts that address only if its domain is verified on your account. Mail you create on your host uses an envelope sender at the your domain, which is verified, so it goes through. A standard Postfix forward keeps the original sender as the envelope sender. A message forwarded from, say, a Gmail or Outlook sender reaches us with MAIL FROM set to that outside domain. You have not verified that domain and cannot, so the relay refuses it with the same ‘sender domain not verified’ error. This is a safeguard that stops an account from sending as domains it does not own, so we can’t relax it for your account.

The fix is on your host. Rewrite the envelope sender to an address on your domain when forwarding, which is called SRS (Sender Rewriting Scheme). On Postfix the usual way is to install postsrsd and enable it with sender_canonical_maps and recipient_canonical_maps. Set its domain to to your domain so forwarded mail leaves with a verified envelope sender. The original sender stays in the From header, and replies still reach them.

I am wondering whether any of the stated requirements are compatible with Yunohost.

Frankly, I fall to identify any reason for it to be inadequate simply that messages be signed by the original sender.

2

YNH has SRS running since long, but you should check your logs to know the domain that it actually uses, see:

3

Thank you for the explanation.

Naturally, it is extremely welcome that the feature is included in Yunohost.

Unfortunately, the observations overall suggest a lack of function on my instance. Since I have done nothing expected to interfere with the particular functionality, I am inclined to wonder whether I am facing a bug.

Regardless, it is most important initially to identify the cause of the misfunction.

I have checked the postfix logs, but found no relevant reporting.

I have also reviewed the discussion you referenced, but failed to recognize any direct relation between the discussion versus my problem.

Perhaps you could try to explain in more detail the steps you would suggest to seek a resolution.

4

Prepare a post with the relevant failing /var/log/mail.log lines, after replacing the domain info etc. with generic ones, and explain what you can make of it, comparing it to the quoted one above.

5

Sorry. What is meant by the “quoted one above”?

I understand that you would like me to share excerpts from a specific log, but I fail to understand the entirety of your suggestion.

6

I reviewed the mail logs, and found some entries for SRS.

It appears that the rewritten sender address is on the domain selected as the default within Yunohost, though it is different from the domain actually being used for mail.

It certainly seems more correct that the selected domain would be the one actually used for mail, in particular, the domain of the mail address of the user whose forwarding rule is being processed.

I am not certain presently whether it would be best to use the the mail address assigned to the user account, versus to use the address through which the current message has been received (which could be an alias), though I think it might be best that the sending domain is consistently the one of that has been functional for message originating locally from the user account, that is, the mail address assigned to the user. The latter choice ensures a unity among the three cases, of messages originating from the local user, messages originating externally and sent to the user, and message originating externally and sent to a group address of the group to which the user is a member.

Regardless, either would be a vast improvement over using the default domain.

As matters stand, it seems I have no choice but for the mail relay to verify the additional domain, despite that the domain is not used otherwise in any way related to mail.

Such a workaround is inconvenient and far from ideal. It would be best if I could prevent the rewritten addresses from using the domain simply that has been selected as the default.