Noel J. Bergman wrote:
With the default thread count of 1, one or more outbound emails to
a non-well-behaved target mail server (e.g. outblaze...) can cause
thousands of undelivered outbound emails to build up for days in
the spool waiting for that one thread trying to send a couple of emails.
It should not be the case that one thread backs up for days to send a couple
of e-mails. Even with a 10 minute time out and many IP addresses. So that
needs to be checked, having nothing to do with interpretation of the proper
implementation of the RFC.
If we want to be sure this does not happen we MUST limit the number of
attempts on temporary errors.
Now we check all of the multihomed IP for every MX server. We don't put
any limit on this. If I create a domain with 20 "IN MX" servers having
each one 20 "IN A" ips. In the worst scenario where the connect works 1
second before timing out and then the smtp server never send the 220
welcome message James will need 20*20*(connectionTimeout+timeout)
milliseconds to make a single attempt. (with 1 minute and 10 minute they
are 4400 minutes for a single attempt. This means a thread is busy for 3
days for a single attempt.. 3*15 = 45... one month and half for a thread
to give up sending that mail).
If you consider that James does not have fastfail I can easily "DOS"
your RemoteDelivery. I just need to setup a fake smtp server that accept
connections after 50 seconds and then do nothing else and a lot of MX
and IP in my trap-domain configuration and send to your domain a mail
from <[EMAIL PROTECTED]> to <[EMAIL PROTECTED]> ... This will
result in a bounce mail created, and this bounce will keep a single
remote delivery thread busy for 3 days at a time, for a total of 45
days... you understand that it's not a big issue for me to send you 10
mails like that.
This is just to add more "worst case scenario" to James.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
