Re: Cannot update smtpd.conf to new format

[paul]

Ok, I seem to have made this work. I replaced mydomain.com 
 (which is really just an alias) in the action clause, 
with the server's name from the hosting provider, and messages are now being 
accepted and delivered.

Thanks to anybody who looked at this. I am curious as to why this may have 
happened ’though, if anybody cares to comment.

Thanks,
Paul.



> On 19/11/2023, at 2:20 PM, paul  wrote:
> 
> Hi list,
> 
> Some time ago I set up opensmtpd on a debian device to forward emails to a 
> remote mailserver for delivery. It's been working beautifully for a couple of 
> years now, and continues to do so. Now I'm attempting to set up a similar 
> device the same way however I cannot get the smptd.conf file to work with the 
> new format.
> 
> I've read the man page and found a number of examples on the web with subtle 
> differences, but I havnt been able to get anything to work.
> 
> Here is the old, working .conf file:
> listen on localhost
> table aliases file:/etc/aliases
> table secrets file:/etc/secrets
> accept for local alias  deliver to mbox
> accept for any relay via tls+auth://p...@mydomain.com auth 
> 
> And here is what I'm trying:
> table aliases file:/etc/aliases
> table secrets file:/etc/secrets
> listen on localhost
> action "localmail" mbox alias 
> action "outbound" relay host smtp+tls://p...@mydomain.com auth 
> match from local for local action "localmail"
> match from local for any action "outbound"
> 
> Here are some snippets from the syslogs
> old way - working
> Nov 19 13:31:45 pumpshed smtpd[631]: 311de33e8257add4 mta event=connected
> Nov 19 13:31:47 pumpshed smtpd[631]: 311de33e8257add4 mta event=starttls 
> ciphers=version=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256
> Nov 19 13:31:47 pumpshed smtpd[631]: smtp-out: Server certificate 
> verification succeeded on session 311de33e8257add4
> 
> new way - fails:
> Nov 19 13:30:14 play1 smtpd[28337]: 94dbb1ad70252b45 mta connected
> Nov 19 13:30:15 play1 smtpd[28337]: 94dbb1ad70252b45 mta tls 
> ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
> Nov 19 13:30:16 play1 smtpd[28337]: 94dbb1ad70252b45 mta ssl_check_name: no 
> match for 'no-tek.com' in cert
> Nov 19 13:30:16 play1 smtpd[28337]: 94dbb1ad70252b45 mta error reason=SSL 
> certificate check failed
> 
> Is the new version more restrictive that the old? Is there anything I'm 
> missing to achieve this functionality? Or is there a better way than what I'm 
> attemptin?
> 
> Thanks for any help with this.
> Paul
> 
> 
> 

Re: Cannot update smtpd.conf to new format

[paul]

Further info:

Opensmtpd on these devices was installed using the debian package manager, the 
old version is 6.0.3-portable, the new is 6.8.0p.
After edits to smtp.conf, I check with the ‘smtp -n’ command and restart the 
server with ‘systemctl restart opensmtpd’.
The remote mail server is a shared server from a reasonably large service 
provider - as far as I have seen, it’s configuration is pretty ordinary. They 
state they prefer SSL/TLS on SMTP port 465.
The secrets and aliases files are identical on both devices and conform to the 
man page.
I’m unclear of the need for newaliases or makemap, but issuing these commands 
doesn’t seem to change anything.

I’m sure there is more info I need to provide. I’m sorry, I can’t think what.
As you can see, I’m stumbling round in the dark a bit here.

Thanks,
Paul

Cannot update smtpd.conf to new format

[paul]

Hi list,

Some time ago I set up opensmtpd on a debian device to forward emails to a 
remote mailserver for delivery. It's been working beautifully for a couple of 
years now, and continues to do so. Now I'm attempting to set up a similar 
device the same way however I cannot get the smptd.conf file to work with the 
new format.

I've read the man page and found a number of examples on the web with subtle 
differences, but I havnt been able to get anything to work.

Here is the old, working .conf file:
listen on localhost
table aliases file:/etc/aliases
table secrets file:/etc/secrets
accept for local alias  deliver to mbox
accept for any relay via tls+auth://p...@mydomain.com auth 

And here is what I'm trying:
table aliases file:/etc/aliases
table secrets file:/etc/secrets
listen on localhost
action "localmail" mbox alias 
action "outbound" relay host smtp+tls://p...@mydomain.com auth 
match from local for local action "localmail"
match from local for any action "outbound"

Here are some snippets from the syslogs
old way - working
Nov 19 13:31:45 pumpshed smtpd[631]: 311de33e8257add4 mta event=connected
Nov 19 13:31:47 pumpshed smtpd[631]: 311de33e8257add4 mta event=starttls 
ciphers=version=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256
Nov 19 13:31:47 pumpshed smtpd[631]: smtp-out: Server certificate verification 
succeeded on session 311de33e8257add4

new way - fails:
Nov 19 13:30:14 play1 smtpd[28337]: 94dbb1ad70252b45 mta connected
Nov 19 13:30:15 play1 smtpd[28337]: 94dbb1ad70252b45 mta tls 
ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
Nov 19 13:30:16 play1 smtpd[28337]: 94dbb1ad70252b45 mta ssl_check_name: no 
match for 'no-tek.com' in cert
Nov 19 13:30:16 play1 smtpd[28337]: 94dbb1ad70252b45 mta error reason=SSL 
certificate check failed

Is the new version more restrictive that the old? Is there anything I'm missing 
to achieve this functionality? Or is there a better way than what I'm attemptin?

Thanks for any help with this.
Paul

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

[Tassilo Philipp]

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

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


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


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

Thank you


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


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


Thanks!

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


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


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


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


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


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


Cheers,

Tim

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


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

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

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

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

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

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

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

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

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

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

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

int valid_localpart(const char *);
int valid_domainpart(const char *);
int valid_domainname(const char *);
+int valid_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