Diego Sanchez <disa1710@???> (Do 13 Feb 2014 03:45:21 CET):
> Thank you Heike.
>
> The retry rules would only apply after the message is deferred by the
> recipient host, right?
Yes, after the first delivery attempt is deferred. If more messages
arrive for the domain in question, they're spooled, no delivery is
attempted until the retry time is reached, because it's a remote
transport.
(This is, what I understand from the specs.)
> But let's say I want send directly to queue all
> messages that exceed a certain limit per time frame.
> That is what I mean by throttling. This in intended to warm up fresh IPs.
The ACL action 'control = queue_only' could help to leave new arriving
messages in the queue. (But I think new messages are held in the queue
anyway, no delivery is attempted, until the retry time is reached.)
> I was thinking perhaps using transport_filter that passes the
> recipients domain to an external command. Documentation says that if
> the command returns a non zero code, then the message is queued.
> What do you think?
Hm, I'm not sure, if - before starting the transport filter - the remote
destination is contacted and the SMTP handshake is already done to some
extend.
A router could fail temporarly (not sure how, but I think there'll be
some way), or it could set a transport that fails temporarly, thus
preventing the transport to the destination.
But still I think it's better to rely on the deferral by the remote
side and than use the retry rules to prevent "overrunning" the other
side.
Does yahoo defer purely on the connection count, or based on the message
count?
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: 7CBF764A -
gnupg fingerprint: 9288 F17D BBF9 9625 5ABC 285C 26A9 687E 7CBF 764A -
(gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B)-
