<[EMAIL PROTECTED]> writes: > Just so you know I wasnt blaiming anyone, Im just confused.
I didn't think you were blaming anyone. I just wasn't convinced of their analysis. > I'm realizing that unless your a mad genious who has RFC memorized > many of the people in the qmail channel of efnet just ignore you. Same on the qmail list, sadly. > So I return here were everyone was at least friendly for > more assistance. IT IS GREATLY APPRICIATED. Thanks. I hope we're a little better than some of the "help" you'll find out there. > I have not changed my logging back to the prefered qmail method yet > as I figured Id maintain consistancey till I find a resolution to > this problem, they were changed when I followed the directions for > getting vpopmai + courier-imap + roaming users working and I never > changed the run files. This is not a problem. Either syslog or multilog are fine. Syslog is just known to be slower and have a few minor problems. > Bellow I have included all the information you asked for. Thanks. It's really frustrating when everything looks correct :) Below, I want to clarify a couple of things I said, in case someone tries to ding me over this. > > In fact, it does return a success status, or qmail would log the > > error in its own logfile. It turns out that 99 is also considered by qmail to be success and qmail will log 'success' in its logfile. It won't process any more lines in the .qmail file, though. So if TMDA were to return 99 to qmail, you might see the problem you're seeing. However, I don't believe TMDA is doing that. TMDA has two places where it delivers mail. One is where the mail matches something in your incoming filter. If there is a filter match and the action is 'ok', 'accept' or 'deliver', TMDA immediately exits with a 0 return. There are no header changes and the mail is not resent. qmail should continue processing the next line(s) in the .qmail file, thus delivering the mail. The second place is where TMDA actually placed the mail in pending and sent back a confirmation request because the mail didn't match anything in your filter. After you reply to the confirmation request, TMDA takes the message in pending, changes all Delivered-To fields to Old-Delivered-To, adds an X-TMDA-Confirm-Done field and an X-TMDA-Confirmed field and resends that message, as if it were brand new, coming from outside. This is the one time (at confirmation) that TMDA mucks with header fields. But qmail doesn't care about any of those header fields and no MTA should. qmail adds a new Delivered-To field, which allows certain programs that you might run from .qmail to process the message correctly and goes through the whole .qmail processing again. When that new message comes in, TMDA recognizes the X-TMDA-Confirm-Done field, renames the file in pending to indicate that is has been successfully confirmed and again, exits 0. Here's your example of that: Date: Wed Jan 29 10:24:30 GMT 2003 From: "Bryan McWhirt" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subj: Re: Please confirm your message Actn: CONFIRM accept 1043835836.56969.msg (2249) Date: Wed Jan 29 10:24:30 GMT 2003 From: "Bryan McWhirt" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subj: Re: Please confirm your message Actn: CONFIRM_APPEND /var/vpopmail/domains/techropolis.com/tmda/lists/whitelist(2249) Date: Wed Jan 29 10:24:32 GMT 2003 From: "Bryan McWhirt" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subj: testing Actn: OK good_confirm_done_cookie (1044) The first entry says you confirmed correctly, the second entry says you ([EMAIL PROTECTED]) were added to your whitelist and the third entry says that, when the new message came back through, the cryptographic stuff in the X-TMDA-Confirm-Done field was correct. Immediately after printing that last log entry, TMDA exits 0. > > The next thing that happens is that qmail processes the ./Maildir/ line. > > It does so by copying the original message from its queue into the > > maildir. Nothing that TMDA changed in the header could affect that, > > since qmail is using the original mail and not the copy it > > passed to TMDA. Here, I was thinking about the normal case, where something in your filter matches, rather than the much less common confirmation case. I'm left with the suspicion that something is wrong with your .qmail-tmda file. Here's what you posted before. | preline /var/vpopmail/tmda-0.68/bin/tmda-filter -c /var/vpopmail/domains/techropolis.com/.tmdarc-tmda /var/vpopmail/domains/techropolis.com/tmda/Maildir/ I need you show me where the line breaks are. If this is all on one line (in other words, when you 'cat' it, it just wraps like this | preline /var/vpopmail/tmda-0.68/bin/tmda-filter -c |/var/vpopmail/domains/techropolis.com/.tmdarc-tmda |/var/vpopmail/domains/techropolis.com/tmda/Maildir/ then that's your problem. If it looks something like this | preline /var/vpopmail/tmda-0.68/bin/tmda-filter -c |/var/vpopmail/domains/techropolis.com/.tmdarc-tmda /var/vpopmail/domains/techropolis.com/tmda/Maildir/ then we need to keep looking. Note how the wrapping occurs. If you are not sure, just run 'wc -l .qmail-tmda' and, if the number that comes up isn't 2, you have a problem. Tim _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
