ietf-smtp
[Top] [All Lists]

Re: request discussion of two documents on SMTP relaying

2005-06-15 20:58:14

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

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
eXchanger)".


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


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

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


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 "smarthost" here?

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

Keith