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