Fwd: Message status notification
Folks, I'm having trouble tracing down a problem subscriber and I wanted to see if any list member could offer some tips. For the last several months every message sent to my list has generated the below. I've e-mailed postmaster@att.com and have not received any response. Short of removing all 30-40 list members in the att.com domain, is there any way to trace this below message back to a specific mailbox that can be removed? Thanks in advance, Irwin ----------------------
X-Persona: <mplsforum> X-POP3-Rcpt: mplsrc12@mplsrc.com Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id fBKJJLj27991 for mplsrc12@mplsrc.com; Thu, 20 Dec 2001 14:19:21 -0500 Date: Thu, 20 Dec 2001 14:19:21 -0500 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f X-From_: Thu Dec 20 14:19:19 2001 Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by host.secure4-hosting.net (8.10.2/8.10.2) with ESMTP id fBKJJJp27960 for <mpls-ops-request@mplsrc.com>; Thu, 20 Dec 2001 14:19:19 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fBKJJDn15282 for <mpls-ops-request@mplsrc.com>; Thu, 20 Dec 2001 14:19:13 -0500 (EST) Received: by attrh3i.attrh.att.com (5.5.029) id 3C069505004DF0E2 for mpls-ops-request@mplsrc.com; Thu, 20 Dec 2001 14:18:44 -0500 Message-Id: <200112201918.RBQ13665@attrh3i.attrh.att.com> Old-Date: Thu, Dec 20 2001 14:18:39 EST From: MAILER-DAEMON@attrh3i.attrh.att.com To: mpls-ops-request@mplsrc.com Subject: Message status notification X-Diagnostic: Mail coming from a daemon, ignored X-Diagnostic: Possible loopback problem X-Envelope-To: mpls-ops-request
The mail routing agent encountered the following class of error:
No entries found in directory for query
----- Original Message Text Follows -----
Received: from wsscan.att.com (135.71.63.10) by attrh3i.attrh.att.com (5.5.029) id 3C069505004DF0C9; Thu, 20 Dec 2001 14:18:37 -0500 Received: by wsscan.att.com; id OAA06742; Thu, 20 Dec 2001 14:18:55 -0500 (EST) Received: from almsi1.proxy.att.com(192.168.109.69) by cyrus0.wsscan.att.com via csmap (V4.1) id srcAAAisaOjn; Thu, 20 Dec 01 14:18:54 -0500 Received: from host.secure4-hosting.net ([209.239.41.31]) by almsi1.proxy.att.com (AT&T IPNS/MSI-3.0) with ESMTP id fBKJIwG10837; Thu, 20 Dec 2001 14:18:58 -0500 (EST) Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id fBKJIva27924; Thu, 20 Dec 2001 14:18:57 -0500 Resent-Date: Thu, 20 Dec 2001 14:18:57 -0500 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f
At 2:55 PM -0500 12/20/01, Irwin Lazar is rumored to have typed:
Short of removing all 30-40 list members in the att.com domain, is there any way to trace this below message back to a specific mailbox that can be removed?
Welcome to the need for...THE PROBE. Not a superhero, not a medical procedure, but a vital part of the listmaster's toolbox. I have no idea how many of us have written some routine or another to "probe" addresses when things go bad and mailers are brain-damaged, or more frequently in my case some subscriber sets up a four-way address relay that breaks somewhere in the middle without complete headers to track it back, or most recently some poor schmoe just got a wireless account and discovered the guy who had the number before had a forwarder set up to deliver a _digested_ list to it (with, of course, no available Received: headers). I usually allow the problem bounces to collect until I have a handfull of 'em before sending a probe, but some folks I know send one out every month whether they need one or not. I doubt the one I wrote would do you any good (I hacked it out in Frontier on a Macintosh), but there are, I think, prober software scripts freely available out there. Basically, you want to send mail to either a subset, or your entire distribution list, with seperate messages to each address coded in some way (I just place the address I'm sending to in the first line of the body; some sooper-sekret code, eh?) so you know when you get the bounce that is header-useless what address bit the big'un. There should be pre-written perl probers out there, at the very least, although it would be way cool to see something written in C for eventual distribution with the SmartList package (a temporary replacement for choplist that placed the line number of the address in the prome text, maybe? I dunno, I'm talking out of my hat here). In the example you gave, I'd send a probe to all of the att.com addresses first, since you have likely (but not necessarily definitively) narrowed the problem down to one of their addresses; if you find it, cool, if not, branch out and probe the rest of your list. (You can use the probe to give basic subscribe/unsubscribe information, too, or remind subscribers of posting rules, or anything else you might want to infrequently remind your subscribers about - this way, even on the 99.9% of good addresses, the probe still has some value.) Charlie
Charlie was explaining to Irwin, | Welcome to the need for...THE PROBE. Not a superhero, not a medical | procedure, ... nor a model of Ford. | Basically, you want to send mail to either a subset, or | your entire distribution list, with separate messages to each address | coded in some way (I just place the address I'm sending to in the first | line of the body; some sooper-sekret code, eh?) so you know when you get | the bounce that is header-useless what address bit the big'un. Putting the target address in the first line of the body works when the mystery bounces return the text (or at least the beginning of the text). Usually they will return some or all of the text, so that will do the job in most cases, but sometimes they don't. You have to look at the mystery bounces for something from the rejected message that comes back in it (and there are some seriously non-compliant mailers out there that won't tell you anything about the rejected message at all). Sometimes there is no body returned, but the subject of the rejected message its Message-Id: is there. You have to make sure that the target address is in a place that the bad mail transport will send back to you. What do you do when there's absolutely nothing? If your system allows suffixing addresses, you can send out each probe From:, Reply-To:, and From_ (if you can set envelope information) yourusername+codestring@your.site (or yourusername-codestring@your.site if the suffixing there is with hyphens instead of plus signs), and then you can tell which member is unreachable by which suffixed address receives the mystery bounce. Either use the member's address (with any @ sign changed to something else, like = or &) as the codestring or keep a table of each probed address and the string you've assigned to that member. (These are called VERPs, or variable envelope reply paths. ezMLM, for example, automatically uses something like listname-owner-user=dom.ain -- where user@dom.ain is the member getting that copy -- as the envelope sender of each recipient's copy of every post or digest.) If the other end returns absolutely nothing that you can include in the probe and if you set VERPs up either, try to gauge the timing on the bounces. If they come back very quickly, try probing one address per, say, half hour until the bounce happens. Finally, if that isn't possible either, draft a letter explaining to members that you're really sorry about this, but there's a bouncing problem on the list that can't be tracked down in any of the usual ways, and they're going to get a number of these probe messages. If they get them, that means that they aren't the problem, and they should just ignore them; there's no need to reply. Then ... 1. If there are a group of addresses you believe you can narrow it down to, send probe #1 to them; otherwise, send probe #1 to half the list. 2. If probe #1 generated a mystery bounce, eliminate everyone who wasn't sent #1; if #1 didn't bounce, eliminate everyone who was sent #1. Then send probe #2 to half the remaining people. 3. If #2 bounced, eliminate everyone who wasn't sent #2; if #2 didn't bounce, eliminate the people who were sent #2. Then send probe #3 to half the remaining people. And keep doing that until you're down to one person. I had a situation once where Prodigy was sending bounces with no information from the rejected message: no original address that it was for, no Received: headers, no subject, no text, just the invalid Prodigy address, which was not on the list rolls! Apparently someone was forwarding the list to that Prodigy account. I could tell from the frequency that it happened only to digests, not to individual posts; also, the list had a sublist that about 5% of members belonged to, and posts to the sublist (which was not available as a digest) didn't generate the mystery bounces. The only help was that Prodigy was respecting the envelope sender addresses and directing the bounces there. But I couldn't use VERPs on that system, so I had to use what few envelope sender addresses were available: my personal logname, the list's submission address (the list was moderated, so if a bounce came there, it wouldn't go out to the members as a post; besides, the bounces matched ^FROM_DAEMON, so SmartList would have caught them anyway), the -request address, and, well, let's just say I had four others at my disposal. So I took the 1220 digest-mode readers who were not on the sublist, divided them into seven groups of 174 or 175, and sent the seven versions of the first probe. When I saw the address to which the bounce was sent, I knew which of the seven groups the bad address was in, so I divided those 175 people into seven groups of twenty-five and sent the seven versions of the second probe. That narrowed it to twenty-five people, whom I divided into seven groups of three or four addresses each. The third probe pinpointed four people, and the fourth probe caught the perp. It was not fun, and three members in good standing had to be bugged all four times, but it got the job done. I was on a list where a worse thing happened. A disgruntled member deliberately set up forwarding only of list posts and not of those by the listowner to an invalid email-to-fax address that would bounce back to the poster instead of the listowner. The listowner kept insisting that he couldn't find a problem (it never happened on *his* posts, after all). Although the bounces came to individual authors, we knew they were for list posts because the fax gateway returned the subject line (but not the address that had forwarded the post to it). The listowner finally had to subscribe a dummy address, mark the list moderated so that any real posts coming in would not be affected, take half the members off the list temporarily, and send a probe *to*the*list* (after all, this was done out of malice and was not affecting mail directly to the malefactor's address), and see if it bounced. Then it was a matter of cutting the remaining suspects in half again and again until the jerk was caught (and putting the list back the way it was and sending out any posts that came in during the hunt). At least the bounces came fairly quickly, so it didn't take long.
At 10:54 PM -0500 12/20/01, David W. Tamkin is rumored to have typed:
You have to make sure that the target address is in a place that the bad mail transport will send back to you.
You are, of course, correct. Most of the time, the return will include either the header fields (I have our sendmail adding the X-Envelope-To: header field, which admittedly not all do) or the body, but sometimes there are those brain-damaged mailers like FirstClass that cause the problems posters to this list are seeing from exon.massart.edu - it's bouncing messages sent from the mailing list server not to the envelope sender, but to the From: header field (Yuck!), and isn't including _any_ of the message whatsoever; no header, no body, no nuthin'. Even though the address might be inferred from the non-standard bounce message it's returning (Yuck! again, and not a guarantee if there are aliases set up in the thing), since it's sending it to the wrong address in the first place there's nothing the Lists.RWTH-Aachen.DE machine can possibly do about auto-unsubscribing the address anyway. In this case the only solution seems to be a polite email to the SmartList listowner, and a...er...different kind of mail to the Massachusettes College of Art. To drag this message into a semblance of on-topic relevancy, it would be impossible for Smartlist to intepret the useless FirstClass 6.0 error message even if it _did_ come to a SmartList server (which it wouldn't, of course, except possibly in the case of a digest list), and so the listowner would need to manually unsubscribe the address anyway. But fortunately, that's a rare (albiet _really_ annoying) condition. Usually bounce messages contain either headers, or partial body, or both of the rejected messages, so there's usually something to track. Charlie (who's almost getting ticked off enough at massart.edu to start rejecting _all_ SMTP connections from 'em)
Oops. I wrote, | If the other end returns absolutely nothing that you can include in the | probe and if you set VERPs up either, try to gauge the timing on the | bounces. ^^^ Er, I meant (and should have typed), if you *can't* set VERPs up either. Sorry.
participants (3)
-
Charlie Summers
-
David W. Tamkin
-
Irwin Lazar