Re: public key BATV isn't useful
2008-05-20 01:39:58
Dave Crocker wrote:
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:
No. To me, that is still talking about people SENDING notices to
unwitting and unwilling recipients. Note that it says that the
unauthorised use results in notices being *SENT* to unwitting and
unwilling recipients. So, I read BATV as being a solution to prevent
these notices being *SENT*.
Nowhere does it say anything about BATV being checked by the *recipient*
MTA of the bounce messages.
"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.
Again, to me, that looks like it's a framework for use by the SENDER of
the notices.
As I said, I think my problem is that I'm looking at this as someone who
knows nothing about BATV, rather than someone who has known about it all
along.
How should the Introduction be different?
Just words along the lines of those that you used would help.
Eg, something like "BATV is intended primarily to be used by the MTA
receiving a bounce message to determine whether the bounce message is in
response to a message sent by an authorised sender for that domain. It
will allow the MTA receiving the bounce message to discard bounce
messages due to blowback/back-scatter from messages using forged return
path addresses"
Some examples of use would also be useful.
eg
"An MTA receiving a bounce message like:
MAIL FROM:<>
RCPT TO:<private-key-tagged-localpart(_at_)domain>
DATA
...bounce message...
could accept the message, where as an MTA receiving a bounce message like:
MAIL FROM:<>
RCPT TO:<untagged-localpart(_at_)domain>
DATA
...bounce message...
could decide to reject the bounce message as it doesn't appear to have
been in response to an authorised message sent from this domain"
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.
Because that's the ONLY thing in the introduction (AFAICS) which states
how BATV could be used... I did initially read it as 'this is something
for the future', but when I looked for 'something for now', I couldn't
find anything, so I assumed I'd misunderstood, and the above was
actually for now as well.
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.
It doesn't say ANYTHING about how BATV could/should be used in its
current state (AFAICS). See above for the sort of thing I think should
be there.
--
Paul Smith
VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows
<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
- Re: BATV pseudo-Last Call, John Levine
|
|
|