Re: smtp-out: Address family mismatch

2020-07-21 Thread Peter J. Philipp 
Hi, I had these when I changed my secrets password, smtpd needs to be 
restarted after.


Regards,

-peter

On 2020-07-20 11:14, Harald Dunkel wrote:

Currently I have 100+ EMails queued with "Network error on
destination MX". This is a severe regression since OpenBSD
6.6.

Every insightful comment is highly appreciated

Harri


On 7/6/20 9:01 AM, Harald Dunkel wrote:

Hi folks,

I see a lot of outgoing EMails queued with a message "smtp-out:
Address family mismatch" in the log file. My colleagues don't like
EMails being put on hold at all.

Prior to 6.4 there was a

 limit mta inet4

The upgrade guide to the new smtpd.conf syntax 
(https://www.openbsd.org/faq/upgrade64.html)

mentioned "set and limit removed as main keywords" and a new
"mta namespace", but smtpd.conf(5) is insufficient in this aspect.
It doesn't tell. 
https://poolp.org/posts/2018-05-21/switching-to-opensmtpd-new-config/

doesn't tell, either.

My current (new-style) smtpd.conf has a line

 action "relay_external" relay src 192.168.1.1 helo 
"mail.example.com"


i.e. the AF is implicitly defined, but as the AF mismatch messages 
indicate

this is not sufficient.

Could you please elaborate?


Regards
Harri

Re: smtp-out: Address family mismatch

2020-07-21 Thread Harald Dunkel 

Currently I have 100+ EMails queued with "Network error on
destination MX". This is a severe regression since OpenBSD
6.6.

Every insightful comment is highly appreciated

Harri


On 7/6/20 9:01 AM, Harald Dunkel wrote:

Hi folks,

I see a lot of outgoing EMails queued with a message "smtp-out:
Address family mismatch" in the log file. My colleagues don't like
EMails being put on hold at all.

Prior to 6.4 there was a

 limit mta inet4

The upgrade guide to the new smtpd.conf syntax 
(https://www.openbsd.org/faq/upgrade64.html)
mentioned "set and limit removed as main keywords" and a new
"mta namespace", but smtpd.conf(5) is insufficient in this aspect.
It doesn't tell. 
https://poolp.org/posts/2018-05-21/switching-to-opensmtpd-new-config/
doesn't tell, either.

My current (new-style) smtpd.conf has a line

 action "relay_external" relay src 192.168.1.1 helo "mail.example.com"

i.e. the AF is implicitly defined, but as the AF mismatch messages indicate
this is not sufficient.

Could you please elaborate?


Regards
Harri

Failure to check FCrDNS with long DNS replies?

2020-07-21 Thread Tassilo Philipp 

Hello,

I have a strange problem, emails coming from a specific SMTP from SFR, 
namely smtp26.services.sfr.fr get incorrectly filtered by a fcrdns 
check. The filter line in question is:


filter check_fcrdns phase connect match !fcrdns disconnect "550 incorrect or no PTR 
record for submitting host (no FC)"


I made sure it's exactly that check, and not any other that is 
triggered, by using a specific error message.


The connecting server in my case is 93.17.128.197, which points 
back to smtp26.services.sfr.fr:


--%<---
$ dig -x 93.17.128.197

; <<>> DiG 9.16.2 <<>> -x 93.17.128.197
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34923
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;197.128.17.93.in-addr.arpa.IN  PTR

;; ANSWER SECTION:
197.128.17.93.in-addr.arpa. 83568 INPTR smtp26.services.sfr.fr.

;; Query time: 0 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: Tue Jul 21 12:26:47 CEST 2020
;; MSG SIZE  rcvd: 91
--->%--


And this is what smtp26.services.sfr.fr resolves to:

--%<---
$ dig smtp26.services.sfr.fr

; <<>> DiG 9.16.2 <<>> smtp26.services.sfr.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4219
;; flags: qr rd ra; QUERY: 1, ANSWER: 42, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;smtp26.services.sfr.fr.IN  A

;; ANSWER SECTION:
smtp26.services.sfr.fr. 3084IN  A   93.17.128.198
smtp26.services.sfr.fr. 3084IN  A   93.17.128.199
smtp26.services.sfr.fr. 3084IN  A   93.17.128.200
smtp26.services.sfr.fr. 3084IN  A   93.17.128.201
smtp26.services.sfr.fr. 3084IN  A   93.17.128.202
smtp26.services.sfr.fr. 3084IN  A   93.17.128.203
smtp26.services.sfr.fr. 3084IN  A   93.17.128.204
smtp26.services.sfr.fr. 3084IN  A   93.17.128.205
smtp26.services.sfr.fr. 3084IN  A   93.17.128.207
smtp26.services.sfr.fr. 3084IN  A   93.17.128.208
smtp26.services.sfr.fr. 3084IN  A   93.17.128.209
smtp26.services.sfr.fr. 3084IN  A   93.17.128.210
smtp26.services.sfr.fr. 3084IN  A   93.17.128.211
smtp26.services.sfr.fr. 3084IN  A   93.17.128.212
smtp26.services.sfr.fr. 3084IN  A   93.17.128.213
smtp26.services.sfr.fr. 3084IN  A   93.17.128.206
smtp26.services.sfr.fr. 3084IN  A   93.17.128.214
smtp26.services.sfr.fr. 3084IN  A   93.17.128.215
smtp26.services.sfr.fr. 3084IN  A   93.17.128.216
smtp26.services.sfr.fr. 3084IN  A   93.17.128.217
smtp26.services.sfr.fr. 3084IN  A   93.17.128.218
smtp26.services.sfr.fr. 3084IN  A   93.17.128.3
smtp26.services.sfr.fr. 3084IN  A   93.17.128.163
smtp26.services.sfr.fr. 3084IN  A   93.17.128.20
smtp26.services.sfr.fr. 3084IN  A   93.17.128.10
smtp26.services.sfr.fr. 3084IN  A   93.17.128.1
smtp26.services.sfr.fr. 3084IN  A   93.17.128.11
smtp26.services.sfr.fr. 3084IN  A   93.17.128.12
smtp26.services.sfr.fr. 3084IN  A   93.17.128.13
smtp26.services.sfr.fr. 3084IN  A   93.17.128.2
smtp26.services.sfr.fr. 3084IN  A   93.17.128.4
smtp26.services.sfr.fr. 3084IN  A   93.17.128.21
smtp26.services.sfr.fr. 3084IN  A   93.17.128.22
smtp26.services.sfr.fr. 3084IN  A   93.17.128.189
smtp26.services.sfr.fr. 3084IN  A   93.17.128.190
smtp26.services.sfr.fr. 3084IN  A   93.17.128.191
smtp26.services.sfr.fr. 3084IN  A   93.17.128.192
smtp26.services.sfr.fr. 3084IN  A   93.17.128.193
smtp26.services.sfr.fr. 3084IN  A   93.17.128.194
smtp26.services.sfr.fr. 3084IN  A   93.17.128.195
smtp26.services.sfr.fr. 3084IN  A   93.17.128.196
smtp26.services.sfr.fr. 3084IN  A   93.17.128.197

;; Query time: 0 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: Tue Jul 21 12:26:50 CEST 2020
;; MSG SIZE  rcvd: 723
--->%--


So, from my understanding, their DNS setup is correct, and the check 
shouldn't fail. The only thing that looks suspicious to me is that 
smtp26.services.sfr.fr points to a lot of records. Their order is 
seemingly random when fetching those records, I haven't tested, yet, 
whether it works if 93.17.128.19 is one of the first records returned. 
In the lookup that's cached at the moment, it's the last record.


So... is it somehow somewhere limited how many records are checked by a 
fcrdns check?


Thank you!