John Traweek wrote:
*snip*
u...@baddomain.com. During the initial receiving transaction Exim will
verify baddomain.com. If it doesn't exist it will 550 the transaction
and no NDR from my server. Great!
So my question is can it also verify the RCPT TO of the forwarding
address during the original transaction as well? This would issue a
transaction response back to the connecting MTA, thus preventing further
NDRs being generated?
Not pre- 'hand off', and not without (unpredictable) 'help' from the
far-end, no.
IF the target host itself does NOT do specific-recipient verification,
and many do not, NEITHER system will 'know' that a specific recipient is
invalid until after far-end DATA phase when it tries to deliver and cannot.
Not readily resolved, as the far-end in turn may ALSO be forwarding...
Not to mention quotas, temporary suspension, server milter or mailstore
glitches, etc.
That said, you should still see a major improvement in what Exim CAN do
w/r reducing NDR backscatter - just need a bit more work. See below.
If this is possible, what will happen with non permanent failures, such
as 400's, ie mail box full etc? Will those be issued back to the
originator during the transaction, so the responsibility is put back on
the originating MTA to retry the transmission?
TIA
As you are using a flexible DB, you can intercept and evaluate these,
then implement timed (full, over-quota) or permanent (no such user)
'banning' of problematic users based on substrings within the NDR's you
get back. 'At least' (part of) the numerical response code is standard,
so you'll want to pick those out - nothing else can be guaranteed.
MLM's generally have such features to either 'park' or unsubscribe
problematic recipients, so there is prior art around that can be
borrowed/adapted.
HTH,
Bill
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
