easiest way to reject/process emails based on Return Path

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

easiest way to reject/process emails based on Return Path

Yuval Levy
Hello List:

I am operating a smallish postfix server for my law office.  Many of
our contacts use Google's calendar, and when they enter one of our
email addresses into their calendar entries, we receive a flood of
annoying emails.  Invitations / reminders / updates / changes /
cancellations of meetings.

Initially, after receiving twelve emails for a single calendar entry
repeated weekly for three months, I wanted to outright reject the
Google spam.  After the second change within 24 hours, I also wanted to
fire the client.  But maybe there is smarter way to deal with this
annoyance, such as re-directing the emails to an auto-responder or some
other form of automated processing (/dev/null comes to my mind too)?

Below is the PCRE that I came up with to catch the offending messages,
without blocking other correspondence (the contacts and their
organizations are likely to use Google's SMTP for their regular
emails):

/^Return-Path:(.+)(calendar-server.bounces.google.com)(.*)/  REJECT No
Google Calendar Spam Here

where/how do I best add the restriction to Postfix?  I was thinking to
make it an smtpd_restriction_classes so that I can apply it to some
recipients but not to others.

But maybe rewriting the destination address, or sending an auto-
responder right away?  I just want to get that spam out of the way in
the most elegant way possible.

Thanks in advance for your help,
Yuv

Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

@lbutlr
On 07 May 2020, at 19:31, yuv <[hidden email]> wrote:
> I am operating a smallish postfix server for my law office.  Many of
> our contacts use Google's calendar, and when they enter one of our
> email addresses into their calendar entries, we receive a flood of
> annoying emails.  Invitations / reminders / updates / changes /
> cancellations of meetings.

This is a “feature” of Google Calendar.

> Initially, after receiving twelve emails for a single calendar entry
> repeated weekly for three months, I wanted to outright reject the
> Google spam. After the second change within 24 hours, I also wanted to
> fire the client.  But maybe there is smarter way to deal with this
> annoyance, such as re-directing the emails to an auto-responder

That would be a very bad idea.

> or some other form of automated processing (/dev/null comes to my mind too)?

Filter them into their own mailbox and auto-mark them as read.

> Below is the PCRE that I came up with to catch the offending messages,
> without blocking other correspondence (the contacts and their
> organizations are likely to use Google's SMTP for their regular
> emails):
>
> /^Return-Path:(.+)(calendar-server.bounces.google.com)(.*)/  REJECT No
> Google Calendar Spam Here

If you reject mail from Google, Google will stop sending you mail. ALL mail. Can you afford that?

> But maybe rewriting the destination address, or sending an auto-
> responder right away?  I just want to get that spam out of the way in
> the most elegant way possible.

Sieve/procmail.




--
My own people are trying to kill me? It's so French.


Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

Gerald Galster

>> Below is the PCRE that I came up with to catch the offending messages,
>> without blocking other correspondence (the contacts and their
>> organizations are likely to use Google's SMTP for their regular
>> emails):
>>
>> /^Return-Path:(.+)(calendar-server.bounces.google.com)(.*)/  REJECT No
>> Google Calendar Spam Here
>
> If you reject mail from Google, Google will stop sending you mail. ALL mail. Can you afford that?


You could use DISCARD instead of REJECT.

#        DISCARD optional text...
#               Claim successful delivery and silently discard  the
#               message.   Log the optional text if specified, oth-
#               erwise log a generic message.


Best regards
Gerald
Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

Yuval Levy
On Fri, 2020-05-08 at 09:51 +0200, Gerald Galster wrote:

> > > Below is the PCRE that I came up with to catch the offending
> > > messages,
> > > without blocking other correspondence (the contacts and their
> > > organizations are likely to use Google's SMTP for their regular
> > > emails):
> > >
> > > /^Return-Path:(.+)(calendar-
> > > server.bounces.google.com)(.*)/  REJECT No
> > > Google Calendar Spam Here
> >
> > If you reject mail from Google, Google will stop sending you mail.
> > ALL mail. Can you afford that?
>
> You could use DISCARD instead of REJECT.
>
> #        DISCARD optional text...
> #               Claim successful delivery and silently discard  the
> #               message.   Log the optional text if specified, oth-
> #               erwise log a generic message.
>

