[pfx] Re: Open relay clarification

[Tyler Montney via Postfix-users]

> 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, be

[pfx] Re: Open relay clarification

[Matus UHLAR - fantomas via Postfix-users]

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 "app

[pfx] Re: Open relay clarification

[Jaroslaw Rafa via Postfix-users]

Dnia 18.04.2023 o godz. 12:11:06 Tyler Montney via Postfix-users pisze:
> > - mail for all local domains coming in on port 25 should be accepted (of
> > course considering all usual restrictions - the recipient exists, the
> > sending IP is not on a blacklist etc.)
> >
> > - mail for all non-local domains coming in on port 25 should be outright
> > rejected with "Relay access denied" (or similar) message.
> >
> > There is no authenticated submission on port 25.
> 
> I do not see anything in the RFC explicitly prohibiting authenticated
> submission.

I agree that it is not prohibited, but because there are separate ports
defined for authenticated submission, the current best practice (used by
most mail server administrators, and also being actively recommended here on
this list) is to not enable authentication on port 25 (btw. this also largely
reduces the scale of password-guessing attacks). Port 25 is considered to be
strictly for incoming mail (to "local" domains), and ports 465/587 are for
outgoing mail (usually to "non-local" domains, although one may as well send
to another local domain on the same server).
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"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."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Tyler Montney via Postfix-users]

> By "local", I mean here the domains for which that particular server is
the
> final destination, ie. the mail delivered locally and the server "knows"
> what to do with it.

I can't find anything more on what *local* is per the RFC, just that it
must be defined.
Based on that, I guess any argument to what should be local is outside the
scope.

