Keith Moore wrote:
http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html
Do you have this somewhere as plain text I-D ? I collect some
interesting I-Ds, and your text could fit into my collection:
<http://purl.net/xyzzy/home/test/>
this topic needs more discussion among SMTP implementors and
users before any document can claim to have rough consensus
Maybe they'll publish draft-hutzler-spamops as "experimental",
with the IESG expecting the worst is a fatal lack of fantasy.
| A Mail Submission Agent (MSA) is an agent that allows an
| authorized originator to submit messages via the Submission
| protocol, as defined in RFC 2476 or its successors, on port
| 587.
Sites MAY also use port 25 for an MSA (gellens-submit-bis-02).
| A Mail Originator Network (MON) is a set of MSAs and MTAs
| that accept messages on behalf of authorized users, and relay
| each message to the appropriate MDNs for delivery of the
| message to its intended recipients.
Probably you wanted s/MDN/MRN/ (mail recipient network).
| A Mail Reception Network (MRN) is a set of MTAs that accept
| mail on behalf of a set of mail domains and deliver each
| message to each recipient's message store.
Maybe add to MTAs "(some of them also known as 'MX' or Mail
eXchanger)".
| A nonlocal recipient address of an MRN is an email address
| that is not a local recipient address of that MRN.
Okay, that promises to be hardcore, I'm intrigued.
| Submission servers MUST NOT disclose the authenticated
| identity of the originator of a message (in the Sender,
| Received, or any other fields, or in the message body, or
| in any SMTP command) unless that identity also appears in
| the originator-supplied MAIL FROM field, From header field,
| or Reply-To header field.
This MUST NOT doesn't fly with option 8.1 in 2476 / 2476bis.
| Submission servers MAY disclose the authenticated identity of
| the originator of a message (in the Sender, Received, or
| other fields) if that identity already appears in the
| MAIL FROM, From, or Reply-To fields in the message as
| submitted by the originator.
They MAY disclose it if it's disclosed anyway ? Well, yes. Or
are you thinking about draft-kucherawy, something like "MSA did
check x", where x matches one of the three "return addresses"
in your terminology ?
| The originator has explicitly consented to the provision of
| such information.
That might fix the MUST NOT problem mentioned above - the user
of an MSA generally accepts its AUP, otherwise he can't use it.
| The Submission protocol is a recent addition to the Internet
| mail protocol suite.
1998 (RfC 2476) is three years older than 2001 (RfC 2821).
| An SMTP server SHOULD treat an incoming message as a
| submission if the SMTP server exists for only the purpose of
| mail submission, the server is not listed as an mail
| exchanger for any of the domains associated with the MRN, and
| the server is not otherwise advertised as a mail relay.
I'm not sure what Hector will say about this. In some cases an
MTA just "knows" that it's used as MSA. Okay, "only" a SHOULD.
| An SMTP server SHOULD NOT attempt to distinguish submissions
| from relayed mail based on the source IP address of the
| client.
Sorry, I don't get it, what's the idea here, RADIUS is evil ?
Or is it about SMTP-after-POP ? Both ? Something else ?
| A laptop-based MUA which submits mail successfully when
| connected to its home network (because the SMTP server
| "trusts" the laptop's "home" IP address) might inexplicably
| fail to submit mail when connected to another network.
The laptop user didn't understand the AUP of his favourite MSA.
Or do you want an "MSA for roaming users" != "smarthost" here ?
| MONs SHOULD encourage users to configure their MUAs to use
| Submission servers (rather than SMTP servers) to submit mail.
Yes, that's exactly what you want. And your definition of MSA
doesn't cover "smarthost". That's a major difference from the
2476 terminology if I understand it correctly. I've no problem
with your goal by itself.
Maybe you could say "dedicated MSA" instead 2476-MSA, if you
want "2476-MSA minus smarthost".
In your MON-recommendations I miss strong support for RfC 2476
option 6.1. Again and again I see articles where users think
that SMTP AUTH catches "cross-user forgeries". Only 6.1 does.
| This memo takes no position on the blocking of outgoing
| traffic on port 25.
If this memo is intended to "block" draft-hutzler-spamops, then
it might as well say that "blocking port 25" doesn't remove the
mail worms from infected systems. The bot-nets will find some
other abuse like DDoS attacks or redirecting spamvertized URLs.
| MUAs MUST
No, MUAs SHOULD. It's the privilege of users to use old MUAs,
and any "upgrade all MUAs" scheme is a doomed FUSSP. And it's
probably a support nightmare.
| any method requiring transmission of password-equivalent
| material, MUST NOT be accepted over an unsecured channel.
Is that about CRAM-MD5 ? Then this memo should be presented
again in 2015, and until then draft-hutzler-spamops will do.
| Submission servers and SMTP servers intended to provide
| submission services
Is it not only me who has difficulties with your terminology ?
Something's odd, SMTP servers intended to provide submission
services (maybe among other services) _are_ submission servers.
Bye, Frank