On 6 Apr 99, at 10:39, Frank FitzMaurice wrote:

>
> You said that it uses a lot of resources since it sends a separate message
> for each recipient. I thought messages posted to the list doubled as
> probes so that those subscribers with good addresses would not see a
> "probe" message. Even if you did send a separate probe message for each
> recipient, why does this use up so many resources versus a regular posting
> to the list, is it the processing on the server?

The probes do look to the user exactly like a regular list posting.

However, pardon me while I launch into a mini-lesson on how SMTP
mail works, and how lists use it...

Each mail message sent using SMTP (i.e. most Internet mail) has what
is referred to as an SMTP "envelope" that looks like this:
MAIL FROM:<bounce-address>
RCPT TO:<recipient-address>
DATA
[mail message goes here]
.
^ Line with just a "." signals the end of the data stream.

The part between "DATA" and "." is the part of the message that the
recipient usually sees in the mail reader. It includes the standard
internet mail headers, such as the To: From: Date: Subject: etc. Even
the Received: headers that most mail clients hide by default. The MAIL
FROM and the RCPT TO are the important parts of the envelope. They
tell the SMTP server where to deliver the mail (RCPT TO) and where to
send the bounces (MAIL FROM) if for any reason the mail is
undeliverable. You can have as many RCPT TO lines as you want, so
that the exact same message is sent to all the recipients, and this is
how list mail is generally sent. This is why the To: has to be a generic
address (the list address), rather than the individual addressee's
address. There is only one MAIL FROM per envelope, so all bounces
will be directed to that one address. On LISTSERV list mail, this is the
owner-listname address.

Now what happens sometimes is that sometimes an email address is
forwarded to another email address along the way, and so the RCPT TO
line might get changed as the message travels to its destination. If it
bounces when it arrives, the mail server at the bouncing end only knows
about the forwarded address and says that this is the address that
bounced, and when it gets to LISTSERV, LISTSERV obviously doesn't
recognize that address as subscribed. Alternatively, there may not be
any forwarding going on, but perhaps the bouncing mailer is not using
the DSN-format for its bounces, so again, LISTSERV can't figure out
which address really is bouncing.

This is where the probes come in. When LISTSERV sends out a
passive probe, it sends a separate envelope for each probe recipient.
The mail message, including all the mail headers, is exactly the same
as the message sent to all the other list members. The difference is in
the envelope. The MAIL FROM on these probes is a "mangled" version
of the bounce address -- it is mangled in that it not only identifies the
LIST for which it is a bounce, but it also identifies the exact recipient for
this envelope. So that no matter how many times the mail is forwarded,
no matter how non-standard the bounce format used by the receiving
mail server is, when LISTSERV receives a bounce at that mangled
address, it knows exactly which subscriber of which list is the one that
bounced.

Now why is this more resource intensive? Because instead of sending
out one envelope, with one copy of the mail message plus 1000 RCPT
TO lines, you have to send 1000 envelopes each with its own copy of
the mail message and one RCPT TO line.

In the case of the non-probe message, if you have 500 AOL
subscribers, your mail server will pass on one envelope to AOL, with
one copy of the mail message and 500 recipients. If they are all probes,
then your mail server has to work harder, sending 500 seperate emails.

Now, let's say that 90% of email bounces use the DSN format and are
not for forwarded addresses. That means that 90% of your bounces are
going to be acted on, whether you use passive probes or not. The
purpose of the probes is to catch those remaining 10% of bounces
(actually only 9%, because some mail servers are so wildly in violation
of the Internet standards that they don't even bounce to the correct
address, in which case LISTSERV can't do anything about it).

So if you use probing on 100% of your list, 90% of that extra processing
you're putting it through is wasted because you would have gotten 90%
of the bounces even without the probing. If you're probing 10% of your
list each month, then some of those non-compliant bounces are going
to hang around your list for as long as 10 months, but there are so few
of those that the extra processing they require for those 10 months is
really not worth concerning yourself over.


> It appears to me that the number used in the header, Probe(#), corresponds
> in a way to a list with one posting daily. For example, you say that Probe
> (10) will check 10% of the list. The manual says that the number specifies
> the number of days between probes for a subscriber.

Yes, it's really "posting" days.

>
> Also, can you confirm that Passive Probing works the same as Active
> Probing once a bounce is received, i.e. from the manual: "LISTSERV first
> sends the PROBE2 template with a copy of the bounce, to show the user (if
> the account actually works in spite of the bounce) what garbage his mail
> system is sending people. LISTSERV then schedules a new probe for the next
> day, or deletes the user immediately, depending on the auto-delete policy.
> Every failure triggers a new daily probe until the user gets deleted or
> the problem gets fixed."

Yes, I'm pretty sure it does, with one exception. If your Auto-Delete is
set to Max(1),Delay(0) then it will not send any follow-up messages. It
deletes on the first bounce, with no warning.

Francoise