> That's fine, as it doesn't seem that the remote server is supposed to
> gain any benefit. It's the spoofed domain's MTAs which can gain the
but then why standardize the format? anybody can use "internal aliases"
of any form (aka disposable addresses).
Several reasons. First of all, while the primary purpose of IETF standards is
so that stuff can interoperate properly over the global Internet, a secondary
goal is so that different components built by different implementors can
interoperate within a particular administative domain.
It is quite common for large scale messaging setups to consist of components
built by multiple manufacturers. In fact it isn't uncommon to have setups
incorporating, say, different MTAs from different vendors. Deploying something
like BATV into such a setup requires that everyone be on the same page when
it comes to creating and processing these addresses.
Second, another reason standards exist is to tell people what sorts of
capabilities they may want to consider implementiing, and how to go about it.
Consider the discussion we've just had about including a timestamp in the
format: The potential issue with replay attacks clearly wasn't something some
people had considered. If everyone goes out and does this differently
there are bound to be cases where people get some of the details wrong.
This actually points out another omission from the current specification -
something Chris Newman caught immediately when I mentioned this draft to him
yesterday. There are likely to be cases within a domain where a client wants to
get his address "signed" with BATV but where you don't want to hand out the
shared secret (or private key for that matter) to the client. As such, a
missing component here is a on-wire way to ask some agent to form this signing
operation. The obvious place to have this is as an SMTP eubmit extension,
although of course other approaches are possible.