On Mon, Nov 22, 2021 at 11:22:33AM -0600, Aaron Poffenberger wrote: > On 2021-11-22 16:48 +0000, Claus Assmann <mutt+...@esmtp.org> wrote: > > I'm not sure the problem is really related to "fqdn of the Message-ID", > > could you give a real example: > > sending from the same host using the same addresses but two different > > Message-ID - only one of which fulfills the requirement you stated.
Clauss et al. are correct. The SMTP server does not look at the contents (i.e. the message headers) to make this decision; it is based solely on the message envelope presented in the SMTP conversation. That conversation can be and often is entirely different from what's in the headers, and you generally don't ever get to see it. The server has given you an honest accounting of the error.. > sbcglobal.net will fail delivery of the message with the following error: > > <user>@*sbcglobal.net*: 550 5.7.1 Connections not accepted from > servers without a valid sender domain.alph758 Fix reverse DNS for 198.51.100.1 It's just told you what the problem is, and you've misunderstood or ignored the explanation, and come up with a solution that just happens to work by coincidence, because it *also* effectively changes the piece of data that actually matters... Most likely the failed SMTP conversation (in its entirety) looks something like this: -=-=-=-=- EHLO host.example.com 550 5.71 Connections not accepted from servers without a valid sender domain.alph758 Fix reverse DNS for 198.51.100.1 -=-=-=-=- The receiving SMTP server most likely never gets past this--never gives your laptop a chance to send the message data (including the completely irrelevant message ID and the rest of the headers), because it first tries to look up host.example.com, which as you've said has no A record, so that fails. The IP address 198.51.100.1 also does not have a PTR record: $ host 198.51.100.1 Host 1.100.51.198.in-addr.arpa. not found: 3(NXDOMAIN) Normally the server will check the forward and reverse DNS lookups match (there's some minor variation and configurable behavior around this check from server to server, including the possibility to enable or disable it entirely), and reject the connection if there's a problem. I'm 99.9% sure that is what has happened here. The usual (and most correct) way around this problem is to set the outgoing mail relay on the machine from which you're sending mail to be the mail server responsible for your domain, assuming it is propertly configured to accept mail to be relayed from your machine... If it's your ISP's server or similar, there may be hoops you need to jump through to configure authentication so that it will do that. Bottom line: This is NOT a Mutt problem. It's a misconfigured MTA/host problem. Without a MUCH better justification, this patch should be rejected: It only allows the user to configure their message ID improperly. But then again, I made that same argument for the entire message ID format feature, and pointed out that if you let people do that, they will... > I know this is related to Message-ID... The most confounding part of being human is you can be absolutely certain that something is true, and still be wrong... =8^) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
