Re: dropping other's email(s) as a "best practice" for hosted email?
On Fri, 27 Apr 2018, L A Walsh wrote: Alan Hodgson wrote: Rejecting the message during receipt causes the sending server to generate a bounce. If it's at all functional. That used to happen on poorly implemented mailing lists -- a delivery error would be bounced back to the email list as a reply that would get sent out to all the subscribers. *used* to happen. Such mis-coding should have been fixed a long time ago, and if there's ML software that still does that it is *not* the receiving MTA's problem or fault. On a list with 10,000 subscribers or more with maybe ~1000 messages/day, how many people would be getting back mail-delivery failures that they could do nothing about. These days, none should. The ML software should have mechanisms to capture those delivery problem reports and disable that subscriber, and/or notify them that list messages are failing (though notifying them isn't guaranteed if there are problems delivering to them...). If a given user wants emails to be dropped at the border I echo the request that you stop misusing the term "dropped" when you mean "rejected". -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Teach a man to fish, and he'll eat for life. Give him someone else's fish, and he'll vote for you. --- 4 days until May Day - Remember 110 million people murdered by Communism
Re: dropping other's email(s) as a "best practice" for hosted email?
Alan Hodgson wrote: Rejecting the message during receipt causes the sending server to generate a bounce. If it's at all functional. On 27.04.18 09:32, L A Walsh wrote: If a given user wants emails to be dropped at the border -- that would be fine. *I* would not mind configuring a filter that dropped some incoming emails, but if it is going to make the incoming mail server too slow to handle per-user options, it might not be doable. once more: STOP calling rejection a dropping. Rejecting is NOT dropping. They are two different things. If you try to hand me an envelope, and I will refuse to take it, It is NOT the same as if I took it and dropped to trash. The envelope stays in your hands and you are responsible for it. If you drop it later, it's your problem, not mine. You are blaming us for how internet communication works for years. Your rant is completely useless. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 2B|!2B, that's a question!
Re: dropping other's email(s) as a "best practice" for hosted email?
Alan Hodgson wrote: Rejecting the message during receipt causes the sending server to generate a bounce. If it's at all functional. That used to happen on poorly implemented mailing lists -- a delivery error would be bounced back to the email list as a reply that would get sent out to all the subscribers. Would it even be practical to bounce a deliver failures back to the original poster of the message to the list? On a list with 10,000 subscribers or more with maybe ~1000 messages/day, how many people would be getting back mail-delivery failures that they could do nothing about. Many or most hosted email services provide a user-controllable spam filter. The problem is, if an email is not accepted, rather than being delivered and filtered by the "per user-filtering", the user can not tailor such filters to their own mail. It preempts the oft needed ability for the user to judge what is spam and what is not. I am not suggesting sending a "bounce back message", but have the default be to do what the user configures via their account options. If a given user wants emails to be dropped at the border -- that would be fine. *I* would not mind configuring a filter that dropped some incoming emails, but if it is going to make the incoming mail server too slow to handle per-user options, it might not be doable. Even without per-user options, many servers that try to do filtering between reading the message and sending a response end up having periods of unacceptable response time. NTL, running filters over incoming email when the user has explicitly ask for unfiltered email is reprehensible. I do my own email filtering on my home server. I find ISP's doing their own filtering and modification of incoming user messages based on their criteria to be a very bad situation. Also, someone mentioned safe-harbor provisions. Those were designed for websites where material is hosted for public view on the host's computers. The wording in the US act applies to those who *publish information by others* (like a website). It doesn't apply to pass-through services like ISP's and email services. Email and ISP service has been more held in line with services provided by the phone company -- that of common carrier status that is predicated upon NOT inspecting content as it travels through a carrier's equipment. That said, different countries will have different laws, and the laws are changing as email-provider demonstrate their ability to monitor and filter real-time communications. Some countries are moving to have email providers be responsible for filtering or allowing discussion of illegal acts. That's not a good direction to be going, IMO.
Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")
On Fri, 27 Apr 2018, Matus UHLAR - fantomas wrote:
On 26.04.18 13:41, L A Walsh wrote:
To my way of thinking, dropping someone else's email,
telling the sender the email is being rejected for having
spam-like characteristics and telling the recipient nothing
seems like it might have legal liability for the for the
user potentially missing vital email.
Refusing to take a mail is not dropping. Noone is required by any means to
accept anything because there may be many reasons a mail can't be accepted.
The place where dropping is a risk is if the next-to-last hop is Dain Bramaged
and doesn't handle SMTP rejects properly.
But that isn't your server's fault, it's the poor service the sender's using.
(unfortunately the sender may not know of that bad link in their chain).
Also it's entirely possible that the NtLH server may strip off useful
info from the SMTP reject message and leave the poor sender wondering what went
wrong. (I'm looking at you MS Exchange).
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")
On Thu, 26 Apr 2018 13:41:05 -0700 L A Walsh wrote: > To my way of thinking, dropping someone else's email, > telling the sender the email is being rejected for having > spam-like characteristics and telling the recipient nothing > seems like it might have legal liability for the for the > user potentially missing vital email. It all depends on the contract between the service provider and the customer. If the service provider puts something in to the effect that it will make best-effort attempts to deliver mail but is not responsible for lost mail, then I doubt there's any legal liability. For example, Google's Terms of Service say the following (in all-caps) Other than as expressly set out in these terms or additional terms, neither Google nor its suppliers or distributors make any specific promises about the services. For example, we don’t make any commitments about the content within the services, the specific functions of the services, or their reliability, availability, or ability to meet your needs. We provide the services “as is”. Some jurisdictions provide for certain warranties, like the implied warranty of merchantability, fitness for a particular purpose and non-infringement. To the extent permitted by law, we exclude all warranties. They also have a limitation of liability clause that limits their liability to the amount paid to use the services. Regards, Dianne.
Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")
On 2018-04-26 (14:41 MDT), L A Walsh wrote: > > To my way of thinking, dropping someone else's email, telling the sender the > email is being rejected for having spam-like characteristics and telling the > recipient nothing seems like it might have legal liability for the for the > user potentially missing vital email. I agree that once the mail has been ACCEPTED the recent has to either receive the mail or know why the mail isn't there. For example, most spammy mail is delivered to a users Junk box, where they have a week to check it for mistagged mail, but after a certain threshold, users know that the email will be discarded (scoring over 10 in my case). However, this is very rare because most mail that is that spammy is rejected at the SMTP phase. > It also would seem to violate what used to be a basic expectation of internet > email -- that it is either delivered to the recipient's inbox OR you'll > receive a non-delivery notification (a "bounce"). Or you will receive a rejection immediately. Thin about it this way, if you send an email to da...@example.com and there is no such account because you intended to send it to d...@example.com you do not get an NDN, you get a rejection. -- I want a party where all the women wear new dresses and all the men drink beer. -- Jason Gaes
Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")
On 26.04.18 13:41, L A Walsh wrote: To my way of thinking, dropping someone else's email, telling the sender the email is being rejected for having spam-like characteristics and telling the recipient nothing seems like it might have legal liability for the for the user potentially missing vital email. Refusing to take a mail is not dropping. Noone is required by any means to accept anything because there may be many reasons a mail can't be accepted. For example, mail server that it out of disk space cannot accept a mail thus the only possibility is to refuse accepting it. Dropping mail is the case where mailserver accepts mail and does not deliver it, nor send a bounce. It also would seem to violate what used to be a basic expectation of internet email -- that it is either delivered to the recipient's inbox OR you'll receive a non-delivery notification (a "bounce"). I have no idea where did you get this expectation - your assumption is false. Nearly (if not completely) all mailservers tend to refuse accept mail even from the client, if: - the mail is over allowed size - the sending address is invalid, undeliverable or forged - the mail contains virus, phish, malware or otherwise dangerous content especially in the case the sending address is invalid or undeliverable, it is impossible impossible to send bounce to the sending address. When the address is forged, those bounces would go to a innocent victim. There are many reasons why mailserver (even your submission server) could refuse message. If your submission server accepts a message, it of course SHOULD send a bounce when the recipient's server refuses it (exemptions named above) Note that in this case the recipients server refuses to handle a message, and instead of bouncing, sending the bounce is up to your submission server. I hope some of those who think it was a good practice to delete a user's email (because they think it is malware) might rethink that practice. I hope you now understand what is the difference between deleting and refusing a mail and won't blame us for way how mail system works (and always worked), just because you have misunderstood (or assumed) it. I didn't realize email was no longer considered unreliable afaik e-mail was NEVER considered reliable, mostly because of reasons mentioned above. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "The box said 'Requires Windows 95 or better', so I bought a Macintosh".
Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")
On 26 Apr 2018, at 16:41 (-0400), L A Walsh wrote: To my way of thinking, dropping someone else's email, telling the sender the email is being rejected for having spam-like characteristics and telling the recipient nothing seems like it might have legal liability for the for the user potentially missing vital email. Not so much, at least not in the US, Canada, or the EU. There are safe harbor provisions in the relevant laws (e.g. COPPA and CAN-SPAM in the US) protecting service providers from liability for errors in their good faith efforts at filtering out harmful material. Beyond that, email end users typically have a business relationship only with their immediate service provider to whom they first submit a message, NOT with any intermediaries between their provider and the ultimate recipient end-user. Internet email is a loose store-and-forward system. A message's transport path usually has 3 transactions involved (but often more) with usually exactly 1 of those being governed by no specific law or any contract between the parties involved. At that interface, only courtesy and pragmatic interoperability concerns govern, and it provides a wall between the parties accountable to the sender and those accountable to the recipient. NO party involved in normal cross-provider email transport has obligations to both end users. It also would seem to violate what used to be a basic expectation of internet email -- that it is either delivered to the recipient's inbox OR you'll receive a non-delivery notification (a "bounce"). How is being told using a standard mechanism during initial submission that the mail is rejected by a spam filter not the operational equivalent of a bounce message? That is precisely the mechanism that would cause an intermediary MTA to construct and send a non-delivery notification message. It has ALWAYS been true for the entire existence of SMTP (and of its relatively new "Message Submission" subset) that the server side of a SMTP transaction can reject the transaction at any step and that the client side has the only duty to notify anyone and that it should ONLY notify the sender, NOT the recipient. Furthermore, for me, about 20-25% of the email lists I used to be on have policies to drop subscribers w/o notice if an email cannot be delivered. [ examples of how various entities do good, bad, or no notification elided... ] I hope some of those who think it was a good practice to delete a user's email (because they think it is malware) might rethink that practice. There is a huge difference between deleting stored delivered mail and refusing to accept deliver mail. I didn't realize email was no longer considered unreliable primarily due to spam scanning. For the entire history of the Internet, cross-domain email has been an intrinsically unreliable means of communication. Whoever made you think otherwise deceived you. I wonder if that will happen for USPS letters: getting permanently dropped due to the envelop having SPAM-like characteristics (like most bulk mail). USPS is a government entity with special privileges and duties defined in law and/or by regulations promulgated to implement the governing law. They handle every step of delivery from sender to recipient and are prepaid by every sender to perform end-to-end delivery. In most of the Internet-heavy world, no email provider has any of those supporting features of reliability, even within their own home nations. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")
On Thu, 2018-04-26 at 13:41 -0700, L A Walsh wrote: > To my way of thinking, dropping someone else's email, > telling the sender the email is being rejected for having > spam-like characteristics and telling the recipient nothing > seems like it might have legal liability for the for the > user potentially missing vital email. > > It also would seem to violate what used to be a basic > expectation of internet email -- that it is either delivered > to the recipient's inbox OR you'll receive a > non-delivery notification (a "bounce"). Rejecting the message during receipt causes the sending server to generate a bounce. If it's at all functional.
