ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3

2021-04-06 19:12:40
Kristijonas,

I'm not a lawyer either, but it is clear to me that the
discussion has strayed far outside any area that the IETF can do
anything about or that is productive for discussion on this
list.  

While I don't see the odds of forcing Microsoft to change their
behavior and/or to punish them for it as particularly high
(which may just be more evidence that I am not a lawyer), it
seems to me that, if you are convinced that they are behaving
illegally or very badly, your next step would be to raise the
issue with local regulatory, consumer protection, or
competitiveness authorities. Or perhaps with someone who has a
contractual relationship with Microsoft that they believes
Microsoft is violating and who might be inclined to try to
enforce those provisions.  However, I am quite certain (despite
not being a lawyer) that there is no contractual relationship
between Microsoft and "the Internet" (partially because I can't
even imagine what that would mean).

     best,
      john


--On Wednesday, April 7, 2021 01:44 +0300 Kristijonas Lukas
Bukauskas <kr=40n0(_dot_)lt(_at_)dmarc(_dot_)ietf(_dot_)org> wrote:

On 2021-04-06 23:33, Arnt Gulbrandsen wrote:

Look it up and quote chapter and verse, please. I don't see
anything of the kind. I do see wording in "my" enterprise
documentation that IMO suggests a required ability to send to
working sites, but nothing that requires Microsoft to provide
a correct analysis of what is broken at sites outside
Microsoft's control.

[DISCLAIMER: I am not a lawyer. The following is not legal
advice. Even if I was a lawyer, this discussion would not make
me *your* lawyer, and this would still not be legal advice.
This is only my interpretation of the law and opinion about
some aspect thereof. Don't sue me if you do something
unreasonable based on what I said; I disclaim all
responsibility for your actions. Act at your own risk]

https://www.microsoft.com/en-us/servicesagreement:

8. APPLICABLE LAW.

a. United States and Canada. If you acquired the application
in the  United States or
Canada, the laws of the state or province where you live (or,
if a  business, where your
principal place of business is located) govern the
interpretation of  these terms, claims
for breach of them, and all other claims (including consumer 
protection, unfair
competition, and tort claims), regardless of conflict of laws 
principles.
b. Outside the United States and Canada. If you acquired the 
application in any other
country, the laws of that country apply.

9. LEGAL EFFECT.

This agreement describes certain legal rights. You may have
other  rights under the laws of your state or country. This
agreement doesn't  change your rights under
the laws of your state or country if the laws of your state
or country  don't permit it to do so.

Thus, the client has rights laid down in the agreement plus
the rights in the laws of the corresponding country. A service
provider has obligations laid down in the agreement and might
have obligations set in the laws of a corresponding country.

For example, local law here in Lithuania (Article 6.200 of the
Civil Code of the Republic of
Lithuania)[https://e-seimas.lrs.lt/portal/legalAct/lt/TAD/TAIS
.245495]:

Principles of performance of a contract

* A contract must be performed by the parties in a proper way
and in  good faith.
* In performing a contract, each party shall be bound to
contribute to  and to
cooperate with the other party.
* The parties shall be bound to use the most economical means
in the  performance of the contract.
* Where according to a contract or its nature, a party in
exercising  certain actions is bound to make the best effort
in the performance of  a contract, this party shall be
bound to make such effort as a reasonable person would make
in the same  circumstances.

If a party (a service provider) of a contract is a
professional in his field with extensive experience, also due
to the nature of a contract (e-mail services), although it not
reasonable to require the provider to examine internal
third-party server errors or misconfiguration, it's reasonable
to expect the provider to know why it cannot provide the
service (why it fails to send out a message on its end), and
if requested, to explain those reasons to a client (sender).
Showing specific errors (as opposed to generic ones) suggests
the service provider's choice to provide a piece of detailed
information. Being a professional, the service provider that
shows detailed but misleading information (a client usually
being a weaker side of the contract and that's especially true
when it is a natural person) cannot be considered as acting in
a good faith while performing the contract.

That's my view.


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>