Re: request discussion of two documents on SMTP relaying
[sigh. Frank's message didn't cc the ietf-smtp(_at_)imc(_dot_)org list but was
sent instead to a newsgroup that was gatewayed to the ietf-smtp list.
since my MUA isn't configured to send messages to newsgroups it didn't
send a reply to the list. and I wrote my reply to Frank as if it were a
personal reply not a list reply - so I was slightly more candid in that
reply than I would be on a list. it was only after I sent my private
reply to Frank that I realized he had effectively bcc'ed the ietf-smtp
list. So for the benefit of the list, this is a slightly edited version
of my reply to Frank's message.]
Keith Moore wrote:
Do you have this somewhere as plain text I-D ?
not yet. I'll republish as an I-D if there seems to be interest.
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
Sites MAY also use port 25 for an MSA (gellens-submit-bis-02).
hmm. I should definitely try to get in sync with that document.
| 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).
yes, you're right. I changed from MDN to MRN in the middle of writing
the document to avoid confusion with message disposition notification.
| 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
the MTAs don't all have to be MXes - only the MTAs that accept mail from
other networks need to be MXes. some mail networks route mail through
multiple levels of MTAs internally - maybe for firewall traversal or
some other purpose. all of those MTAs belong to the MRN but not all of
them need to be MXes. really I need to have a figure showing how MRNs
and MONs are composed of MTAs, and how they interface to each other, to
MUAs, and to message stores, to make this clearer.
| 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.
I don't think they're mutually inconsistent. It's just that
2476/2476bis doesn't recognize that one of the reasons to not add a
Sender field is to avoid disclosing an email address that the originator
doesn't want to disclose (maybe because he wants to keep it a secret, or
maybe just because he doesn't want to receive mail there).
| 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
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 ?
I'm not familar with that document, I'll have to look at it.
| 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.
Yeah, I'm a bit uncomfortable with that, but I don't see any way to
prevent ISPs making this a part of their AUPs. What I hope to do is
convince people that it's not reasonable to expect the originator's
authenticated identity to be exposed or for it to be a valid email
address. I want to strike a balance between saying that the mail has to
be traceable without saying that the originator's identity has to be
| The Submission protocol is a recent addition to the Internet
| mail protocol suite.
1998 (RfC 2476) is three years older than 2001 (RfC 2821).
yes, but SMTP has been around since 1980 or so.
| 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.
I probably need to rewrite this text. It's fine for an MTA to be
configured to be an MSA and to treat all incoming messages as
submissions. It's also fine for an MTA to be an MX (or a relay by
private arrangement) and treat all incoming messages as relays for a set
of "local" domains. What's tricky is when the same MTA tries to be both
MSA and relay - then it needs a reliable way to whether an incoming
message is a submission or a relayed message. Using authenticated
identites to know which is which works fine, I think. Using source IP
addresses to determine which is which doesn't work so well.
| An SMTP server SHOULD NOT attempt to distinguish submissions
| from relayed mail based on the source IP address of the
Sorry, I don't get it, what's the idea here, RADIUS is evil ?
Or is it about SMTP-after-POP ? Both ? Something else ?
none of those. the problem is that this behavior makes submission
behavior of MUAs location-sensitive, so they fail in odd ways that are
hard for users to diagnose. but it's a SHOULD NOT, so mail networks can
make exceptions to the rule if they have a good reason to do so.
| 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 ?
having separate MSAs for roaming users vs. fixed users seems like poor
design. it's another set of MSAs to maintain, another set of
instructions to provide, another configuration detail users have
> to get right, another source of calls to tech support. I don't know
> why we should encourage it.
| 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".
I think there's a gap between our terminologies. what do you mean by
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 is a point that needs amplification in my document, and probably
needs to be clarified in RFC 2476bis.
in general, the MSA is not in a position to know that the MAIL FROM
address is not authorized for use by the authenticated identity. the
MSA may be in a position to say "yes, this MAIL FROM address _is_
authorized" but can rarely be in a position to reject the message. The
MSA can always say "I won't submit this message with this MAIL FROM
address" but that leads to fairly dysfunctional behavior.
| 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.
well, I'm not really trying to "block" the hutzler document, just trying
to make sure that any document that does get approved as BCP is
there are lots of reasons that ISPs block port 25, so I don't see any
particular reason to mention bot-nets. I certainly agree that bot-nets
will adapt to port 25 blocking.
| 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.
well, MUST just means you don't comply with this specification unless you
follow the recommendations in the specification. nobody should expect
legacy MUAs, MTAs, MSAs, or anything else to comply with a specification
that was written after they were installed. the whole point of this
kind of a specification is to improve existing implementations and
practice rather than to legitimize existing implementations and practices
that don't work well.
yes, users will eventually need to upgrade their MUAs. I think that's a
reasonable expectation for anyone who is using MUAs that send cleartext
passwords, or for MUAs that can't specify a port # on the submission
server, or that can't do STARTTLS and AUTH PLAIN. but this document
doesn't specify a timeframe.
| 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.
actually this one isn't about about cram-md5, it's more like auth plain
and auth login.
regarding cram-md5: anything that does challenge-response without
changing the key each time is easy to break independent of what hash
algorithm is used, especially in the case of a wireless network where
it's very easy to impersonate a server and mount a man-in-the-middle
attack. one time passwords (s/key) work okay, but not
challenge-response. this implicates cram-md5, and also APOP (not that
this is relevant to message submission), and some other things too.
| 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.
maybe the terminology needs some tweaking. maybe I should talk about
MSAs, relays, and dual-use MTAs that act as both MSAs and relays
depending on the conditions.
thanks for the careful review and insightful comments.