A lot of this stuff is advice that doubtless seemed reasonable in 1998,
but not so much now.
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'm a little unclear on why you think the requirement to check the validity of
the MAIL FROM would be a problem here.
But that's not what it says. By my reading, if the MSA can't divine "a
return path to the submitting user", it's supposed to reject the mail.
As in my example, what if the submission is a web script that happens to
be sending a message with a null return path, something that the following
pp specifically says is OK, or that returns bounces to some other server
which is configured to handle them, but the MSA doesn't happen to know
about. What's "a return path to the submitting user"? Why should an MSA
care?
That's not the same as syntax-checking any return path that the client
provides, which I agree is entirely reasonable, and is implicitly covered
in sec 4.2 and explicitly in 5.1.
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.
Strongly disagree. Yes, people handle bounce mnaully all the time, and they
often handling them badly. MUA correlation of bounces with original
messages addresses that and IMO we should encourage it, which is what this
section does.
I realize this advice has been in SUBMIT RFCs since 1998, but just out of
curiosity, what MUAs do that? I've never seen one. If after 13 years
nobody's taken the advice, perhaps it's time to stop.
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 difficulty of IP address spoofing varies tremendously with network geometry
and location. The nature of the address you're attempting to spoof can also be
a factor.
Right. But if they're on your LAN and sniffing your traffic, like I said,
you've got worse problems than spoofed mail. To me this implies that IP
spoofing is easy in general, like spoofing a From: address, but it's not.
Question: Aside from the VPN case, how much IPsec usage for securing SMTP have
you seen?
I've never used IPsec at all, being an ssh kind of guy. How about redoing
the advice to say something general about using session security
appropriate to the (in)security of the connection?
The NOTE: in section 8 appears to contradict the last paragraph in 4.2.
Is it OK to expand single-component domains or not?
The restriction in 4.2 is talking about multi-compponent but not fully
qualified domains, so I don't see the conflict.
Sec 4.2 says that adding a domain to a single component doman is OK,
multicompoment domain isn't. Sec 8 says:
For example, indiscriminately appending a domain to an address or element
that lacks one typically results in more broken addresses. An
unqualified address must be verified to be a valid local part in the
domain before the domain can be safely added.
Which now says that adding domains to single component domains isn't
always a great idea either. It would be nice if they agreed.
Section 8 also says:
An unqualified address must be verified to be a valid local part in the
domain before the domain can be safely added.
Again, I see the point but in the not uncommon case that the MSA doesn't
have access to the full table of local addresses, the worst thing that
will happen is a bounce, which may be annoying but doesn't seem "unsafe"
to me.
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
