[Top] [All Lists]

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

2020-01-02 10:48:55
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 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

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

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.


ietf-smtp mailing list