Re: Rethinking the Postfix release schedule
Daniel Miller: > On 1/29/2019 7:40 AM, Wietse Venema wrote: > > I'm reconsidering the once-per-year schedule for stable releases. > > Basically, a Postfix stable release freezes development at a point > > in time, forever. Primarily, this is good for stability. > > > Are the reasons you imposed a once-per-year release previously lessened > in some way today? The release schedule is far less important than the > quality & usability of the product.? So the question is what works for > you - and what will encourage you to continue making your efforts > available to others? Mainly, I don't want to race to get code ready for the once-per-year release, and I don't want to wait for an entire year if the code is not ready before the deadline. I indent to keep using non-stable (dated) releases for code that I can still change, because that works best for me. Wietse
Re: Rethinking the Postfix release schedule
On 1/29/2019 7:40 AM, Wietse Venema wrote: I'm reconsidering the once-per-year schedule for stable releases. Basically, a Postfix stable release freezes development at a point in time, forever. Primarily, this is good for stability. Are the reasons you imposed a once-per-year release previously lessened in some way today? The release schedule is far less important than the quality & usability of the product. So the question is what works for you - and what will encourage you to continue making your efforts available to others? As a user - I'd prefer releases "when they're ready" regardless of timeline or age. Postfix has the unfortunately unusual record of extreme stability - so as far as I'm concerned if you and those you work with consider a particular revision "stable-worthy" I'd rather you release it instead of waiting an arbitrary time period. Which/how many versions you choose to provide support for is far less important to *me* than seeing continued growth. But knowing that Postfix enjoys a preferred role for many distributions as the SMTP solution of choice I'm assuming you're also concerned about interactions with distro maintainers. So I suggest two possibilities: 1. Similar to Ubuntu - have more frequent "short-term support" releases with designated "long-term support" releases at longer intervals. 2. Re-consider whether arbitrary date-based releases are meaningful at all. Instead, release on the "when they're ready" model and when a combination of reporting frequency and your own sensibilities tell you conditions are right designate a particular release as "long-term stable" - which will probably be close to an annual basis and will hopefully line-up with most distro freeze schedules as well. -- Daniel
Re: Sender address rejected, but I didn't ask it to be checked.
On 1/29/2019 1:51 PM, paiNgoo4 wrote: > Hi, > > I have been using postfix for many years. So far whenever I had a problem, > Google or the documentation helped out. > However today I got stuck and have no idea what to do. > This is a new machine, fresh Debian stretch install. > I am trying to use postfix with virtual users, Dovecot imap and > authentication. I have not used virtual users in the past, so maybe there is > some rookie mistake somewhere. > > I have set up postfix, the machine can receive and send emails. I have set > up dovecot, I can log in and read the emails that I received. But if I try > to submit an email (using thunderbird), I receive the error message: > > postfix/submission/smtpd[13993]: connect from 1270... > postfix/submission/smtpd[13993]: NOQUEUE: reject: RCPT from > 1270.isp.net[xx.xx.xx.xx]: 553 5.7.1 : Sender address > rejected: not owned by user j...@example.com; from= > to= proto=ESMTP helo=<[192.168.0.11]> > postfix/submission/smtpd[13993]: disconnect from 1270.isp.net[xx.xx.xx.xx] > ehlo=2 starttls=1 auth=1 mail=1 rcpt=0/1 quit=1 commands=6/7 > > Google told me that this error message is related to smtpd_sender_login_maps > and smtpd_recipient_restrictions = reject_sender_login_mismatch (in > http://www.postfix.org/SASL_README.html) Your google analysis is correct. > this may be a mistake in the > documentation because according to the > http://www.postfix.org/postconf.5.html page this is a parameter for > smtpd_sender_restrictions. No mistake. As documented, sender restrictions can be used in smtpd_recipient_restrictions. > > So I checked and found that none of these is set. Check for -o overrides in your master.cf submission entry. If you need more help, please see: http://www.postfix.org/DEBUG_README.html#mail -- Noel Jones > # postfix reload > # postconf | grep smtpd_sender > proxy_read_maps = ... $smtpd_sender_login_maps ... > smtpd_sender_login_maps = > smtpd_sender_restrictions = > # postconf | grep smtpd_recipient_restrictions > proxy_read_maps = ... $smtpd_recipient_restrictions > smtpd_recipient_restrictions = > > Sender address rejected: not owned by user > > I thought, OK, so for some reason it is checking it, let's put the > configuration in, with the table, then surely it will work. > But no. > > # postfix reload > # postconf | grep --color smtpd_recipient_restrictions > smtpd_recipient_restrictions = reject_sender_login_mismatch > # postconf | grep --color smtpd_sender > smtpd_sender_login_maps = hash:/etc/postfix/logins > smtpd_sender_restrictions = reject_sender_login_mismatch > /etc/postfix# ls logins* > logins logins.db > /etc/postfix# cat logins > # envelope sender owners (SASL login names) > j...@example.com j...@example.com > > Please tell me, what is it that I can't see. > Thanks > > > > -- > Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html >
Sender address rejected, but I didn't ask it to be checked.
Hi, I have been using postfix for many years. So far whenever I had a problem, Google or the documentation helped out. However today I got stuck and have no idea what to do. This is a new machine, fresh Debian stretch install. I am trying to use postfix with virtual users, Dovecot imap and authentication. I have not used virtual users in the past, so maybe there is some rookie mistake somewhere. I have set up postfix, the machine can receive and send emails. I have set up dovecot, I can log in and read the emails that I received. But if I try to submit an email (using thunderbird), I receive the error message: postfix/submission/smtpd[13993]: connect from 1270... postfix/submission/smtpd[13993]: NOQUEUE: reject: RCPT from 1270.isp.net[xx.xx.xx.xx]: 553 5.7.1 : Sender address rejected: not owned by user j...@example.com; from= to= proto=ESMTP helo=<[192.168.0.11]> postfix/submission/smtpd[13993]: disconnect from 1270.isp.net[xx.xx.xx.xx] ehlo=2 starttls=1 auth=1 mail=1 rcpt=0/1 quit=1 commands=6/7 Google told me that this error message is related to smtpd_sender_login_maps and smtpd_recipient_restrictions = reject_sender_login_mismatch (in http://www.postfix.org/SASL_README.html) this may be a mistake in the documentation because according to the http://www.postfix.org/postconf.5.html page this is a parameter for smtpd_sender_restrictions. So I checked and found that none of these is set. # postfix reload # postconf | grep smtpd_sender proxy_read_maps = ... $smtpd_sender_login_maps ... smtpd_sender_login_maps = smtpd_sender_restrictions = # postconf | grep smtpd_recipient_restrictions proxy_read_maps = ... $smtpd_recipient_restrictions smtpd_recipient_restrictions = Sender address rejected: not owned by user I thought, OK, so for some reason it is checking it, let's put the configuration in, with the table, then surely it will work. But no. # postfix reload # postconf | grep --color smtpd_recipient_restrictions smtpd_recipient_restrictions = reject_sender_login_mismatch # postconf | grep --color smtpd_sender smtpd_sender_login_maps = hash:/etc/postfix/logins smtpd_sender_restrictions = reject_sender_login_mismatch /etc/postfix# ls logins* logins logins.db /etc/postfix# cat logins # envelope sender owners (SASL login names) j...@example.com j...@example.com Please tell me, what is it that I can't see. Thanks -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Rethinking the Postfix release schedule
On Tuesday, January 29, 2019 10:40:37 AM Wietse Venema wrote: > I'm reconsidering the once-per-year schedule for stable releases. > Basically, a Postfix stable release freezes development at a point > in time, forever. Primarily, this is good for stability. > > * In this day and age it seems archaic to have to wait for up to a > year before useful code can be deployed in a stable release. > > * The once-per-year schedule makes development a race to get things > into the upcoming release, so that it does not have to wait for > another year. > > There is a downside to less than a year between stable releases: > the support time window will become less than four years. Currently, > four stable releases are supported, and that is unlikely to change. > > Examples of things that have been ready for months: > > - TLS connection reuse without closing/reconnecting, a big deal for > sites that send many messages, completed in June 2018. > > - BDAT support, requested by a provider, completed in August 2018. > > Things that are ready in ~week, expected to be in Postfix 3.4.0: > > - SNI support is feature and documentation complete. We are polishing > some externally-visible behavior such as message headers and logging. > > - Logging to file or stdout, to work around crippled infrastructure > (MacOS, systemd), or to make Postfix play nice with containers. > This interrupted my work on BURL support (see below). > > Things that we're racing to implement, so that they would not have > to wait until 2020: > > - OpenSSL configuration file support. > > - BURL (submit email without downloading content from IMAP server > first). Reuses most of the BDAT code. > > - And so on. > > A higher release frequency would help to get good code out the door > without having to race against a once-per-year schedule. But, as > mentioned, it also reduces the length of time that a given release > will be supported. >From my perspective as the primary packager for Debian, I think a faster release cycle would possibly have very little impact on us, it mostly depends how much faster. Currently you are supporting releases a bit longer than we need. If you switch to a new release every 9 months, I don't think that would impact us significantly. If you switch to every 6 months, then I would start to worry about supporting Debian stable users properly. Would you consider doing limited support (security fixes only perhaps) for an additional release or two? If so, then I would think even 6 months wouldn't hurt us. It would definitely help with the problem of our freeze schedule being slightly behind the postfix release schedule, so we just miss the newest version. Scott K
Re: Rethinking the Postfix release schedule
* Wietse Venema: > There is a downside to less than a year between stable releases: > the support time window will become less than four years. Personally, I consider Postfix to be among the software packages which are easiest to update (and I build from the sources, since early 2.5.x) because of the outstanding quality. No server of mine or my customers is using four-year-old Postfix versions. From my point of view, a shorter support period is fully acceptable, especially if it means getting useful changes released earlier. -Ralph
Re: Rethinking the Postfix release schedule
On 29.01.19 16:40, Wietse Venema wrote: > A higher release frequency would help to get good code out the door > without having to race against a once-per-year schedule. But, as > mentioned, it also reduces the length of time that a given release > will be supported. IMO not much of a problem, the usual LTS distributions will offer longer support cycles for those that really need it anyway (for varying values of "support"). signature.asc Description: OpenPGP digital signature
Rethinking the Postfix release schedule
I'm reconsidering the once-per-year schedule for stable releases. Basically, a Postfix stable release freezes development at a point in time, forever. Primarily, this is good for stability. * In this day and age it seems archaic to have to wait for up to a year before useful code can be deployed in a stable release. * The once-per-year schedule makes development a race to get things into the upcoming release, so that it does not have to wait for another year. There is a downside to less than a year between stable releases: the support time window will become less than four years. Currently, four stable releases are supported, and that is unlikely to change. Examples of things that have been ready for months: - TLS connection reuse without closing/reconnecting, a big deal for sites that send many messages, completed in June 2018. - BDAT support, requested by a provider, completed in August 2018. Things that are ready in ~week, expected to be in Postfix 3.4.0: - SNI support is feature and documentation complete. We are polishing some externally-visible behavior such as message headers and logging. - Logging to file or stdout, to work around crippled infrastructure (MacOS, systemd), or to make Postfix play nice with containers. This interrupted my work on BURL support (see below). Things that we're racing to implement, so that they would not have to wait until 2020: - OpenSSL configuration file support. - BURL (submit email without downloading content from IMAP server first). Reuses most of the BDAT code. - And so on. A higher release frequency would help to get good code out the door without having to race against a once-per-year schedule. But, as mentioned, it also reduces the length of time that a given release will be supported. Wietse
Re: It is possible for Postfix logging to bypass journald?
Curtis: > On 1/9/2019 5:55 PM, Robert L Mathews wrote: > > On 1/9/19 4:05 PM, Curtis wrote: > >> We recently switched our Postfix mail servers to Ubuntu Server 18, which > >> uses journald for logging. Since we have monitoring systems that parse > >> /var/log/maillog, we enabled rsyslog with imuxsock so we still can parse > >> the log like we did before journald.? But, it's unreliable. Postfix 3.4 will have support for logging to file and to stdout. Otherwise, Postfix uses the syslog function, part of the system library; Postfix has no control over where that library sends its data. You may be able to tell systemd to keep its hands off the syslog socket, in which case rsyslogd can do it job. Wietse
