[Top] [All Lists]

Re: public key BATV isn't useful

2008-05-19 07:43:40

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

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.