In <20041226123713(_dot_)GA22103(_at_)alatheia(_dot_)elm(_dot_)net> Alex van
den Bogaerdt <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> writes:
There are a couple of comments I'd like to make; especially
the first one is _very_ important IMHO.
Thanks much!
2.1:
"Note that requirements for the domain presented in
the EHLO and HELO commands are not strict, and software must be
prepared for the "HELO" identity to be malformed."
Requirements _are_ strict. RFC2821 is clear on this:
[snip]
You are correct, I meant to same something like "not strictly
enforced", rather than "not strict".
However, there is a lot of confusion and therefore there are a
lot of bad clients out there. I suggest:
"Note that requirements for the domain presented in the
EHLO or HELO command are not always clear to the sending
party, and receiving software must be prepared for the
"HELO" identity to be malformed."
I'll use that.
2.4:
"If the authorization fails, then generating a non-delivery
notification to the alleged sender is problematic as such an action
would go against the explicit wishes of the alleged sender."
I'd prefer an addition. It needs to be clear even for the casual
reader that this may easily result in bounces to someone other than
the sender of the message. For instance:
...."wishes of the alleged sender. Furthermore, in todays
Internet there's a high probability the claimed sender is
a falsification and the non-delivery notification would be
sent not to the real sender of the original message but to
the victim of an attack. MTAs SHOULD NOT send non-delivery
reports in this case."
I really need to make another pass through the draft to find stuff to
*remove*. I could use some help here. The natural instinct is to
just keep adding stuff, and then a casual reader won't have a clear
idea of anything.
I think in this case, most people will understand the purpose of SPF
and the consequences. Also, this paragraph is about post-MTA
checking, so I think talking about what an MTA should not do is not
appropriate.
I changed the wording slightly to:
2) If the
authorization fails, then generating a non-delivery
notification to the alleged sender is problematic due to the
large number of forged emails on the Internet today. Such
an action would go against the explicit wishes of the
alleged sender.
2.5.2:
...."like the None result." --> "like the None result. The
different response if for logging purposes only."
Personally, I have argued that having separate Neutral and None
results is a bad idea because it encouraged people to treat them
differently. Unfortunately, there appears to be a lot of people who
want to treat them differently in certain cases. I'm afraid that
adding that line will just open a can of worms.
2.5.6:
Unless the 450 is really THE number to use, I suggest:
...."MUST use a 450 reply"... --> "MUST use a 4xx series reply"
2.5.7:
dito
Very good point and one that I've worried about before. I am *not*
certain what the correct SMTP response code should be. Suggestions
are welcome and I'll investigate both this, and the extended response
codes.
-wayne