> Note that the term "delivered locally" is quite broad and may include
> *forwarding* the mail to other servers, eg. by aliases defined locally on
> the server. But still, the mail *is* delivered locally, it just happens to
> be delivered to an alias that forwards it elsewhere.
>
> In terms of Postfix, I interpret the term "local" in the meaning I used
> above as everything that is not in the default domain class (see
> http://www.postfix.org/ADDRESS_CLASS_README.html ), ie. all domains for
> which the server is configured to "handle" mail somehow. We can discuss if
> this description includes relay domain class, but it definitely (at least
> for me) includes local domain class, virtual alias domain class and
virtual
> mailbox domain class.
>
> In the meaning above, yes. They are all hosted on that server, so they are
> local. The "operational" difference between local and non-local is simple
> for me:

"Operational" is an acceptable way of distinguishing this.

If the RFC made any reference to "open relay", I could suggest it be revised
to include definitions for local. "Traditionally local" would be the
default but an
optimized "operationally local" would be the preferred. It could very well
be within
scope if it was treated as "rules of the road", as is the point of this
RFC. Sender and admins
expect consistent and safe results when it comes to delivery. Section 7.1
exists but
seems mostly to advise against misguided attempts to prevent spoofing.

> - mail for all local domains coming in on port 25 should be accepted (of
> course considering all usual restrictions - the recipient exists, the
> sending IP is not on a blacklist etc.)
>
> - mail for all non-local domains coming in on port 25 should be outright
> rejected with "Relay access denied" (or similar) message.
>
> There is no authenticated submission on port 25.

I do not see anything in the RFC explicitly prohibiting authenticated
submission.
(I will admit I have been somewhat using "authentication" and
"authorization" interchangeably.)
7.1 does say that the inherent nature of SMTP cannot be authenticated
(again,
going back to that "misguided attempt to secure SMTP [leading to more
problems]").
Perhaps because you could easily forge a submission as a relay?

On Tue, Apr 18, 2023 at 6:23 AM Jaroslaw Rafa via Postfix-users <
postfix-users@postfix.org> wrote:

> Dnia 17.04.2023 o godz. 19:59:48 Tyler Montney via Postfix-users pisze:
> > And that's a definition I've been struggling with: What is *local* in
> > relation to SMTP?
>
> By "local", I mean here the domains for which that particular server is the
> final destination, ie. the mail delivered locally and the server "knows"
> what to do with it.
>
> Note that the term "delivered locally" is quite broad and may include
> *forwarding* the mail to other servers, eg. by aliases defined locally on
> the server. But still, the mail *is* delivered locally, it just happens to
> be delivered to an alias that forwards it elsewhere.
>
> In terms of Postfix, I interpret the term "local" in the meaning I used
> above as everything that is not in the default domain class (see
> http://www.postfix.org/ADDRESS_CLASS_README.html ), ie. all domains for
> which the server is configured to "handle" mail somehow. We can discuss if
> this description includes relay domain class, but it definitely (at least
> for me) includes local domain class, virtual alias domain class and virtual
> mailbox domain class.
>
> > What if I'm a managed service provider hosting email on Postfix? Are all
> my
> > customers considered local?
>
> In the meaning above, yes. They are all hosted on that server, so they are
> local. The "operational" difference between local and non-local is simple
> for me:
>
> - mail for all local domains coming in on port 25 should be accepted (of
> course considering all usual restrictions - the recipient exists, the
> sending IP is not on a blacklist etc.)
>
> - mail for all non-local domains coming in on port 25 should be outright
> rejected with "Relay access denied" (or similar) message.
>
> There is no authenticated submission on port 25.
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "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."
> ___
> 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-user

[pfx] Re: Open relay clarification

[Jaroslaw Rafa via Postfix-users]

Dnia 17.04.2023 o godz. 19:59:48 Tyler Montney via Postfix-users pisze:
> And that's a definition I've been struggling with: What is *local* in
> relation to SMTP?

By "local", I mean here the domains for which that particular server is the
final destination, ie. the mail delivered locally and the server "knows"
what to do with it.

Note that the term "delivered locally" is quite broad and may include
*forwarding* the mail to other servers, eg. by aliases defined locally on
the server. But still, the mail *is* delivered locally, it just happens to
be delivered to an alias that forwards it elsewhere.

In terms of Postfix, I interpret the term "local" in the meaning I used
above as everything that is not in the default domain class (see
http://www.postfix.org/ADDRESS_CLASS_README.html ), ie. all domains for
which the server is configured to "handle" mail somehow. We can discuss if
this description includes relay domain class, but it definitely (at least
for me) includes local domain class, virtual alias domain class and virtual
mailbox domain class.

> What if I'm a managed service provider hosting email on Postfix? Are all my
> customers considered local?

In the meaning above, yes. They are all hosted on that server, so they are
local. The "operational" difference between local and non-local is simple
for me:

- mail for all local domains coming in on port 25 should be accepted (of
course considering all usual restrictions - the recipient exists, the
sending IP is not on a blacklist etc.)

- mail for all non-local domains coming in on port 25 should be outright
rejected with "Relay access denied" (or similar) message.

There is no authenticated submission on port 25.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"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."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Tyler Montney via Postfix-users]

>   One important information is missing here: on what port?

Good catch. Port 25.

>   There should be no authentication on port 25 and all mail destined for
local
>   domains should be accepted.
>
>   There should be mandatory authentication on ports 465/587.
>
>   As both acme.com and corley.com are local to provider A, on port 25 any
mail
>   to any of these domains should be accepted, regardless of sender,
without
>   authentication.

And that's a definition I've been struggling with: What is *local* in
relation to SMTP?

What if I'm a managed service provider hosting email on Postfix? Are all my
customers considered local?
Wouldn't *local* be considered the domains under an organization's control?

>   However, on ports 465 or 587, authentication should be required,
regardless
>   of destination.
>
> If authentication is required on port 25, or no authentication is allowed
on
>   port 465 or 587, someone has misconfigured something.

On Mon, Apr 17, 2023 at 4:58 PM Jaroslaw Rafa via Postfix-users <
postfix-users@postfix.org> wrote:

> Dnia 17.04.2023 o godz. 14:49:11 Noel Jones via Postfix-users pisze:
> > Please keep replies on list.
> >
> > On 4/17/2023 2:16 PM, Tyler Montney wrote:
> > >I'll put it this way, since I'm struggling to word this:
> > >
> > >Provider A contains the following customers:
> > >Acme Corporation (acme.com )
> > >Corley Motors (corley.com )
> > >
> > >Provider B contains the following customers:
> > >ConSec (consec.com )
> > >Teldar Paper (teldar.com )
> > >
> > >f...@acme.com can send to b...@corley.com without authentication.
>
> One important information is missing here: on what port?
>
> There should be no authentication on port 25 and all mail destined for
> local
> domains should be accepted.
>
> There should be mandatory authentication on ports 465/587.
>
> As both acme.com and corley.com are local to provider A, on port 25 any
> mail
> to any of these domains should be accepted, regardless of sender, without
> authentication.
>
> However, on ports 465 or 587, authentication should be required, regardless
> of destination.
>
> If authentication is required on port 25, or no authentication is allowed
> on
> port 465 or 587, someone has misconfigured something.
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "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."
> ___
> 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

[pfx] Re: Open relay clarification

[Jaroslaw Rafa via Postfix-users]

Dnia 17.04.2023 o godz. 14:49:11 Noel Jones via Postfix-users pisze:
> Please keep replies on list.
> 
> On 4/17/2023 2:16 PM, Tyler Montney wrote:
> >I'll put it this way, since I'm struggling to word this:
> >
> >Provider A contains the following customers:
> >Acme Corporation (acme.com )
> >Corley Motors (corley.com )
> >
> >Provider B contains the following customers:
> >ConSec (consec.com )
> >Teldar Paper (teldar.com )
> >
> >f...@acme.com can send to b...@corley.com without authentication.

One important information is missing here: on what port?

There should be no authentication on port 25 and all mail destined for local
domains should be accepted.

There should be mandatory authentication on ports 465/587.

As both acme.com and corley.com are local to provider A, on port 25 any mail
to any of these domains should be accepted, regardless of sender, without
authentication.

However, on ports 465 or 587, authentication should be required, regardless
of destination.

If authentication is required on port 25, or no authentication is allowed on
port 465 or 587, someone has misconfigured something.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"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."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Noel Jones via Postfix-users]

On 4/17/2023 3:59 PM, Tyler Montney via Postfix-users wrote:


That is the purpose of this discussion, to determine what exactly 
this scenario presents. As stated above, Provider A is aware and 
believes it's acceptable. It is acceptable because their 
documentation has features which rely on it. No justification why 
these features require it was given, so their reasoning for initial 
acceptance is poor. To put it another way, it's like RFC-Ignorant. 
You don't HAVE to list a postmaster address, but it's such a small 
gesture to play nice with the rest of the world. Why rely entirely 
on your spam filter (or unknown mitigations) when a common feature 
such as authentication will do the job? Why the risk?


This is a local spam problem.

Report abuse to your provider. If the provider is unwilling or 
unable to fix the abuse, find another provider.



  -- Noel Jones
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Tyler Montney via Postfix-users]

