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(&ep->dsn_notify, buf);


if (strcasecmp("dsn-orcpt", field) == 0)
-   return ascii_load_mailaddr(&ep->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(&ep->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(&ep->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

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(&ep->dsn_notify, buf);
 
if (strcasecmp("dsn-orcpt", field) == 0)
-   return ascii_load_mailaddr(&ep->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(&ep->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(&ep->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
-

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/

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;

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(&tx->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(&orcptaddr, 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 cha

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(&tx->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(&orcptaddr, 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

[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(&tx->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(&orcptaddr, 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: Syntax Error

[Edgar Pettijohn]

On 8/5/21 9:56 AM, Vigneshwaran Ravichandran wrote:

Hi Thomas,

I am attaching my log file for reference.

-Original Message-
From: Thomas Bohl 
Sent: Thursday, 5 August, 2021 10:24 PM
To: misc@opensmtpd.org
Subject: Re: Syntax Error


I am Vigneshwaran R @ vgnshlvnz. I am a FreeBSD OS enthusiast. Recently I tried 
to deploy opensmtpd in FreeBSD 12.2-RELEASE, I get syntax error when I run 
`smtpd -n`. I have attached the file for reference. Can someone point out the 
issue?


Probably because you are using the old syntax. Not sure how its even 
starting up though. Also the maillog shows multiple permission errors 
early on and one of the daemons closes its socket if I'm reading 
correctly. I would do a `pgrep smtpd` and make sure all the daemons are 
still running. Off the top of my head I think there should be 4 or 5 going.



Edgar


Since you didn't show your error message, I got to assume its the fact that the 
file has CR LF at the end of a line (Windows encoding for a new
line) instead of just LF (What a *nix systems expects).

Re: Syntax Error

[Thomas Bohl]

I am attaching my log file for reference.


Which is not really helping. It has over 7000 lines. It clearly shows 
that the daemon is running, so there can't be a syntax error.


Please be more specific. Show the commands you enter and the output that 
is generates. Try to use smtpd -d


There are a lot of "Connection timeout"-Errors in the maillog. Are you 
sure you can connect to port 25?

Re: Syntax Error

[Thomas Bohl]

I am Vigneshwaran R @ vgnshlvnz. I am a FreeBSD OS enthusiast. Recently I tried 
to deploy opensmtpd in FreeBSD 12.2-RELEASE, I get syntax error when I run 
`smtpd -n`. I have attached the file for reference. Can someone point out the 
issue?


Since you didn't show your error message, I got to assume its the fact 
that the file has CR LF at the end of a line (Windows encoding for a new 
line) instead of just LF (What a *nix systems expects).

Syntax Error

[Vigneshwaran Ravichandran]

Hi,

I am Vigneshwaran R @ vgnshlvnz. I am a FreeBSD OS enthusiast. Recently I tried 
to deploy opensmtpd in FreeBSD 12.2-RELEASE, I get syntax error when I run 
`smtpd -n`. I have attached the file for reference. Can someone point out the 
issue?

-Original Message-
From: Vigneshwaran Ravichandran 
Sent: Thursday, 5 August, 2021 9:09 PM
To: misc+h...@opensmtpd.org
Subject: Syntax Error

Hi,

I am Vigneshwaran R @ vgnshlvnz. I am a FreeBSD OS enthusiast. Recently I tried 
to deploy opensmtpd in FreeBSD 12.2-RELEASE, I get syntax error when I run 
`smtpd -n`. I have attached the file for reference. Can someone point out the 
issue?

-Original Message-
From: misc+h...@opensmtpd.org  
Sent: Thursday, 5 August, 2021 9:03 PM
To: vigneshwar...@outlook.com
Subject: Welcome to misc@opensmtpd.org


Thank you for confirming your subscription. You have now been added to the 
normal version of the list.

The email address you are subscribed with is .

If you ever wish to unsubscribe, send a message to 
 using this email address. The subject and the 
body of the message can be anything. You will then receive confirmation or 
further instructions.

For other information and help about this list, send a message to 
.




smtpd.conf
Description: smtpd.conf

Re: RCPT syntax error from bank

[Martijn van Duren]

On Sun, 2021-04-04 at 07:03 -0600, Anthony J. Bentley wrote:
> Hi,
> 
> I had an interesting occurrence today... I was performing an action
> that required a confirmation code from my bank, which they sent by
> email. Unfortunately the mail never arrived, because:
> 
> Apr  4 03:25:16 axx smtpd[59645]: fdc8f818f7adb2aa smtp failed-command
> command="RCPT TO:<"username"@example.com>"
> result="501 5.1.3 Recipient address syntax error"
> 
> I assume the double quotes in there were the problem. I had to switch
> to a GMail account to receive it.
> 
Since everyone responding likes to point to what might be a nice and
comfy workaround, let me take some inspiration from RFC5321.

>From section 3.3:
  RCPT TO: [ SP  ] 

So let´s expand forward-path from section 4.1.2:
   Forward-path   = Path
   Path   = "<" [ A-d-l ":" ] Mailbox ">"
   Mailbox= Local-part "@" ( Domain / address-literal )
   Local-part = Dot-string / Quoted-string
  ; MAY be case-sensitive
   Quoted-string  = DQUOTE *QcontentSMTP DQUOTE

In other words: the bank is correct (although maybe a little unusual)
to use a double-quote surrounding the local-part. This should be fixed
in smtpd.

I´m not very familiar with that part of the code and I don´t know when
I have the time to look into it. If anyone else beats me to this I would
most welcome it. :-)

martijn@

Re: RCPT syntax error from bank

[Edgar Pettijohn]

On Apr 4, 2021 5:36 PM, "Anthony J. Bentley"  wrote:Hi Peter,



Peter Nicolai Mathias Hansteen writes:

> It's interesting that the subject turns up here, when there is a

> fresh (and good IMO) blog post out about email address validation out,

> "Your E-Mail Validation Logic is Wrong"

>  by Jan Schaumann



This seems to suggest the problem is in the opposite direction: that

OpenSMTPD is wrong to reject "user"@example.com, and perhaps also

wrong to not map "user"@example.com to u...@example.com.



-- 

Anthony J. Bentley


It would be wrong if the "user"@example.com was an actual username. I don't think smtpd should have any hard coded mappings built in. I believe the real problem is the banks server decided to change your email username to another valid username without your consent. Luckily its your server and you can see what happened.Edgar 

Re: RCPT syntax error from bank

[Peter Nicolai Mathias Hansteen]

> 4. apr. 2021 kl. 15:51 skrev Edgar Pettijohn :
> 
> On Sun, Apr 04, 2021 at 07:03:47AM -0600, Anthony J. Bentley wrote:
>> Hi,
>> 
>> I had an interesting occurrence today... I was performing an action
>> that required a confirmation code from my bank, which they sent by
>> email. Unfortunately the mail never arrived, because:
>> 
>> Apr  4 03:25:16 axx smtpd[59645]: fdc8f818f7adb2aa smtp failed-command
>> command="RCPT TO:<"username"@example.com>"
>> result="501 5.1.3 Recipient address syntax error"
>> 
>> I assume the double quotes in there were the problem. I had to switch
>> to a GMail account to receive it.
>> 
> 
> It is. Seemed like a good problem for a filter to solve, but it looks like
> smtpd verifies the syntax before sending to filterland.
> 
> You should write their postmaster and complain.

It’s interesting that the subject turns up here, when there is a fresh (and 
good IMO) blog post out about email address validation out, "Your E-Mail 
Validation Logic is Wrong" https://www.netmeister.org/blog/email.html 
<https://www.netmeister.org/blog/email.html> by Jan Schaumann

It’s worth reading and perhaps pointing to when complaining to said postmaster.

All the best,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP

Re: RCPT syntax error from bank

[Anthony J. Bentley]

Hi Peter,

Peter Nicolai Mathias Hansteen writes:
> It's interesting that the subject turns up here, when there is a
> fresh (and good IMO) blog post out about email address validation out,
> "Your E-Mail Validation Logic is Wrong"
>  by Jan Schaumann

This seems to suggest the problem is in the opposite direction: that
OpenSMTPD is wrong to reject "user"@example.com, and perhaps also
wrong to not map "user"@example.com to u...@example.com.

-- 
Anthony J. Bentley

Re: RCPT syntax error from bank

[Edgar Pettijohn]

On Sun, Apr 04, 2021 at 07:03:47AM -0600, Anthony J. Bentley wrote:
> Hi,
> 
> I had an interesting occurrence today... I was performing an action
> that required a confirmation code from my bank, which they sent by
> email. Unfortunately the mail never arrived, because:
> 
> Apr  4 03:25:16 axx smtpd[59645]: fdc8f818f7adb2aa smtp failed-command
> command="RCPT TO:<"username"@example.com>"
> result="501 5.1.3 Recipient address syntax error"
> 
> I assume the double quotes in there were the problem. I had to switch
> to a GMail account to receive it.
>

It is. Seemed like a good problem for a filter to solve, but it looks like
smtpd verifies the syntax before sending to filterland.

You should write their postmaster and complain.

Edgar
> -- 
> Anthony J. Bentley
> 

RCPT syntax error from bank

[Anthony J. Bentley]

Hi,

I had an interesting occurrence today... I was performing an action
that required a confirmation code from my bank, which they sent by
email. Unfortunately the mail never arrived, because:

Apr  4 03:25:16 axx smtpd[59645]: fdc8f818f7adb2aa smtp failed-command
command="RCPT TO:<"username"@example.com>"
result="501 5.1.3 Recipient address syntax error"

I assume the double quotes in there were the problem. I had to switch
to a GMail account to receive it.

-- 
Anthony J. Bentley

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
follow

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)

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

[Martijn van Duren]

On Mon, 2020-07-27 at 22:46 -0400, Larkin Nickle wrote:
> 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.
> 
I probably agree with you; from smtp_session.c:3213:
} else if (ADVERTISE_EXT_DSN(tx->session) && strncasecmp(opt, 
"ORCPT=", 6) == 0) {
opt += 6;

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

if (!text_to_mailaddr(&tx->evp.dsn_orcpt, opt) ||
!valid_localpart(tx->evp.dsn_orcpt.user) ||
!valid_domainpart(tx->evp.dsn_orcpt.domain)) {
    smtp_reply(tx->session,
"553 ORCPT address syntax error");
return;
}
}
Where valid_domainpart uses res_hnok(), which only allows for:
'.', alpha, digit, '-', and '_' according to libc/net/res_comp.c.

According to RFC3461 section 4.2:
  orcpt-parameter = "ORCPT=" original-recipient-address
  original-recipient-address = addr-type ";" xtext

So addr-type here is rfc822, which is supported by smtpd. So the
address-part is in xtext, on which the RFC says the following:
while the "xtext" portion contains an encoded representation of the
original recipient address using the rules in section 5 of this
document.

I haven't read section 5 fully (don't have the time now) but I'm highly
doubtful that ":1:1" is a legitimate postfix on a domainname. You should
ask your colleague where this comes from and why this should be
accepted.

As for why google, outlook, etc support this: I don't know. I don't see
any value in it yet personally, so maybe they don't either and just
parse the value to see if it's valid xtext, without actually validating
that it's a valid mail address. Just taking a blind guess here.

martijn@

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

[Tony Boston]

> On 15. Jun 2020, at 15:10, Slavik Svyrydiuk  wrote:
> 
>> 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

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

> 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
> 

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
 

Re: Filter trustee src bypass - syntax error

[KJ (Klaas Jan) Schuurs]

Dear Martijn en Pete,

Thank you for your help and answers.

I think Pete has nailed the problem. I'm sorry I've overlooked the fact 
that filter... bypass is not available in openbsd 6.6 release. I'll just 
have to wait till openbsd 6.7 will be out.


Thank you again for your help.
KJ (Klaas Jan) Schuurs

k...@kjenj.nl
06 1500 3207

Malvert 2301
6538AR Nijmegen

Martijn van Duren schreef op 2020-04-28 11:09:
In that case we'd need to know which version of OpenSMTPd you're 
running

and your full configuration. This was just an educated guess, but
without all the information it's impossible to help you.

On 4/28/20 11:07 AM, KJ (Klaas Jan) Schuurs wrote:

Dear Martijn,

Thank you for your answer. I've corrected my table definition to:

table trustedip file:/etc/mail/trustedip

I'm still getting syntax error on the line with:
filter trusted phase mail-from match src  bypass



KJ (Klaas Jan) Schuurs



Martijn van Duren schreef op 2020-04-28 10:45:

On 4/28/20 10:29 AM, KJ (Klaas Jan) Schuurs wrote:



***
smtpd.conf
***
table  file:/etc/mail/trustedip


This should be:
table trustedip file:/etc/mail/trustedip

Can you tell if it works with this change?

Re: Filter trustee src bypass - syntax error

[KJ (Klaas Jan) Schuurs]

Dear Martijn,

Thank you for your answer. I've corrected my table definition to:

table trustedip file:/etc/mail/trustedip

I'm still getting syntax error on the line with:
filter trusted phase mail-from match src  bypass



KJ (Klaas Jan) Schuurs



Martijn van Duren schreef op 2020-04-28 10:45:

On 4/28/20 10:29 AM, KJ (Klaas Jan) Schuurs wrote:



***
smtpd.conf
***
table  file:/etc/mail/trustedip


This should be:
table trustedip file:/etc/mail/trustedip

Can you tell if it works with this change?

Re: Filter trustee src bypass - syntax error

[Pete]

Hi,

filter ... bypass
is not a valid syntax in 6.6 release.
I assume it will be in 6.7.



> Dear all,

> Hi! This is the first time I'm posting to this mailinglist. English is
> not my native language, so if I'm not making sense, then accept my
> apologies.

> First of all I would like to tell @Gilles and others that I love
> opensmtpd. I've used it now for like two years and I like it way better
> than postfix.

> I'm trying to setup a filter bypass. I've looked at the example Gilles
> has provided on his website.

> ***
> smtpd.conf
> ***
> table  file:/etc/mail/trustedip

> filter trusted phase mail-from match src  bypass

> listen on all tls pki example.com filter { trusted check_rdns ... }
> ***

> ***
> /etc/mail/trustedip
> ***
> 192.168.1.0/24
> ***

> When I do 'smtpd -n' I get a syntax error on the line where I define the
> filter trusted.

> I'm not sure what the error is.

> I'm running openbsd 6.6 release.

> Can someone shed some light on my syntax error?

> Thank you!

> With regards,

> KJ (Klaas Jan) Schuurs

Re: Filter trustee src bypass - syntax error

[Martijn van Duren]

In that case we'd need to know which version of OpenSMTPd you're running
and your full configuration. This was just an educated guess, but
without all the information it's impossible to help you.

On 4/28/20 11:07 AM, KJ (Klaas Jan) Schuurs wrote:
> Dear Martijn,
> 
> Thank you for your answer. I've corrected my table definition to:
> 
> table trustedip file:/etc/mail/trustedip
> 
> I'm still getting syntax error on the line with:
> filter trusted phase mail-from match src  bypass
> 
> 
> 
> KJ (Klaas Jan) Schuurs
> 
> 
> 
> Martijn van Duren schreef op 2020-04-28 10:45:
>> On 4/28/20 10:29 AM, KJ (Klaas Jan) Schuurs wrote:
> 
>>> ***
>>> smtpd.conf
>>> ***
>>> table  file:/etc/mail/trustedip
>>
>> This should be:
>> table trustedip file:/etc/mail/trustedip
>>
>> Can you tell if it works with this change?
>>

Re: Filter trustee src bypass - syntax error

[Martijn van Duren]

On 4/28/20 10:29 AM, KJ (Klaas Jan) Schuurs wrote:
> Dear all,
> 
> Hi! This is the first time I'm posting to this mailinglist. English is 
> not my native language, so if I'm not making sense, then accept my 
> apologies.
> 
> First of all I would like to tell @Gilles and others that I love 
> opensmtpd. I've used it now for like two years and I like it way better 
> than postfix.
> 
> I'm trying to setup a filter bypass. I've looked at the example Gilles 
> has provided on his website.
> 
> ***
> smtpd.conf
> ***
> table  file:/etc/mail/trustedip

This should be:
table trustedip file:/etc/mail/trustedip

Can you tell if it works with this change?

> 
> filter trusted phase mail-from match src  bypass
> 
> listen on all tls pki example.com filter { trusted check_rdns ... }
> ***
> 
> ***
> /etc/mail/trustedip
> ***
> 192.168.1.0/24
> ***
> 
> When I do 'smtpd -n' I get a syntax error on the line where I define the 
> filter trusted.
> 
> I'm not sure what the error is.
> 
> I'm running openbsd 6.6 release.
> 
> Can someone shed some light on my syntax error?
> 
> Thank you!
> 
> With regards,
> 
> KJ (Klaas Jan) Schuurs
> 

Filter trustee src bypass - syntax error

[KJ (Klaas Jan) Schuurs]

Dear all,

Hi! This is the first time I'm posting to this mailinglist. English is 
not my native language, so if I'm not making sense, then accept my 
apologies.


First of all I would like to tell @Gilles and others that I love 
opensmtpd. I've used it now for like two years and I like it way better 
than postfix.


I'm trying to setup a filter bypass. I've looked at the example Gilles 
has provided on his website.


***
smtpd.conf
***
table  file:/etc/mail/trustedip

filter trusted phase mail-from match src  bypass

listen on all tls pki example.com filter { trusted check_rdns ... }
***

***
/etc/mail/trustedip
***
192.168.1.0/24
***

When I do 'smtpd -n' I get a syntax error on the line where I define the 
filter trusted.


I'm not sure what the error is.

I'm running openbsd 6.6 release.

Can someone shed some light on my syntax error?

Thank you!

With regards,

KJ (Klaas Jan) Schuurs

Re: "relay verify" produces syntax error

[Gilles Chehade]

On Tue, May 05, 2015 at 05:21:39PM -0700, Seth wrote:
> On Tue, 05 May 2015 13:11:32 -0700, Daniel Pajonzeck 
> wrote:
> >I haven't tested if invalid certificates are rejected, but surprisingly
> >"accept for any relay tls verify" doesn't result in a syntax error.
> >This contradicts the manpage:
> >
> >"relay ... [tls | verify]"
> >and
> >"Note that the tls and verify options are mutually exclusive"
> >
> >Correct me if I am wrong.
> 
> You are correct this contradicts the man page. I just pulled example from
> one of my production configs.
> 
> Can't even remember how I decided to set it that way to be honest, probably
> just experimentation.
> 
> Someone who understands C code or one the devs will have to weight in to
> explain the observed behavior.
> 

Hi,

This is a documentation error:

When I initially wrote the relay tls verify code, it worked the way that
is described in the man page. Later, the code was rearranged, the verify
code was made the same for the incoming and outgoing path and it ocurred
to me that "verify" should be a parameter to "tls" like we do in listen:

   listen [...] tls-require verify

The code was updated and when I checked that there was documentation for
the feature later on, I missed the fact that it had changed.

This is why I no longer document stuff before it has stabilized a bit.

I'll fix the documentation bug today, it'll be part of next snapshot,

Thanks


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: "relay verify" produces syntax error

[Seth]

On Tue, 05 May 2015 13:11:32 -0700, Daniel Pajonzeck   
wrote:


It's a man page bug, found this in the list archives

http://marc.info/?l=opensmtpd-misc&m=142866776526943&w=2

--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: "relay verify" produces syntax error

[Seth]

On Tue, 05 May 2015 13:11:32 -0700, Daniel Pajonzeck   
wrote:

I haven't tested if invalid certificates are rejected, but surprisingly
"accept for any relay tls verify" doesn't result in a syntax error.
This contradicts the manpage:

"relay ... [tls | verify]"
and
"Note that the tls and verify options are mutually exclusive"

Correct me if I am wrong.


You are correct this contradicts the man page. I just pulled example from  
one of my production configs.


Can't even remember how I decided to set it that way to be honest,  
probably just experimentation.


Someone who understands C code or one the devs will have to weight in to  
explain the observed behavior.


--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: "relay verify" produces syntax error

[Daniel Pajonzeck]

I haven't tested if invalid certificates are rejected, but surprisingly
"accept for any relay tls verify" doesn't result in a syntax error.
This contradicts the manpage:

"relay ... [tls | verify]"
and
"Note that the tls and verify options are mutually exclusive"

Correct me if I am wrong.

// Daniel


On 05.05.2015 06:24, Seth wrote:
> "accept for any relay verify" should probably read
> "accept for any relay tls verify" instead.

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: "relay verify" produces syntax error

[Seth]

On Mon, 04 May 2015 09:44:09 -0700, Daniel Pajonzeck   
wrote:

$ cat smtpd.conf
table aliases { root=pi, pi=f...@domain.tld }
accept for local alias  deliver to mbox
accept for any relay verify

$ smtpd -dv
/usr/local/etc/smtpd.conf:3: syntax error


If I change the 'verify' to 'tls' everything is working well.
Looks like a bug!?


"accept for any relay verify" should probably read
"accept for any relay tls verify" instead.

--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

"relay verify" produces syntax error

[Daniel Pajonzeck]

Hi,

I've installed OpenSMTPD from the latest tarball release 5.4.5p2 on a
Raspberry Pi (Raspbian/Debian Wheezy) for local mail relaying.
I get a syntax error with the following configuration:

$ cat smtpd.conf
table aliases { root=pi, pi=f...@domain.tld }
accept for local alias  deliver to mbox
accept for any relay verify

$ smtpd -dv
/usr/local/etc/smtpd.conf:3: syntax error


If I change the 'verify' to 'tls' everything is working well.
Looks like a bug!?


// Daniel

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: 553 Sender address syntax error

[Thomas Schmitz]

Am 06.01.2014 15:33, schrieb Gilles Chehade:

The snapshot I published has the fix for your issue;-)


Thanks, works like a charm!

Kind regards
Thomas

--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: 553 Sender address syntax error

[Gilles Chehade]

The snapshot I published has the fix for your issue ;-)

On Mon, Jan 06, 2014 at 02:10:41PM +0100, Gilles Chehade wrote:
> On Mon, Jan 06, 2014 at 01:29:52PM +0100, Thomas Schmitz wrote:
> > Hello guys,
> > 
> 
> Hello,
> 
> 
> > I am experiencing strange problems receiving emails from Apple:
> > 
> > Jan  6 12:14:11 mail smtpd[19047]: smtp-in: New session
> > 01a17a5c0d5a from host nwk-txn-msbadger0404.apple.com
> > [17.151.1.65]
> > Jan  6 12:14:11 mail smtpd[19047]: smtp-in: Failed command on
> > session 01a17a5c0d5a: "MAIL
> > FROM:<20140106111410~789~7734550954580063553566...@email.apple.com>"
> > => 553 Sender address syntax error
> > Jan  6 12:14:16 mail smtpd[19047]: smtp-in: Closing session 01a17a5c0d5a
> > 
> > I don't know what is wrong with that sender address, the tilde
> > should be an acceptable character, afaik?
> >
> 
> We have to whitelist it and escape it ...
> 
> 
> > I'm running snapshot 201308201225 on openbsd.
> > 
> 
> You can either fix by editing the util.c valid_user() function
> to add ~ in the accepted chars list; or wait till I publish a new
> snapshot this week ;-)
> 
> 
> 
> -- 
> Gilles Chehade
> 
> https://www.poolp.org  @poolpOrg
> 
> -- 
> You received this mail because you are subscribed to misc@opensmtpd.org
> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
> 

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: 553 Sender address syntax error

[Gilles Chehade]

On Mon, Jan 06, 2014 at 01:29:52PM +0100, Thomas Schmitz wrote:
> Hello guys,
> 

Hello,


> I am experiencing strange problems receiving emails from Apple:
> 
> Jan  6 12:14:11 mail smtpd[19047]: smtp-in: New session
> 01a17a5c0d5a from host nwk-txn-msbadger0404.apple.com
> [17.151.1.65]
> Jan  6 12:14:11 mail smtpd[19047]: smtp-in: Failed command on
> session 01a17a5c0d5a: "MAIL
> FROM:<20140106111410~789~7734550954580063553566...@email.apple.com>"
> => 553 Sender address syntax error
> Jan  6 12:14:16 mail smtpd[19047]: smtp-in: Closing session 01a17a5c0d5a
> 
> I don't know what is wrong with that sender address, the tilde
> should be an acceptable character, afaik?
>

We have to whitelist it and escape it ...


> I'm running snapshot 201308201225 on openbsd.
> 

You can either fix by editing the util.c valid_user() function
to add ~ in the accepted chars list; or wait till I publish a new
snapshot this week ;-)



-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

553 Sender address syntax error

[Thomas Schmitz]

Hello guys,

I am experiencing strange problems receiving emails from Apple:

Jan  6 12:14:11 mail smtpd[19047]: smtp-in: New session 01a17a5c0d5a 
from host nwk-txn-msbadger0404.apple.com [17.151.1.65]
Jan  6 12:14:11 mail smtpd[19047]: smtp-in: Failed command on session 
01a17a5c0d5a: "MAIL 
FROM:<20140106111410~789~7734550954580063553566...@email.apple.com>" => 
553 Sender address syntax error

Jan  6 12:14:16 mail smtpd[19047]: smtp-in: Closing session 01a17a5c0d5a

I don't know what is wrong with that sender address, the tilde should be 
an acceptable character, afaik?


I'm running snapshot 201308201225 on openbsd.

Kind regards,
Thomas

--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: 553 Sender address syntax error

[Gilles Chehade]

On Thu, Jun 27, 2013 at 05:23:44PM -0300, Hugo Osvaldo Barrera wrote:
> > 
> > It probably is the address size, '=' is an acceptable character.
> > With release, we had a maximum user-part of 64 bytes, which was what RFC
> > suggested. We bumped this post-release after an exchange with the FreeBSD
> > maintainer and one of the guys who wrote the RFC.
> 
> So you're accepting even those that exceed the maximum?
> What's the current maximum?
> 

It's slightly more complex than "accepting those that exceed the max":

The RFC says that a user-part should not exceed 64 bytes.
At the same time, it says that server should try not to impose limits if
possible. While at the same time, some particular limits must be imposed
to avoid issues when exchanging with other software (ie: the length of a
header or data line).

So basically, we should disregard the arbitrary 64 bytes limits if it is
possible, but we're still bound to limits we cannot disregard, and which
are completely unrelated to the email address itself...

We decided to bump to an arbitrary 255 bytes limit for the user-part and
255 bytes limit for the domain-part. An email address can be at most 511
bytes with today's code.


> > People using SMTP have been assuming infinite size in email addresses...
> 
> I see. It's somewhat interesting how *some* major providers are rejecting
> these emails, while other accept them. Lots of those emails clearly
> don't make it through.
> 

Sometimes the RFC gives too much space for interpretation.


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this email because you are subscribed to mailing list: 
misc@opensmtpd.org
To unsubscribe, send mail with subject:
[misc@opensmtpd.org] unregister

Re: 553 Sender address syntax error

[Hugo Osvaldo Barrera]

On 2013-06-27 22:12, Gilles Chehade wrote:
> On Thu, Jun 27, 2013 at 02:58:22PM -0300, Hugo Osvaldo Barrera wrote:
> > Hi all,
> > 
> 
> Hi,
> 
> 
> > I've been failing to receive some automated emails from both yahoo
> > and gmail.
> > The error smtpd is printing out is:
> > 
> > Jun 27 17:40:02 elysion smtpd[17570]: smtp-in: Failed command on session 
> > 00002741922c17e6: "MAIL 
> > FROM:"
> >  => 553 Sender address syntax error
> > 
> > I'm wondering what the syntax error is. I tried looking at the RFCs a
> > bit, but I've not found anything (though I'm sure that I skipped some
> > important part).
> > 
> > Is the "=" an invalid character, or does the address size exceed the
> > limit?
> >
> 
> It probably is the address size, '=' is an acceptable character.
> With release, we had a maximum user-part of 64 bytes, which was what RFC
> suggested. We bumped this post-release after an exchange with the FreeBSD
> maintainer and one of the guys who wrote the RFC.

So you're accepting even those that exceed the maximum? What's the current 
maximum?

> 
> What version are you running ?

That would by my primary MX that runs the version from OpenBSD 5.3-current
from about a month ago.
So yes, it is pretty old. :D

> 
> 
> > As an informtive note, I've noticed that these same automated emails
> > (google groups invites, and yahoo password recoveries) fail to reach
> > their recipients if the recipients are using hotmail.com/outlook.com,
> > amongst other popular email providers some friends use, so I don't
> > strictly think smtpd is doing something wrong - I'm just curious as to
> > what's wrong with those addresses.
> >
> 
> People using SMTP have been assuming infinite size in email addresses...

I see. It's somewhat interesting how *some* major providers are rejecting
these emails, while other accept them. Lots of those emails clearly
don't make it through.

> 
> 
> > Please note that I'm not complaining about this issue; I'm just asking
> > what's wrong with this address and what RFC I should read (so yes,
> > it *is* slighlty OT).
> > 
> 
> Nope, perfectly on topic ;-)
> 

Thanks, very informative.

> 
> -- 
> Gilles Chehade
> 
> https://www.poolp.org  @poolpOrg

-- 
Hugo Osvaldo Barrera


pgpqVUVTBeCNm.pgp
Description: PGP signature

Re: 553 Sender address syntax error

[Gilles Chehade]

On Thu, Jun 27, 2013 at 02:58:22PM -0300, Hugo Osvaldo Barrera wrote:
> Hi all,
> 

Hi,


> I've been failing to receive some automated emails from both yahoo
> and gmail.
> The error smtpd is printing out is:
> 
> Jun 27 17:40:02 elysion smtpd[17570]: smtp-in: Failed command on session 
> 2741922c17e6: "MAIL 
> FROM:"
>  => 553 Sender address syntax error
> 
> I'm wondering what the syntax error is. I tried looking at the RFCs a
> bit, but I've not found anything (though I'm sure that I skipped some
> important part).
> 
> Is the "=" an invalid character, or does the address size exceed the
> limit?
>

It probably is the address size, '=' is an acceptable character.
With release, we had a maximum user-part of 64 bytes, which was what RFC
suggested. We bumped this post-release after an exchange with the FreeBSD
maintainer and one of the guys who wrote the RFC.

What version are you running ?


> As an informtive note, I've noticed that these same automated emails
> (google groups invites, and yahoo password recoveries) fail to reach
> their recipients if the recipients are using hotmail.com/outlook.com,
> amongst other popular email providers some friends use, so I don't
> strictly think smtpd is doing something wrong - I'm just curious as to
> what's wrong with those addresses.
>

People using SMTP have been assuming infinite size in email addresses...


> Please note that I'm not complaining about this issue; I'm just asking
> what's wrong with this address and what RFC I should read (so yes,
> it *is* slighlty OT).
> 

