Dave Pooser wrote:
We had a client whose RFP vanished into thin air because of that-- he sent it from a hotel that practiced port 25 hijacking and had had their IP blacklisted for spewing much spam and viruses. So our server rejected the message, and when it tried to send the NDN to him *his* server rejected the NDN for the same reason. Fortunately he called the next day with some details he'd omitted....
I recommended he go back with an army of Huns and raze the hotel, but he settled for a nasty letter and using 587/TLS in future.
You should have used the oppurtunity to educate your customer. Email is a best-effort, no receipt service. It is simply not appropriate to use for business-critical communication without some kind of confirmation of receipt. The hotel didn't really do the wrong thing. It took the email and made a best effort to deliver it. When it failed, it made a best effort to alert the sender. That is what email is supposed to be like. Obviously, they've had a spam problem. So just passing port 25 unmolested would not be right. Blocking it is not a very good solution either because people who are not sophisticated will just be unable to send mail. People who are sophisticated won't be using port 25 outbound from odd net locations anyway. You should blame whoever decided not to accept *any* email from the hotel just because *some* of the email was spam. That person knew or should have know that some of that email might be business critical. Hmm, that was *YOU*. Perhaps you are using a misguided spam filtering technique? How many RFPs are you willing to lose to reduce spam? DS