> This appears to be a specially built MTA, and with the (probable) > consent of its users, has policy in place to not resend after 4xx under > specific conditions. I.e. the sending MTA is interpreting specific 4xx > responses (and more likely the text) to mean a permanent failure. > > I do not see a problem with elevating a 4xx to mean 5xx where the users > of the system understand the policy as it does not appear to impact the > receiving system. In fact one could take section 4.5.4.1 of RFC5321 to > opening the door for just that; "[...] however, more sophisticated and > variable strategies will be beneficial when the SMTP client can > determine the reason for non-delivery."
Agree. Also, I think it's unreasonable to assume that people will never try new things when it comes to bounce processing or MTA queue management. RFCs could never evolve if folks were prohibited from ever trying anything different than what's written in the RFCs today. Many large sending email platforms have had unique MTA handling rules in place for years. And there are a lot of reasons smart platforms HAVE to, going all the way back to (pulls note out of greybeard, checks) stuff like Cisco PIX firewalls causing email bombing -- not a 4xx/5xx handling issue, but an example of how going back for 20+ years, weird shit has sometimes happened that required workarounds. Those workarounds are not always based on a sender's intent to get away with something. Often the intent is to do better, be better-- not to be sneaky. -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
