> 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 <http://acme.com>) > > Corley Motors (corley.com <http://corley.com>) > > > > Provider B contains the following customers: > > ConSec (consec.com <http://consec.com>) > > Teldar Paper (teldar.com <http://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
