Re: [PATCH] relax 553 ORCPT address syntax error (was Re: EMails to "ORCPT=rfc822;u...@example.com" are rejected)
Sorry, some unnecessary whitespace change was part of the attached
patch. Find attached a cleaned up version of the patch (functionally the
same).
On Thu, Dec 07, 2023 at 01:34:42PM +0100, Tassilo Philipp wrote:
After a direct exchange with Omar Polo about the ORCPT patch, find
attached a revised version of it. The changes compared to Tim's last
patch are, just fyi:
1) valid_xtext() has been modified to avoid potential problems with
sign extensions when using the ctype is*() functions. I also narrowed
down the checks for hexchar letters to only allow ABCDEF (previously
it just checked if it's an uppercase letter). A superflous string
length check on hexchars was removed, b/c this is implicitly handled
when checking the characters ('\0' fails the isdigit() check and
related). While at it I reformatted a bit to be less verbose.
2) I reintroduced the check whether the entire ORCPT parameter exceeds
the rfc3461 specified 500 char limit that Tim had in his previous
patch.
3) I relaxed the check whether the ORCPT param is a valid mail
address, which was done by text_to_mailaddr(). The reason is that it
simply doesn't apply to the ORCPT parameter, as it's xtext encoded (so
you could for example write '@' - which that function tries to find -
as '+40'). It might also be a different address type altogether (e.g.
X.400 as given as example by the rfc), etc.. so that
text_to_mailaddr() logic might simply not apply to that param. So
basically what's left is using that function only to see whether it's
an uncommon ORCPT param (and printing that to the log), or not.
In theory, the xtext would have to be decoded, first, to be pendantic
about this, which I skipped b/c it won't make a difference in this
case for deliverability... not sure if this all should be simplified
even more to just check for xtext, and that's it, not writing any
"uncommon ORCPT param" to the log at all. In any case we leave the
ORCPT param untouched. Thoughts?
4) The patch is now rebased against the latest version of opensmtpd.
Patch is attached
Cheers
On Sat, Nov 18, 2023 at 11:54:33AM +0100, Tassilo Philipp wrote:
Sorry for another bump of this patch: can it be merged?
I know the groupwise example in this thread is rare and doesn't
affect a lot of smtpd users, but without it, it's unfortunately a
bit of a blocker for some people. We personally apply this patch to
our opensmtpd builds, but for others this might simply be a blocker
to use opensmtpd, as they cannot control e.g. what a client uses to
send them mail.
Such mails get rejected by any MTA on a route, no matter if the
rejecting server is just a helper relay. The weird ORCP format used
by groupwise is adhering to the RFC xtext spec, after all, and is
valid.
If this cannot/won't be merged, please share the reasons for why not.
Thank you
On Thu, Jul 20, 2023 at 09:58:16AM +0200, Tassilo Philipp wrote:
Sorry to shamelessly "bump" this, but any way to get this
integrated into upstream, eventually?
We used the original patch from Frank Scholl and then this
improved one in production now for like a year, now, and didn't
experience issues. In our case it is specifically needed for a
client that uses GroupWise[0] internally to send mails (which
seems to always generate mails with an "xtext" ORCPT param).
Thanks!
[0] https://www.microfocus.com/products/groupwise/
On Fri, Oct 28, 2022 at 04:16:36PM +0200, Tim Kuijsten wrote:
I have refined and more thoroughly tested a previous patch that
relaxes the ORCPT address check.
Over the years mail has been rejected by senders that use RCPT
TO commands like:
RCPT TO:
ORCPT=rfc822;groupwise-i...@example.com:0:0 or RCPT
TO:
ORCPT=rfc822;groupwise-i...@example.com:0:0
NOTIFY=SUCCESS,FAILURE
In the above the domain part of the ORCPT address resolves to
example.com:0:0 which is rejected by smtpd with the message:
smtpd[20797]: 1a3a396cd4c57d05 smtp failed-command command="RCPT
TO:
ORCPT=rfc822;groupwise-i...@example.com:0:0
NOTIFY=SUCCESS,FAILURE" result="553 ORCPT address syntax error"
I've studied RFC 3461 section 4 and 4.2 but it's not entirely
clear to me if the above ORCPT command is valid or not. The
encoding adheres to the spec, which says it must be valid xtext.
With this patch smtpd accepts any ORCPT that is valid xtext as
defined in the RFC (and logs on informational message when it
consists of an invalid user or domain name).
Cheers,
Tim
---
usr.sbin/smtpd/smtp_session.c | 22 ++
usr.sbin/smtpd/smtpd.h| 1 +
usr.sbin/smtpd/util.c | 32
3 files changed, 51
insertions(+), 4 deletions(-)
diff --git a/usr.sbin/smtpd/smtp_session.c
b/usr.sbin/smtpd/smtp_session.c index 72e13e8fd8d..c0c29d4a695
100644
--- a/usr.sbin/smtpd/smtp_session.c
+++ b/usr.sbin/smtpd/smtp_session.c
@@ -2415,6 +2415,7 @@ smtp_tx_create_message(struct smtp_tx *tx)
static void
smtp_tx_rcpt_to(struct smtp_tx *tx, const
Re: [PATCH] relax 553 ORCPT address syntax error (was Re: EMails to "ORCPT=rfc822;u...@example.com" are rejected)
After a direct exchange with Omar Polo about the ORCPT patch, find
attached a revised version of it. The changes compared to Tim's last
patch are, just fyi:
1) valid_xtext() has been modified to avoid potential problems with sign
extensions when using the ctype is*() functions. I also narrowed down
the checks for hexchar letters to only allow ABCDEF (previously it just
checked if it's an uppercase letter). A superflous string length check
on hexchars was removed, b/c this is implicitly handled when checking
the characters ('\0' fails the isdigit() check and related). While at it
I reformatted a bit to be less verbose.
2) I reintroduced the check whether the entire ORCPT parameter exceeds
the rfc3461 specified 500 char limit that Tim had in his previous patch.
3) I relaxed the check whether the ORCPT param is a valid mail address,
which was done by text_to_mailaddr(). The reason is that it simply
doesn't apply to the ORCPT parameter, as it's xtext encoded (so you
could for example write '@' - which that function tries to find - as
'+40'). It might also be a different address type altogether (e.g. X.400
as given as example by the rfc), etc.. so that text_to_mailaddr() logic
might simply not apply to that param. So basically what's left is using
that function only to see whether it's an uncommon ORCPT param (and
printing that to the log), or not.
In theory, the xtext would have to be decoded, first, to be pendantic
about this, which I skipped b/c it won't make a difference in this case
for deliverability... not sure if this all should be simplified even
more to just check for xtext, and that's it, not writing any "uncommon
ORCPT param" to the log at all. In any case we leave the ORCPT param
untouched. Thoughts?
4) The patch is now rebased against the latest version of opensmtpd.
Patch is attached
Cheers
On Sat, Nov 18, 2023 at 11:54:33AM +0100, Tassilo Philipp wrote:
Sorry for another bump of this patch: can it be merged?
I know the groupwise example in this thread is rare and doesn't affect
a lot of smtpd users, but without it, it's unfortunately a bit of a
blocker for some people. We personally apply this patch to our
opensmtpd builds, but for others this might simply be a blocker to use
opensmtpd, as they cannot control e.g. what a client uses to send them
mail.
Such mails get rejected by any MTA on a route, no matter if the
rejecting server is just a helper relay. The weird ORCP format used by
groupwise is adhering to the RFC xtext spec, after all, and is valid.
If this cannot/won't be merged, please share the reasons for why not.
Thank you
On Thu, Jul 20, 2023 at 09:58:16AM +0200, Tassilo Philipp wrote:
Sorry to shamelessly "bump" this, but any way to get this integrated
into upstream, eventually?
We used the original patch from Frank Scholl and then this improved
one in production now for like a year, now, and didn't experience
issues. In our case it is specifically needed for a client that uses
GroupWise[0] internally to send mails (which seems to always
generate mails with an "xtext" ORCPT param).
Thanks!
[0] https://www.microfocus.com/products/groupwise/
On Fri, Oct 28, 2022 at 04:16:36PM +0200, Tim Kuijsten wrote:
I have refined and more thoroughly tested a previous patch that
relaxes the ORCPT address check.
Over the years mail has been rejected by senders that use RCPT TO
commands like:
RCPT TO:
ORCPT=rfc822;groupwise-i...@example.com:0:0 or RCPT
TO: ORCPT=rfc822;groupwise-i...@example.com:0:0
NOTIFY=SUCCESS,FAILURE
In the above the domain part of the ORCPT address resolves to
example.com:0:0 which is rejected by smtpd with the message:
smtpd[20797]: 1a3a396cd4c57d05 smtp failed-command command="RCPT
TO: ORCPT=rfc822;groupwise-i...@example.com:0:0
NOTIFY=SUCCESS,FAILURE" result="553 ORCPT address syntax error"
I've studied RFC 3461 section 4 and 4.2 but it's not entirely
clear to me if the above ORCPT command is valid or not. The
encoding adheres to the spec, which says it must be valid xtext.
With this patch smtpd accepts any ORCPT that is valid xtext as
defined in the RFC (and logs on informational message when it
consists of an invalid user or domain name).
Cheers,
Tim
---
usr.sbin/smtpd/smtp_session.c | 22 ++
usr.sbin/smtpd/smtpd.h| 1 +
usr.sbin/smtpd/util.c | 32
3 files changed, 51
insertions(+), 4 deletions(-)
diff --git a/usr.sbin/smtpd/smtp_session.c
b/usr.sbin/smtpd/smtp_session.c index 72e13e8fd8d..c0c29d4a695
100644
--- a/usr.sbin/smtpd/smtp_session.c
+++ b/usr.sbin/smtpd/smtp_session.c
@@ -2415,6 +2415,7 @@ smtp_tx_create_message(struct smtp_tx *tx)
static void
smtp_tx_rcpt_to(struct smtp_tx *tx, const char *line)
{
+ struct mailaddr orcptaddr;
char *opt, *p;
char *copy;
char tmp[SMTP_LINE_MAX]; @@ -2469,10 +2470,23 @@
smtp_tx_rcpt_to(struct smtp_tx *tx, const char *line)
if
Re: Silently reject mails
Since you mentioned "all mails" and "without creating non deliverable notices", I think it's worth pointing out that the mail server will probably send delivery status notifications for successfully delivered mails, if the sender requested it, so also look for the no-dsn option you can set on the listener. On Wed, Dec 06, 2023 at 09:43:22PM +0100, Omar Polo wrote: On 2023/12/06 20:17:49 +0100, Hagen Bauer wrote: hi, i have not found a way to silently drop all mails to a domain. (yes there is a use case to run a mail server that does not store any mails without creating non deliverable notices) Is there a way to configure opensmpt for such a use case? Haven't tried, but a mda command that writes to to /dev/null should be a way. (not tested) action "ignore" [...] mda "cat >/dev/null" Cheers, Omar Polo
