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.
But it also states that having a valid MAIL FROM is one way to meet that
condition.
You appear to be reading this backwards. There are a number of ways to
determine an error reporting path, including but not limited to having
a valid MAIL FROM.
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.
When a MUA uses a null MAIL FROM it is explicitly saying that it doesn't care
about error reports. In this case it seems rather obvious that the MSA
shouldn't care either
I think this is totally obvious, but if you believe it needs to be clarified
then let's clarify it by saying that this only applies when an MUA says it care
about errors.
What's "a return path to the submitting user"? Why should an MSA
care?
It's a implementation quality thing. The longer you wait to return an error,
the less likely the notification will make it back to the person who needs to
know the message didn't make it.
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.
If a MSA can perform additional validity checks it should.
>> 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.
There are several that came out of the X.400 world that do this - it's a GOSIP
requirement, more or less.
I would be inclined to agree with removing this if compliance language
were involved, but AFAICT it isn't. THis is just implementation advice, and
IMO it is sound implementation advice.
>> 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?
Sounds like a good idea to me. At this point I'm not even sure that it is sound
implementation advice to recommend IPSec. (I have been forced to use IPSec; it
has not been a happy experience at all and I'm delighted that the trend seems
to be towards TLS or ssh and away from IPSec.)
>> 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.
Still not seeing any real conflict here.
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.
I've seen this practice result in delivery to the wrong recipient. That
seems unsafe to me.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
