Re: how to ignore TLS1.3 for test purposes?

2020-07-28 Thread Larkin Nickle

On 2020-07-28 02:56, Harald Dunkel wrote:

Hi folks,

there seems to be a compatibility issue between opensmtpd on
OpenBSD 6.7 and exim4 on Debian's bugtracker, see

 https://lists.debian.org/debian-user/2020/07/msg01091.html

Most recent syspatches are applied, of course. I cannot reproduce
this problem with opensmtpd 6.7.1-p1 on Debian.

How can I tell opensmtpd on OpenBSD to ignore TLS1.3 and to use
TLS1.2 only, just for test purposes? TLS1.3 in libressl appears
to be brand new. Maybe its buggy.


Every helpful hint is highly appreciated
Harri



Looking at smtpd.conf(5), you should be able to put `smtp ciphers 
control` (control being the control string of allowed ciphers). The 
default is "HIGH:!aNULL:!MD5". I think "HIGH:!aNULL:!MD5!TLSv1.3" should 
be valid in removing TLSv1.3 as far as I can tell according to 
SSL_CTX_set_cipher_list(3). I haven't actually tested this however, but 
this might be a useful starting point.




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

2020-07-28 Thread 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)




how to ignore TLS1.3 for test purposes?

2020-07-28 Thread Harald Dunkel

Hi folks,

there seems to be a compatibility issue between opensmtpd on
OpenBSD 6.7 and exim4 on Debian's bugtracker, see

https://lists.debian.org/debian-user/2020/07/msg01091.html

Most recent syspatches are applied, of course. I cannot reproduce
this problem with opensmtpd 6.7.1-p1 on Debian.

How can I tell opensmtpd on OpenBSD to ignore TLS1.3 and to use
TLS1.2 only, just for test purposes? TLS1.3 in libressl appears
to be brand new. Maybe its buggy.


Every helpful hint is highly appreciated
Harri



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

2020-07-28 Thread 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(>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@