> Please keep replies on list.
>You've explained what's observable, but not why it's a problem.
> Any random server on the internet can send to b...@corley.com without
> authentication. The original sender may or may not authenticate to
> *their* mail server, corley.com cannot control that. So corley.com
> accepts unauthenticated mail all day long.
> How is this different?

"This provider allows unauthenticated SMTP [Provider A] ... I have tried
one of my other larger providers, Provider B, and I was unable to do this
successfully."

In context, I am able to send as anyone to anyone without restriction.
Spoofing is bad. On top of this, a similar provider preventing this implies
a problem.

But if you're attempting to deliver a message to b...@corley.com, why use
"any random server on the internet" when you can tell one of corley's
servers to do it? (This assumes Acme is a supplier of Corley and you're
trying to trick Corley into paying an invoice.) As far as I can tell, there
is no difference between a legitimate message coming from Acme or a
malicious actor spoofing Acme.

> Some providers require all to authenticate, without exception. This
> is generally considered good, but providers may use other methods to
> prevent abuse of their system.

Most messages done in this manner go to spam, so this method could be
considered an alternative. However, that is part of this discussion. Is
something like this acceptable? Why allow a substitution like this at all?
(What are the benefits of making it optional? Doesn't this go against the
nature of standardization?) How does one know when substitution is
acceptable? (In other words, can we be accused of "cherry picking"?)