Thanks for the suggestion, Gerald.  I was hoping for something more ...
*honest*.  To claim successful delivery and silently discard a message
is a lie.  The legal term is *misrepresentation* and I am eagerly
waiting for the client coming through my door who has been damaged by
an email service operator that replied with a 250 and then silently
discarded the message.  It is one of the main reasons why we lawyers
continue to use fax transmission: the protocol is reliable, my fax
device receives the equivalent of a 250, I can rely on the fact that
something has been delivered.  Not silently discarded.

As for the other comments elicited by my post: is there any evidence
that Google stops sending ALL mails on some very specific rejections?
or is this just FUD?  After all, Google is used by millions of senders,
and some of them are most obvious spammer.  Does anyone expect an email
server to accept an email containing a request to send money by Western
Union to some exotic country in exchange for the prospect of receiving
an inheritance from an obscure prince or despot of said country?

Thanks,
Yuv

Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

Jaroslaw Rafa
Dnia 18.05.2020 o godz. 11:50:53 yuv pisze:
> discarded the message.  It is one of the main reasons why we lawyers
> continue to use fax transmission: the protocol is reliable, my fax
> device receives the equivalent of a 250, I can rely on the fact that
> something has been delivered.  Not silently discarded.

In what area of the world people are still using faxes?
I haven't heard abut anybody using fax (even a lawyer) for years.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

Jaroslaw Rafa
In reply to this post by Yuval Levy
Dnia 18.05.2020 o godz. 11:50:53 yuv pisze:
> Thanks for the suggestion, Gerald.  I was hoping for something more ...
> *honest*. To claim successful delivery and silently discard a message
> is a lie. The legal term is *misrepresentation* and I am eagerly
> waiting for the client coming through my door who has been damaged by
> an email service operator that replied with a 250 and then silently
> discarded the message.

For a mail service operator it would actually be unacceptable. But for *end
recipient* it's a different story.
It's your own (ie. your company's) server, so you represent an *end
recipient*, not a mail service operator, and any action you perform, you
perform as (or on behalf of) the end recipient.
No recipient has an obligation to read all mail that's coming to them (well,
maybe lawyers view it differently? ;)). Delivered doesn't mean read.
Accepting a message and silently discarding it is no different from deleting
a message without even opening it - only the former is automated, but this
automation is authorized by you - it's you who, as the end recipient, set
the rule to discard messages. You are absolutely allowed to do it.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

Bill Cole-3
In reply to this post by Yuval Levy
On 18 May 2020, at 11:50, yuv wrote:

>  To claim successful delivery and silently discard a message
> is a lie.

A 250 reply to end-of-data is not a claim of final delivery. Even if
there's following text that seems to assert that the message is
delivered, it has always been true that one cannot rely on that delivery
being to a final destination which is readily accessible to the intended
recipient.

> The legal term is *misrepresentation*

It is not misrepresentation. The SMTP protocol definitions have NEVER
required the 250 reply to end-of-data to indicate actual (much less
final) delivery and has ALWAYS explicitly cautioned against reliance in
any way on the optional text part of any server reply.

> and I am eagerly
> waiting for the client coming through my door who has been damaged by
> an email service operator that replied with a 250 and then silently
> discarded the message.

I am not a lawyer in any sense and so cannot give any legal advice worth
taking, however I have been peripherally involved in civil suits under
US law which have touched on this issue in their pre-trial phases and I
believe that you would be wise to research relevant precedents before
taking on that hypothetical client, and especially to not take on such a
client on a contingent fee basis.

I can't do that research for you or even point at any case where
non-delivery of Internet email has been an issue at trial or in appeals.
If you practice in the US, I know that 47 U.S. Code § 230 can be
relevant but may or may not be in any particular case.

