Peter J. Holzer <[EMAIL PROTECTED]> 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 '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED], 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 <[EMAIL PROTECTED]>
