You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by L A Walsh <sa...@tlinx.org> on 2018/04/26 20:41:05 UTC
dropping other's email(s) as a "best practice" for hosted email?
(was: "anyone recognize these headers? ...")
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").
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.
Some, ~10-15% will drop your email address from all lists hosted on
the server.
Some ~20-25% will send out some sort of probe or notification
of missed messages, many claiming you need to respond to
a notice:
Your membership in the mailing list XXX has been disabled
due to excessive bounces The last bounce received from you was
dated 01-Jan-2017. You will not get any more messages from this
list until you re-enable your membership. You will receive
3 more reminders like this before your membership in the list is
deleted.
Some simply inform you of missed messages. Only "ezmlm" gave
some clue allowing me to track what was happening w/a
message like:
Subject: failure notice
Hi. This is qmail. [not able to deliver. Permanent error.]
<sa...@my-domain.org> failed.
Remote host said:
550 5.7.1 This message has been blocked for containing
SPAM-like characteristics.
Some were notifications of a response to a message I
posted in a forum -- an automated form, but certainly not
spam or malware. None of the ones I was able to find
copies of (went to a list-archive), were spam or malware.
The most troublesome are those lists who auto-drop you for
a bounced message (like the linux-kernel mailing list
and other high-volume lists).
Ironically (or maliciously), anytime I've brought a problem
like this to a MSP's support staff, I'm inevitably asked for
a copy of the email or its headers. I can't provide what
never reached me. Then they'll respond that they can't
do anything without a copy of the rejected email (as though
they only work with user emails that were outgoing or
something).
If it is a 'MSP', I'd hope they'd act more responsibly
with emails.
Of note: in my case, I was often told that I could diable
filtering in my account options (it was disabled & had never
been enabled). All of the front-line support
people I've talked to have had no idea that email was also
being filtered on the incoming server, so of course they
had a problem wrapping their head around what was happening
and even though I've been told more than once that filtering
was turned off for my account -- it eventually continues.
Another reason I have asked about this is that if the email
is in an alternate encoding, they decode it to check it and
place the decoded version in my mail stream. Unfortunately
they don't do it right with the result that problems occur
on my email client (T-bird) with the improperly decoded
email (since I don't have the original, I can't tell exactly
why it is bad).
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 didn't realize email was no longer considered unreliable
primarily due to spam scanning. I wonder if that will
happen for USPS letters: getting permanently dropped due
to the envelop having SPAM-like characteristics (like
most bulk mail).
Thanks for the hints on the headers...
-linda
Re: dropping other's email(s) as a "best practice" for hosted email?
(was: "anyone recognize these headers? ...")
Posted by Bill Cole <sa...@billmail.scconsult.com>.
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
bill@scconsult.com or billcole@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? ...")
Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-04-26 (14:41 MDT), L A Walsh <sa...@tlinx.org> 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 davee@example.com and there is no such account because you intended to send it to dave@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? ...")
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Thu, 26 Apr 2018 13:41:05 -0700
L A Walsh <sa...@tlinx.org> 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 mail
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 27 Apr 2018 15:18:28 -0500 (CDT)
David B Funk <db...@engineering.uiowa.edu> wrote:
> If you have that many different classes of recipients, just set the
> number of allowed recipients/transaction to one and be done with it.
That will cause mail failures. It's not *supposed* to, but I know
from experience it will. Some MTAs limit the number of retries to a
ridiculously low number like 10 or 20 and then give up.
Regards,
Dianne.
Re: Dropping mail
Posted by Pedro David Marco <pe...@yahoo.com>.
>> Define two classes of recipients:
>> class A == all users who want everything
>> class B == all users who want "standard" filtering
Be aware of Class A users... once they click on where they should not, then as if by magic it was your fault and the s--t hits the fun... (of course when the fun point towards you)
---------PedroD
Re: Dropping mail
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Fri, 27 Apr 2018, Dianne Skoll wrote:
> On Fri, 27 Apr 2018 14:39:43 -0500 (CDT)
> David B Funk <db...@engineering.uiowa.edu> wrote:
>
> [snip]
>
>> Define two classes of recipients:
>> class A == all users who want everything
>> class B == all users who want "standard" filtering
>
> This works if you have a limited number of classes, but in some cases
> users can make their own rules and settings so the number of classes
> can be the same as the number of RCPTs.
>
> Even in the two-class case, there's still a delay for the subsequent
> class(es).
If you have that many different classes of recipients, just set the number of
allowed recipients/transaction to one and be done with it.
The delay is entirely up to the sending side, they could immediately retry the
subsequent recipients.
I was just trying to suggest a solution to your conundrum that didn't require
you to drop messages. I didn't say it was optimal, just avoiding the loss of
messages.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Dropping mail
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On April 29, 2018 11:11:18 PM EDT, Linda Walsh <sa...@tlinx.org> wrote:
> Except users who have their own rules are not likely
>doing it in the context of the initial choice of whether or
>not to accept the email onto the server.
They do in our system.
> I.e. it "should" never be the case that user-defined
>filters are run in the MTA's initial receive context as the MTA
>just received (or is in process of receiving) an email coming
>in on a privileged port (like port 25) which would imply a
>privileged context (most likely root).
No; see the milter API and library.
> Delays are not the same as dropped email.
I have seen sending MTAs give up after an absurdly small number of retries.
Regards,
Dianne.
Re: Dropping mail
Posted by Linda Walsh <sa...@tlinx.org>.
Dianne Skoll wrote:
> On Fri, 27 Apr 2018 14:39:43 -0500 (CDT)
> David B Funk <db...@engineering.uiowa.edu> wrote:
>
> [snip]
>
>> Define two classes of recipients:
>> class A == all users who want everything
>> class B == all users who want "standard" filtering
>
> This works if you have a limited number of classes, but in some cases
> users can make their own rules and settings so the number of classes
> can be the same as the number of RCPTs.
---
Except users who have their own rules are not likely
doing it in the context of the initial choice of whether or
not to accept the email onto the server. I.e. they'll run some
anti-spam filter in their "account" context as a normal user.
The users who want "standard filtering", may have it
done such that the email is never accepted onto their
email server.
I.e. it "should" never be the case that user-defined
filters are run in the MTA's initial receive context as the MTA
just received (or is in process of receiving) an email coming
in on a privileged port (like port 25) which would imply a
privileged context (most likely root).
>
> Even in the two-class case, there's still a delay for the subsequent
> class(es).
---
Delays are not the same as dropped email. People use
grey-listing which often causes some delay, but in this case,
I've seen examples of people who's mail-provider was
inspecting+filtering emails for spam+malware also have
problems in delivery time (60-90 minutes after the fact).
So it is already the case that mail-providers who do
filtering on the mail-server are sometimes slow to pass
on the email to their users, depending on their volume).
linda
Re: Dropping mail
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 27 Apr 2018 14:39:43 -0500 (CDT)
David B Funk <db...@engineering.uiowa.edu> wrote:
[snip]
> Define two classes of recipients:
> class A == all users who want everything
> class B == all users who want "standard" filtering
This works if you have a limited number of classes, but in some cases
users can make their own rules and settings so the number of classes
can be the same as the number of RCPTs.
Even in the two-class case, there's still a delay for the subsequent
class(es).
Regards,
Dianne.
Re: Dropping mail
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Fri, 27 Apr 2018, Dianne Skoll wrote:
> Hi,
>
> I have reluctantly come to the conclusion that in some cases, it is
> necessary to silently drop spam rather than reject it. This is the
> situation:
>
> An email comes in for two recipients in one SMTP trasaction (ie,
> a MAIL, two RCPTs and then DATA).
>
> One recipient's rules say to accept. The other recipient's says to reject.
>
> You can't reject post-DATA because then it looks like both recipients
> received the mail.
>
> You can accept and create a failure message for one recipient, but then
> you risk generating backscatter.
>
> You can tempfail all but the first RCPT to force the message to be
> split up into individual messages per recipient, allowing you to accept
> or reject individually. But this will delay mail and possibly cause it
> not to be delivered if there are many recipients and the sending relay
> is impatient.
>
> So I reluctantly conclude that in all but the smallest of installations,
> dropping the mail for the recipient whose rules say to do so is the
> best thing to do.
>
> There have been SMTP extensions proposed to combat this. I recall an
> extension that had you issue RCPTs until one of the RCPTs was
> accepted, then DATA, then additional RCPTs with a "also send the
> foregoing to this one" keyword so you could have per-recipient data
> filtering, but of course spammers could not be obliged to use the
> extension. :(
One possible way to deal with this situation (which would require some additional
complexity on the server and require good behavior on the senders) is:
Define two classes of recipients:
class A == all users who want everything
class B == all users who want "standard" filtering
At 'RCPT' phase of the SMTP transaction note if the first valid recipient is
class "A" or class "B", set a flag to remember it.
For each subsequent valid recipient see if their class is the same as the first
recipient. If not then return a "452 Too many recipients" reply code for that
one and all subsequent valid recipients.
Ideally the sender should then move on to the DATA phase, complete the
processing for the first batch of recipients, and then try again for the
remainder.
If all goes well, this should split up the different classes of recipients into
separate SMTP transactions allowing for appropriate processing with out loss.
Your classifications can be expanded upon to meet your site requirements but
the processing logic should be the same.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Dropping mail
Posted by Dianne Skoll <df...@roaringpenguin.com>.
Hi,
I have reluctantly come to the conclusion that in some cases, it is
necessary to silently drop spam rather than reject it. This is the
situation:
An email comes in for two recipients in one SMTP trasaction (ie,
a MAIL, two RCPTs and then DATA).
One recipient's rules say to accept. The other recipient's says to reject.
You can't reject post-DATA because then it looks like both recipients
received the mail.
You can accept and create a failure message for one recipient, but then
you risk generating backscatter.
You can tempfail all but the first RCPT to force the message to be
split up into individual messages per recipient, allowing you to accept
or reject individually. But this will delay mail and possibly cause it
not to be delivered if there are many recipients and the sending relay
is impatient.
So I reluctantly conclude that in all but the smallest of installations,
dropping the mail for the recipient whose rules say to do so is the
best thing to do.
There have been SMTP extensions proposed to combat this. I recall an
extension that had you issue RCPTs until one of the RCPTs was
accepted, then DATA, then additional RCPTs with a "also send the
foregoing to this one" keyword so you could have per-recipient data
filtering, but of course spammers could not be obliged to use the
extension. :(
Regards,
Dianne.
Re: dropping other's email(s) as a "best practice" for hosted
email?
Posted by John Hardin <jh...@impsec.org>.
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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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: rejection w/o sender (or recipient) knowing == dropping
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
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, uhlar@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
Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-04-29 (21:02 MDT), L A Walsh <sa...@tlinx.org> 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
Posted by L A Walsh <sa...@tlinx.org>.
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.
Re: dropping other's email(s) as a "best practice" for hosted email?
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>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, uhlar@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?
Posted by L A Walsh <sa...@tlinx.org>.
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? ...")
Posted by Alan Hodgson <ah...@lists.simkin.ca>.
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.
Re: dropping other's email(s) as a "best practice" for hosted email?
(was: "anyone recognize these headers? ...")
Posted by David B Funk <db...@engineering.uiowa.edu>.
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
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
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? ...")
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
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, uhlar@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".