On 03/23/2016 08:35 PM, Aaron C. de Bruyn wrote: > 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. > i second this. in germany it's still a huge argument for sales people that no mail will be dropped. there must be a bounce, spam delivery or at least a notification about a stripped/purged malicious attachment.
of course there are things to handle like user quota etc., but if it's not possible/efficient for your system to check such things while connection is open, there are other ways like delivering the mail even if over quota. i know freemail provider that are doing it this way and just allow login for the customer but prevent him from sending mails before he did not cleanup his mailbox. btw in germany you would even run into legal issues if a customer could proof that an e-mail was accepted but neither delivered nor bounced. > >> 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 > -- BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
