Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7
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
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
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
I did obtain consent before sending here but didn't mention it.
Re: Fwd: 553 ORCPT address syntax error on OpenBSD 6.7
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
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
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.