> It is one of the main reasons why we lawyers
> continue to use fax transmission: the protocol is reliable, my fax
> device receives the equivalent of a 250, I can rely on the fact that
> something has been delivered.  Not silently discarded.

A wise practice. On the other hand, the fax acknowledgement does not
normally guarantee that the fax machine does not feed directly into a
shredder or incinerator, or simply that there wasn't a fatal paper jam
or ink mishap in the fax machine's printer. However, the fact that fax
acknowledgements are generally considered reliable is largely a
consequence of laws like the US TCPA (and the abuses prior to
regulation.)

In 30 years of working with Internet email, I have never seen any fully
automated mechanism for making its delivery reliable in general,
non-contracted cases. Proposals for that have always failed in some
fashion due to the fact that there's no universal standard mechanism for
how email is handled after it leaves the realm of SMTP. Spammers (and
the slightly broader population of people who fear being seen as
spammers) have sought mechanisms to automatically verify addresses for
decades and have only succeeded in making it increasingly true that the
only way to confirm any email address as being delivered to a human is
to send it email and get a clearly human-written reply. Even that
verification is valid for just that one message.

There is no virtual replacement for a physical process server. Maybe
someday that will mean robots of some sort (e.g. drones) but

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

Gerard E. Seibert
In reply to this post by Jaroslaw Rafa
On Mon, 18 May 2020 18:20:36 +0200, Jaroslaw Rafa stated:
>Dnia 18.05.2020 o godz. 11:50:53 yuv pisze:
>> discarded the message.  It is one of the main reasons why we lawyers
>> continue to use fax transmission: the protocol is reliable, my fax
>> device receives the equivalent of a 250, I can rely on the fact that
>> something has been delivered.  Not silently discarded.  
>
>In what area of the world people are still using faxes?
>I haven't heard abut anybody using fax (even a lawyer) for years.

FAXs are used my municipalities all the time.

--
Jerry
Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

Yuval Levy
In reply to this post by Bill Cole-3
On Mon, 2020-05-18 at 13:50 -0400, Bill Cole wrote:
> In 30 years of working with Internet email, I have never seen any
> fully
> automated mechanism for making its delivery reliable in general,
> non-contracted cases.

...

> There is no virtual replacement for a physical process server. Maybe
> someday that will mean robots of some sort (e.g. drones) but


before I embark on an interesting conversation, can somebody confirm that I am not veering off-topic?  I came here for a technical solution.  Jerry gave an elegant one, although I am not ethically comfortable with it.

The problem of Internet email is the problem of any federated standard.  Embrace, Extend, Extinguish.  Internet email is being replaced by text messaging, and I dare betting that fax will survive Internet email, because fax has a niche that Internet email has failed to create for itself.

Fax niche is the communication with adverse interest.  A minimum common denominator, that enable the less powerful of the parties to stay in the game.  Internet email could have been even better.  Could have...

I am not expecting process serving standards (though I wish mechanical process serving could be replaced by something electronic).  Just the same reliability of fax transmission (if the message gets lost after the 250, the fax operator is liable) would be good enough to give Internet email more purpose than the delivery of spam.

--
Yuval Levy, JD, MBA, CFA
Ontario-licensed lawyer
https :// moneylaw.ca
Tel: 1.844.234.5389
Fax: 1.888.900.5709


Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

Jaroslaw Rafa
Dnia 18.05.2020 o godz. 22:38:11 yuv pisze:

> The problem of Internet email is the problem of any federated standard.
> Embrace, Extend, Extinguish.  Internet email is being replaced by text
> messaging, and I dare betting that fax will survive Internet email,
> because fax has a niche that Internet email has failed to create for
> itself.
>
> Fax niche is the communication with adverse interest.  A minimum common
> denominator, that enable the less powerful of the parties to stay in the
> game.  Internet email could have been even better.  Could have...
>
> I am not expecting process serving standards (though I wish mechanical
> process serving could be replaced by something electronic).  Just the same
> reliability of fax transmission (if the message gets lost after the 250,
> the fax operator is liable) would be good enough to give Internet email
> more purpose than the delivery of spam.

