How to interpret the Delivered-To: header
How do you interpret the Delivered-To: header to determine what address a message was really sent to? Specifically, I want to figure out why the message below went to me (probably via a -default address) instead of being discarded by Ezmlm's bounce- handler. home0 is the user account which handles the surrogacy.org virtual domain. Then comes a myterious "0." which I don't understand. Any clues? -- Norbert. Note: in the following, '**CENSORED**' replaces the localpart of the subscriber email address, which consists of a reasonable number (between 4 and 8) of lower-case Ascii letters. --snip Received: (qmail 28924 invoked by uid 894); 11 Mar 2001 14:10:29 - Delivered-To: home0-0.pps-l-return-64-**CENSORED**[EMAIL PROTECTED] Received: (qmail 28921 invoked from network); 11 Mar 2001 14:10:29 - Received: from smv665-mc.mail.com (165.251.4.203) by tasc.surrogacy.org with SMTP; 11 Mar 2001 14:10:29 - Received: from localhost (localhost) by smv665-mc.mail.com (8.9.3/8.9.1SMV070400) with internal id UDK05175; Sun, 11 Mar 2001 04:10:27 -0500 (EST) Date: Sun, 11 Mar 2001 04:10:27 -0500 (EST) From: Mail Delivery Subsystem [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] To: pps-l-return-64-**CENSORED**[EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="UDK05175.984301827/smv665-mc.mail.com" Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) Thiss is a MIME-encapsulated message --UDK05175.984301827/smv665-mc.mail.com ** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ** The original message was received at Sat, 10 Mar 2001 12:07:23 -0500 (EST) from tasc.surrogacy.org [64.74.37.81] - The following addresses had transient non-fatal errors - **CENSORED**@techie.com - Transcript of session follows - **CENSORED**@techie.com... Deferred: Connection timed out with lmtp11.iname.ne Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old --snap
Re: How to interpret the Delivered-To: header
Norbert Bollow [EMAIL PROTECTED] wrote: How do you interpret the Delivered-To: header [...] [...] Note: in the following, '**CENSORED**' replaces the localpart of the subscriber email address, which consists of a reasonable number (between 4 and 8) of lower-case Ascii letters. Note that in the following answer, '**CENSORED**' replaces a random english word, phrase, or alphanumeric series of 1-78 characters. **CENSORED** **CENSORED** **CENSORED** **CENSORED** **CENSORED** **CENSORED** **CENSORED** If you want answers, don't hide the evidence that we may need to find them. You don't know the answer; that's why you're asking us -- so don't tell us what information we do and do not need to find your answer for you. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: How to interpret the Delivered-To: header
On Tue, Mar 13, 2001 at 08:46:19AM -0600, Charles Cazabon wrote: Norbert Bollow [EMAIL PROTECTED] wrote: How do you interpret the Delivered-To: header [...] [...] Note: in the following, '**CENSORED**' replaces the localpart of If you want answers, don't hide the evidence that we may need to find them. You don't know the answer; that's why you're asking us -- so don't tell us what information we do and do not need to find your answer for you. Indeed. I always find it amusing that people have a problem they cannot solve, yet they know precisely what information is needed to solve it. Funny people. Regards.
Re: How to interpret the Delivered-To: header
"Mark Delany" [EMAIL PROTECTED] wrote: On Tue, Mar 13, 2001 at 08:46:19AM -0600, Charles Cazabon wrote: Norbert Bollow [EMAIL PROTECTED] wrote: How do you interpret the Delivered-To: header [...] [...] Note: in the following, '**CENSORED**' replaces the localpart of If you want answers, don't hide the evidence that we may need to find them. You don't know the answer; that's why you're asking us -- so don't tell us what information we do and do not need to find your answer for you. Indeed. I always find it amusing that people have a problem they cannot solve, yet they know precisely what information is needed to solve it. Funny people. Well, there are very good reasons for avoiding to publicly post personal data about a subscriber to an infertility support group. Anyway, if no one can answer the question based on the information which I have shared (which is very likely all the relevant data) then I can read the qmail source and find the answer there. God bless you, Norbert -- Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69[EMAIL PROTECTED]
Re: How to interpret the Delivered-To: header
On Tue, Mar 13, 2001 at 05:14:48PM +0100, Norbert Bollow wrote: [snip] Anyway, if no one can answer the question based on the information which I have shared (which is very likely all the relevant data) then I can read the qmail source and find the answer there. It is not all the relevant data. Stop thinking *you* know what *we* need to solve *your* problem. Greetz, Peter.
Re: How to interpret the Delivered-To: header
Norbert Bollow [EMAIL PROTECTED] wrote: If you want answers, don't hide the evidence that we may need to find them. Well, there are very good reasons for avoiding to publicly post personal data about a subscriber to an infertility support group. If you cannot publicly post the information, without obscuring or hiding it, then you should hire a paid consultant (there are several listed at www.qmail.org) to find and fix your problem. If you want free help from a mailing list, expect to post real, unadulterated information. Anyway, if no one can answer the question based on the information which I have shared (which is very likely all the relevant data) then I can read the qmail source and find the answer there. Lots of people here can answer your question. They're just not going to even bother to try if you arbitrarily replace useful information with '**CENSORED**'. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: How to interpret the Delivered-To: header
+ Peter van Dijk [EMAIL PROTECTED]: | On Tue, Mar 13, 2001 at 05:14:48PM +0100, Norbert Bollow wrote: | [snip] | Anyway, if no one can answer the question based on the | information which I have shared (which is very likely all the | relevant data) then I can read the qmail source and find the | answer there. | | It is not all the relevant data. Stop thinking *you* know what *we* | need to solve *your* problem. Indeed. But I don't think we need the user name. The contents of control/virtualdomains file seems much more relevant, whether you have any stuff in users/assign that might have any bearing on the problem, relevant .qmail-* files, and ezmlm setup (though you might need to ask the ezmlm mailing list instead if the problem lies in that direction). - Harald
Re: How to interpret the Delivered-To: header
Well, there are very good reasons for avoiding to publicly post personal data about a subscriber to an infertility support group. Fine. If it needs to remain confidential, buy support from someone identified on www.qmail.org and have them sign an NDA. Problem solved. If you pay for support - they abide by your terms. If you want free support then we ask you to abide by our terms. That's not asking too much is it? Anyway, if no one can answer the question based on the information which I have shared (which is very likely all the relevant data) If you want to guess what we need then be my guest to guess away at your solution, just don't ask us to guess. Regards.
Re: How to interpret the Delivered-To: header
If that is the consensus of this list, I'll just go and read the qmail source and not bother to contribute by posting the answer. Is this what you want? -- Norbert. Norbert Bollow [EMAIL PROTECTED] wrote: If you want answers, don't hide the evidence that we may need to find them. Well, there are very good reasons for avoiding to publicly post personal data about a subscriber to an infertility support group. If you cannot publicly post the information, without obscuring or hiding it, then you should hire a paid consultant (there are several listed at www.qmail.org) to find and fix your problem. If you want free help from a mailing list, expect to post real, unadulterated information. Anyway, if no one can answer the question based on the information which I have shared (which is very likely all the relevant data) then I can read the qmail source and find the answer there. Lots of people here can answer your question. They're just not going to even bother to try if you arbitrarily replace useful information with '**CENSORED**'. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: How to interpret the Delivered-To: header
Harald Hanche-Olsen [EMAIL PROTECTED] wrote: Indeed. But I don't think we need the user name. The contents of control/virtualdomains file seems much more relevant, $ cat /var/qmail/control/virtualdomains bentwater-atlanta.com:bwater25 surrogacy.org:home0 surrogacy.com:home1 marketingspecifics.com:home2 salescenters.com:home2 whether you have any stuff in users/assign that might have any bearing on the problem, $ ls -la /var/qmail/users total 2 drwxr-xr-x 2 root qmail1024 Dec 11 11:59 . drwxr-xr-x 13 root qmail1024 Feb 5 07:43 .. relevant .qmail-* files, $ ls -al ~home0/.qmail-0* ls: /home/sites/home0/mail/.qmail-0*: No such file or directory $ cat ~home0/.qmail-default [EMAIL PROTECTED] $ ls -al ~home0/.qmail-pps-l-return* lrwxrwxrwx 1 home0root 36 Mar 13 03:50 /home/sites/home0/mail/.qmail-pps-l-return-default - /home/sites/home0/mail/pps-l/bouncer $ cat ~home0/pps-l/bouncer |/usr/local/bin/ezmlm/ezmlm-weed |/usr/local/bin/ezmlm/ezmlm-return -D '/home/sites/home0/mail/pps-l' and ezmlm setup What are the configuration files/options that you feel should be shared? Just to make sure that it doesn't get forgotten, the question was how to interpret the Delivered-To: header which was added by qmail, not ezmlm. As (admittedly, not quite conclusive) evidence for this claim I present the following grep, which was done in the source directory from which the ezmlm executable was built: $ grep -i 'delivered-to' *.c *.h ezmlm-get.c: if (!stralloc_copys(mydtline,"Delivered-To: responder for ")) die_nomem(); ezmlm-get.c: if (case_startb(line.s,line.len,"delivered-to:")) ezmlm-manage.c: if (!stralloc_copys(mydtline,"Delivered-To: responder for ")) die_nomem(); ezmlm-manage.c: if (case_startb(line.s,line.len,"delivered-to:")) ezmlm-reject.c: if (!stralloc_copys(mydtline,"Delivered-To: command forwarder for ")) ezmlm-request.c: "Delivered-To: request processor for ")) die_nomem(); ezmlm-send.c: if (!stralloc_copys(mydtline,"Delivered-To: mailing list ")) die_nomem(); ezmlm-split.c: qmail_puts(qq,dtline); /* delivered-to */ ezmlm-store.c: if (!stralloc_copys(mydtline,"Delivered-To: moderator for ")) die_nomem(); errtxt.h:#define ERR_LOOPING "this message is looping: it already has my Delivered-To line (#5.4.6)" The Delivered-To: line in question does not match any of the forms of the Delivered-To: headers that ezmlm (I'm using ezmlm-0.53/ezmlm-idx.040) would add. God bless you, Norbert -- Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69[EMAIL PROTECTED]
RE: How to interpret the Delivered-To: header
We can understand your reasoning for not posting sensitive information, however without such information it is VERY tough to decide what exactly is the problem. Too much so to cause people to continue trying to help. If you think that you have to mask your information perhaps you can send us some information that doesn't need to be edited so that we can look at it properly. There is no need to continue this thread unless you are going to post useful information. -Original Message- From: Norbert Bollow [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 13, 2001 12:13 PM To: [EMAIL PROTECTED] Subject: Re: How to interpret the Delivered-To: header If that is the consensus of this list, I'll just go and read the qmail source and not bother to contribute by posting the answer. Is this what you want? -- Norbert. Norbert Bollow [EMAIL PROTECTED] wrote: If you want answers, don't hide the evidence that we may need to find them. Well, there are very good reasons for avoiding to publicly post personal data about a subscriber to an infertility support group. If you cannot publicly post the information, without obscuring or hiding it, then you should hire a paid consultant (there are several listed at www.qmail.org) to find and fix your problem. If you want free help from a mailing list, expect to post real, unadulterated information. Anyway, if no one can answer the question based on the information which I have shared (which is very likely all the relevant data) then I can read the qmail source and find the answer there. Lots of people here can answer your question. They're just not going to even bother to try if you arbitrarily replace useful information with '**CENSORED**'. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: How to interpret the Delivered-To: header
+ Norbert Bollow [EMAIL PROTECTED]: | and ezmlm setup | | What are the configuration files/options that you feel should be | shared? Don't know, since I don't do ezmlm. But it seems very unlikely to be an ezmlm problem anyway. Your setup (which I won't repeat here, for brevity's sake) seems eminently reasonable, and I cannot find any evidence there that would point a finger at qmail. So let us return to the headers you quoted: | Received: (qmail 28924 invoked by uid 894); 11 Mar 2001 14:10:29 - | Delivered-To: home0-0.pps-l-return-64-**CENSORED**[EMAIL PROTECTED] | Received: (qmail 28921 invoked from network); 11 Mar 2001 14:10:29 - | Received: from smv665-mc.mail.com (165.251.4.203) | by tasc.surrogacy.org with SMTP; 11 Mar 2001 14:10:29 - | Received: from localhost (localhost) | by smv665-mc.mail.com (8.9.3/8.9.1SMV070400) with internal id UDK05175; | Sun, 11 Mar 2001 04:10:27 -0500 (EST) | Date: Sun, 11 Mar 2001 04:10:27 -0500 (EST) | From: Mail Delivery Subsystem [EMAIL PROTECTED] | Message-Id: [EMAIL PROTECTED] | To: pps-l-return-64-**CENSORED**[EMAIL PROTECTED] To me, that To: field whose address must surely have come from the envelope sender, at least shows that the message arrived at iname.net with the correct envelope sender. But I'm willing to bet a modest amount that iname.net mangled the envelope recipient of the bounce into 0.pps-l-return-64-**CENSORED**[EMAIL PROTECTED] with the results you have seen. At least, that theory is consistent with everything you have shown us. There it is, then: Not a qmail problem at all, but some external host perhaps having troubles coping with an unusal form of email address. Perhaps a sendmail.cf entry thrown off by the equals sign in there? If you still have your log files lying around, you might look for further evidence there, but I really don't think you can blame this on qmail or ezmlm at all. Oh, and concerning others' reactions to your hiding the user's identity: It's just a reflex action, flaming everybody to a crisp who does header mangling before asking questions. In 99.9% of all cases the flaming is fully justified, since the mangling really throws away useful information. But I think it's quite clear that this was not the case here. - Harald
Re: How to interpret the Delivered-To: header
To me, that To: field whose address must surely have come from the envelope sender, at least shows that the message arrived at iname.net with the correct envelope sender. But I'm willing to bet a modest amount that iname.net mangled the envelope recipient of the bounce into 0.pps-l-return-64-**CENSORED**[EMAIL PROTECTED] with the results you have seen. At least, that theory is consistent with everything you have shown us. There it is, then: Not a qmail problem at all, but some external host perhaps having troubles coping with an unusal form of email address. Perhaps a sendmail.cf entry thrown off by the equals sign in there? the explanation certainily rings true, I had mails every now and again to my iname account saying a message couldn't be deliveried by ezmlm and it hasnt happened since changing my email server for the qmail mailing list Neil _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: How to interpret the Delivered-To: header
Norbert Bollow writes: Specifically, I want to figure out why the message below went to me (probably via a -default address) instead of being discarded by Ezmlm's bounce- handler. Because mail.com is run by a bunch of weenies, who have somehow modified their SMTP server (which *was* running just fine until about 1Mar2001) so that it munges the envelope sender. I imagine that there's a sendmail rule somewhere named "destroy the envelope sender" that they turned on. Fortunately, you have to work much harder to get qmail to munge the envelope sender. Note: in the following, '**CENSORED**' replaces the localpart of the subscriber email address, which consists of a reasonable number (between 4 and 8) of lower-case Ascii letters. Don't do this. I know you have good reasons, but if you aren't willing to help us by providing full disclosure, don't come asking for help. Remember: you have a problem, and you don't know where it is. When you modify information that you think is unrelated to the problem, you might be wasting our time. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Watch out! He's got an 521 Pleasant Valley Rd. | +1 315 268 1925 voice | opinion, and he's not Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | afraid to share it!
