[pfx] Re: Open relay clarification
> 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 58
[pfx] Re: Open relay clarification
> 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 m
[pfx] Re: Open relay clarification
> 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 <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. > > 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
> 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
[pfx] Open relay clarification
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. 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? 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. 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 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]. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: Setting up virtual mail users
I really gotta remember to reply all. Here's what was between Bobby and I: Here: Home-less Users Having a home directory for users is highly recommended. At a minimum, the Pigeonhole Sieve plugin requires a home directory to work. See Home Directories for Virtual Users for more reasons why it’s a good idea, and how to give Dovecot a home directory even if you don’t have a “real home directory”. If you really don’t want to set any home directory, you can use something like: mail_location = maildir:/home/%u/Maildir https://doc.dovecot.org/configuration_manual/mail_location/ Hide quoted text On Sat, Dec 4, 2021 at 12:34 PM Tyler Montney wrote: > reading in the documentation that user home folders are highly recommended Who (Dovecot or Postfix) and where? As for my configuration, I use /srv/vmail. Just personal preference. Assuming we're talking about using /home/%u, I wouldn't do that because I expect shell users to be there. (It might even go against convention for Linux.) If I'm wrong, someone else correct me as I'm interested to know. On Sat, Dec 4, 2021 at 10:30 AM bobby wrote: I was not planning on using Postfix admin. I would like to go the Virtual Users route... but I was reading in the documentation that user home folders, even for virtual, are highly recommended. Is this true? On Sat, Dec 4, 2021 at 11:14 AM Tyler Montney wrote: I'm confused, are you looking to support virtual users *and* local users, or is this about "only being available via Postfix admin"?
Re: RCPT info in logging
For 3.6.2 (from source) may influence this, but I am seeing enough to identify without any change in mail.log: > Nov 25 18:57:01 mail postfix/smtpd[2814]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 450 4.7.1 : Helo command rejected: Host not found; from= to= proto=ESMTP helo= However, adding "debug_peer_list = 127.0.0.1" to main.cf generates a LOT more content, including all responses sent to and from.
Re: RCPT info in logging
Not a direct answer but the domain in question has an Email verification API. They are definitely probing for valid users. I wonder if there's ever a valid use case for this. However, if you wanted to allow you would just enable the VERIFY feature. On Thu, Nov 25, 2021, 12:19 PM wrote: > I am guessing when this happens: > >postfix/smtpd[879005]: connect from smtpout79.briteverify.com > [54.175.215.209] >postfix/smtpd[879005]: 4J0QTC1PzHz4l3gS: client= > smtpout79.briteverify.com[54.175.215.209] >postfix/smtpd[879005]: disconnect from > smtpout79.briteverify.com[54.175.215.209] > helo=1 mail=1 rcpt=1 quit=1 commands=4 > > They are probing for valid usernames. Is there a way to have it output in > the logs what RCPT address they supplied? >
Re: Various questions about Postfix
Missed this one: > message_size_limit = 52428800 > virtual_mailbox_limit = 524288 > > message_size_limit needs to be less than or equal to > virtual_mailbox_limit. Your virtual_mailbox_limit is > 100 times message_size_limit. Not intentional, definitely a typo. I think early on I saw mailbox_size_limit and thought that's what I wanted.
Re: Various questions about Postfix
"You seem to be explicitly setting many parameters to their defaults." I removed a bunch, but might have missed some. That "command_directory" parameter I definitely didn't set. I think that's a result of building from source. "You have the address mappings happening before, which means that the filter doesn't have access to the original addresses." I was unaware entirely. I'm thinking I probably want the original addresses? "I don't know what the milter on port 11332 is doing" Believe that's rspamd. "But I expect that you understand this much better than I do" I've gotten into "from scratch" mail hosting a couple months back. I've done all I can to learn before asking questions. I want to know the reason why I put each line of config. "Removing $myhostname from mydestination looks unusual to me. I assume there's a good reason" That was early on in my research. Believe it had something to do with Postfix saying my LDAP user didn't exist. Removing it allowed delivery. "This can lead to your mail server transmitting email unencrypted" In my effort to be a little less flexible (to get more encryption), it seems I'll do the opposite. I'll change that. Speaking of which... smtp_tls_mandatory_protocols smtp_tls_protocol What is the difference between these two? I've read the docs but it didn't help. "then you could make Postfix DANE-aware and avoid falling prey to man-in-the-middle attack" Going to have to brush up on this. I have my AD PDC running DNS. Does it have to be localhost or can it be LAN? "You might want to add "silent-discard" to the above to suppress warnings in your log files about it." Good call, I was noticing that a bit. I'm sure when it goes into production that error would've annoyed me. "I assume port 10023 is running Postgrey." Correct. "smtpd_sasl_auth_enable shouldn't be in main.cf." Ah, because that would set the default across everything and we prefer it on 587. "That limits authentication attempts (successful or not" Do you have a specific recommendation on anvil or just pointing out what that parameter does? "you eliminate the chance of a race condition when Postfix reads the new key and chain" Race condition on renewal? If this happened, what would the effects look like? An untrusted certificate until I reload? "if you set up a renewal hook that executes a script like this" Thanks, saves me some work. "It's best not to disable_dns_lookups. The Amavis guide says to do it" It's tough to find much of anything on Amavis. Nowhere near as documented as Postfix and Dovecot. Is it still a good one to go with? "Yep." Does this mean "ditto" or "OK don't change"? "you might also want to add SPF checking" I did have 'postfix-policyd-spf-perl' but noticed OpenDMARC offers SPF. I have it set to always check even if the headers are provided. Or am I misunderstanding? Thanks for taking the time to review this. I feel confident now in putting it online (after I make a few of your adjustments).
Re: Various questions about Postfix
virtual lmtp unix - - y - - lmtp anvil unix - - y - 1 anvil scache unix - - y - 1 scache postlogunix-dgram n - n - 1 postlogd smtp-amavis unix - - n - 2 smtp -o syslog_name=postfix/amavis -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 -o smtp_tls_security_level=none 127.0.0.1:10025 inet n - n - - smtpd -o syslog_name=postfix/10025 -o content_filter= -o mynetworks_style=host -o mynetworks=127.0.0.0/8 -o local_recipient_maps= -o relay_recipient_maps= -o strict_rfc821_envelopes=yes -o smtp_tls_security_level=none -o smtpd_tls_security_level=none -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_end_of_data_restrictions= -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings On Sun, Oct 17, 2021 at 6:25 PM raf wrote: > On Fri, Oct 15, 2021 at 12:20:55PM -0500, Tyler Montney < > montneyty...@gmail.com> wrote: > > > One other thing while I wait... > > > > Once I'm done researching (in a week or two), I'd like someone to > provide a > > sanity check on my Postfix config by posting it here. Is that allowed? > > Sure. When you're ready, post the output of "postconf -nf" and "postconf > -Mf". > > cheers, > raf > >
Re: Various questions about Postfix
One other thing while I wait... Once I'm done researching (in a week or two), I'd like someone to provide a sanity check on my Postfix config by posting it here. Is that allowed? On Fri, Oct 15, 2021 at 1:13 AM Viktor Dukhovni wrote: > On Fri, Oct 15, 2021 at 12:53:03AM -0500, Tyler Montney wrote: > > > Perfect, all of that makes sense. Here's 3 more: > > You might try the book by Patrick and Ralf, the basics haven't changed. > > >- The way I understand master.cf is that it spins up services. > > On demand, unless some idle instances of the service are already up and > running and waiting for requests. > > >For instance, the smtpd service to accept incoming connections on > >port 25, > > These spin up on demand and exit after a number of requests or when idle > too long. A lightly loaded system might not have any running much of > the time. > > >or qmgr that handles the various queues (like active and deferred). > > The qmgr(8) daemon runs indefinitely, until a "stop" or "reload". > > >For other services that wish to interact with say 'verify', how do > >they do this? > > By connecting to the service socket. > > >Would it be accurate to compare it to an HTTP routing table? > > The inetd(8) service and inetd.conf file is a better analogy. > > >They call postfix with the service name, and in turn get the > >executed command? > > No. They connect to the relevant public or private socket, and the > service is started if not already running or busy and the process limit > has not been reached. > > >- Why are Postfix manual pages for these services identical? > > - smtp/lmtp > > Same program implements multiple services. > > > - bounce/defer/trace > > Same program implements multiple services. > > >- Is there any documentation for the service 'relay'? > > It is an smtp(8) transport, see smtp(8) and ADDRESS_CLASS_README. > > For more basic background questions, let Patrick and Ralf earn some > royalties, and: > > http://www.postfix.org/OVERVIEW.html > http://www.postfix.org/BASIC_CONFIGURATION_README.html > http://www.postfix.org/STANDARD_CONFIGURATION_README.html > > and other documents at: > > http://www.postfix.org/documentation.html > > -- > Viktor. > On Fri, Oct 15, 2021 at 1:13 AM Viktor Dukhovni wrote: > On Fri, Oct 15, 2021 at 12:53:03AM -0500, Tyler Montney wrote: > > > Perfect, all of that makes sense. Here's 3 more: > > You might try the book by Patrick and Ralf, the basics haven't changed. > > >- The way I understand master.cf is that it spins up services. > > On demand, unless some idle instances of the service are already up and > running and waiting for requests. > > >For instance, the smtpd service to accept incoming connections on > >port 25, > > These spin up on demand and exit after a number of requests or when idle > too long. A lightly loaded system might not have any running much of > the time. > > >or qmgr that handles the various queues (like active and deferred). > > The qmgr(8) daemon runs indefinitely, until a "stop" or "reload". > > >For other services that wish to interact with say 'verify', how do > >they do this? > > By connecting to the service socket. > > >Would it be accurate to compare it to an HTTP routing table? > > The inetd(8) service and inetd.conf file is a better analogy. > > >They call postfix with the service name, and in turn get the > >executed command? > > No. They connect to the relevant public or private socket, and the > service is started if not already running or busy and the process limit > has not been reached. > > >- Why are Postfix manual pages for these services identical? > > - smtp/lmtp > > Same program implements multiple services. > > > - bounce/defer/trace > > Same program implements multiple services. > > >- Is there any documentation for the service 'relay'? > > It is an smtp(8) transport, see smtp(8) and ADDRESS_CLASS_README. > > For more basic background questions, let Patrick and Ralf earn some > royalties, and: > > http://www.postfix.org/OVERVIEW.html > http://www.postfix.org/BASIC_CONFIGURATION_README.html > http://www.postfix.org/STANDARD_CONFIGURATION_README.html > > and other documents at: > > http://www.postfix.org/documentation.html > > -- > Viktor. >
Re: Various questions about Postfix
I'll give that book a try and return to this thread with any remaining questions. On Fri, Oct 15, 2021, 1:13 AM Viktor Dukhovni wrote: > On Fri, Oct 15, 2021 at 12:53:03AM -0500, Tyler Montney wrote: > > > Perfect, all of that makes sense. Here's 3 more: > > You might try the book by Patrick and Ralf, the basics haven't changed. > > >- The way I understand master.cf is that it spins up services. > > On demand, unless some idle instances of the service are already up and > running and waiting for requests. > > >For instance, the smtpd service to accept incoming connections on > >port 25, > > These spin up on demand and exit after a number of requests or when idle > too long. A lightly loaded system might not have any running much of > the time. > > >or qmgr that handles the various queues (like active and deferred). > > The qmgr(8) daemon runs indefinitely, until a "stop" or "reload". > > >For other services that wish to interact with say 'verify', how do > >they do this? > > By connecting to the service socket. > > >Would it be accurate to compare it to an HTTP routing table? > > The inetd(8) service and inetd.conf file is a better analogy. > > >They call postfix with the service name, and in turn get the > >executed command? > > No. They connect to the relevant public or private socket, and the > service is started if not already running or busy and the process limit > has not been reached. > > >- Why are Postfix manual pages for these services identical? > > - smtp/lmtp > > Same program implements multiple services. > > > - bounce/defer/trace > > Same program implements multiple services. > > >- Is there any documentation for the service 'relay'? > > It is an smtp(8) transport, see smtp(8) and ADDRESS_CLASS_README. > > For more basic background questions, let Patrick and Ralf earn some > royalties, and: > > http://www.postfix.org/OVERVIEW.html > http://www.postfix.org/BASIC_CONFIGURATION_README.html > http://www.postfix.org/STANDARD_CONFIGURATION_README.html > > and other documents at: > > http://www.postfix.org/documentation.html > > -- > Viktor. >
Re: Various questions about Postfix
Perfect, all of that makes sense. Here's 3 more: - The way I understand master.cf is that it spins up services. For instance, the smtp(d) service to accept incoming connections on port 25, or qmgr that handles the various queues (like active and deferred). For other services that wish to interact with say 'verify', how do they do this? Would it be accurate to compare it to an HTTP routing table? They call postfix with the service name, and in turn get the executed command? - Why are Postfix manual pages for these services identical? - smtp/lmtp - bounce/trace - Is there any documentation for the service 'relay'? On Fri, Oct 15, 2021 at 12:25 AM Viktor Dukhovni wrote: > On Fri, Oct 15, 2021 at 12:15:23AM -0500, Tyler Montney wrote: > > > So by private, you mean services that end users shouldn't be able to > > interact with? Public services have CLI tools (as an interface) whereas > > private ones do not. > > Yes. > > > For wakeup, why would a service need wake up timer? It has no active > > requests so what is it doing when being woke? Perhaps some kind of > > maintenance tasks? > > Services that need to run periodic maintenance tasks are periodically > woken up by the "master" service. The stock master.cf file has > reasonable settings for their wakeup timers. > > For example, the pickup service periodically scans the "maildrop" queue, > just in case Postfix was down when a local message was submitted, or > postdrop(1) failed to notify the pickup(8) service for some reason. > > Similary, qmgr(8) periodically rescans the deferred and incoming queues. > ... > > -- > Viktor. >
Re: Various questions about Postfix
Thank you. So by private, you mean services that end users shouldn't be able to interact with? Public services have CLI tools (as an interface) whereas private ones do not. For wakeup, why would a service need wake up timer? It has no active requests so what is it doing when being woke? Perhaps some kind of maintenance tasks? On Thu, Oct 14, 2021, 11:45 PM Viktor Dukhovni wrote: > On Thu, Oct 14, 2021 at 09:12:40PM -0500, Tyler Montney wrote: > > > I am doing a deep dive on mail hosting and this includes Postfix. I have > > quite a number of questions about Postfix. Is this the best place to get > > those answered? > > > > To give a sample: > > > >- What does 'private' mean for master.cf? Documentation is quite > scarce. > >I can tell it doesn't apply to inet, but how does that affect other > service > >types? > > Internal services, including all mail transports are private. The > public services are in aid of command-line tools like postdrop(1) > and postqueue(1) to allow local users to interact with a small > set of special services. > > >- For unprivileged (master.cf again) > > - "root privileges or as the owner": Is this the same permissions > > level? What is an example of "the owner"? > > The only services that need retain privileges after pre-jail > initialisation are local(8), virtual(8) and pipe(8), because they > subsequently need to be able to switch to an appropriate uid/gid. > > Otherwise, services should drop privileges. > > >- If a service is unprivileged, who does it run as? > > It runs as $mail_owner (typically "postfix"). > > >- What makes a service 'sleep'? (referring to 'wakeup') > > Not having any active requests. Only specific services > need wakeup. If it does not have a wakeup timer in the > stock master.cf, then no wakeup should be specified, > otherwise there should be a wakeup. > > The services that need wakeup are: > > - qmgr > - pickup > - tlsmgr > - flush > > The last of these is only needed if you support ETRN, which > I generally disable and set "fast_flush_domains" empty if > not empty by default (because relay_domains is empty). > > -- > Viktor. >
Various questions about Postfix
I am doing a deep dive on mail hosting and this includes Postfix. I have quite a number of questions about Postfix. Is this the best place to get those answered? To give a sample: - What does 'private' mean for master.cf? Documentation is quite scarce. I can tell it doesn't apply to inet, but how does that affect other service types? - For unprivileged (master.cf again) - "root privileges or as the owner": Is this the same permissions level? What is an example of "the owner"? - If a service is unprivileged, who does it run as? - What makes a service 'sleep'? (referring to 'wakeup')
