Re: [ietf-smtp] Endless debate on IP literals

[Hector Santos <[e-mail]>]

On 1/1/2020 11:30 AM, Keith Moore wrote:
> On 1/1/20 11:01 AM, John R Levine wrote:
>
>> I'm thinking, for example, of DMA (Dragonfly Mail Agent), a small
>> almost MTA that I use on my small server boxes.  Even though DMA can
>> technically do all the things that 5321 says an MTA is supposed to do,
>> I have it configured to relay everything to the submission server on
>> my real MTA rather than trying to send mail directly.
>
> I've been wondering if there's a need to talk about (for lack of a
> better term) "pre-submission relaying" which happens when a message is
> (for whatever reason) not initially submitted to a real submission
> server that does whatever sanity checking and fixup are needed to make
> the message suitable for relaying into the global email system.

Interesting. A SMTP lint or MCA "Mail Compliancy Agent?"

   MTA <--> MCA
        --> MDA

The MTA connects to the MCA which can issue MCN (Mail Compliancy 
Notification) responses vis reply codes as an initial check. If 
positive, the MTA continues with the normal transport with a higher 
confidence all will work.  But what if the MCA doesn't match the 
target MDA checks, like at mail.ietf.org who will reject valid 
ip-literal usage?

Also, once MCA certification takes place, is it turn off, because it 
becomes redundant at that point.  It would be a nice idea for SMTP 
test site for new and updated MTAs.

Under wcSMTP and I believe across many other peer products, a "SMART 
HOST" concept is used. The profile and configuration in wcSMTP allows 
for sessions attributes:

- Profile Name: Target Email Domain
- required field: mail host domain
- optional field: port, default 25
- optional field: EHLO field, if blank, dynamic FQDN::IP-literal
- optional field: TLS Yes/No
- optional Field: ESMTP AUTH credentials

> The next thing I wonder is what port should be used for pre-submission
> relaying, or whether there should be a separate port for that, or
> whether there's a need for in-band signaling to tell an MTA which role
> it is supposed to play for a particular transaction.   (Somehow I
> don't think yet another port is a good idea, as I suspect that it just
> has the effect of giving people more confusing configuration choices
> to make).

No more ports please, :-) but you reminded me of another new 
legitimate section item for RFC5321bis:

- "Well-known" Protocol for MUA Configuration

https://tools.ietf.org/html/rfc8615

I did not use this, but I followed the Mozilla Thunderbird 
"well-known" setup for the next update of wcSMTP for auto-configuration:

https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat

> So to my mind the
> question then becomes, how do we unambiguously indicate where that
> fixup is to be done, so that it is only done once?

I see the "MCA" as an optional testing site.  It would be redundant 
once the kinks are worked out.

Some of us remember Fidonet, but back in the day, a new Fidonet 
installation node MUST have a valid compliant mail client/server 
frontend that following FTN1 specification before getting an address 
for the world-wide public nodelist.  Each local regional networks had 
a Network Hub who did the compliancy testing.

That would be equivalent to a domain registrar or ISP not giving you a 
DOMAIN or not allowed to get on the network or put the domain in DNS 
unless your SMTP installation supported the original protocol RFC788 
which predated RFC821.

I use to say it was the beginning of the demise when Fidonet 
Developers who were now working on X.25 and the coming IP world, were 
stuck supporting a primitive FTN1 (XMODEM based packet transfer 
protocol) when we now had text-based WAZOO client/server negotiating 
link phases.  That would be akin to having EHLO. If you didn't support 
it, you would not be allowed to send/receive mail.

Fortunately, the IETF did not go to this extent.

-- 
HLS