Juan Miscaro schrieb:
James Robertson wrote:
>>
Maybe router or firewall based traffic shaping would help - at least you
could prevent SMTP from hogging all the bandwidth.
That's an interesting option. How would Postfix react to saturated
bandwidth? Will it simply defer messages and try again?
We use a setting like this at one of our clients:
iptables -I OUTPUT -d \! "192.168.1.0/24" -p tcp --dport 25 -j DROP
iptables -I OUTPUT -d \! "192.168.1.0/24" -p tcp --dport 25 -m limit
--limit 240/sec -j ACCEPT
iptables -I OUTPUT -d "127.0.0.1/24" -p tcp --dport 25 -j ACCEPT
(Rules are "in reverse order" since they are inserted.)
This allows traffic to the smtp on localhost (127.0.0.1) and the local
network (192.168.1.0/24) with no limits and restricts smtp traffic to
other destinations to 240 packets per second.
Since one packet is roughly 1500 bytes, SMTP traffic has a maximum of
about 3.6 MBit/sec. We use this setting on a 4MBit/sec DSL line.
It is transparent to postfix whether your uplink is slow or if you drop
packets with iptables: the tcp layer will throttle the connections and
retransmit packets as appropriate.
As has been said, you should configure postfix to a "sane" number of
parallel deliveries. And you should also make sure that there is enough
space on the queue partition when the client starts their mailing ;-)
-hannes