As a non-lawyer, it is hard for me to understand what you're trying to
debate about.

Even physical postal mail service does not give any guarantee that the
recipient has actually READ your mail. (BTW, it's even a recurring theme in
movies and books that person A keeps sending letters to person B, but they
never get to the recipient as some other person C, who is a family member of
person B, intercepts and hides them).
 
Even if you send via registered mail and request delivery confirmation,
nobody will guarantee you that the recipient hasn't thrown your letter into
the trash right away after picking it up from the post office.

If you have your OWN SERVER, a 250 reply to SMTP transaction is an
equivalent of confirming that the message has arrived into your "mailbox".
But by the "mailbox", we should consider the entire mail system here, as
it's your own mail system and it's you who decides how it works.

If YOU decided, that messages matching particular criteria are silently
discarded (which is technically the same as deleting them right away after
they are delivered), it's equal to the case I described above - where YOU
throw the physical letter into the trash right away after having it
delivered to you. In both cases it's the recipient who decided to discard
the message without looking at it. What's ethically doubtful in this? If it
were a third party who discarded the message - yes, that would be unethical
(and probably against the law as well). But if the recipient does it
him/herself - I can see no ethical or legal issue at all.

What more do you want to expect from SMTP? Do you want to expect it to
provide something that even physical mail - and similarly your glorified fax
- doesn't provide? Ie. a guarantee that recipient has actually READ your
mail?

No asynchronous communication method will guarantee you that, simply because
of the very fact it's asynchronous, ie. the delivery of the message is
separated in time from the act of actually reading it by the recipient, and
the latter may never happen (imagine sending e-mail to a still functioning
e-mail address of a person who has just died; the same is true for postal
mail and fax as well. Is a 250 reply in that case also a "lie" or
"misrepresentation"?). If you want to have guarantee that your message
actually got to the recipient, you must use synchronous communication -
face-to-face meeting, telephone, videoconference etc. so that you can
see/hear the actual response of your correspondent in real time.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

Yuval Levy
On Tue, 2020-05-19 at 11:38 +0200, Jaroslaw Rafa wrote:
> As a non-lawyer, it is hard for me to understand what you're trying
> to debate about.

The legal issue is NOTICE.  NOTICE is the fact that the recipient knew
or *should have known* the content of the message.  Let me know if you
want me to expand on the concept of notice.


> Even physical postal mail service does not give any guarantee that
> the recipient has actually READ your mail.

That is not of concern, neither for snail-mail, nor for fax, nor for
internet-email.  The three of them have done their job when they have
delivered.

After delivery, the responsibility (and the legal liability) lies with
the recipient.

The general rule is that spam is in the eye of the recipient:  if you
find my message to be irrelevant to you, I must accept your judgment.
Except for some specific situations.  For example, a debtor cannot say
that a request to pay from a creditor is spam.  It is a direct
consequence of the debtor accepting a loan.  This is where the concept
of notice kicks in:  the debtor should have known that he owes money,
ignoring the payment request does not absolve the debtor from the
consequences of not paying the debt.  I had clients who learned this
the hard way:  they ignored the snail-mail letters from the bank. the
bank repossessed their home, evicted them, and sold it, at great
expense/loss to the idiots who ignored the letters.


> If you have your OWN SERVER, a 250 reply to SMTP transaction is an
> equivalent of confirming that the message has arrived into your
> "mailbox".

This is a conflation of the general case, and irrelevant to my concern.
In the OWN SERVER case, the law will find that the recipient has
willfully ignored the message and knew or should have known the
message.


> What's ethically doubtful in this? If it were a third party
> who discarded the message - yes, that would be unethical
> (and probably against the law as well). But if the recipient does it
> him/herself - I can see no ethical or legal issue at all.

if the third party is Gmail or Hotmail (and many more, no intention to
single out those two services), then it is not even against the law, as
the contract between the unaware user and the sophisticated "free"
email provider stipulates that the email provider has no responsibility
for delivering the message.  Let me first expand on the legal issue,
and then touch on the soft / ethical issue.

