On Sun, 1 Feb 2004, Pete Weiss wrote:

> The user has paid for the ISP to provide that service (whether they knew
> it or not).  Their failure to choose an ISP that enables them to take
> personal responsibility for subscribing does NOT constitute your
> agreement to have to jump thru hoops.  They turned the social compact
> between subscriber and list-owner on its head.
>
> I suggest that the subscriber read the archives via the WEB.

Thanks, Pete. The problem is that these challenge messages don't identify
the subscriber! They come from turbonet.com itself, and they tell us to
follow a link to confirm the address--and that we're refusing to do. We do
know who this particular subscriber is, but only because she
coincidentally posted to the list (during a discussion of spam) about this
new approach her ISP is using. We then contacted the network administrator
at turbonet to try to figure out how the subscriber herself can fix the
problem--but he says she can't; *we* have to respond to the challenge. If
we aren't going to respond through their Web link, and if this software
can't generate messages that identify the subscriber, widespread use could
create a nightmare for list owners--especially those of you who manage a
lot of lists. You can't delete the subscriber because you don't know who
it is, so your only option is to visit the Web site and accept the
challenge--or continue to get a challenge message for each list post.

When I asked why the challenge message doesn't include the address or
identity of the subscriber, the Turbonet's network admin's response was:
"That is a good point and I'll bring it up with the mail server's
developers. They listen.  I'm not sure I see a good solution.  For
example, the virus Novarg sends emails to people in the victim's address
book.  It would be easy to send fake challenges with addresses the
recipient recognizes."

He went on to say this:

"So, as I see it, if the list server managers would simply make the two
addresses the same, then the list owners would never see a challenge, the
list members would never see a challenge and it is in the hands of the
individual members and their ISP's to do the white listing.  Why delete
them from the list?  It would be a non-issue for the list managers.

When a mail or list server contacts another mail server it sends three
things to the receiving mail server:  the sender's email address, a list
of the recipients email addresses and the message.  The commands
corresponding to these are MAIL FROM, RCPT TO and DATA.  The mail server
does not pay any attention to the contents of the message (except for
virus checking and spam filtering).

With challenge-response, the receiveing mail server has a list of email
addresses authorized to send email to the recipient.  If a MAIL FROM
address is not on this list, the email is saved waiting authorization by a
successful response to the challenge.  The mail is typically kept seven
days and is deleted if not authorized during that time period.

You see the flaws.  If both the sender and the recipient use
challenge-response, challenges would never be successfully completed
because no one would ever receive the challenge.  I'm sent about 250 spams
a day because my email address is very public.  If I were notified each
time someone tried to send me an email, I'd end up having to look 250
spams a day instead of just deleting or ignoring them. It would be worse
than receiving the spam in the first place, so this is not an option with
challenge-response.

To alleviate these flaws to some degree, challenge-response usually has a
few additional features: (1) automatic authorization for email addresses
the subscriber sends an email to, (2) a way to upload the subscribers
address book so everyone in their address book is authorized, and (3) a
way to view the list of pending autorizations and manually authorize
senders.

Now, there are flaws here as well.  Normally nothing in the email message
itself comtains the address that was sent in the MAIL FROM command to the
mail server.  Address books use the From: header or the Reply-to: header
of an email when adding the sender of an email to an address book.  So if
the MAIL FROM address is different then the From: or Reply-to: addresses,
the sender will not be autorized by uploading the address book to the mail
server.

(Aside:  The RCPT TO and To: headers can also differ causing people to
think they received someone else's email.  And making them afraid someone
else is receiving their email.)

My suggestions for list server managers if they want to successfully work
with challenge-response and white lists:

(1) If you want replies sent to the list, make the MAIL FROM and the
Reply-to: header agree.  When the list member sends an email to the list
or uploads their address book, the list will automatically be authorized.
It also makes it easier for people to manually add the list's email
address to their white list.

(2) If you want the replies sent to the original sender, then you need to
make sure the address subscribers use to send to the list is the same as
the MAIL FROM address.  This will make it easier for the member to add the
list to their white list because they will have the address the mail
server needs to accept the list's messages.

You do not need to worry about the situation where the MAIL FROM, From:
and Rept-to: addresses all differ.  This is the case where you want the
recipients of the message to respond to the original sender.  If I respond
to such a message, then the original sender's address is automatically
added to my white list.  If the original sender is using
challenge-response, I will receive the challenge because they are already
on my white list.  I would then respond to the challenge because I want
them to receive the message I sent.

You do not need to worry about the list receiving challenges because the
MAIL FROM address on the challenge is not a member of the list and the
challenge will not be forwarded to list members."