> 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.
This is a good point. It seems odd they're presenting the functionality
they are
by using this port. In all other cases, it's 587.
> 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).
>
> 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.
>
> Yes, of course. I'm accidentally blurring the lines between these
discussions
> and my end goal. Although unlikely, I could make the decision SMTP is too
> insecure for my needs. (SMTP is supposed to function this way, but it
doesn't
> mean that it must be acceptable to me.)
>
> As others mentioned, this is very broad question.
Yes, that was intentional. It was to start a discussion, and to narrow it
as required.
If this mailing list isn't suitable, please point me to a better place (if
one is known).
> 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.
What I take from this is we want mail to get there rather than risk users
to lose
faith in the reliability of the system. If I have a problem with this
layout, I'd have
to argue elsewhere.
No one so far seems particularly surprised by my findings, and I mostly
expected
this. However, this has given me a few items to explore with the provider
that
I didn't have before.
On Wed, Apr 19, 2023 at 4:03 AM Matus UHLAR - fantomas via Postfix-users <
postfix-users@postfix.org> wrote:
> 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
>
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
