>> 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. ...
In any event, this language is unchanged since 2476 and it seems to me
that is that it's so obviously wrong that nobody's tried to do what it
says, making it harmless.
We implemented this advice long before 2476 even existed. While there have been
some peculiar exceptions (like people using an MUA that doesn't show the actual
SMTP error to the user - in this case accepting the message and generating a
DSN later is actually more informative), it has generally proved to be sound.
> 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.
Now I'm doubly confused. Are we interpreting this as "if the MSA knows
the message is messed up, reject it?"
That's the effect of what it says.
That's fine advice, but I can't see
any relation between that and the existing text.
The relationship seems completely obvious to me.
>> 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.
Seems a bit odd to reiterate advice that people have been ignoring for 13
years, but I suppose many of us have teen-aged children.
No, what seems odd is wanting to remove sound advice just because it hasn't
been widely implemented.
>> 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.
Huh? I send a message to "foo", an address that doesn't exist because the
user's address is actually "[email protected]". Then what happens?
No, what happens is someone sends to foo or foo@bar because that worked in one
context; this gets blindly expanded to [email protected] or
[email protected] in another context and gets sent to the wrong user.
Unfortunately lots of places make extensive use of short form names in their
infrastructure and don't think through the consequences, especially for mobile
devices.
Or maybe this is in fact OK with you since you appear to be arguing that
implementation advice should always reflect what implementations actually do
instead or what they should be doing.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
