Conference iosg::all-in-1_v30

The most common way of this happening, I believe, is caused by the recipient 
being on the address list twice. This can easily happen with remote mail, and 
reply to All. Because of area routing, the same address can be formed 
diferently and so the message can be split and sent via different routes. have 
you checked the address list to see if this happens? 

Lots of other things to check - is the MRID the same? Are all the posted, 
sent,received dates the same? Any error messages in the fetcher logfile, 
OA$MTI_ERR? This does only happen on remote mail doesn't it?

(Er, and any others you can think of!)

grahame

When a mail message is delivered the delivery code checks to see if the filename
is already on the recipiants PENDING queue, if it is the message is not
delivered again.

If the distribution list for a mail is long enough and a user is on there twice
it is possible to get two deliveries with the right timing.

The first delivery will inform the user that there is new mail, if the user does
II immediately that empties the PENDING queue into the DOCDB and when the next
attempt to deliver to that user will not find the message in the PENDING queue
and hence it will be delivered again.

The same will apply if the user is addressed remotely and locally, the local
mail will be delivered first, if the entry is still in the PENDING queue when
the remote mail delivery is attempted it will not be delivered a second time,
however if the user has done an II or RN the remote delivery will deliver the
message a second time.

Could this be the cause?

Terry

    Certain errors in the processing, either when Sending if it's local or
    when Fetching if remote, will cause the message to be left on the
    appropriate queue and re-tried later. There's no way the sender or
    fetcher can tell how far through the addresee list it got last time
    (before the failure) so it does the whole list again. So addresses who
    received the mail the first time, before the failure, will get it
    again.
    
    Hence .1 suggesting that you looked at the error logs.
    
    I got the feeling from .0 that this started happening, happened for a
    while, and then stopped happening. True? If so, this would point to
    some error re-occuring (such as flaky disks), which got fixed.
    
    Dave.

Dave,

The second try by the Fetcher would only deliver again if the user had done 
an II or RN to move the first delivery out of the PENDING queue. Hence the
behaviour may appear inconsistant (i.e. delivering twice to some users and
once to others earlier in the dist list).

Terry

    Good point, Terry.
    
    Dave.

>The second try by the Fetcher would only deliver again if the user had done 
>an II or RN to move the first delivery out of the PENDING queue. Hence the
>behaviour may appear inconsistant (i.e. delivering twice to some users and
>once to others earlier in the dist list).
>
>Terry

Well, can I disagree with this one? If the Fetcher runs twice to deliver the 
same piece of mail, it WILL deliver it twice. This is because the key in 
PENDING is the shared-area filename, and the second run of the fetcher will 
create another file in the shared area (it restarts from the NBS files and 
creates all the ALL-IN-1 stuff again)

Just as well we haven't got any real work to do - we can spend all day with 
the ex-Mail developes trying to score points off each other! [Course, it's all 
in the cause of education isn't it]?!!

grahame

Graham,

You are right the fetcher generates a completely new message every time it 
tries to deliver.

I was thinking of local delivery via the sender (e.g. second class or deferred)
where the filename does not change and hence second delivery will only happen
if the first one has been removed from the user's pending queue.

If you have not got any work to do, I can think of a list of bugs you could 
fix for the first V3.0 patch, of course most of them will not be in your
part of the product but I am sure a man of you talents would be able to cope
with that. ;^}

Terry

    Terry,
    
    Graham left ALL-IN-1 Development before I did. I am sure he doesn't
    really want to go back (:==:)
    
    I am sure that he has more important work to do on the MR/GASH gateway
    than ALL-IN-1.
    
    regards,
    
    Andrew.D.Wicks
                             

Next time I will read the author field before assuming which Graham(e) wrote
the note.

I mistakenly assumed the note was from Graham Pye, not Grahame Ash.

My appologies to both of the fine gentlemen for mixing them up!

Terry

    GAP,
    
    You sure - the v3.0 sources indicate otherwise.
    
    Regards,
    
    Andrew.D.Wicks

    Well Winton rewrote most of my change afterwards to fix up all the
    loopholes I left, so I might as well have *not* been there...
    
    Graham

    There is a customer that has VMS V5.4-1A and ALL-IN-1 V2.4. The problem
    they have run into is the following:
    
    A user has sent a memo to a distribution list of 10 people. As of this
    time, 4-5 users have received 70 copies of this same memo! The mail was
    strictly local, so no routing was involved.
    
    Does anyone have any idea what is/did cause this? This is the first
    time this has happened.
    
    Cheryl

                        -< MEssage delivered 70 times >-

Can you get some more information to help track this down?

Are the messages absolutely identical? Do a EM SH on some of them - check the 
times, the addressee format, the MR-id

How often do they arrive? Regularly? (About the time the sender runs? Or could 
another process be doing it?

Are you SURE they're still local? 

Do any of the user have auto-forward set?

Any errors in OA$MTI_ERR or OAMTISEND.LOG?

and everything else of course!!

grahame

    Here is some follow up information...
    
    This has just occurred again (this afternoon) and this time it was
    delivered 73 times!
    
    Although most of the recipients were local, there were a few sent
    remote. All 73 memos have different VMS file names, but the MR id is
    the same for each one. There are no errors in OA$MTI_ERR or
    OAMTISEND.LOG. The sender runs continuously - batch job goes into wait
    state. They feel it 'might' be the fetcher, but not sure. 
    
    Cheryl

    
    	Can you post the list of recipients of one of these messages?
    	If your customer thinks this is too secret, you could edit
    	the names in the list to protect the innocent AS LONG AS YOU
    	ONLY CHANGE ALPHABETIC CHARS (leave all @ . " " alone so we
    	can see the address format).
    
    Regards,
    Paul