Hi John,
At 13:25 27-05-2011, John Levine wrote:
The description of the protocol is fine. The dicta, less so.
Setion 3.2 says:
If an MSA is not able to determine a return path to the submitting
user, from a valid MAIL FROM, a valid source IP address, or based on
authenticated identity, then the MSA SHOULD immediately reject the
message. A message can be immediately rejected by returning a 550
code to the MAIL command.
I think I understand the motivation, but that just seems wrong. I
have lots of web scripts that submit mail using various bounce
addresses, and there's no way to tell whose script it was without
looking at the web logs. My MUAs put a variety of bounce addresses on
the mail they send, some in domains local to the host with the
submission server, some not. So what?
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.
The NOTE: at the end of the section suffers from our endemic bad UI
advice syndrome:
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".
Section 3.3, third pp says:
IP address restrictions are very widely implemented, but do not
allow for travelers and similar situations, and can be easily
spoofed unless all transport paths between the MUA and MSA are
trustworthy.
Spoofing the IP on a TCP session is very difficult, and if an attacker
can do that, you've got worse problems than faked mail.
The following paragraph mentions IPsec, the pp after that
pop-before-smtp. Speaking as the inventor of pop-before-smtp, I think
it's time to kill that dinosaur. I'd suggest replacing all three PP
with something like this:
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.
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.
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.
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.
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.
Regards,
-sm
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
