Re: public key BATV isn't useful
2008-05-19 10:13:49
Paul Smith wrote:
Tony Hansen wrote:
Paul, The original idea behind BATV was so that 1) the original
sending MTA can protect itself such that 2) non-delivery reports for
messages originally sent from there can be differentiated from 3)
non-delivery reports that are being sent in response to messages *not*
originating from that sending MTA. That is, NDRs from your users (#2)
will come back using your BATV tagging, whereas NDRs from spammers
(#3) will come back without using your BATV tagging, and your system
(#1) can happily ignore the #3 NDRs.
Ah. I think I seem my problem... I looked at the BATV spec as a newcomer
to BATV rather than someone who had known about it for ages...
The BATV introduction is misleading. It doesn't mention anything about
the reasoning behind BATV that you state,
#2 and #3, above, are two types of bounce messages that are invalid, because
they result from unauthorized creation of the bounce address (MailFrom). The
Introduction says:
"existing Internet mail permits unauthorized use of addresses in the
MailFrom command, which results in having notices sent to unwitting and
unwilling recipients."
which seems to state exactly that condition, and:
"Bounce Address Tag Validation (BATV) defines a framework for mechanisms
that validate the value in this command."
says that BATV seeks to remedy that problem.
How should the Introduction be different?
and the introduction says
things like "This assessment could aid in deciding whether to *send* a
bounce message, thereby reducing the Internet mail infrastructure cost
for transmitting notification messages in response to addresses used
without permission." (emphasis mine) - thus implying that the thing
sending the bounce message (ie NOT your own server - that should already
know that the address was used legitimately) is the thing checking the
BATV tags. To do that, you MUST have public key BATV tagging, private
key tagging doesn't make sense.
Right. And since the sentence before the one you cite says:
"Enhancements would permit processing agents that are along the original
message's transfer path to determine whether the MailFrom adress is likely to
be valid.",
it is meant to be clear that this portion of the discussion is referring to
something beyond the current specification. So I'm not sure I understand your
concern.
This reaction to the reference to a public-key version of BATV once again
demonstrates the dangers of having a specification discuss anything about a
hypothetical future. Best we remove all such references. If and when there
is an effort to specify and deploy and enhancement such as a public key
version, we can document it separately.
So, I think the introduction needs to have something in it about the
rationale, reasoning and purpose behind BATV, as I obviously
misunderstood it, and even though I've now had my mistake explained to
me, I still can't see anything in the spec which explains it...
I do not understand what it should say that it does not already say. Please
offer suggested text.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: public key BATV isn't useful, (continued)
- Re: public key BATV isn't useful, Tony Hansen
- Re: public key BATV isn't useful, Paul Smith
- Re: public key BATV isn't useful,
Dave Crocker <=
- Re: public key BATV isn't useful, Paul Smith
- Re: public key BATV isn't useful, Paul Smith
- Re: public key BATV isn't useful, Douglas Otis
- Re: BATV pseudo-Last Call, Alessandro Vesely
- Re: BATV pseudo-Last Call, John Levine
- Re: BATV pseudo-Last Call, Frank Ellermann
- Re: BATV pseudo-Last Call, ned+ietf-smtp
- Re: BATV pseudo-Last Call, Dave Crocker
- Re: BATV pseudo-Last Call, ned+ietf-smtp
- Re: BATV pseudo-Last Call, Dave Crocker
|
|
|