Martin Waschbuesch ha scritto:
My users are used to have a message delivered in a few seconds, despite of
destination.
If you really mean 'delivered' in the sentence above, then I am afraid your
users have, sort of, incorrect expectations. All anyone may reasonably expect
is that the mail server processes and attempts to send mail as quickly as
possible. It's not like anyone can control the availability of other people's
mail servers.
And you have to admit that, from what you describe, your qmail toaster does
process things quickly and delays are due to receiving MTAs?
It is well clear. Local processing is fast. Remote MTAs delay and tarpit
when they see a lot of connections.
Some huge local ISP apply this kind of delay. If they see a lot of
concurrent connections from the same sender IP, they stop receiving for
some minutes from that IP.
Sometimes this kind of "filter" is set directly on firewall, limiting
the rate of new connections.
From my point of view, as my "relay" server (for auth users only) is on
a dedicated IP, I feel right to put a FW limit on new connections on MX IP.
But when a "ligh" mailing list, or a message with 20 or 50 recipients, contains
a nice number of recipients for the same domain, delivery of some messages takes dozens
of minutes, because destination MX delay my servers.
With the change I ask, I'd have the same quality of service for small traffic.
For large deliveries, I'm thinking to a patch for changing qmail queue (sending
to a low priority mail queue), so I will not care of large mailing lists or
messages with hundreds of recipients.
If delivery of some messages takes dozens of minutes, the connection to that
host itself seems slow? Reducing the number of SMTP-connections surely would
save some bandwidth, but the bulk of the bandwidth should still be the message
content itself, so I would expect it to still be slow. Are you sure the
destination is not e.g. a tarpit or something? There might be other reasons for
the delays you see...
As I said before, remote MTAs reject too many connections.
Also note that, if you send one mail to 50 recipients, this will result in 50
individual items in the queue. As long as but one of these items is still
unsent, qmailctl queue will list all 50 items as still being in the queue but
will indicate with each item if said item has been sent. Once all items
belonging to the message have been sent, they'll all no longer be shown in the
queue. Is that the behavior you see when saying some messages need a long time
to send?
If I send to 50 recipients on the same remote domain, I will have 50
connections opened to the same remote server...
So, if remote server has limit on new connections, some deliveries will
abort and retry nextly.
Ciao,
Tonino
Martin
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
--
------------------------------------------------------------
in...@zioni Interazioni di Antonio Nati
http://www.interazioni.it to...@interazioni.it
------------------------------------------------------------
