[Top] [All Lists]

Re: request discussion of two documents on SMTP relaying

2005-06-15 17:59:44

Keith Moore wrote:

Do you have this somewhere as plain text I-D ?  I collect some
interesting I-Ds, and your text could fit into my collection:

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

| 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.


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