Peter J. Holzer <hjp-ietf-smtp(_at_)hjp(_dot_)at> wrote:
I think most people these days use web interface to subscribe to
mailing-lists. People probably don't know their current BATV address, so
a user will enter 'john(_dot_)doe(_at_)example(_dot_)com' into the web form.
He will get
the confirmation mail to this address, click on the confirmation url,
and get all the mails delivered to this address.
Note that the opt-in confirmation presumably _will_ contain a BATV-
coded MailFrom.
So it appears to work fine. Until he actually tries to send mail to the
list - the mail comes from prv=53638f9=john(_dot_)doe(_at_)example(_dot_)com,
which
doesn't match the address he's subscribed with, so it will be rejected.
To tell truth, that's broken.
Requiring a MailFrom you've never seen isn't nearly as reasonable as
requiring a 2822-From you have seen.
Nonetheless, if we observe such behavior in the wild, we should at
the very least warn about it; and IMHO we should design in a workaround.
All of which goes to show why BATV is worth standardizing: it will
work more comfortably with some cooperation between senders and
receivers.
--
John Leslie <john(_at_)jlc(_dot_)net>