> We have run into a problem with a subscriber (the first of what I'm sure
> will turn out to be many) whose ISP has begun using challenge messages to
> verify a sender's address, thereby reducing spam. The program being used is
> very poorly designed; it sends the challenge messages to us, the list
> owners, directing us to a Web site where we can verify the list
> address--but it doesn't identify the address of the subscriber whose ISP is
> issuing the challenge. Nor does it identify the subscriber's ISP.
>
> Neither of us owners has done this yet, and we don't want to have to start
> doing it, because we soon could be responding to many challenges each day.
> (And how long will it be until spammers start sending fake challenge
> messages to get people to go to their Web site?)
>
> We have been corresponding with someone at turbonet.com, where the
> challenges are issued, and he tells us that we can easily fix the problem
> by changing our configuration so that the return path is the list address
> itself--the same address that the subscriber sends posts to (that way it
> would automatically be whitelisted). Since it reads owner-copyediting-l, he
> says, the challenge software won't whitelist copyediting-l.
>
> Can that be done? He tells me that he's done it to the lists that he
> manages.
>
> Is anyone else dealing with this problem?

Not yet and I will delete any subscriber that does use it.
LISTSERV conforms to all RFCs and all mail is compliant.
If some ISP creates problems with their customer receiving
their requested, compliant and legitimate email, it's all on
them, not me.

> If we aren't going to be told
> which address is creating the challenge, so that we can either delete the
> subscriber or tell him/her to take care of the problem on that end, then
> we're going to keep getting those challenge messages for every post that
> goes out from the list--and as far as I'm concerned, that's spam right
> there!
>
> Thanks for your input. (And I have a detailed response from the challenge
> guy if anyone would like to read it.)

LISTSERV of course uses a Sender:  address which is the list address, e.g.
[log in to unmask]

LISTSERV will send all list messages with the following MAIL FROM:
<[log in to unmask]>

This is so when any mail bounces back to this address, LISTSERV then knows
it's a bounce for this list. You can NOT configure LISTSERV to use an
alternate MAIL FROM:, nor would you want to for this very reason. Using a
different MAIL FROM:  than  From:  or Sender:  is perfectly legal and is
very widely used. This is something these developers never considered.
That's the problem with most developers, they never take all the RFC's and
compliant situations into consideration. This is about as brain dead as
rejecting mail with blank MAIL FROM:<>

At this point I assume the challenge message is being sent to the Sender:
(list) address and you are seeing it as the list moderator.

As I see this, you could do either of these two things:

1.)  Sender= NONE
This eliminates the Sender: field. So the challenge message would go to (I
assume) either:
        a.) The From: (original sender) which would be very confusing for
        them.
        b.) The Return-path. This would arrive as a bounce and handled by
        LISTSERV.

2.) Sender= owner-listname@hostname...
This would satisfy this software as I understand this. The problem lies
with this address being in this field in all the recipients mail. If they
replied to the Sender:  it would be received by LISTSERV and processed as
a bounce rather than a list message. I understand most mail clients will
(by default) reply to either the From:  or  Reply-To: (or both), but not
all.

Other problems are messages from LISTSERV@....
Some of these will have a blank  MAIL FROM:<>  (perfectly legal)
What happens to those?
Certainly any challenge message to LISTSERV@.... will never be responded
to.  What about a command sent to a new (not in their whitelist) LISTSERV
site, like the command:

INFO SOMELIST

It will be From: LISTSERV@....   but the Return-Path: will be:
owner-SOMELIST@......  There are many other situations where
this happens too. Not to mention the 100,000 sites world wide using
LISTSERV and other mailing list software which operated the same way.

I'm sure there are many other issues that will raise their ugly head. I see this
as another futile attempt to prevent spam that was not very well thought out.
Personally I don't want my ISP touching any of my mail for this very reason.

There are plenty of end user programs to handle spam, do it very well and
I always have my delete key.