Re: [PATCH] relax 553 ORCPT address syntax error (was Re: EMails to "ORCPT=rfc822;u...@example.co

[Tassilo Philipp]

Thanks for looking into this! Also thanks for taking this a step further 
and removing unneeded complexity, given the train of thought to consider 
this param an opaque string.


I tried the patch in a real world scenario, having rolled it out to 
multiple machines and relays, ran manual tests with this parameter, and 
I didn't spot any issues, so far.




On Mon, Dec 11, 2023 at 08:56:08PM +0100, Omar Polo wrote:

[moving to tech@]

This seems to be a long-standing issue in opensmtpd.  There seem to be 
(at least) one fairly popular application that uses a, upon a first 
look, odd ORCPT parameter:



On Fri, Oct 28, 2022 at 04:16:36PM +0200, Tim Kuijsten wrote:
I have refined and more thoroughly tested a previous patch that 
relaxes the ORCPT address check.


Over the years mail has been rejected by senders that use RCPT 
TO commands like:

RCPT TO:
ORCPT=rfc822;groupwise-i...@example.com:0:0 or RCPT 
TO:
ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE


In the above the domain part of the ORCPT address resolves to 
example.com:0:0 which is rejected by smtpd with the message:
smtpd[20797]: 1a3a396cd4c57d05 smtp failed-command command="RCPT 
TO:
ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE" result="553 ORCPT address syntax error"


[...]


Quoting RFC 3461, the ORCPT parameter is defined as (¶ 4.2)

 orcpt-parameter = "ORCPT=" original-recipient-address
 original-recipient-address = addr-type ";" xtext
 addr-type = atom

  The "addr-type" portion MUST be an IANA-registered electronic mail
  address-type (as defined in [3]), while the "xtext" portion contains
  an encoded representation of the original recipient address using the
  rules in section 5 of this document.

  [...]

  The "addr-type" portion of the original-recipient-address is used to
  indicate the "type" of the address which appears in the ORCPT
  parameter value.  However, the address associated with the ORCPT
  keyword is NOT constrained to conform to the syntax rules for that
  "addr-type".

I'd like to emphasize the last sentence, which is the one I missed 
upon the first couple of look at this RFC: even if addr-type is 
rfc822, the xtext part (once decoded) is not constrained to conform to 
the syntax rules of rfc822.


That is, this groupwise thingy is actually confirming to the rfc when 
using a param of "rfc822;groupwise-i...@example.com:0:0".


Honesty, I fail to understand the meaning of the addr-type if any 
gargabe is allowed.


The "once decoded" part is important since the RFC allows for ANY 
character to be encoded, so rfc822;+45+78+62+6d+70+6c+65+40... 
(i.e. example@...) is still a valid ORCPT param.


Tassilo' diff (which is a slightly modified version of the one 
originally sent in the bug report by Tim) is available here


https://www.mail-archive.com/misc@opensmtpd.org/msg06054.html

and it relaxes the checks but IMHO it doesn't address the underlying 
issue: we expect a valid rfc822 address where it's not mandatory.


I think we should just keep the ORCPT address as on opaque string 
(modulo some validation) without trying to parse it.


I still have to test the diff below in a real-world scenario, but I'm 
sending it out so other can hopefully give it a spin.


