>> We update kernels, reload AV signatures, have databases go down, 
>> accidentally crash postfix during OS upgrades, typo config files, etc. 

Couldn't you make so if the inner servers are in trouble or go down or similar, 
then the perimeter server will buffer the email for you without a temporary 
reject?
Because, what I understand from your description, you have inner postfix 
servers, and when these crash due to OS upgrades, they will stop responding on 
port 25. Thus the outer perimeter servers return a 4xx code to tell any 
would-be mailers that your inner servers has a problem.

By buffering the email in the perimeter servers yourself, you avoid the whole 
problem. And for the short time your inner servers have a problem, the outer 
servers should have plenty of space to buffer.

When it comes to spam and virus filtering, you could skip spam filtering for 
"buffered" email, ergo email that was received during outage. And just apply 
virus filtering.
For virus filtering, you ARE allowed to silently delete email according to RFC, 
and what I know, also for those countries that prohibit silently deleting 
emails for "spam":

"Conversely, if a message is rejected because it is found to contain
   hostile content (a decision that is outside the scope of an SMTP
   server as defined in this document), rejection ("bounce") messages
   SHOULD NOT be sent unless the receiving site is confident that those
   messages will be usefully delivered.  The preference and default in
   these cases is to avoid sending non-delivery messages when the
   incoming message is determined to contain hostile content."


Note that with "hostile content" they obviously mean virus attacks, exploits 
and such, not phishing or spam that isn't hostile per se, but more a nuisance.

This should create a nice situation for both your customers that don't lose 
tickets because SendGrid refuses to retry on 4xx, and for you so you can 
upgrade kernels, reload AV signatures, database maintenance, OS upgrades and 
change configs without problems.

_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Reply via email to