On 17.04.23 13:38, Tyler Montney via Postfix-users wrote:
Before getting started, this has been publicly disclosed by someone else a
while ago. However, I still don't think it's necessary to name the
organization to explain myself. My goal here is not only to give a proper
argument to the provider, but also my own curiosity and research (on the
workings of SMTP).
I use a mail provider (Provider A) which has thousands of organizations.
This provider allows unauthenticated SMTP to other organizations so long as
they're using them as a provider (within their ecosystem). Of course, you
cannot send unauthenticated email to other providers. I have tried one of
my other larger providers, Provider B, and I was unable to do this
successfully. Provider A claims this behavior is by design, as some devices
have simple or no authentication capabilities. Provider B has similar
allowances but all of their methods require a form of authentication.
It was common practice to allow your (from the ISP PoV) clients to submit
mail via SMTP, through port 25 on your mailserver. Some ISPs still do this.
The client authentication here is done via client IP address, no further
checks.
Next, enciphered and authenticated mail submission became common, where
client can connect from the internet and submit mail, auithentication done
via user/password (later using different ways).
The alternative ports 465 and 587 are used here. The authentication should
be mandatory on these ports, as well as encryption (on port 465 implicitly,
before SMTP comes in, on port 587 using STARTTLS SMTP extension).
Some providers started to require SMTP authentication for any mail
submission long ago.
Also, because port 25 is used for server-server communication, some
providers started blocking their clients from connecting to port 25 of
remote (or even local) hosts, preventing clients from sending spam this way.
The sender address is completely unrelated to this, providers may or may not
verify, if the client is authorized to send mail from provided address, e.g.
compare login name to list of allowed sending addresses.
Further, envelope (mail from:) and header From: senders may be two different
addresses (this question pops up here once in a while).
Mechanisms such as SPF or spam filtering certainly are effective here, but
unauthenticated SMTP seems like a core failing. "Open relay" is the first
thing that comes to mind; however, is it really an open relay?
From traditional point of view an open relay is mail server that allows you
to relay non-local mail without authentication - you connect, send mail,
server will accept it and pass it to he recipient.
The "local" in this case means any domain that is configured on server
("I handle this domain, so I accept mail for it"). Mail for such domain may
be delivered to local users (mail destination), or relay servers (mail
gateway, backup MX servers) etc.
SPF/DKIM/DMARC mechanism were designed for recipient of the mail, not for
sending/relaying server.
sending server of course may verify sender address and refuse mail if the
sender is not local/known/configured, whether it's on domain or address
level (see above).
As
mentioned, I cannot send from Provider A to Provider B. The scope is
limited to just this ecosystem. But is there an expectation on how limited
that really is? Say for instance only Provider A and Provider B existed in
all the world, and Provider B was 1% of all servers. Surely that would not
be acceptable to most.
As others mentioned, this is very broad question.
If you have mail server, nobody should stop you from sending mail to anyone
by connecting to recipients' SMTP servers, but nobody is required to accept
mail from you.
If you rely on your provider to submit mail, it's up to them to set their
requirements.
It is my belief that unauthenticated SMTP best practice should only
function when sending within the same domain (f...@domain.com -->
b...@domain.com).
Unless you are owner of domain.com, please use example.com, example.net or
example.org instead.
The best practice should be requiring your to authenticate to send mail at all
(port 465/587, block port 25) when you are considered to be end-user,
or not to limit you at all AND allow you to connect port 25 to any server on
internet to send mail to them, leaving the decision on the recipient, when
you are mail server (being able to receive mail via SMTP may not to be a
requirement here).
Unless they're in an approved senders list, it does not
matter whether the same server, company, ecosystem, and so forth. (Perhaps
there is some unforeseen dependency in being a multi-organization mail
provider, where this is required.) I have reviewed RFC 2821 but have not
found anything concrete, just that it MAY accept or reject as it sees fit
[3.7].
RFC 5321 (and previous) did not care if you will accept mail, they only
cared how mail it supposed be send/delivered.
the "approved senders list" may be list of IP addresses, mail addresses, the
whole policy depends on mail server administrator.
--
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.
I drive way too fast to worry about cholesterol.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
