Re: public key BATV isn't useful

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.
The notion of a public-key component would extend the BATV notion one 
step further and allow receiving MTAs to validate the MAIL FROM address. 
To achieve that would require the same level of infrastructure as DKIM 
uses. Whether it would be worth taking BATV to that level is another 
discussion.
        Tony Hansen
        tony(_at_)att(_dot_)com

Paul Smith wrote:
> John Levine wrote:
> > > > Oh, and one final note. The document talks a bit about defining a
> > > > public key BATV scheme but doesn't actually define anything.
> > > >       
> > Humor me for a moment here.
> >
> > The idea of a public key BATV is so the system generating the bounce
> > can check the signature and not even send bogus bounces.  But any
> > system that is going to DKIM sign its bounce addresses would also be
> > able to DKIM sign its message bodies, so ADSP discardable already
> > allows you to declare that everything is signed so don't bounce the
> > unsigned stuff.  We're talking about DSNs here, not SMTP rejects, so
> > the system generating the bounce is going to have received the message
> > already.  This isn't a situation where you might skip the DATA in a
> > SMTP session.
> >
> > Can you think of any likely scenarios where you'd use a DKIM signed
> > bounce address but not a DKIM signed message?  Again, maybe I'm dense,
> > but I can only think of contrived mailing list examples where the
> > bounce address domain and the From: address domain are different and
> > don't have enough DKIM signatures to use ADSP.  But I'd think the
> > solution wouldn't be signed bounces, it'd be a body signature from the
> > bounce address domain, and an added ADSP keyword to say that you
> > always do that.
> >   
> Well, you could say that if the bounce address isn't valid, then 
> probably the whole message isn't, so just reject it before you start 
> receiving the data.
> However, I'm struggling a bit with the usefulness of BATV as well. I may 
> be missing something, so I'm quite happy to be told that :)
> For BATV to be useful, a domain would have to be able to say that all 
> messages from that domain must have BATV tags. I can't see anything in 
> the spec to cover that requirement. Otherwise a spammer will just send 
> messages without BATV tags, and BATV will achieve nothing other than 
> upsetting some legitimate mailing lists...
> I'm not entirely sure I understand the point of 'private tagging', and 
> since 'public tagging' seems to be documented in an airy-fairy way, I 
> can't see the benefit of that either.
> If public tagging was more tightly specified, and there was some way of 
> saying that a domain must use BATV (possibly piggybacking on DKIM and 
> DKIM policies), then I could see a small point to this, but even then 
> the lack of replay protection seems like it could be a significant 
> weakness for spam protection.