Mark Delany wrote:
>
> On Wed, Dec 06, 2000 at 10:41:28PM -0600, Ken Jones wrote:
> > Mark Delany wrote:
> > >
> > > On Thu, Dec 07, 2000 at 11:15:45AM +0800, Wayne Chu wrote:
> > > > Am Mittwoch, 6. Dezember 2000 22:04 schrieb Thomas Duterme:
> > > > > > How about increasing your concurrencyremote to something
> > > > > > like 100? you most likely are hitting your limits.
> > > > >
> > > > > Good point. Will try that tonight. I've gotten some
> > > > > problems before from ISP's blocking us
> > > > > when I went up to 240...I'm not quite sure what the highest
> > > > > polite limit on this should be.
> > > >
> > > > My newsletter program calls qmail-qmqpc directly.
> > > > Does qmail send mails to recpt in the order I write the address
> > > > to qmail-qmqpc?
> > >
> > > It surely does. But that's ultimately just a queuing order and it
> > > doesn't necessarily mean a delivery order.
> >
> > Delivery order depends on DNS servicing smtp servicing and the
> > exact code you are using to inject emails into qmail-pmpqc.
>
> Right. But all things being equal, their will be a very strong
> correlation between the injection order and the delivery order. DNS
> lookups may certainly perturb this, but don't fundamentally change it
> in anyway.
Okay. All things being equal. I can understand that. Would you please
explain what you mean "all things being equal". How do we relate an
unprecise english phrase to email delivery?
Unless you post exact information about your exact case with exact
log information..
Perhaps we should all bow down and worhship the mystical order
of the "blah blah".
My meaning is.. Unless you post your exact information, you are just
posing a hypothetical situation. If you want answers to your
"hypothetical"
situation, that's fine. But I expect you have a defined goal in mind.
And I expect any hypothetical answer will not solve your particular
problem.
If you wish for me to attempt to solve your problem. I'm willing
to devote my limited resources. However, you have not posted
your dns information, nor your email delivery information.
Shall we attempt to devine your intensions from you unclear
descriptions?
>
> > > As it happens, yes. I don't believe that it is gauranteed in any
> > > documentation, therefore relying on this current behaviour may be
> > > risky.
> >
> > Your delivery order depends on your remote concurrency limitations,
> > the availablity of dns results and your disk IO.
>
> No, yes, no. Concurrency does not change order. DNS results may
> perturb order, disk IO is unlikely to change order. In other words,
> there remains a strong correlation. Your point is?
DNS order of service information completely depends on the DNS
service you are relying on. Do you attempt to decieve us and
say that all DNS services act the same?
Please provide exact information about the dns results you
are receiveing so that others may attempt to duplicate your
results.
>
> > Why are you so concerned about delivery order?
> >
> > What is your ultimate goal?
>
> I think the original poster made that clear. He wants to minimize the
> concurrency to any one domain by sorting the recipients in such a way
> that the recipient domains are distributed across the whole list.
So, you wish to minimize the concurrency on your machine, or do you
wish to minimize the delivery speed. I suspect the original poster
is attempting to minimize the delivery to the recipient.
Can you please post delivery speed information for multiple
reciepients to a singular domain versus alternative mail
delivery agents?
Or are you just another poser?
>
> > Why is delivery order such a concern?
>
> How is this a different question from "Why are you so concerned" etc.
Because, unless you have been living in a cave, all of us email
admins have to deal with people who are concerned about "email
throughput". And most of those people are illegal spammers who
are hard to take to court.
Why did you evade my question?
If you are a real person with a non-illegal concern,
please post your company information, email address
dns host name, company phone number, corporate officers
names to this list.
I'm sure you won't.
>
> > So.. You sit back.. and launch your spam list on the internet,
> > and you wonder why.. when it gets to the yahoo.com list...
> > it stalls with 255 remote deliveries, and they all take a long
> > time to complete. And you are upset because you can't get your
> > spam list delivered?
> >
> > Just what kind of email are you delivering?
>
> Ken. You're assuming a spammer here - if you're wrong what do you
> think you're achieving apart from besmerching his name?
Prove me wrong sir.
>
> In any event, if you've worked with large lists and large delivery
> capabilities, you'll know that many sites *do* block based on
> concurrency. Why only a month or so ago I was working with a company
> that does 20+million deliveries on a busy day and they were blocked by
> hotmail based on exceeding concurrent connection limits. It took quite
> an amount of work to have hotmail remove their automated block (phone
> calls, ceo to ceo, blah blah blah) - but they did so in the end,
> solely because they were ultimately convinced of the opt-in nature of
> the email.
>
> These problems do happen regularly in real life with legitimate
> lists. Perhaps the original poster has suffered the same problem?
Sir. You ask questions that spammers ask. And then you confront
me with the qustion, "are you a spammer". What should I think.
"i'm not a crook".
Perhaps you need to prove that your mass mailings are valid.
Or perhaps you should prove that you have a valid large email
base. However, you have not shown any information abour your
user base.
So, "these problems occure in real life". Isn't it strange
that more than 90% of these problems occur with sites that
are mailing to large lists of unsoliceted email addresses.
Sir..
What is your company name?
Ken Jones
