On 14 Feb 2001, at 11:18, Charlie Brady wrote:
>
> On Wed, 14 Feb 2001, Dean Staff wrote:
> Re-interpreting To: lists more than once is very dangerous!! It should
> *only* be done at the sender's MTA.
I agree, and we were luck not to have had a problem until now. If
the message had delivered directly to the sendmail box, we would
never have known.
>
> You can avoid it, even using sendmail, by using the envelope address
> rather than parsing To:, Cc: etc. Configure sendmail to do per
> recipient delivery. But that's by the by.
I think I'm going to take that to our lead developer tomorrow.
Because we archive all mail messages received by these fax
servers I can pull out a copy of the message with the header intact
and show him what to look for.
>
> You have no control over whether you receive one copy of a message,
> with two recipients, or two copies, with one recipient each (*).
> That's entirely up to the sending MTA. You therefore have your problem
> whether you use e-smith or some other system.
That's originally what I thought. I actually figured that the senders
MTA sent the message once for each recipient, and that just
because they were both on the same server we processed it twice.
But that was not the case. Even so this has shown that this could
easily happen again if the senders MTA decided to send each copy
separately and we don't change the way we process the message.
>
> (*) Here's an analogy for you. Postcards inside envelopes. The
> postmaster at Yellowknife is given a postcard with two addressees. She
> can place the postcard in a single envelope, and send it to you,
> asking you to pass it on to both recipients. Or she can copy it,
> placing it in two envelopes, with instructions to you to pass each on
> to a single recipient. These two paths are equally valid. If you rip
> open the envelopes and discard them, then pass on each copy of the
> postcard to both recipients, then it is you who has created the
> problem.
I'm sure Canada Post would have something to say about this :-)
> >
> > Is this (the relaying) handled by the smtpfwdd daemon in 4.1? Or is
> > it part of the qmail package?
>
> Both smtpdfwdd and qmail relay the mail. smtpdfwdd to qmail, qmail to
> either local delivery, or relay, depending on recipient.
Now I understand.... Lord I'm thick
>
> > > The suppression is a P.I.T.A. IMO - if I send mail to an alias of
> > > which I am a member, I expect a copy in return.
> >
> > P.I.T.A ? echew obfuscation. (DNA)
>
> Pain in the nether regions, or something like that.
Something like certain users eh?
>
> > I did look at the header and did notice that for each message the
> > Delivered-To and Message ID were different. (this was on the message
> > received on the final destination sendmail box. The qmail router
> > only recieved the message once.
>
> If that was the case, then the message arrived without a Message ID.
> As mentioned earlier, it is perfectly valid for the qmail router to
> have received multiple copies of the message. The downstream sendmail
> will not/cannot coalesce the multiple copies.
I'm not sure , I don't keep copies of the messages as they arrive at
the qmail box, so I'll take your word on it.
I'll take all this to our developers, were gearing up for a new release
at then of March. It would be nice to have this issue listed as a fix.
Thanks for feed back guys.
Dean
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dean Staff Kanata On. Canada
[EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