> I still don't see a problem. If someone has found a way to abuse
> this, then the abuse should be reported to the provider.

That is the purpose of this discussion, to determine what exactly this
scenario presents. As stated above, Provider A is aware and believes it's
acceptable. It is acceptable because their documentation has features which
rely on it. No justification why these features require it was given, so
their reasoning for initial acceptance is poor. To put it another way, it's
like RFC-Ignorant. You don't HAVE to list a postmaster address, but it's
such a small gesture to play nice with the rest of the world. Why rely
entirely on your spam filter (or unknown mitigations) when a common feature
such as authentication will do the job? Why the risk?

On Mon, Apr 17, 2023 at 2:49 PM Noel Jones via Postfix-users <
postfix-users@postfix.org> wrote:

> Please keep replies on list.
>
> On 4/17/2023 2:16 PM, Tyler Montney wrote:
> > I'll put it this way, since I'm struggling to word this:
> >
> > Provider A contains the following customers:
> > Acme Corporation (acme.com )
> > Corley Motors (corley.com )
> >
> > Provider B contains the following customers:
> > ConSec (consec.com )
> > Teldar Paper (teldar.com )
> >
> > f...@acme.com can send to b...@corley.com
> > without authentication.
>
> You've explained what's observable, but not why it's a problem.
> Any random server on the internet can send to b...@corley.com without
> authentication. The original sender may or may not authenticate to
> *their* mail server, corley.com cannot control that. So corley.com
> accepts unauthenticated mail all day long.
> How is this different?
>
> > f...@acme.com
> > must authenticate in order to send to
> > f...@consec.com . Similarly, f...@consec.com
> > must authenticate in order to send to
> > b...@teldar.com .
> >
>
> Some providers require all to authenticate, without exception. This
> is generally considered good, but providers may use other methods to
> prevent abuse of their system.
>
> I still don't see a problem. If someone has found a way to abuse
> this, then the abuse should be reported to the provider.
>
>
>-- Noel Jones
> ___
> 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

[pfx] Re: Open relay clarification

[Noel Jones via Postfix-users]

Please keep replies on list.

On 4/17/2023 2:16 PM, Tyler Montney wrote:

I'll put it this way, since I'm struggling to word this:

Provider A contains the following customers:
Acme Corporation (acme.com )
Corley Motors (corley.com )

Provider B contains the following customers:
ConSec (consec.com )
Teldar Paper (teldar.com )

f...@acme.com can send to b...@corley.com 
without authentication. 


You've explained what's observable, but not why it's a problem.
Any random server on the internet can send to b...@corley.com without 
authentication. The original sender may or may not authenticate to 
*their* mail server, corley.com cannot control that. So corley.com 
accepts unauthenticated mail all day long.

How is this different?

f...@acme.com 
must authenticate in order to send to 
f...@consec.com . Similarly, f...@consec.com 
must authenticate in order to send to 
b...@teldar.com .




Some providers require all to authenticate, without exception. This 
is generally considered good, but providers may use other methods to 
prevent abuse of their system.


I still don't see a problem. If someone has found a way to abuse 
this, then the abuse should be reported to the provider.



  -- Noel Jones
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Noel Jones via Postfix-users]

On 4/17/2023 1:38 PM, Tyler Montney via Postfix-users wrote:


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.


I'm probably missing something... If they're willing to accept 
(unauthenticated) general internet mail from any well-behaved server 
to their customer, what does it matter if it's from another customer?


Sure, most providers require authentication to send any mail, but I 
don't see where this is a problem.


  -- Noel Jones
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org