Re: [Exim] Double Messages

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Marilyn Davis
Fecha:  
A: exim-users
Cc: MLN Administrators, clint.davis
Asunto: Re: [Exim] Double Messages
Thank you so much again, Philip.

So a test message to my test email list (3 members) with log_arguments
turned on gives:

2000-03-27 14:37:54 4 args: /usr/sbin/sendmail -bs -odb -oem
2000-03-27 14:37:54 12Zi8w-00031a-00 <= marilyn@??? U=marilyn P=local-esmtp S=431 id=Pine.LNX.4.10.10003271437450.672-100000@???
2000-03-27 14:37:57 4 args: /usr/lib/sendmail -oi -fowner-test@??? test-outgoing
2000-03-27 14:37:57 12Zi8z-00031i-00 <= owner-test@??? U=majordom P=local S=560 id=Pine.LNX.4.10.10003271437450.672-100000@???
2000-03-27 14:37:57 12Zi8z-00031i-00 => marilyn <test-outgoing@???> D=localuser T=local_delivery
2000-03-27 14:38:05 12Zi8z-00031i-00 => sue.buckler@??? <test-outgoing@???> R=lookuphost T=remote_smtp H=mail.multiboard.com [216.38.24.1]
2000-03-27 14:38:10 12Zi8z-00031i-00 => jjjacq@??? <test-outgoing@???> R=lookuphost T=remote_smtp H=mx.ozemail.com.au [203.2.192.101]
2000-03-27 14:38:10 12Zi8z-00031i-00 Completed
2000-03-27 14:38:10 12Zi8w-00031a-00 => |/usr/local/majordomo/wrapper eVote_script resend -l test -f owner-test@??? -h deliberate.com test-outgoing <test@???> D=system_aliases T=address_pipe
2000-03-27 14:38:10 12Zi8w-00031a-00 Completed

---

Is it significant that the log entries for each of the sends to list
members comes before the log entry for the send and "Completed" of the
message going into majordomo? This is the one that goes to majordomo:

2000-03-27 14:38:10 12Zi8w-00031a-00 => |/usr/local/majordomo/wrapper eVote_script resend -l test -f owner-test@??? -h deliberate.com test-outgoing <test@???> D=system_aliases T=address_pipe

"resend" is the majordomo program. "eVote_script" redirects stderr and
feeds the message into "eVote_insert" which passes it along with a
fork and exec in the C code.

Shall I try:

receiver_verify_hosts = !deliberate.com : *

in the main part of my configure file?

I'm very grateful for your help.

Marilyn Davis, Ph.D.
eVote - online polling software for email lists
http://www.deliberate.com 
marilyn@???    
+1 650 965-7121  (USA)







On Mon, 27 Mar 2000, Philip Hazel wrote:

> On Mon, 27 Mar 2000, Marilyn Davis wrote:
>
> > Well, I can tell you what happened to me recently. We use MMDF here,
> > which certainly colors the picture a little. What was happening here
> > was that MMDF was verifying the validity of the whole mailing list
> > before returning from the Submit call.
>
> Exim will not do that, if you are just passing over the name of a list
> that Exim is going to expand. All it will check is the list name. (And
> indeed, it will only do that if Majordomo is submitting using SMTP.) But
> if Majordomo is submitting a large number of addresses, then each one
> gets verified as it is given in the SMTP dialogue (if receiver_verify is
> set).
>
> You could try turning on log_arguments for a short while to determine
> with what arguments Exim is being called by MD - i.e. if it *is* using
> SMTP or not.
>
> > The thing calling the Submit
> > would time out and close, but the Submit itself would still be running
>
> I can see how that might happen if MD works in a certain way, but I
> don't know how MD actually works.
>
> > The solution for us was MMDF-specific. We used a different channel
> > for submission and delivery, one which deliberately doesn't verify the
> > addresses before accepting a job.
>
> If MajorDomo *is* using SMTP submission for large lists of addresses,
> then you can make use of receiver_verify_hosts to except your own host
> from this verification.
>
> > There have been many reports from Linux users complaining about
> > duplicate mail. The problem seems to be that flock() under Linux is
> > broken.
>
> Exim does not use flock(). It uses fcntl() for locking (which is
> compatible with lockf(), not flock()).
>
> -- 
> Philip Hazel            University of Cambridge Computing Service,
> ph10@???      Cambridge, England. Phone: +44 1223 334714.

>
>