--Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
The current reality is that none of the identity fields in question
"need" to be correlated with much of anything. The goal of efforts
like this working group is to provide mechanisms that create and
enforce some type of correlation.
I agree with this.
MTA.MailFrom is a field set by the identity specified in Msg.Sender
and designated where transmission-level return notices should go.
Hence, this MTA-level address is specified by a message-level
identity, an arbitrary number of hops earlier in the sequence.
Further, the proposals for MTA.MailFrom validation all tie the peer
MTA authorization with the originator Sender (or From, but we can
debate that distinction separately.)
This degree of indirection is the reason these schemes break valid and
useful scenarios.
I think there is not enough information in these three paragraphs for me to
agree or disagree, so instead of doing either, I will attempt to clarify if
I understand, and ask for more information.
You are saying that the Sender is the entity which sets the MTA MAIL FROM.
This makes sense. The MAIL FROM is a return address, and could be
different from the sender address. I think I can understand this part.
The Sender is the source, and the MAIL FROM is a return path, so it should
not be considered as the source. Correct so far?
I don't really understand this sentence:
Further, the proposals for MTA.MailFrom validation all tie the peer
MTA authorization with the originator Sender (or From, but we can
debate that distinction separately.)
I'm not sure what proposals these are. I am familiar with SPF, which
validates MAIL FROM but doesn't try to tie it to Sender. I have also
reviewed MS-CID which validates From/Sender/Resent-From/Resent-Sender but
doesn't tie it to MAIL FROM. Are there proposals that tie the two together
which I may not be familiar with yet?
With regard to:
This degree of indirection is the reason these schemes break valid and
useful scenarios.
Can you give an example of such a scheme and such a scenario? Not trying
to be snide here, just that I don't understand the point.
As written here, it sounds like you are saying:
1. There are proposals that validate MTA MAIL FROM
2. All of these tie peer MTA authorization with (to?) the Sender
3. This is a degree of indirection. This breaks valid/useful scenarios.
I believe this is what the above 3 paragraphs say. But, then I am further
confused, because I understood you to say before that MAIL FROM *should
not* be validated by itself, and *should* be tied somehow to Sender. Maybe
I misunderstood you before.
I'm pretty sure you are saying that Sender is important. More so than the
MAIL FROM, which is just a return address. So, if I try to read the rest
in context with that, and take a couple of probable logic leaps, I can
*guess* that you are trying to say: "The Sender determines the MAIL FROM,
and the Sender determines the outgoing MTA, and there may be legitimate
reasons why the MAIL FROM and the outgoing MTA don't directly match up with
each other." Am I close?
I will not respond to the points until I can verify that I understand you
correctly.
The MTA.Helo construct is an assertion of the domain name associated
with the peer MTA. A mechanism that validates that domain name
provides a basis for an authorization (acceptability) mechanism,
associated with the owner of the domain. Whether that validation, in
turn, ties the domain name to the IP network address of the peer
network is a test of the scheme proposing to validate MTA.Helo. (For
reference, my own proposal does not yet achieve this; it's a goal but
it hasn't achieved it yet.)
JK> Indeed, HELO isn't an attribute of the mail at all, so
JK> while it's unlikely to break anything much, it's probably going to be
of JK> very little value in achieving the groups charter objective.
Rogue MTAs (eg, compromised systems) are a very serious problem,
considerably beyond bad bounce addresses. Validating that a machine
is authorized by its hosting network to act as an MTA would do quite a
bit to improve the basis for trusting that an MTA is well-behaved.
More generally, SMTP is a point-to-point protocol. Any attempt to
assign a level of trustworthiness to an MTA requires a chain-of-trust
model back to the originator. A chain is built in terms of its links.
Validating the acceptability of the peer MTA.Helo is the basis for
building that chain.
Here is another data point for discussion:
SPF had implemented a way to check HELO names, and the original proposal
was to only check HELO if the MAIL FROM was <>. However, many people said,
"Hey, I don't want MY domain used in HELO for other unauthorized MTAs, who
are just trying to forge HELO to fool people. Let's do this check all the
time, not just for MAIL FROM: <>" There is some support for this. In this
proposal, HELO would be checked in the same way as MAIL FROM, but the value
would only be blocked if it was failed - no information for the domain or
non-FQDN HELO would not block the message.
Now, I am not sure if you are saying HELO validation is important, or just
describing what HELO validation is/should be. The proposed extension to
SPF catches obvious forgeries, and where data is available, it does tie the
info we positively know about the MTA calling (its IP) with a certain
domain (the HELO).
The connection between the claim (HELO) and the known (IP) is good, and
provides us with some solid data we can record. I think this data is not
as important as the MAIL FROM or From:/Sender:. I think that HELO checking
can be worthwhile in itself, but I don't think it gets further toward the
other goals of reducing abuse of my domain as a return address, or as a
sender address. Would you agree with this?
Let me close by bringing us back to the beginning.. You said
The current reality is that none of the identity fields in question
"need" to be correlated with much of anything. The goal of efforts
like this working group is to provide mechanisms that create and
enforce some type of correlation.
I'll ask something fairly open-ended here. What fields do YOU want to see
correlated with something? What would you like to correlate them with?
(Apologies if you have answered this already, but I believe I have been
paying attention during the time I have been tuned in and I haven't seen
your statement of what you want and how you would judge the success of the
final proposal...)
Thanks
gregc
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>