Re: rejection w/o sender (or recipient) knowing == dropping
On 29.04.18 20:02, L A Walsh wrote: Stop thinking that silently rejecting an email isn't the same as dropping. I have never said anything about silent rejection. SMTP message "550 5.7.1 Spam Refused" is NOT a silent rejection - it is a VERBOSE rejection by (e.g. my) mail server, and sending (e.g. your) mailserver is supposed to construct DSN to the sender (e.g. you). If your mailserver does not construct the bounce or drops it, it is NOT my fault because my mail server has verbosely refused to take the message. It's even much more likely that this message will get to the sender than if my mail server accepted such mail and sent a bounce, because many bounces are spammy and many spam filters are likely to drop bounces, especially those received from remote servers. If this is what you are angry at, you are whining at wrong side, rejecting mail is correct, not sending or droping bounce is what's wrong and it happens on senders side. Matus UHLAR - fantomas wrote: 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. --- That's because I received a rejection. And it's the rejection equivalent to "550 5.7.1 Spam Refused", instead of bounce, which can be compared to another envelope with part of original mail stuck inside. Your rant is completely useless. --- Apparently you don't know what "rejecting" is, vs. silently dropping it into the trash. The latter is dropping. see above. What you are blaming us for, is the proper way to reject e-mail. If some dropping happens, it happens at different stage which outside of receiving server's scope. I will repeat that, if you send mail through your MSP, and the mail gets rejected by remote mail server, it's your MSP's job to properly notify you about the mail being rejected. If it does not, it's your MSP's fault. If your MSP delivered the mail to remote mailserver and the remote server would create a bounce, then it would be your MSP's job to deliver bounce to you. However, your MSP likely drops many of bounces sent to your addresses as result of mail forgeries, which you certainly don't want to receive, and the mentioned bounce may be dropped. If it is dropped, it's your MSP's "fault". I have even encountered complaints about mail sent via remote MSP's (not the one that would receive mail) and then not getting the bounce (because receiving MSP expectedly considered the bounce to be spammy). Simply said, if you want to receive a DSN, you must cooperate with your MSP and avoid sending mail through other MSPs to avoid useless bounces. Rejections are not the problem here. It's just the opposite: accepting mail and then sending a bounce is what causes the loss. And in both cases the loss happens on se3nding MSPs side. -- 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. Due to unexpected conditions Windows 2000 will be released in first quarter of year 1901
Re: rejection w/o sender (or recipient) knowing == dropping
On 2018-04-29 (21:02 MDT), L A Walsh wrote: > Until the past few years, email that was sent to me was either received by me > or the sender got a rejection message. Few? No, more like 20 years ago, when spam became a huge problem. If a message is spammy or contains dangerous attachments, it is discarded. The user targeted with the attack will never know. This is because this is what users WANT. Also, it is *my* mail server. My hardware. My bandwidth. I can do whatever I want with it. If users do not like what I am doing, they are free to get services elsewhere. I've had users "insist" that I allow MS Office files in attachments. I've informed them otherwise. > Apparently you don't know what "rejecting" is, vs. silently dropping it into > the trash. The latter is dropping. The former tells the sender there was a > problem delivering the email -- usually accompanied by the type of error. The VAST majority of senders are fraudulent. > In the former case, the sender knows something is refusing to deliver the > email and knows the sender didn't get it. In the latter case, the sender > "expects" that the user is likely to have received it (because there was no > message send back that there was a problem delivering it). If the message is discovered to be unwanted before it is delivered, the sender (the REAL sender) gets a notification the email wasn't accepted. If the message isn't discovered to be unwanted until after it is accepted, then discarding is the only possible action. > If the sender gets a rejected message, they can tell the listed-recipient > that the email was rejected and to please correct the problem. If they don't > get anything back, they won't even know what is wrong with the email should > they want to resend it. The world is an imperfect place. Emails fall out all the time. > To compound the issue, the recipient may not know their email is being > filtered since they asked for it NOT to be. I know of no mail service that will allow unfiltered mail. I mean, maybe they exist, but I seriously doubt it. *I* would never use one myself. -- And Super Heroes come to feast To taste the flesh not yet deceased And all I know is still the beast is feeding.
Re: rejection w/o sender (or recipient) knowing == dropping
Stop thinking that silently rejecting an email isn't the same as dropping. Matus UHLAR - fantomas wrote: 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. --- That's because I received a rejection. You are blaming us for how internet communication works for years. --- Until the past few years, email that was sent to me was either received by me or the sender got a rejection message. Your rant is completely useless. --- Apparently you don't know what "rejecting" is, vs. silently dropping it into the trash. The latter is dropping. The former tells the sender there was a problem delivering the email -- usually accompanied by the type of error. In the former case, the sender knows something is refusing to deliver the email and knows the sender didn't get it. In the latter case, the sender "expects" that the user is likely to have received it (because there was no message send back that there was a problem delivering it). If the sender gets a rejected message, they can tell the listed-recipient that the email was rejected and to please correct the problem. If they don't get anything back, they won't even know what is wrong with the email should they want to resend it. To compound the issue, the recipient may not know their email is being filtered since they asked for it NOT to be. That their own mail-provider is the one doing the dropping after that provider gave the impression that filtering was an option to be turned off/on in the user-control-panel, and that they had chosen "no filtering" is likely to be a bit miffed. Since the user knows the incoming email wasn't spam (after looking at the group archives), whether or not it was rejected or dropped is a bit moot at that point.