In a previous message on this thread, on Mon, 2020-05-18 at 13:50
-0400, Bill Cole wrote:
| > The legal term is *misrepresentation*
|
| It is not misrepresentation. The SMTP protocol definitions have
| NEVER required the 250 reply to end-of-data to indicate actual
| (much less final) delivery and has ALWAYS explicitly cautioned
| against reliance in any way on the optional text part of any
| server reply.


A *misrepresentation* occurs when a person lies.  SMTP is not a person.
An MTA is not a person.  A fax is not a person.  They are merely
devices that a person use to make the misrepresentation.

The *LEGAL ISSUE* with an MTA or with a fax is product liability.

The manufacturer of a fax device (or the operator of a fax server -- I
have not owned a fax device since 2003) represents that its device or
service complies with the CCITT standards (or whatever has followed
since, the last time I have looked in depth at the protocols around
faxes during a 1989 summer job when I programmed a software-fax), and
failure to comply with the standard attracts a product liability suit.

Software publishers for MTAs (and in general) exclude product liability
with the licensing term that disclaims "implied warranties or
conditions of merchantability and fitness for a particular purpose"
(quoted text from the terms under which Postfix is licensed).  Which
basically says to the user: here is a knife, use it at your own risk.

If the OWN SERVER sends a 250 and discards the message, the user is
both recipient and operator.  The law will find sufficient notice and
the sender is protected.

In the general case, the user is the MTA operator and is not the
recipient.  The user has caused the MTA to send a 250 and
*misrepresented* to the sender that the message was delivered.  The
user has caused the message to be silently discarded, preventing the
recipient from noticing the message.  The user is liable for the damage
caused by the lack of notice, except if said damage is disclaimed in
the general terms and conditions of the service (see reference to
"free" email services above).  Unsurprisingly, free email services
invariably have such disclaimer, preventing the recipient from making a
damages claim against the operator.  I believe that paid email services
(from the same providers) do not have such disclaimer, and if they do,
why would one want to be customer of their service?

The *ETHICAL ISSUE*, and the reason why I do not want to send a 250 and
discard the message in the conflated scenario:  when I am the sender,
and I am told 250, and that 250 cause damage to me because it is a lie,
I am obviously not happy.  Which wise person said 'Don't do unto others
what you don't want done unto you?'

The 250 + silent discard makes internet-email much less useful, and the
general terms and conditions of the free services probably contemplate
that case as well and allocates to the recipient liability for the
damages to the sender through an indemnity clause.  The recipient will
"indemnify and hold harmless" the service provider.

Which is why, as a sender, instead of doing the simple thing of
attaching a PDF to an email, I do one of the two following things:
(1) when I am in control of the relationship, I upload a PDF to a
server that I control, send a text message and email to the recipient
with a link to the PDF, and use logs from my web-server to have proof
of actual notice.  I follow up with a phone call (synchronous
communication, as you mention) if I need actual notice.  And sometimes
I get written, wet ink confirmation of receipt, to nip in the bud every
possible claim that they did not notice.
(2) when an opposite party is in control of the relationship
(typically: I act for a debtor and communicate with a creditor; or I
act in a contract negotiation), I send a fax.  The 250-equivalent that
I receive from the opposite's party is notice (knew or should have
known), and saves me all the hassles of confirming actual notice (or
READ, in your examples).


| the fax acknowledgement does not normally guarantee that the fax
| machine does not feed directly into a  shredder or incinerator, or
| simply that there wasn't a fatal paper jam or ink mishap in the fax
| machine's printer.

What the fax ack does "normally" guarantee is that the recipient has
notice and can call back to ask for a re-sent in case of an accident,
and cannot get away in case of intentional ignorance.  There is still a
margin of uncertainty (e.g. fax device destroyed in a fire; or sender
not providing a valid fax number in the transmission).  From a legal
point of view, liability can still be reasonably allocated (e.g. fire
insurance, or sender for not providing a valid sender number).