Nope, perfectly on topic ;-)


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this email because you are subscribed to mailing list: 
misc@opensmtpd.org
To unsubscribe, send mail with subject:
[misc@opensmtpd.org] unregister

553 Sender address syntax error

[Hugo Osvaldo Barrera]

Hi all,

I've been failing to receive some automated emails from both yahoo
and gmail.
The error smtpd is printing out is:

Jun 27 17:40:02 elysion smtpd[17570]: smtp-in: Failed command on session 
2741922c17e6: "MAIL 
FROM:"
 => 553 Sender address syntax error

I'm wondering what the syntax error is. I tried looking at the RFCs a
bit, but I've not found anything (though I'm sure that I skipped some
important part).

Is the "=" an invalid character, or does the address size exceed the
limit?

As an informtive note, I've noticed that these same automated emails
(google groups invites, and yahoo password recoveries) fail to reach
their recipients if the recipients are using hotmail.com/outlook.com,
amongst other popular email providers some friends use, so I don't
strictly think smtpd is doing something wrong - I'm just curious as to
what's wrong with those addresses.

Please note that I'm not complaining about this issue; I'm just asking
what's wrong with this address and what RFC I should read (so yes,
it *is* slighlty OT).

Thanks,

-- 
Hugo Osvaldo Barrera


pgpSCcPFwtPZN.pgp
Description: PGP signature