I read the entire Section 3.2 again for context. There are cases when the
text you quoted may be applicable. The paragraph is about "Message Rejection
and Bouncing". Basically, it says that it is better for the MSA to reject a
message instead of bouncing it. As this is done close to the sender,
problems can be resolved more easily.
That part is fine. What seems wrong is the advice that the MSA should
reject the message "if it is not able to determine a return path to the
submitting user." My MSAs have no idea what is a return path to the
submitting user, nor whether a return path offered by a client has any
connection to that client. They check the bounce address syntax, put some
stuff in the Received: header that will let me identify the AUTH or login
user if need be, and go on.
This text is unchanged since 2476, so I must admit that even though it
makes no sense, it doesn't seem to have caused much damage.
To properly handle delayed bounces, the client MUA needs to maintain
a queue of messages it has submitted, and match bounces to them.
Again, that just seems wrong. Humans can and do look at bounces and
do whatever they do with no MUA help. Suggest deleting the sentence.
The user usually call the help desk or ignore these bounces. If a MUA were
to follow that advice, the user could be informed about whether the message
that is flagged as "sent" was actually delivered. Unfortunately, "many
contemporary MUAs do not have this capability".
Well, actually, most of the bounces I see have the return address and a
copy of at least part of the failed messsage, so there's not much less
context than there would be if the MUA were able to fish up a copy of the
original message. In any event, as far as I can tell, in the 13 years
this advice has been on offer, nobody's taken it. Perhaps it's time to
give up.
Some people are still doing pop-before-smtp "authentication". I advise
people to use SMTP-AUTH which is covered by the second paragraph of Section
3.3. One of the changes to the document is the normative reference to RFC
4954.
Agreed. My suggestion is to say less about pop-before-SMTP and just
mention that there are lots of ways to authenticate directly or
indirectly. In practice, I find that its problems are less that there's a
window for bad guys (never exploited that I'm aware of) and more that
there's no explicit support for it in most MUAs so users are baffled when
it doesn't work. ("You have to check your mail." "I did check my mail."
"You checked it too long ago." "???")
Section 6,1 refers to "submission rights." They're not defined anywhere.
What are they? The phrase appears in RFCs 2476 and 4409 but not in any
other RFC as far as I can tell.
As I read it, the text mentions the reply code and the enhanced status code
to use in such cases. "Submission rights" might, for example, be viewed as
which addresses are allowed in the "MAIL FROM". I am not sure whether the
text is a remnant from Section 3.4 of RFC 2476.
It's unchanged from 2476. Again, it doesn't seem to have caused much
damage even though I suspect I am not the only person who doesn't know
what it means. Your suggestion seems reasonable, although of course there
are plenty of other possibilities.
Section 6.4 describes special case handling of mail addressed to
postmaster. Does anyone actually do that? If not, perhaps move it to
a deprecated appendix.
My litmus test would be: "is this a problem". I suggest leaving it in.
Certainly harmless.
The NOTE: in section 8 appears to contradict the last paragraph in 4.2.
Is it OK to expand single-component domains or not?
I'll apply the same test as above.
It's only a problem if people take it seriously, which doesn't seem to
have happened in the past 13 years. Maybe we'll continue to be lucky.
Section 8.7 makes resolving CNAMES optional. I thought it was still
officially mandatory.
Section 8.7 goes with Section 8.8 (header rewriting). The decision for
address fields of the header is subject to local policy. I'm open on this
one.
I don't have any personal opinion, other that that it should be consistent
with whatever the relevant advice for SMTP is.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