The really good fax devices time-stamp each individual page of the
transmission, so if there was a deadline, pages that arrived after that
deadline do not count in the legal process.


| However, the fact that fax acknowledgements are generally considered
| reliable is largely a  consequence of laws like the US TCPA (and the
| abuses prior to regulation.)

"Generally considered reliable" is mere comfort.  The real and hard
value of fax ack is that for the purpose of allocating legal liability,
they are *deemed* reliable and *enforced* by the legal system, whether
it is the Common Law, or a code created by a legislator such as US
TCPA.  This is what makes the fax, on this one particular aspect,
superior to internet email.  I wish internet-email would achieve
superiority, or at least parity, over fax.  I do not hold my breath,
and this is the problem of the federated protocol:  without
participants agreement (ITU in the case of fax) federated protocols
generally fall apart as each party pulls for its own interest instead
of the common interest, and we all fall back on the least common
denominator.

text messages work better than internet email because the telcos make
tons of money from servicing highly regulated, scarce (artificially) phone numbers, as opposed to internet email service providers that fight an uphill battle against the infinite supply of domain names and email addresses.


> your glorified fax

Careful.  I am not glorifying the fax or anything, but you are
antagonizing me with the above allegation.  Here is one math problem
for you to solve, and you tell me if you come to the same conclusion
that I do, which is why I use the fax so much.

You work for home buyers that need mortgages.  You need to receive
mortgage instructions from the lender.  The lender gives you two
options:
(a) use a proprietary platform that requires use of Internet Explorer
(no Edge, no Chrome, no Safari, no Firefox) and Adobe Reader.  A
typical fee of $30/mortgage is charged to you/your client
(b) use a fax; for which you/your client cover your side of the expense
(receiving and, if necessary, printing).

Add to the scenario that:
* a typical mortgage is in the range of 10-20 transmitted fax pages
(standard documents are made available by the lenders on their
websites, only specifics to each deal are faxed)
* the cost range of a bidirectional fax to email gateway is in the
$0.03-$.10/page
* there are multiple lenders and a few proprietary platforms, each with
its own quirks and learning curves
* A small law office working full time on these kinds of mortgage
transactions will do 15 to 20 per month.

I receive my faxes as PDF.  The fax gateway to internal email is
reliable.  I automate processing of those PDF.  OCR if needed.  Extract
pages and overlay text (complete forms) out of my database.  Overlay
signatures or present to clients for wet ink signatures.  Fax back,
making sure that all deadlines are met and that the other party has
legal notice.

I wish I could skip the fax gateway and use internet email directly.
With a few of the lenders it works, but it is up to the contractual
agreement of the parties.  This is during sunny days.  Imagine when
things go wrong, and allegations start to fly.


> No asynchronous communication method will guarantee you that [the
> recipient has actually READ your mail]

I am not expecting the middle-man, whether a human, a corporation, or a
piece of hardware or software, to guarantee anything in respect of the
recipient.  All that I expect is that it does a "best effort" to
deliver the message to the next hop (may not be the end recipient) and
does not misrepresent to the sender that it has delivered on its
effort.  A 250+silent drop does not cut it.  And since I am expecting
that of others, I am expecting that of myself as well, which is why I
came here for a technical solution on how to let Google know (and I am
not singling out Google) that their calendar reminder have been
REJECTED, without retaliation from Google (stop sending you all
emails), without lying to Google (250+discard) and trying to promote a
healthy internet email federation.  If we do not act ethically with
one-another, our federation will die and the walled gardens of the
telecoms will prevail.  AOL or Compuserve, anybody?

Back from lunch break,
--
Yuval Levy, JD, MBA, CFA
Ontario-licensed lawyer
https :// moneylaw.ca


Reply | Threaded
Open this post in threaded view
|

Re: easiest way to reject/process emails based on Return Path

Jaroslaw Rafa
Dnia 25.05.2020 o godz. 12:59:30 yuv pisze:
>
> The legal issue is NOTICE.  NOTICE is the fact that the recipient knew
> or *should have known* the content of the message.  Let me know if you
> want me to expand on the concept of notice.

