V. T. Mueller wrote:
In fact, I'm quite p****d about folks using greylisting in a way that
SMTP callbacks are rendered useless: we reject mail temporarily
since the callback is deferred by greylisting at the sending site.
What makes you think that your FUSSP-attempt is any better than theirs?
I'm not really a friend of greylisting (if used in a one-size-fits-all
manner, where simply everything is delayed), but if someone does
anything unusual in his MTA he should be prepared to get strange results.
Due to a[nother] broken setup there, their enduser doesn't get
informed about the non-delivery. No second delivery is attempted from
the remote site.
That sounds _very_ broken, though. I don't see why you should bother
yourself fixing that. And it has nothing to do with your callbacks,
temporary errors happen of many other reasons too.
My question now is: is there a way I can make exim
overcome this situation? Maybe delaying the incoming SMTP in order to
shoot off a second callback attempt after a while, hoping that
bl**dy greylisting became satisfied in the meantime?
What's the usual minimum greylisting-delay, something like 5 minutes? I
think that's a little long to keep the connection open and the sending
MTA may drop it meanwhile.
You could add defer_ok to your callout acl statement, delay in the next
one if the callout failed and make a new callout statement (if the
previous one failed, of course). You have to find out how to check that
the callout was rejected with a temporary error.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
