On Wed, Jan 26, 2000 at 11:33:17AM -0500, Kevin Lee wrote:
> At 09:47 AM 1/24/00 -0800, Mark Delany wrote:
> >Do your logs show that you are sending it twice?
> >
> >Note that duplicates are always possible with SMTP and there is nothing
> The logs do sometimes have an error that the connection died, and I guess
> it is impossible to determine if the message was delivered or not.
Quite so. Unless you have access to the mail logs at the receiving end.
> The think is, our subscribers (to BRIEFME.COM) don't care if the reason for
> the duplicates is their provider not having implemented a de-duping system,
> they blame us.
>
> Anyone who can help us solve this one is a real hero (and will be treated
> to a really nice dinner when they are in NYC).
Can't be done without a change to the SMTP protocol I'm afraid.
This is not a problem unique to qmail, it's a problem that every
implementation of SMTP suffers from.
It's possible that some characteristic of qmail-remote is exacerbating this
situation with briefme.com, but determining the exact reason and determining
ways to ameliorate this problem would require pretty extensive analysis of
the traffic and connections at each end. It may, eg, simply be that way that
qmail-remote closes the connection without waiting for the QUIT response.
I do note that briefme have a truly *interesting* DNS setup. I get different
results when querying that domain with dnscache and bind.
dnscache shows me:
briefme.com. 0S IN MX 10 mail.remove-it.com.
briefme.com. 0S IN MX 10 209.191.19.113.
bind shows me:
;; ANSWER SECTION:
briefme.com. 23h51m32s IN MX 10 remove-it.com.
erg.
There is more to this but it's probably more relevant to the tinydns list.
As an aside, are others complaining of dupes or largely this site?
Mark.