You have explained it sufficiently in your message and I fully understand
your concerns about this topic. However:

> This is a conflation of the general case, and irrelevant to my concern.
> In the OWN SERVER case, the law will find that the recipient has
> willfully ignored the message and knew or should have known the
> message.
[...]
> If the OWN SERVER sends a 250 and discards the message, the user is
> both recipient and operator.  The law will find sufficient notice and
> the sender is protected.
>
> In the general case, the user is the MTA operator and is not the
> recipient.

That's the difference between us. For you, the "own server" case is
irrelevant, as you think about general case. But you have in your very first
post stated that you run your own (ie. your company's) server. So all
further comments, advices and replies in this thread should be viewed in
context of runing an own server and only in this context! So for you, the
case of own server is irrelevant; for me - it's the only one that is
relevant to this discussion; all others are irrelevant :)

I would never advise anyone to do 250+silent discard as a third party, and
probably the person who advised you to do this wouldn't as well. But - as I
understand from your quotes above - it states no legal issue when done on
own server.

> The *ETHICAL ISSUE*, and the reason why I do not want to send a 250 and
> discard the message in the conflated scenario:  when I am the sender,
> and I am told 250, and that 250 cause damage to me because it is a lie,
> I am obviously not happy.  Which wise person said 'Don't do unto others
> what you don't want done unto you?'

But if you do it on your own server (I will still hold on to the only
relevant case ;)), it's practically equivalent to deleting a message without
opening it. Do we still remember that your original question was about
getting rid of superfluous Google Calendar notifications? You probably
delete them without opening. So if you set up a filtering rule that matches
them and only them - and deletes them before they reach your inbox - would
it be different in any way? What's unethical in this (in this particular
case ONLY)?

Again, I repeat: I would never advise to do it as a third party. Only as a
final recipient. That's a fundamental difference (at least for me).

> You work for home buyers that need mortgages.  You need to receive
> mortgage instructions from the lender.  The lender gives you two
> options:
> (a) use a proprietary platform that requires use of Internet Explorer
> (no Edge, no Chrome, no Safari, no Firefox) and Adobe Reader.  A
> typical fee of $30/mortgage is charged to you/your client
> (b) use a fax; for which you/your client cover your side of the expense
> (receiving and, if necessary, printing).

Very strange scenario if I think about my country.

First: there is no such thing as faxing or emailing PDFs back and forth for
signature. Such documents would have no legal value. A fax copy is not a
document in legal sense; it's just an "image of a document", in similar
sense as a photograph or photocopy of a document would be. It can be a kind
of proof that a document exists (or existed), but it's not a document itself
(and as every proof, can be questioned in court).
And if you put a signature overlay from a different source onto a different
PDF file it may even be considered fraud, because it's no more an "image of
a document"; the image has been manipulated.
Of course, you can fax (or scan and email) a signed paper document just to
give the other party information that you signed it, but this is only an
information; only an actual paper document is a legally valid document.
So, legally valid documents can be signed only using two ways (of course
unless there's a previous contract between parties in place, which may allow
for different terms, eg. doing it online via website):
a) physically on paper. No faxes, no scans, no PDFs etc. If you cannot meet
with the other party in person to sign, you have to send the document via
snail-mail.
b) electronically (eg. in a PDF file), using a X.509 digital signature
issued by one of government-approved Certificate Authorities. Obviously you
cannot fax a digital signature :)

As for "your" lender, such a lender would most probably quickly go out of
business. No finance-related company here would think about charging for
using their Internet platform for processing loan application. That would be
a suicidal move. Nobody would borrow from them (unless you had no other
option because nobody else would want to give you a loan) if they charged
$30 just for use of Internet platform while the others aren't. One can just
imagine how much are they charging extra for other things.

And an Internet Explorer only platform? Do they still live in year 2000 or
what? One more reason to move to another lender.

Also less and less companies continue to have fax numbers, as almost nobody
is using them. So using a fax is often simply impossible.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."