I think it's a numbers problem. If you handle a high enough volume of mail, if you sometimes drop mail, and sometimes have false positives that you drop... you will eventually reach a volume of dropped false positives that will have visible affects.
Ie, if you reach a point of dropping 100k or 1M good messages, you're going to have a bad time. And, dropping mail that the user tells you to drop is fine, obviously. Brandon 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: > >> “…delete it without delivering it to the intended recipient’s INBOX or >> Junk folder with no NDR…” >> >> When did dropping mail on the floor become acceptable? Or am I just >> grumpy? >> >> Nobody wants backscatter, but that’s what SMTP-time DSNs are for, no? >> > > Dropping Email has been acceptable ever since unwanted email has occurred. > > 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. > > Once the email handler takes ownership, of course it can set any standards > on what it wants to deliver. For instance, if it believes the message is > spam, and the recipient has requested that 'all' email be forwarded to a > remote account, forwarding that email could make it appear that the > forwarder is the source of spam. > > Should you deliver malicious or harmful vectors to a person's email box? > (Eg, a Virus laden attachment?) > > What if you are in jurisdiction where delivering emails of a specific > content is illegal? > > What if the recipient has indicated that he wants it dropped, rather than > be delivered? > > There are many reasons why rejection action cannot always happen at > 'SMTP-time', however yes that should be the first line of defence. > > And especially in very high volume environments, not all delivery logic is > possible during SMTP (well, anything is possible), especially in mixed use > environments, where the logic needed to determine file routing/filtering > may take longer than is acceptable for an SMTP conversation. > > > > -- > "Catch the Magic of Linux..." > ------------------------------------------------------------------------ > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > ------------------------------------------------------------------------ > A Wizard IT Company - For More Info http://www.wizard.ca > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > ------------------------------------------------------------------------ > 604-682-0300 Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and intended > solely for the use of the individual or entity to which they are addressed. > Please note that any views or opinions presented in this email are solely > those of the author and are not intended to represent those of the company. > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
