On 5/30/22 12:30, [email protected] wrote: > Hi Harri, > > we had issues with e-mails containing ORCPT as well and fixed the > rejection with a patch. Originally, we created the patch when 6.7 was > out and applied it to the version of OpenSMTPD available in the FreeBSD > ports. > > As of today, OpenSMTPD 6.8 is available in the FreeBSD ports system. > The attached patches can be applied to this version (if you are on > FreeBSD, just put them into ports/mail/opensmtpd/files). > > If needed, I can massage the patches so they can be applied against the > OpenBSD base as well, where OpenSMTPD resides in nowadays (we mainly > use it on FreeBSD). I did not do this yet, since I wanted to provide a > quick answer. > > In our case, the above mentioned groupware introduced characters in the > ORCPT field (colons.., 0x3a), that led smtp_tx_rcpt_to() > (usr.sbin/smtpd/smtp_session.c) to return with "553 ORCPT address > syntax error". > > RFC3461 led us to the solution we are using today. > > In section 4.2 [1], the ABNF of ORCPT is defined as: > >> orcpt-parameter = "ORCPT=" original-recipient-address >> original-recipient-address = addr-type ";" xtext >> addr-type = atom > > The log you see is: > >> May 27 08:42:30 mymta smtpd[10310]: f06a752b657b4a05 smtp failed- >> command command="RCPT TO:<[email protected]> >> ORCPT=rfc822;[email protected]" result="550 Invalid recipient: >> <[email protected]>" > > According to the ABNF of ORCPT, everything after addr-type ";" > ("rfc822;" in your case) is supposed to be xtext, which is described a > bit earlier in the introductory part of section 4 [2]. > >> xtext = *( xchar / hexchar ) >> >> xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, >> except for "+" and "=". >> >> ; "hexchar"s are intended to encode octets that cannot appear >> ; as ASCII characters within an esmtp-value. >> >> hexchar = ASCII "+" immediately followed by two upper case >> hexadecimal digits > > smtp_tx_rcpt_to() in usr.sbin/smtpd/smtp_session.c tries to convert the > text of the ORCPT DSN into an e-mail address and wants to check the > validity of the local and the domain part. We replaced this check, are > validating the xtext portion as specified above and are replying with a > more precise error message if this check fails: > > 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 (!valid_xtext(opt)) { > smtp_reply(tx->session, > - "553 ORCPT address syntax error"); > + "553 ORCPT xtext syntax error"); > return; > } > > > In usr.sbin/smtpd/util.c we added valid_xtext(): > > +int > +valid_xtext(const char *s) > +{ > + while (*s != '\0') { > + if(*s == '\x2b' || *s == '\x3d') { > + return 0; > + } else if(*s <= '\x21' || *s >= '\x7e') { > + return 0; > + } else { > + s++; > + continue; > + } > + return 0; > + } > + return 1; > +} > > I hope this helps to narrow down your issue a bit. What kind of non-e- > mailish characters do you see in the ORCPT? > > In our case, the xtext portion of the ORCPT quite often contained valid > e-mail addresses, but sometimes, it did not. As far as we understood > the RFCs, xtext doas not necessarily need to be an e-mail address. This > is why we decided to replace the original check. The above mentioned > groupware used colons as field separators inside the xtext portion to > keep track of the communication belonging to certain thread or, well, > recipients. > > What do the others think of the way we are handling the ORCPT?
This patch does not consider the case of hexchars in ORCPT. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
