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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp