It is too bad if you or your user feels the message was legit but
reported as junk, spam or unwanted, whether directly or indirectly,
whether mistaken or not -- even messages that "need" to be delivered
might get you blocked.
PSA: You should authenticate bounces, feedback reports and even SMTP
rejects as inauthentic ones should be handled differently (often as an
attack that needs mitigation).
Can it be a challenge to get into a feedback loop, yes. For an ESP it
is usually easy or relatively so as long as the WHOIS, RWHOIS and RDAP
data for the IP address(es) name your service -- if the data isn't
correct get it fixed. If you can't get in a loop you'll usually want to
be far more aggressive about reject and bounce handling.
Whether you take action is up to you, of course, though an ESP almost
certainly will want to avoid delivery problems so that the majority of
their users can continue to enjoy their service.
Deciding whether to continue, delay, or desist means deciding what is
going on, things like whether the receiving ORG or MX seems to be having
a problem, vs the ORG/MX spurning your service or sender, vs a specific
recipient accidentally/mistakenly spurning a specific sender vs
intentionally, which is not trivial especially for an ESP due to scale
(they'll need software and databases and people to accomplish it).
As the MTA operator you most certainly should be able to prevent
messages from address A to address Z -- after all you are operating the
thing that says MAIL FROM and RCPT TO. As an ESP if your MTA doesn't
make that easy it is time to augment or switch, and if the one you use
can but isn't configured for such, well, reconfigure.
How an ESP handles all this is part of what differentiates each.
/mark
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
