In <9156B81DAA29204989AD43E88688FAAB013ED5D4(_at_)df-lassie(_dot_)dogfood>
"Harry Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
On Monday, April 19, 2004 7:57 AM, wayne [wayne(_at_)midwestcs(_dot_)com]
wrote
In <9156B81DAA29204989AD43E88688FAABF7EDF8(_at_)df-lassie(_dot_)dogfood>
"Harry Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
As I mentioned previously, I looked through my inbox and
found that there are people using the Sender: header right
now and are doing so in ways that it will not pass
validation. [snip]
[snip] By definition, the behavior we determine to be
acceptable will be a *proper subset* of whatever behavior is possible
today under the RFCs.
[snip]
We should strive to keep the set of acceptable behavior as large as
possible. [snip]
However, if we get hung up on pathological cases like Sender headers
that contain localparts only, we're never going to get anywhere.
I forget who on his list said it, but we aren't talking about "break
everything (now)" vs "break nothing (ever)". We are all in the middle
some where. I agree, we are going to break things and I agree,
if possible, breaking less is better than breaking more.
When we break things, we need to consider whether the breakage will
cause the email to be incorrect rejected, or incorrectly accepted. In
the case of people adding Sender: headers, these were all legitimate
emails that would be incorrectly rejected. As I mentioned, there are
things that clearly won't pass (e.g. local part only), but I *didn't*
check to see if the things that looked right on the surface would have
likely passed.
People will accept *A LOT* more bogus emails that are incorrectly
accepted than valid emails that are incorrectly rejected.
In one of my earlier posts on the subject of the Sender: header, I
compared it with the HELO domain. I suspect that I wasn't clear
enough with that reference, so let me compare the handling of the HELO
domain via SPF with the handling of the Sender: header with C-ID.
Both the HELO domain and the Sender: header have been around for a
long time. Both are used enough to make breaking existing practices a
concern. Neither have been really strongly validated before so people
have gotten away with putting junk in the fields.
With SPF and the HELO domain, having junk in the domain will not cause
the validation to fail. Yes, that means a spammer can use a "HELO
asdf" and a "MAIL FROM:<>" and SPF won't reject it. This is far from
ideal and I suspect that, over time, more and more people will choose
to reject junk in the HELO domain, whether they use SPF or not.
However, even if the spammer can avoid being rejected due to SPF
checks, part of the goal of SPF is still accomplished. My domain name
won't get bounces sent to it, and my domain name won't show up in the
headers.
With C-ID and the Sender: header, having junk in the field will cause
the validation to fail. This means that legitimate email will be
rejected. Even a perfectly valid email addresses can fail the
validation when they are sent to a mailing list or email forwarder
that doesn't overwrite the Sender: header.
If C-ID is changed so that junk in the Sender: header means that the
email would be accepted, kind of like junk in the HELO domain case,
then one of the goals of C-ID is lost: My domain can still end up in
the From: header.
What a Hobson's choice!
Now, we know that validating the Sender: header will break things.
As I mentioned above, that isn't a killer, by itself. The question
comes back to "How much email will break?" and "Is it worth it?" We
don't have any really good data to answer the first question, but we
are arguing about the second question anyway. :-<
So, it seems pretty clear to me that email forwarders should not add
Resent-* headers.
Unfortunately, the RFC is by no means clear on this point. In fact it's
quite ambiguous.
[explanation deleted]
Ok, Andy asked about which identities would not require changes to
RFC2821/2822, which would be beyond the scope of this WG. I'm afraid
that I then went off looking for conflicts with the RFCs and this was
a mistake.
Really, there two important considerations:
1) Are we breaking existing practices? If so, is it worth it?
2) Will the chairs, or IETF editors, or whoever, let us publish an RFC
without complaining that there is a conflict?
I know I can't answer the second item and I think I should concentrate
more an the first.
For what it is worth, I don't completely agree with your explanation,
but that is irrelevant if we can get an RFC published.
Q2: Why not put RFC2821 MAIL FROM as the first identity in
step 2?
A: Because that would *force* adoption of SRS.
[...] Or in RFC lingo, SRS can be a MAY, but
not a MUST.
If I understand you correctly, the above means that you think
that the envelope-from MUST not be validated. Is this correct?
No, what I'm saying is that SRS MUST NOT be a requirement.
Ok. I will have to agree to disagree with you on this subject.
Sorry for the length of this post, I actually did try to make it shorter.
-wayne