(and I couldn't resist splitting a long line in the process.)


Thanks,

Omar Polo


diff /home/op/w/smtpd
commit - 45a7eac758c7b1e9c4f16ab2dfcb25672b49aad9
path + /home/op/w/smtpd
blob - c9611beb48feab47602b766061a7546c375160a8
file + envelope.c
--- envelope.c
+++ envelope.c
@@ -443,7 +443,8 @@ ascii_load_field(const char *field, struct envelope *e 
		return ascii_load_uint8(>dsn_notify, buf);


if (strcasecmp("dsn-orcpt", field) == 0)
-   return ascii_load_mailaddr(>dsn_orcpt, buf);
+   return ascii_load_string(ep->dsn_orcpt, buf,
+   sizeof(ep->dsn_orcpt));

if (strcasecmp("dsn-ret", field) == 0)
return ascii_load_dsn_ret(>dsn_ret, buf);
@@ -703,11 +704,8 @@ ascii_dump_field(const char *field, const struct envel 
	if (strcasecmp(field, "dsn-ret") == 0)

return ascii_dump_dsn_ret(ep->dsn_ret, buf, len);

-   if (strcasecmp(field, "dsn-orcpt") == 0) {
-   if (ep->dsn_orcpt.user[0] && ep->dsn_orcpt.domain[0])
-   return ascii_dump_mailaddr(>dsn_orcpt, buf, len);
-   return 1;
-   }
+   if (strcasecmp(field, "dsn-orcpt") == 0)
+   return ascii_dump_string(ep->dsn_orcpt, buf, len);

if (strcasecmp(field, "dsn-envid") == 0)
return ascii_dump_string(ep->dsn_envid, buf, len);
blob - f0bb42c53ffb8f98012d542209bb55ecd1ae
file + mta.c
--- mta.c
+++ mta.c
@@ -809,11 +809,8 @@ mta_handle_envelope(struct envelope *evp, const char *

Re: [PATCH] relax 553 ORCPT address syntax error (was Re: EMails to "ORCPT=rfc822;u...@example.co

[Omar Polo]

[moving to tech@]

This seems to be a long-standing issue in opensmtpd.  There seem to be
(at least) one fairly popular application that uses a, upon a first
look, odd ORCPT parameter:

> >>> On Fri, Oct 28, 2022 at 04:16:36PM +0200, Tim Kuijsten wrote:
> >>>> I have refined and more thoroughly tested a previous patch that 
> >>>> relaxes the ORCPT address check.
> >>>>
> >>>> Over the years mail has been rejected by senders that use RCPT 
> >>>> TO commands like:
> >>>> RCPT TO: 
> >>>> ORCPT=rfc822;groupwise-i...@example.com:0:0 or RCPT 
> >>>> TO: 
> >>>> ORCPT=rfc822;groupwise-i...@example.com:0:0 
> >>>> NOTIFY=SUCCESS,FAILURE
> >>>>
> >>>> In the above the domain part of the ORCPT address resolves to 
> >>>> example.com:0:0 which is rejected by smtpd with the message:
> >>>> smtpd[20797]: 1a3a396cd4c57d05 smtp failed-command command="RCPT 
> >>>> TO: 
> >>>> ORCPT=rfc822;groupwise-i...@example.com:0:0 
> >>>> NOTIFY=SUCCESS,FAILURE" result="553 ORCPT address syntax error"
> >>>>
> >>>> [...]

Quoting RFC 3461, the ORCPT parameter is defined as (¶ 4.2)

  orcpt-parameter = "ORCPT=" original-recipient-address
  original-recipient-address = addr-type ";" xtext
  addr-type = atom

   The "addr-type" portion MUST be an IANA-registered electronic mail
   address-type (as defined in [3]), while the "xtext" portion contains
   an encoded representation of the original recipient address using the
   rules in section 5 of this document.

   [...]

   The "addr-type" portion of the original-recipient-address is used to
   indicate the "type" of the address which appears in the ORCPT
   parameter value.  However, the address associated with the ORCPT
   keyword is NOT constrained to conform to the syntax rules for that
   "addr-type".

I'd like to emphasize the last sentence, which is the one I missed
upon the first couple of look at this RFC: even if addr-type is
rfc822, the xtext part (once decoded) is not constrained to conform to
the syntax rules of rfc822.

That is, this groupwise thingy is actually confirming to the rfc when
using a param of "rfc822;groupwise-i...@example.com:0:0".

Honesty, I fail to understand the meaning of the addr-type if any
gargabe is allowed.

The "once decoded" part is important since the RFC allows for ANY
character to be encoded, so rfc822;+45+78+62+6d+70+6c+65+40...
(i.e. example@...) is still a valid ORCPT param.

Tassilo' diff (which is a slightly modified version of the one
originally sent in the bug report by Tim) is available here

https://www.mail-archive.com/misc@opensmtpd.org/msg06054.html

and it relaxes the checks but IMHO it doesn't address the underlying
issue: we expect a valid rfc822 address where it's not mandatory.

I think we should just keep the ORCPT address as on opaque string
(modulo some validation) without trying to parse it.

I still have to test the diff below in a real-world scenario, but I'm
sending it out so other can hopefully give it a spin.

(and I couldn't resist splitting a long line in the process.)


Thanks,

Omar Polo


diff /home/op/w/smtpd
commit - 45a7eac758c7b1e9c4f16ab2dfcb25672b49aad9
path + /home/op/w/smtpd
blob - c9611beb48feab47602b766061a7546c375160a8
file + envelope.c
--- envelope.c
+++ envelope.c
@@ -443,7 +443,8 @@ ascii_load_field(const char *field, struct envelope *e
return ascii_load_uint8(>dsn_notify, buf);
 
if (strcasecmp("dsn-orcpt", field) == 0)
-   return ascii_load_mailaddr(>dsn_orcpt, buf);
+   return ascii_load_string(ep->dsn_orcpt, buf,
+   sizeof(ep->dsn_orcpt));
 
if (strcasecmp("dsn-ret", field) == 0)
return ascii_load_dsn_ret(>dsn_ret, buf);
@@ -703,11 +704,8 @@ ascii_dump_field(const char *field, const struct envel
if (strcasecmp(field, "dsn-ret") == 0)
return ascii_dump_dsn_ret(ep->dsn_ret, buf, len);
 
-   if (strcasecmp(field, "dsn-orcpt") == 0) {
-   if (ep->dsn_orcpt.user[0] && ep->dsn_orcpt.domain[0])
-   return ascii_dump_mailaddr(>dsn_orcpt, buf, len);
-   return 1;
-   }
+   if (strcasecmp(field, "dsn-orcpt") == 0)
+   return ascii_dump_string(ep->dsn_orcpt, buf, len);
 
if (strcasecmp(field, "dsn-envid") == 0)
return ascii_dump_string(ep->dsn_envid, buf, len);
blob - f0bb42c53ffb8f98012d542209bb55ecd1ae
file + mta.c
--- mta.c
+++ mta.c
@@ -809,11 +809,8 @@ mta_handle_envelope(st

Re: [PATCH] relax 553 ORCPT address syntax error (was Re: EMails to "ORCPT=rfc822;u...@example.com" are rejected)

[Tassilo Philipp]

Sorry, some unnecessary whitespace change was part of the attached 
patch. Find attached a cleaned up version of the patch (functionally the 
same).


On Thu, Dec 07, 2023 at 01:34:42PM +0100, Tassilo Philipp wrote:
After a direct exchange with Omar Polo about the ORCPT patch, find 
attached a revised version of it. The changes compared to Tim's last 
patch are, just fyi:


1) valid_xtext() has been modified to avoid potential problems with 
sign extensions when using the ctype is*() functions. I also narrowed 
down the checks for hexchar letters to only allow ABCDEF (previously 
it just checked if it's an uppercase letter). A superflous string 
length check on hexchars was removed, b/c this is implicitly handled 
when checking the characters ('\0' fails the isdigit() check and 
related). While at it I reformatted a bit to be less verbose.


2) I reintroduced the check whether the entire ORCPT parameter exceeds 
the rfc3461 specified 500 char limit that Tim had in his previous 
patch.


3) I relaxed the check whether the ORCPT param is a valid mail 
address, which was done by text_to_mailaddr(). The reason is that it 
simply doesn't apply to the ORCPT parameter, as it's xtext encoded (so 
you could for example write '@' - which that function tries to find - 
as '+40'). It might also be a different address type altogether (e.g. 
X.400 as given as example by the rfc), etc.. so that 
text_to_mailaddr() logic might simply not apply to that param. So 
basically what's left is using that function only to see whether it's 
an uncommon ORCPT param (and printing that to the log), or not.


In theory, the xtext would have to be decoded, first, to be pendantic 
about this, which I skipped b/c it won't make a difference in this 
case for deliverability... not sure if this all should be simplified 
even more to just check for xtext, and that's it, not writing any 
"uncommon ORCPT param" to the log at all. In any case we leave the 
ORCPT param untouched. Thoughts?


4) The patch is now rebased against the latest version of opensmtpd.


Patch is attached

Cheers


On Sat, Nov 18, 2023 at 11:54:33AM +0100, Tassilo Philipp wrote:

Sorry for another bump of this patch: can it be merged?

I know the groupwise example in this thread is rare and doesn't 
affect a lot of smtpd users, but without it, it's unfortunately a 
bit of a blocker for some people. We personally apply this patch to 
our opensmtpd builds, but for others this might simply be a blocker 
to use opensmtpd, as they cannot control e.g. what a client uses to 
send them mail.


Such mails get rejected by any MTA on a route, no matter if the 
rejecting server is just a helper relay. The weird ORCP format used 
by groupwise is adhering to the RFC xtext spec, after all, and is 
valid.


If this cannot/won't be merged, please share the reasons for why not.

Thank you


On Thu, Jul 20, 2023 at 09:58:16AM +0200, Tassilo Philipp wrote:
Sorry to shamelessly "bump" this, but any way to get this 
integrated into upstream, eventually?


We used the original patch from Frank Scholl and then this 
improved one in production now for like a year, now, and didn't 
experience issues. In our case it is specifically needed for a 
client that uses GroupWise[0] internally to send mails (which 
seems to always generate mails with an "xtext" ORCPT param).


Thanks!

[0] https://www.microfocus.com/products/groupwise/


On Fri, Oct 28, 2022 at 04:16:36PM +0200, Tim Kuijsten wrote:
I have refined and more thoroughly tested a previous patch that 
relaxes the ORCPT address check.


Over the years mail has been rejected by senders that use RCPT 
TO commands like:
RCPT TO: 
ORCPT=rfc822;groupwise-i...@example.com:0:0 or RCPT 
TO: 
ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE


In the above the domain part of the ORCPT address resolves to 
example.com:0:0 which is rejected by smtpd with the message:
smtpd[20797]: 1a3a396cd4c57d05 smtp failed-command command="RCPT 
TO: 
ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE" result="553 ORCPT address syntax error"


I've studied RFC 3461 section 4 and 4.2 but it's not entirely 
clear to me if the above ORCPT command is valid or not. The 
encoding adheres to the spec, which says it must be valid xtext.


With this patch smtpd accepts any ORCPT that is valid xtext as 
defined in the RFC (and logs on informational message when it 
consists of an invalid user or domain name).


Cheers,

Tim

---
usr.sbin/smtpd/smtp_session.c | 22 ++ 
usr.sbin/smtpd/smtpd.h|  1 +
usr.sbin/smtpd/util.c | 32 
 3 files changed, 51 
insertions(+), 4 deletions(-)


diff --git a/usr.sbin/smtpd/smtp_session.c 
b/usr.sbin/smtpd/smtp_session.c index 72e13e8fd8d..c0c29d4a695 
100644

--- a/usr.sbin/smtpd/smtp_session.c
+++ b/usr.sbin/smtpd/smtp_session.c
@@ -2415,6 +2415,7 @@ smtp_tx_create_message(struct smtp_tx *tx) 
stat

Re: [PATCH] relax 553 ORCPT address syntax error (was Re: EMails to "ORCPT=rfc822;u...@example.com" are rejected)

[Tassilo Philipp]

After a direct exchange with Omar Polo about the ORCPT patch, find 
attached a revised version of it. The changes compared to Tim's last 
patch are, just fyi:


1) valid_xtext() has been modified to avoid potential problems with sign 
extensions when using the ctype is*() functions. I also narrowed down 
the checks for hexchar letters to only allow ABCDEF (previously it just 
checked if it's an uppercase letter). A superflous string length check 
on hexchars was removed, b/c this is implicitly handled when checking 
the characters ('\0' fails the isdigit() check and related). While at it 
I reformatted a bit to be less verbose.


2) I reintroduced the check whether the entire ORCPT parameter exceeds 
the rfc3461 specified 500 char limit that Tim had in his previous patch.


3) I relaxed the check whether the ORCPT param is a valid mail address, 
which was done by text_to_mailaddr(). The reason is that it simply 
doesn't apply to the ORCPT parameter, as it's xtext encoded (so you 
could for example write '@' - which that function tries to find - as 
'+40'). It might also be a different address type altogether (e.g. X.400 
as given as example by the rfc), etc.. so that text_to_mailaddr() logic 
might simply not apply to that param. So basically what's left is using 
that function only to see whether it's an uncommon ORCPT param (and 
printing that to the log), or not.


In theory, the xtext would have to be decoded, first, to be pendantic 
about this, which I skipped b/c it won't make a difference in this case 
for deliverability... not sure if this all should be simplified even 
more to just check for xtext, and that's it, not writing any "uncommon 
ORCPT param" to the log at all. In any case we leave the ORCPT param 
untouched. Thoughts?


4) The patch is now rebased against the latest version of opensmtpd.


Patch is attached

Cheers


On Sat, Nov 18, 2023 at 11:54:33AM +0100, Tassilo Philipp wrote:

Sorry for another bump of this patch: can it be merged?

I know the groupwise example in this thread is rare and doesn't affect 
a lot of smtpd users, but without it, it's unfortunately a bit of a 
blocker for some people. We personally apply this patch to our 
opensmtpd builds, but for others this might simply be a blocker to use 
opensmtpd, as they cannot control e.g. what a client uses to send them 
mail.


Such mails get rejected by any MTA on a route, no matter if the 
rejecting server is just a helper relay. The weird ORCP format used by 
groupwise is adhering to the RFC xtext spec, after all, and is valid.


If this cannot/won't be merged, please share the reasons for why not.

Thank you


On Thu, Jul 20, 2023 at 09:58:16AM +0200, Tassilo Philipp wrote:
Sorry to shamelessly "bump" this, but any way to get this integrated 
into upstream, eventually?


We used the original patch from Frank Scholl and then this improved 
one in production now for like a year, now, and didn't experience 
issues. In our case it is specifically needed for a client that uses 
GroupWise[0] internally to send mails (which seems to always 
generate mails with an "xtext" ORCPT param).


Thanks!

[0] https://www.microfocus.com/products/groupwise/


On Fri, Oct 28, 2022 at 04:16:36PM +0200, Tim Kuijsten wrote:
I have refined and more thoroughly tested a previous patch that 
relaxes the ORCPT address check.


Over the years mail has been rejected by senders that use RCPT TO 
commands like:
RCPT TO: 
ORCPT=rfc822;groupwise-i...@example.com:0:0 or RCPT 
TO: ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE


In the above the domain part of the ORCPT address resolves to 
example.com:0:0 which is rejected by smtpd with the message:
smtpd[20797]: 1a3a396cd4c57d05 smtp failed-command command="RCPT 
TO: ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE" result="553 ORCPT address syntax error"


I've studied RFC 3461 section 4 and 4.2 but it's not entirely 
clear to me if the above ORCPT command is valid or not. The 
encoding adheres to the spec, which says it must be valid xtext.


With this patch smtpd accepts any ORCPT that is valid xtext as 
defined in the RFC (and logs on informational message when it 
consists of an invalid user or domain name).


Cheers,

Tim

---
usr.sbin/smtpd/smtp_session.c | 22 ++ 
usr.sbin/smtpd/smtpd.h|  1 +
usr.sbin/smtpd/util.c | 32 
 3 files changed, 51 
insertions(+), 4 deletions(-)


diff --git a/usr.sbin/smtpd/smtp_session.c 
b/usr.sbin/smtpd/smtp_session.c index 72e13e8fd8d..c0c29d4a695 
100644

--- a/usr.sbin/smtpd/smtp_session.c
+++ b/usr.sbin/smtpd/smtp_session.c
@@ -2415,6 +2415,7 @@ smtp_tx_create_message(struct smtp_tx *tx) 
static void

smtp_tx_rcpt_to(struct smtp_tx *tx, const char *line)
{
+   struct mailaddr orcptaddr;
 char *opt, *p;
 char *copy;
 char tmp[SMTP_LINE_MAX]; @@ -2469,10 +2470,23 @@ 
sm

Re: [PATCH] relax 553 ORCPT address syntax error (was Re: EMails to "ORCPT=rfc822;u...@example.com" are rejected)

[Tassilo Philipp]

Sorry for another bump of this patch: can it be merged?

I know the groupwise example in this thread is rare and doesn't affect a 
lot of smtpd users, but without it, it's unfortunately a bit of a 
blocker for some people. We personally apply this patch to our opensmtpd 
builds, but for others this might simply be a blocker to use opensmtpd, 
as they cannot control e.g. what a client uses to send them mail.


Such mails get rejected by any MTA on a route, no matter if the 
rejecting server is just a helper relay. The weird ORCP format used by 
groupwise is adhering to the RFC xtext spec, after all, and is valid.


If this cannot/won't be merged, please share the reasons for why not.

Thank you


On Thu, Jul 20, 2023 at 09:58:16AM +0200, Tassilo Philipp wrote:
Sorry to shamelessly "bump" this, but any way to get this integrated 
into upstream, eventually?


We used the original patch from Frank Scholl and then this improved 
one in production now for like a year, now, and didn't experience 
issues. In our case it is specifically needed for a client that uses 
GroupWise[0] internally to send mails (which seems to always generate 
mails with an "xtext" ORCPT param).


Thanks!

[0] https://www.microfocus.com/products/groupwise/


On Fri, Oct 28, 2022 at 04:16:36PM +0200, Tim Kuijsten wrote:
I have refined and more thoroughly tested a previous patch that 
relaxes the ORCPT address check.


Over the years mail has been rejected by senders that use RCPT TO 
commands like:
RCPT TO: 
ORCPT=rfc822;groupwise-i...@example.com:0:0 or RCPT 
TO: ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE


In the above the domain part of the ORCPT address resolves to 
example.com:0:0 which is rejected by smtpd with the message:
smtpd[20797]: 1a3a396cd4c57d05 smtp failed-command command="RCPT 
TO: ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE" result="553 ORCPT address syntax error"


I've studied RFC 3461 section 4 and 4.2 but it's not entirely clear 
to me if the above ORCPT command is valid or not. The encoding 
adheres to the spec, which says it must be valid xtext.


With this patch smtpd accepts any ORCPT that is valid xtext as 
defined in the RFC (and logs on informational message when it 
consists of an invalid user or domain name).


Cheers,

Tim

---
usr.sbin/smtpd/smtp_session.c | 22 ++ 
usr.sbin/smtpd/smtpd.h|  1 +
usr.sbin/smtpd/util.c | 32  
3 files changed, 51 insertions(+), 4 deletions(-)


diff --git a/usr.sbin/smtpd/smtp_session.c 
b/usr.sbin/smtpd/smtp_session.c index 72e13e8fd8d..c0c29d4a695 
100644

--- a/usr.sbin/smtpd/smtp_session.c
+++ b/usr.sbin/smtpd/smtp_session.c
@@ -2415,6 +2415,7 @@ smtp_tx_create_message(struct smtp_tx *tx) 
static void

smtp_tx_rcpt_to(struct smtp_tx *tx, const char *line)
{
+   struct mailaddr orcptaddr;
  char *opt, *p;
  char *copy;
  char tmp[SMTP_LINE_MAX]; @@ -2469,10 +2470,23 @@ 
smtp_tx_rcpt_to(struct smtp_tx *tx, const char *line)

  if (strncasecmp(opt, "rfc822;", 7) == 0)
  opt += 7;

-   if (!text_to_mailaddr(>evp.dsn_orcpt, 
opt) || -
!valid_localpart(tx->evp.dsn_orcpt.user) || - 
(strlen(tx->evp.dsn_orcpt.domain) != 0 && - 
!valid_domainpart(tx->evp.dsn_orcpt.domain))) { +

if (!text_to_mailaddr(, opt)) {
+       smtp_reply(tx->session,
+   "553 ORCPT address syntax 
error"); +   return;

+   }
+
+   if (valid_localpart(orcptaddr.user) &&
+   (strlen(orcptaddr.domain) != 0 &&
+valid_domainpart(orcptaddr.domain))) { 
+   tx->evp.dsn_orcpt = orcptaddr;

+   } else if (valid_xtext(opt)) {
+   log_info("%016"PRIx64" smtp "
+   "uncommon ORCPT: \"%s\", 
u:\"%s\", d:\"%s\"",

+   tx->session->id,
+   opt, orcptaddr.user, 
orcptaddr.domain); +           tx->evp.dsn_orcpt 
= orcptaddr;

+   } else {
  smtp_reply(tx->session,
  "553 ORCPT address syntax error");
  return; diff --git 
a/usr.sbin/smtpd/smtpd.h b/usr.sbin/smtpd/smtpd.h

index 125a6a5dfbe..c59706885e2 100644
--- a/usr.sbin/smtpd/smtpd.h
+++ b/usr.sbin/smtpd/smtpd.h
@@ -1702,6 +1702,7 @@ int mailaddr_match(const struct mailaddr *, 
const struct mailaddr *);

int valid_localpart(const char *);
int valid_domainpart(const char *);
int valid_domainname(const char *);
+int valid_

Re: [PATCH] relax 553 ORCPT address syntax error (was Re: EMails to "ORCPT=rfc822;u...@example.com" are rejected)

[Tim Kuijsten]

Op 20-07-2023 om 09:58 schreef Tassilo Philipp:
Sorry to shamelessly "bump" this, but any way to get this integrated 
into upstream, eventually?


We used the original patch from Frank Scholl and then this improved one 
in production now for like a year, now, and didn't experience issues. In 
our case it is specifically needed for a client that uses GroupWise[0] 
internally to send mails (which seems to always generate mails with an 
"xtext" ORCPT param).


Thanks!

[0] https://www.microfocus.com/products/groupwise/


I also have to manually make sure with each update I apply this patch 
because of the software of a client of a client. Thanks for making 
explicit the connection with groupwise.

Re: [PATCH] relax 553 ORCPT address syntax error (was Re: EMails to "ORCPT=rfc822;u...@example.com" are rejected)

[Tassilo Philipp]

Sorry to shamelessly "bump" this, but any way to get this integrated 
into upstream, eventually?


We used the original patch from Frank Scholl and then this improved one 
in production now for like a year, now, and didn't experience issues. In 
our case it is specifically needed for a client that uses GroupWise[0] 
internally to send mails (which seems to always generate mails with an 
"xtext" ORCPT param).


Thanks!

[0] https://www.microfocus.com/products/groupwise/


On Fri, Oct 28, 2022 at 04:16:36PM +0200, Tim Kuijsten wrote:
I have refined and more thoroughly tested a previous patch that 
relaxes the ORCPT address check.


Over the years mail has been rejected by senders that use RCPT TO 
commands like:
RCPT TO: ORCPT=rfc822;groupwise-i...@example.com:0:0 or 
RCPT TO: ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE


In the above the domain part of the ORCPT address resolves to 
example.com:0:0 which is rejected by smtpd with the message:
smtpd[20797]: 1a3a396cd4c57d05 smtp failed-command command="RCPT 
TO: ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE" result="553 ORCPT address syntax error"


I've studied RFC 3461 section 4 and 4.2 but it's not entirely clear to 
me if the above ORCPT command is valid or not. The encoding adheres to 
the spec, which says it must be valid xtext.


With this patch smtpd accepts any ORCPT that is valid xtext as defined 
in the RFC (and logs on informational message when it consists of an 
invalid user or domain name).


Cheers,

Tim

---
usr.sbin/smtpd/smtp_session.c | 22 ++ 
usr.sbin/smtpd/smtpd.h|  1 +
usr.sbin/smtpd/util.c | 32  
3 files changed, 51 insertions(+), 4 deletions(-)


diff --git a/usr.sbin/smtpd/smtp_session.c b/usr.sbin/smtpd/smtp_session.c 
index 72e13e8fd8d..c0c29d4a695 100644

--- a/usr.sbin/smtpd/smtp_session.c
+++ b/usr.sbin/smtpd/smtp_session.c
@@ -2415,6 +2415,7 @@ smtp_tx_create_message(struct smtp_tx *tx) 
static void

smtp_tx_rcpt_to(struct smtp_tx *tx, const char *line)
{
+   struct mailaddr orcptaddr;
   char *opt, *p;
   char *copy;
   char tmp[SMTP_LINE_MAX]; 
@@ -2469,10 +2470,23 @@ smtp_tx_rcpt_to(struct smtp_tx *tx, const char 
*line)

   if (strncasecmp(opt, "rfc822;", 7) == 0)
   opt += 7;

-   if (!text_to_mailaddr(>evp.dsn_orcpt, opt) || 
-   !valid_localpart(tx->evp.dsn_orcpt.user) || 
-   (strlen(tx->evp.dsn_orcpt.domain) != 0 && 
-!valid_domainpart(tx->evp.dsn_orcpt.domain))) { 
+   if (!text_to_mailaddr(, opt)) {

+       smtp_reply(tx->session,
+   "553 ORCPT address syntax error"); 
+   return;

+   }
+
+   if (valid_localpart(orcptaddr.user) &&
+   (strlen(orcptaddr.domain) != 0 &&
+valid_domainpart(orcptaddr.domain))) { 
+   tx->evp.dsn_orcpt = orcptaddr;

+   } else if (valid_xtext(opt)) {
+   log_info("%016"PRIx64" smtp "
+   "uncommon ORCPT: \"%s\", u:\"%s\", 
d:\"%s\"",

+   tx->session->id,
+   opt, orcptaddr.user, orcptaddr.domain); 
+           tx->evp.dsn_orcpt = orcptaddr;

+   } else {
   smtp_reply(tx->session,
   "553 ORCPT address syntax error");
   return; 
diff --git a/usr.sbin/smtpd/smtpd.h b/usr.sbin/smtpd/smtpd.h

index 125a6a5dfbe..c59706885e2 100644
--- a/usr.sbin/smtpd/smtpd.h
+++ b/usr.sbin/smtpd/smtpd.h
@@ -1702,6 +1702,7 @@ int mailaddr_match(const struct mailaddr *, 
const struct mailaddr *);

int valid_localpart(const char *);
int valid_domainpart(const char *);
int valid_domainname(const char *);
+int valid_xtext(const char *s);
int valid_smtp_response(const char *);
int secure_file(int, char *, char *, uid_t, int);
int  lowercase(char *, const char *, size_t);
diff --git a/usr.sbin/smtpd/util.c b/usr.sbin/smtpd/util.c
index feb663cc61e..0c4d0015fa4 100644
--- a/usr.sbin/smtpd/util.c
+++ b/usr.sbin/smtpd/util.c
@@ -515,6 +515,38 @@ valid_domainname(const char *str)
   return 1; 
}


+int
+valid_xtext(const char *s)
+{
+   while (*s != '\0') {
+   if (*s == '=')
+   return 0;
+
+   if (*s < '\x21' || *s > '\x7e')
+   return 0;
+
+   if (*s 

[PATCH] relax 553 ORCPT address syntax error (was Re: EMails to "ORCPT=rfc822;u...@example.com" are rejected)

[Tim Kuijsten]

I have refined and more thoroughly tested a previous patch that relaxes 
the ORCPT address check.


Over the years mail has been rejected by senders that use RCPT TO 
commands like:

RCPT TO: ORCPT=rfc822;groupwise-i...@example.com:0:0 or
RCPT TO: ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE


In the above the domain part of the ORCPT address resolves to 
example.com:0:0 which is rejected by smtpd with the message:
smtpd[20797]: 1a3a396cd4c57d05 smtp failed-command command="RCPT 
TO: ORCPT=rfc822;groupwise-i...@example.com:0:0 
NOTIFY=SUCCESS,FAILURE" result="553 ORCPT address syntax error"


I've studied RFC 3461 section 4 and 4.2 but it's not entirely clear to 
me if the above ORCPT command is valid or not. The encoding adheres to 
the spec, which says it must be valid xtext.


With this patch smtpd accepts any ORCPT that is valid xtext as defined 
in the RFC (and logs on informational message when it consists of an 
invalid user or domain name).


Cheers,

Tim

---
 usr.sbin/smtpd/smtp_session.c | 22 ++
 usr.sbin/smtpd/smtpd.h|  1 +
 usr.sbin/smtpd/util.c | 32 
 3 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/usr.sbin/smtpd/smtp_session.c b/usr.sbin/smtpd/smtp_session.c
index 72e13e8fd8d..c0c29d4a695 100644
--- a/usr.sbin/smtpd/smtp_session.c
+++ b/usr.sbin/smtpd/smtp_session.c
@@ -2415,6 +2415,7 @@ smtp_tx_create_message(struct smtp_tx *tx)
 static void
 smtp_tx_rcpt_to(struct smtp_tx *tx, const char *line)
 {
+   struct mailaddr orcptaddr;
char *opt, *p;
char *copy;
char tmp[SMTP_LINE_MAX];
@@ -2469,10 +2470,23 @@ smtp_tx_rcpt_to(struct smtp_tx *tx, const char 
*line)

if (strncasecmp(opt, "rfc822;", 7) == 0)
opt += 7;

-   if (!text_to_mailaddr(>evp.dsn_orcpt, opt) ||
-   !valid_localpart(tx->evp.dsn_orcpt.user) ||
-   (strlen(tx->evp.dsn_orcpt.domain) != 0 &&
-!valid_domainpart(tx->evp.dsn_orcpt.domain))) {
+   if (!text_to_mailaddr(, opt)) {
+   smtp_reply(tx->session,
+       "553 ORCPT address syntax error");
+   return;
+   }
+
+   if (valid_localpart(orcptaddr.user) &&
+   (strlen(orcptaddr.domain) != 0 &&
+valid_domainpart(orcptaddr.domain))) {
+   tx->evp.dsn_orcpt = orcptaddr;
+   } else if (valid_xtext(opt)) {
+   log_info("%016"PRIx64" smtp "
+   "uncommon ORCPT: \"%s\", u:\"%s\", 
d:\"%s\"",

+   tx->session->id,
+   opt, orcptaddr.user, orcptaddr.domain);
+   tx->evp.dsn_orcpt = orcptaddr;
+   } else {
smtp_reply(tx->session,
"553 ORCPT address syntax error");
return;
diff --git a/usr.sbin/smtpd/smtpd.h b/usr.sbin/smtpd/smtpd.h
index 125a6a5dfbe..c59706885e2 100644
--- a/usr.sbin/smtpd/smtpd.h
+++ b/usr.sbin/smtpd/smtpd.h
@@ -1702,6 +1702,7 @@ int mailaddr_match(const struct mailaddr *, const 
struct mailaddr *);

 int valid_localpart(const char *);
 int valid_domainpart(const char *);
 int valid_domainname(const char *);
+int valid_xtext(const char *s);
 int valid_smtp_response(const char *);
 int secure_file(int, char *, char *, uid_t, int);
 int  lowercase(char *, const char *, size_t);
diff --git a/usr.sbin/smtpd/util.c b/usr.sbin/smtpd/util.c
index feb663cc61e..0c4d0015fa4 100644
--- a/usr.sbin/smtpd/util.c
+++ b/usr.sbin/smtpd/util.c
@@ -515,6 +515,38 @@ valid_domainname(const char *str)
return 1;
 }

+int
+valid_xtext(const char *s)
+{
+   while (*s != '\0') {
+   if (*s == '=')
+   return 0;
+
+   if (*s < '\x21' || *s > '\x7e')
+   return 0;
+
+   if (*s == '+') {
+   /* expect hexchar "+XX" RFC 3461 4. */
+   if (strnlen(s, 3) != 3)
+   return 0;
+
+   s++;
+
+   if (!isdigit(*s) && !isupper(*s))
+   return 0;
+
+   s++;
+
+   if (!isdigit(*s) && !isupper(*s))
+   return 0;
+   }
+
+   s++;
+   }
+
+   return 1;
+}
+
 int
 valid_smtp_response(const char *s)
 {
--
2.37.3

Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7

[Martijn van Duren]

On Wed, 2020-07-29 at 02:57 -0400, Larkin Nickle wrote:
> On 2020-07-29 02:54, Martijn van Duren wrote:
> > I was talking about the mails we exchanged in private.
> > 
> > On Wed, 2020-07-29 at 02:51 -0400, Larkin Nickle wrote:
> > > I did obtain consent before sending here but didn't mention it.
> 
> Oh right, I'm sorry about that. I was under the impression I just 
> started a chain out of the mailing list by hitting the wrong reply 
> button somewhere and we just kept going out-of-list by mistake. You're 
> right, I should've asked.
> 
No harm done and apology accepted.

Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7

[Martijn van Duren]

I was talking about the mails we exchanged in private.

On Wed, 2020-07-29 at 02:51 -0400, Larkin Nickle wrote:
> I did obtain consent before sending here but didn't mention it.

Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7

[Larkin Nickle]

On 2020-07-29 02:54, Martijn van Duren wrote:

I was talking about the mails we exchanged in private.

On Wed, 2020-07-29 at 02:51 -0400, Larkin Nickle wrote:

I did obtain consent before sending here but didn't mention it.




Oh right, I'm sorry about that. I was under the impression I just 
started a chain out of the mailing list by hitting the wrong reply 
button somewhere and we just kept going out-of-list by mistake. You're 
right, I should've asked.

Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7

[Larkin Nickle]

I did obtain consent before sending here but didn't mention it.

Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7

[Martijn van Duren]

On Tue, 2020-07-28 at 22:05 -0400, Larkin Nickle wrote:
> On 2020-07-28 06:02, Martijn van Duren wrote:
> > On Tue, 2020-07-28 at 05:37 -0400, Larkin Nickle wrote:
> > > > Doing a little more searching on "ORCPT :1:1" shows me the following
> > > > links:
> > > > https://groups.google.com/forum/#!topic/mailing.postfix.users/a2wjRII3Q_Y
> > > > https://community.microfocus.com/t5/GroupWise-User-Discussions/550-5-7-1-Unable-to-relay-to-certain-provider/td-p/2302331?p=2287440
> > > > https://info-ims.arnold.narkive.com/GtKAJz28/off-topic-research-on-rcpt-to-s-orcpt-extension
> > > > All complaining about that postfix.
> > > > 
> > > > This looks more and more like a misfeature from groupwise. So unless
> > > > there is some solid evidence that this is actually allowed I'd tell
> > > > your colleague to either turn of this misfeature or change software.
> > > > Or my personal favourite: If I can't receive your mails because you
> > > > violate the protocol I can't handle any requests in those mails.
> > > > 
> > > 
> > > It doesn't actually seem like DSN is enabled as there's no "NOTIFY=" in
> > > the SMTP command either (in the last link they said turning off DSN
> > > server-side fixed things). GroupWise is a major email server software,
> > > if this is actually the issue I wonder if it would be better to just
> > > work around it (esp. since others seem to).
> > 
> > Just because it's major doesn't mean it does the correct thing, just
> > because others don't seem to trip over it doesn't mean it's wise to
> > deviate from the spec.
> > 
> > Personally I'm not inclined to change this check for (imho) the worst,
> > but I'm not the lead developer on this project. So if you want it
> > changed you can write a diff around the smtp_session.c code I pointed
> > to in my previous mail with a detailed explination on how this
> > improves the situation, how this header attribute is/can be used down
> > the line and how this may or may not negatively impact that downstream.
> > Even better would be if you can point to the part of the specifications
> > that allow for this behaviour.
> > 
> > It's quite a bit of work and it might still not be accepted. I'm
> > unlikely to commit it unless you can show me I'm wrong in my previous
> > assessment, but I won't object if you can show us it's not detrimental.
> > 
> > Hope this helps.
> > 
> 
> He got this reply from Micro Focus upon asking them about it:
> 
> ```
> I was able to find a defect that matched this issue back in 2009 for 
> GroupWise version 8.
> 
> The defect specifically mentions that we are following the RFC as directed:
> 
> The :1:1 is essential to GroupWise status tracking.
> The numbers represent the host and user numbers for the creating a 
> GroupWise internal status message.
> 
> According to the RFC, the format of the ORCPT is ;xtext
> We use RFC822 for the address type and we use xtext to contain the 
> information that we need, which is
> groupwise-::
> 
> xtext is defined (see http://tools.ietf.org/html/rfc3461) as any ASCII 
> characters between "!" and "~" excluding "+" and "="
> 
> If this were not the case, we would be seeing tons of undeliverables, 
> but we are not. GroupWise 18.2.1 was released on March 4th of this year 
> and this is the first case we have dealing with undeliverables because 
> of the RFC standard.
> ```
> 
> So according to them it should actually be okay and OpenSMTPD is wrong 
> here. (check 4. Additional parameters for RCPT and MAIL commands for 
> example)
> 

While they are correct that the ABNF only prescribes xtext, they fail to
look at the text the paragraph directly after it:

while the "xtext" portion contains an encoded representation of the
original recipient address using the rules in section 5 of this document.

and the paragraph after that opens with:

When initially submitting a message via SMTP, if the ORCPT parameter is
used, it MUST contain the same address as the RCPT TO address (unlike
the RCPT TO address, the ORCPT parameter will be encoded as xtext).

Now let's follow it to section 5.2.1 (final sentence):

(d) If any ORCPT parameter was present in the RCPT command for a
recipient when the message was received, an ORCPT parameter with the
identical original-recipient-address MUST appear in the RCPT command
issued for that recipient when relaying the message. (For example, the
MTA therefore MUST NOT change the case of any alphabetic characters in
an ORCPT parameter.) If no ORCPT parameter was present in the RCPT
command when the message was received, an ORCPT parameter MAY be added
to the RCPT command when the message is relayed.  If an ORCPT parameter
is added by the relaying MTA, it MUST contain the recipient address
from the RCPT command used when the message was received by that MTA.

Now the only potential ambiguity I see here is the word contain, but
considering it's not accompanied by phrases like "may also contain" or
"next to" or even better "additional information can be added by the

Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7

[Larkin Nickle]

On 2020-07-28 06:02, Martijn van Duren wrote:

On Tue, 2020-07-28 at 05:37 -0400, Larkin Nickle wrote:

Doing a little more searching on "ORCPT :1:1" shows me the following
links:
https://groups.google.com/forum/#!topic/mailing.postfix.users/a2wjRII3Q_Y
https://community.microfocus.com/t5/GroupWise-User-Discussions/550-5-7-1-Unable-to-relay-to-certain-provider/td-p/2302331?p=2287440
https://info-ims.arnold.narkive.com/GtKAJz28/off-topic-research-on-rcpt-to-s-orcpt-extension
All complaining about that postfix.

This looks more and more like a misfeature from groupwise. So unless
there is some solid evidence that this is actually allowed I'd tell
your colleague to either turn of this misfeature or change software.
Or my personal favourite: If I can't receive your mails because you
violate the protocol I can't handle any requests in those mails.



It doesn't actually seem like DSN is enabled as there's no "NOTIFY=" in
the SMTP command either (in the last link they said turning off DSN
server-side fixed things). GroupWise is a major email server software,
if this is actually the issue I wonder if it would be better to just
work around it (esp. since others seem to).


Just because it's major doesn't mean it does the correct thing, just
because others don't seem to trip over it doesn't mean it's wise to
deviate from the spec.

Personally I'm not inclined to change this check for (imho) the worst,
but I'm not the lead developer on this project. So if you want it
changed you can write a diff around the smtp_session.c code I pointed
to in my previous mail with a detailed explination on how this
improves the situation, how this header attribute is/can be used down
the line and how this may or may not negatively impact that downstream.
Even better would be if you can point to the part of the specifications
that allow for this behaviour.

It's quite a bit of work and it might still not be accepted. I'm
unlikely to commit it unless you can show me I'm wrong in my previous
assessment, but I won't object if you can show us it's not detrimental.

Hope this helps.



He got this reply from Micro Focus upon asking them about it:

```
I was able to find a defect that matched this issue back in 2009 for 
GroupWise version 8.


The defect specifically mentions that we are following the RFC as directed:

The :1:1 is essential to GroupWise status tracking.
The numbers represent the host and user numbers for the creating a 
GroupWise internal status message.


According to the RFC, the format of the ORCPT is ;xtext
We use RFC822 for the address type and we use xtext to contain the 
information that we need, which is

groupwise-::

xtext is defined (see http://tools.ietf.org/html/rfc3461) as any ASCII 
characters between "!" and "~" excluding "+" and "="


If this were not the case, we would be seeing tons of undeliverables, 
but we are not. GroupWise 18.2.1 was released on March 4th of this year 
and this is the first case we have dealing with undeliverables because 
of the RFC standard.

```

So according to them it should actually be okay and OpenSMTPD is wrong 
here. (check 4. Additional parameters for RCPT and MAIL commands for 
example)

Fwd: 553 ORCPT address syntax error on OpenBSD 6.7

[Larkin Nickle]

Someone from a corporation that uses GroupWise for email is unable to 
get their mail to deliver to my server running OpenBSD. In the log, I see:


Jul 27 22:10:39 hostname smtpd[34369]: de587a23456fe10c smtp 
failed-command command="RCPT TO: 
ORCPT=rfc822;groupwise...@l..org:1:1" result="553 ORCPT address 
syntax error"


My best guess is that GroupWise is maybe appending :1:1 to the end of 
the address and this is what is tripping this syntax error. They are 
able to successfully send mail to me on Google Mail, Outlook, etc. mail 
accounts.

Re: 553 ORCPT address syntax error

[William Carson]

> On Jun 15, 2020, at 6:43 AM, Tony Boston  wrote:
> 
> Hi,
> 
> I have an issue with forwarding mails which belong to the local root user.
> I never had that and it seems something changed in opensmtpd?
> 
> In /etc/mail/aliases I used to say 
>   root: sys...@example.com
> 
> This always worked but stopped working and the following error pops up in the 
> logs:
> smtp failed-command command="RCPT TO: ORCPT=rfc822;root" 
> result="553 ORCPT address syntax error”
> 
> It actually does work when I try something like ‘echo Test | mail 
> sys...@example.com’ BUT 'echo Test | mail root’ does not
> 
> Am I missing something?
> 
> —
> Tony

Did you ever figure this out? I'm having the same issue. I have a linux system 
with Logwatch set to e-mail 'root', and the root user has a ~/.forward to a 
fully qualified e-mail address (u...@example.com). It only started happening on 
June 11, when I upgraded opensmtpd from 6.6.4,1 -> 6.7.1,1 (on my mailserver, 
which is FreeBSD). I get the same "ORCPT address syntax error" you're seeing. 
Here's the log from smtp when it happened yesterday:

Jul 10 03:19:03 roast smtpd[80856]: 66aa64942b25c1fd smtp failed-command 
command="RCPT TO: ORCPT=rfc822;root" result="553 ORCPT 
address syntax error"

The linux system hasn't been changed in years, and it started happening 
immediately after the upgrade of opensmtpd, so I imagine it's related to that. 

--william

Re: 553 ORCPT address syntax error

[Thomas Bohl]

In /etc/mail/aliases I used to say
  root: sys...@example.com 


Your /etc/aliases must look like:

root: sys...@example.com


And that’s what I used if you read my mail correctly.


The plane text version of your mail has exactly the quoted line.

https://www.mail-archive.com/misc@opensmtpd.org/msg05036.html

Re: 553 ORCPT address syntax error

[Slavik Svyrydiuk]

> In /etc/mail/aliases I used to say 
>   root: sys...@example.com <mailto:sys...@example.com>

Your /etc/aliases must look like:

root: sys...@example.com

>From man page:

 user-part@domain-part
 An email address in RFC 5322 format.  If an address extension is
 appended to the user-part, it is first compared for an exact
 match.  It is then stripped so that an address such as
 user+...@example.com will only use the part that precedes `+' as
 a key.


On Mon, 15 Jun 2020 13:43:11 +0200
Tony Boston  wrote:

> Hi,
> 
> I have an issue with forwarding mails which belong to the local root user.
> I never had that and it seems something changed in opensmtpd?
> 
> In /etc/mail/aliases I used to say 
>   root: sys...@example.com <mailto:sys...@example.com>
> 
> This always worked but stopped working and the following error pops up in the 
> logs:
> smtp failed-command command="RCPT TO: ORCPT=rfc822;root" 
> result="553 ORCPT address syntax error”
> 
> It actually does work when I try something like ‘echo Test | mail 
> sys...@example.com’ BUT 'echo Test | mail root’ does not
> 
> Am I missing something?
> 
> —
> Tony
>  

-- 
with best regards,
Slavik Svyrydiuk

553 ORCPT address syntax error

[Tony Boston]

Hi,

I have an issue with forwarding mails which belong to the local root user.
I never had that and it seems something changed in opensmtpd?

In /etc/mail/aliases I used to say 
  root: sys...@example.com <mailto:sys...@example.com>

This always worked but stopped working and the following error pops up in the 
logs:
smtp failed-command command="RCPT TO: ORCPT=rfc822;root" 
result="553 ORCPT address syntax error”

It actually does work when I try something like ‘echo Test | mail 
sys...@example.com’ BUT 'echo Test | mail root’ does not

Am I missing something?

—
Tony