On Wed, Mar 23, 2016 at 10:16 AM, Michael Peddemors <mich...@linuxmagic.com> wrote:
> On 16-03-18 11:28 AM, Rodgers, Anthony (DTMB) wrote: > >> Dropping Email has been acceptable ever since unwanted email has occurred. >> > I suppose it's your server, do what you want. If I was your customer, I'd be pissed that you silently trash messages without notifying the sender/receiver. > There are obvious cases where this is the only option. Technically, the > ONLY case where email can be rejected, is during the MUA->MTA or MTA->MTA > connection. Once that connection has been severed, there is no guaranteed > way that any form of notifying the sender will work, as the 'sender' > address cannot be guaranteed to be valid, or accept any form of > non-delivery. > Easy enough--make the decision while the connection is active. Or, once the connection is closed I personally believe your only option is to deliver it to the inbox or spam folder. If you do virus scanning out-of-band, trash the message and send a report to the inbox or spam folder in place of the infected message. Or just strip the attachment. > What if you are in jurisdiction where delivering emails of a specific > content is illegal? > Delete the message and deliver a 'notice' in its place. "A message from b...@foo.bar was deleted because it contained <swear words|porn|a virus|etc>" should be sufficient. > > What if the recipient has indicated that he wants it dropped, rather than > be delivered? > That's entirely a different matter. If I (as the end user) delete a message it's my decision. If I decide to create a mail rule to delete messages with certain strings, it's still my decision. If something 'important' was deleted on accident, I still only have myself to blame. Contrast this with the issue I was complaining about with Microsoft properties. Company A was e-mailing users of Microsoft's service. I'm guessing those users didn't decide that all mail from Company A's IP address should be silently dropped--especially since they are paying customers of Company A. They get invoices from Company A. They regularly communicate with Company A. That's the problem. If Company A's mail server simply started getting "550 You are blocked because of SPAM" and maybe a URL for a way to easily resolve the issue, I don't think anyone would be upset or annoyed. Honestly, my first response to anyone having delivery problems to Microsoft is usually "Microsoft is probably down again. Check again in a few hours. Maybe tomorrow." ( http://blogs.technet.com/b/exchange/archive/2004/04/08/109626.aspx) After 4 hours I might start investigating. With other providers, I get a 550 GO AWAY message almost immediately and can respond to that right away. You can't respond to "Is it a delay in delivery, a service outage, or magical e-mail deletion?" right away. -A
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
