[pfx] Re: IPv6 and Cloud server CPU
On 23/11/23 17:20, Peter via Postfix-users wrote: On 23/11/23 14:22, Gerald Galster via Postfix-users wrote: Q2: given the minuscule work-load, is there any preference/preclusion between employing the 'usual' x86 processor or 2 Arm Ampere processors? Both offer Linux. Cost is effectively same. You should check if the software you want to use is available for the desired platform. Distributions might provide dovecot packages for ARM while the official dovecot repository might not. Then you would have to compile the sources yourself. This ^. Specifically if you want to run an EL distro there are good choices that offer ARM support and come with stock postfix and dovecot packages, but if you want to run the GhettoForge packages (which have newer versions of Postfix and Dovecot than that offered by the stock distros) then I'm afraid you're stuck with x86_64 for now. Similarily you might have issues with other supporting software that is only available from 3rd-party repos or where 3rd-party repos have newer versions taht you want to use, but not for ARM. Yes, I was following-through with the earlier advice, and noted the same. No, I'm content with being part of the herd (as distinct from using Hurd), preferring stability and knowing that reliability can be hard-won! I'm torn between RHEL (as a developer-member they give me numbers of $0 licenses), and one of the lighter rpm/yum/dnf distros. The former has a stated commitment to Arm CPUs - which means I could (relatively) easily set-up a server and try a load-test... Further to earlier comments, re: distress at being forced to upgrade: in the interests of fairness it is a previous major-version of Postfix running on an older CentOS. (not mentioned because I'd deserve any pointed criticism!) 'The plan' presumed that the hardest part of the process would be going through the docs to see what needed to be removed/changed and to take advantage of improved services - TLS/encryption first out of the gate. Following personal recommendations (from elsewhere), I was looking at a couple of the 'super-packages' which bundle Postfix, Dovecot, and RDBMS, in with a bunch of 'other stuff'. The virtues of Containers to the fore. However, most would require perhaps twice the RAM that my existing combination doesn't even fully occupy (thus marginal-cost/benefit implication). New to me was Docker Mailserver. This appears to be more cut-down, but also gives (me) the impression that main.cf and master.cf are either hidden-away or totally-inaccessible. Nr1 difference is 'no RDBMS', which I guess I could live-with (am quite at-home with SQL and such) and don't need it for (eg) the web-site side of things, so... Do you have experience using this package? (is it sufficiently "Postfix" to be suitable conversation on this list?) -- Regards =dn ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: No messages from freebsd.org
On Thu, Nov 23, 2023 at 05:44:47AM +0100, Jack Raats wrote: > You're absolutely right. I am ashamed that I didn't think that DANE was > perhaps the problem > Short term solution was to delete the TLSA record from the DNS. > After deleting the TLSA record the mails are getting in. So, you'll finally implement monitoring, right??? It isn't particularly difficult: https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html Or will the FreeBSD list your monitoring "canary"? :-) -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: No messages from freebsd.org
Oeepppss You're absolutely right. I am ashamed that I didn't think that DANE was perhaps the problem Short term solution was to delete the TLSA record from the DNS. After deleting the TLSA record the mails are getting in. Thank you! Gr. Jack Raats Op 23-11-2023 om 05:28 schreef Viktor Dukhovni via Postfix-users: On Thu, Nov 23, 2023 at 04:32:02AM +0100, Jack Raats via Postfix-users wrote: Can anyone help me to address the following problem. I'm receiving messages from the dovecot and postfix mailinglist. I can get mail from gmail etc. but not from the freebsd mailing lists. I get the following in maillog Nov 23 04:23:43 nl postfix/smtpd[2135]: connect from mx2.freebsd.org[2610:1c1:1:606c::19:2] Nov 23 04:23:44 nl postfix/smtpd[2135]: Anonymous TLS connection established from mx2.freebsd.org[2610:1c1:1:606c::19:2]: TLSv1.3 with cipher TLS_AES_256_GCM> Nov 23 04:23:44 nl postfix/smtpd[2135]: disconnect from mx2.freebsd.org[2610:1c1:1:606c::19:2] ehlo=1 starttls=1 quit=1 commands=3 Not surprising, given: https://stats.dnssec-tools.org/explore/?netnl.net I sent a note on Nov 1th to: Subject: netnl.net: SMTP server DNS (DANE TLSA record) issue Perhaps that's wasn't a good choice of contact address. I can only try... I really don't understand users who deploy DANE (or any other security technology) without implementing monitoring. Magical thinking that nothing could possibly go wrong? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: No messages from freebsd.org
On Thu, Nov 23, 2023 at 04:32:02AM +0100, Jack Raats via Postfix-users wrote: > Can anyone help me to address the following problem. > > I'm receiving messages from the dovecot and postfix mailinglist. I can get > mail from gmail etc. but not from the freebsd mailing lists. > > I get the following in maillog > > Nov 23 04:23:43 nl postfix/smtpd[2135]: connect from >mx2.freebsd.org[2610:1c1:1:606c::19:2] > Nov 23 04:23:44 nl postfix/smtpd[2135]: Anonymous TLS connection >established from mx2.freebsd.org[2610:1c1:1:606c::19:2]: TLSv1.3 with >cipher TLS_AES_256_GCM> > Nov 23 04:23:44 nl postfix/smtpd[2135]: disconnect from >mx2.freebsd.org[2610:1c1:1:606c::19:2] ehlo=1 starttls=1 quit=1 commands=3 Not surprising, given: https://stats.dnssec-tools.org/explore/?netnl.net I sent a note on Nov 1th to: Subject: netnl.net: SMTP server DNS (DANE TLSA record) issue Perhaps that's wasn't a good choice of contact address. I can only try... I really don't understand users who deploy DANE (or any other security technology) without implementing monitoring. Magical thinking that nothing could possibly go wrong? -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IPv6 and Cloud server CPU
On 23/11/23 14:22, Gerald Galster via Postfix-users wrote: Q2: given the minuscule work-load, is there any preference/preclusion between employing the 'usual' x86 processor or 2 Arm Ampere processors? Both offer Linux. Cost is effectively same. You should check if the software you want to use is available for the desired platform. Distributions might provide dovecot packages for ARM while the official dovecot repository might not. Then you would have to compile the sources yourself. This ^. Specifically if you want to run an EL distro there are good choices that offer ARM support and come with stock postfix and dovecot packages, but if you want to run the GhettoForge packages (which have newer versions of Postfix and Dovecot than that offered by the stock distros) then I'm afraid you're stuck with x86_64 for now. Similarily you might have issues with other supporting software that is only available from 3rd-party repos or where 3rd-party repos have newer versions taht you want to use, but not for ARM. Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] No messages from freebsd.org
Can anyone help me to address the following problem. I'm receiving messages from the dovecot and postfix mailinglist. I can get mail from gmail etc. but not from the freebsd mailing lists. I get the following in maillog Nov 23 04:23:43 nl postfix/smtpd[2135]: connect from mx2.freebsd.org[2610:1c1:1:606c::19:2] Nov 23 04:23:44 nl postfix/smtpd[2135]: Anonymous TLS connection established from mx2.freebsd.org[2610:1c1:1:606c::19:2]: TLSv1.3 with cipher TLS_AES_256_GCM> Nov 23 04:23:44 nl postfix/smtpd[2135]: disconnect from mx2.freebsd.org[2610:1c1:1:606c::19:2] ehlo=1 starttls=1 quit=1 commands=3 Nov 23 04:23:44 nl postfix/smtpd[2135]: connect from mx2.freebsd.org[96.47.72.81] Nov 23 04:23:44 nl postfix/smtpd[2135]: Anonymous TLS connection established from mx2.freebsd.org[96.47.72.81]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (2> Nov 23 04:23:44 nl postfix/smtpd[2135]: disconnect from mx2.freebsd.org[96.47.72.81] ehlo=1 starttls=1 quit=1 commands=3 Is the problem at my mailserver or at the freebsd mailserver?? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IPv6 and Cloud server CPU
> On Nov 22, 2023, at 8:15 PM, DL Neil via Postfix-users > wrote: > > So, there's no particular advantage to staying with the traditional x86-style > model, nor to moving to the newer Arm-based offerings? It seems like some vendors really want to push ARM and a side-effect of that might be more bang for your buck. I'm sure plenty of folks still only want to run on x86 or are running something with spotty ARM support for 3rd party packages and they might be convinced with some savings to try ARM... For example, Oracle is offering a free tier that's way, way more generous than others, but only on their ARM servers. If you can get an account there, that's certainly an option. (I'll note I tried with 4 different personal cards and 3 different biz cards both debit and credit to sign up and their "anti-fraud" stuff won't let me in, so YMMV in setting up an account there). Charles > > Linux is offered on both, but am wondering if there is possibly some > processor to work-load (mis-)matching beyond my understanding... > > (yes, appreciate the irony that the concern may be 'efficiency' - despite the > fact that the Postfix server is by no means challenging current capabilities > - and the Cloud-Host assures me that the (two) new choices offer superior > performance to the existing set-up) > > Yes, understand that if one is sharing with some 'hog', our under-average > demands will still be disadvantaged by the averaging-algorithm. However, it's > cheap 'n cheerful... > > > -- > Regards =dn > ___ > 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: IPv6 and Cloud server CPU
> Q2: > given the minuscule work-load, is there any preference/preclusion between > employing the 'usual' x86 processor or 2 Arm Ampere processors? Both offer > Linux. Cost is effectively same. You should check if the software you want to use is available for the desired platform. Distributions might provide dovecot packages for ARM while the official dovecot repository might not. Then you would have to compile the sources yourself. Rspamd uses hyperscan, a high performance regular expression library by Intel that does not run on ARM (IIRC). There are forks like Vectorscan that might not run stable yet. In general Linux runs smooth on both platforms, it depends more on your particular needs. > Bonus Q: (sheer curiosity) > Might the latter answer change in a 'real' enterprise environment? Currently ARM processors often outperform x86 in terms of performance per watt which is interesting for hosting/cloud providers, especially in countries where electricity got quite pricey due to green energy transformation regulations. Moreover Ampere processors bundle lots of cores which is good for load that can be distributed whereas x86 processors with fewer cores but higher frequency might be better suited for latency-sensitive applications. Best regards, Gerald ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IPv6 and Cloud server CPU
On 23/11/23 11:56, Wietse Venema via Postfix-users wrote: DL Neil via Postfix-users: Slightly off-topic. My bottom-of-the-line VPS is being deprecated. Making me grumpy because it has been working so well (+updates) for all these years! ... Q1: can an email server be run off IPv6 (exclusively) these days, or are IPv4 + v6 alternatives necessary? You need IPv4, if you have remote users. IPv6 would be fine for internal usage, though. Thank you (both). Q2: given the minuscule work-load, is there any preference/preclusion between employing the 'usual' x86 processor or 2 Arm Ampere processors? Both offer Linux. Cost is effectively same. You mentioned a VPS, which means shared hardware, i.e. unused CPU resources are not really unused, they can be used by someone else. So, there's no particular advantage to staying with the traditional x86-style model, nor to moving to the newer Arm-based offerings? Linux is offered on both, but am wondering if there is possibly some processor to work-load (mis-)matching beyond my understanding... (yes, appreciate the irony that the concern may be 'efficiency' - despite the fact that the Postfix server is by no means challenging current capabilities - and the Cloud-Host assures me that the (two) new choices offer superior performance to the existing set-up) Yes, understand that if one is sharing with some 'hog', our under-average demands will still be disadvantaged by the averaging-algorithm. However, it's cheap 'n cheerful... -- Regards =dn ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IPv6 and Cloud server CPU
DL Neil via Postfix-users: > Slightly off-topic. > > My bottom-of-the-line VPS is being deprecated. Making me grumpy because > it has been working so well (+updates) for all these years! > > Very low volume Postfix/Dovecot for a half-dozen domains, plus a > rarely-used Apache serving only static pages, and the occasional > code-example download for our user group, ie spends most of the day > at-idle and rarely exceeds 50% load. > > Have been offered choice of more-modern Cloud-VPS systems, and two > addressing options: > > Q1: > can an email server be run off IPv6 (exclusively) these days, or are > IPv4 + v6 alternatives necessary? You need IPv4, if you have remote users. IPv6 would be fine for internal usage, though. > Q2: > given the minuscule work-load, is there any preference/preclusion > between employing the 'usual' x86 processor or 2 Arm Ampere processors? > Both offer Linux. Cost is effectively same. You mentioned a VPS, which means shared hardware, i.e. unused CPU resources are not really unused, they can be used by someone else. > Bonus Q: (sheer curiosity) > Might the latter answer change in a 'real' enterprise environment? I expect that will depend on the kind of workloads that will be running on that shared infrastructure. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IPv6 and Cloud server CPU
Dnia 23.11.2023 o godz. 11:16:42 DL Neil via Postfix-users pisze: > Q1: > can an email server be run off IPv6 (exclusively) these days, or are > IPv4 + v6 alternatives necessary? Not possible to use IPv6 only server for any purpose. There are still a LOT of sites that run IPv4 only, and end users (in case of web server, you mentioned Apache) that can use IPv4 only. -- 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] IPv6 and Cloud server CPU
Slightly off-topic. My bottom-of-the-line VPS is being deprecated. Making me grumpy because it has been working so well (+updates) for all these years! Very low volume Postfix/Dovecot for a half-dozen domains, plus a rarely-used Apache serving only static pages, and the occasional code-example download for our user group, ie spends most of the day at-idle and rarely exceeds 50% load. Have been offered choice of more-modern Cloud-VPS systems, and two addressing options: Q1: can an email server be run off IPv6 (exclusively) these days, or are IPv4 + v6 alternatives necessary? Q2: given the minuscule work-load, is there any preference/preclusion between employing the 'usual' x86 processor or 2 Arm Ampere processors? Both offer Linux. Cost is effectively same. Bonus Q: (sheer curiosity) Might the latter answer change in a 'real' enterprise environment? -- Regards, =dn ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to temporarily pause virtual mail delivery?
Ralph Seichter via Postfix-users: > * Viktor Dukhovni via Postfix-users: > > > https://www.postfix.org/postconf.5.html#defer_transports > > Indeed. In my backup scripts, I like to use something like the following > (from memory only, beware of possible typos): > > postconf -e defer_transports=lmtp,local,virtual && postfix reload > > Now that I think of it again, I wonder if the reload command is even > necessary? Yes, because it is implemented in the queue manager which is a long-running process. If you use defer_transports to freeze mail deliveries, then some messages may get close to the bounce_queue_lifetime, meaning that Postfix will try to deliver them only once. To avoid that, use "postsuper -r ALL" to create new queue files. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to temporarily pause virtual mail delivery?
On Wed, Nov 22, 2023 at 09:36:31PM +0100, Ralph Seichter via Postfix-users wrote: > * Viktor Dukhovni via Postfix-users: > > > https://www.postfix.org/postconf.5.html#defer_transports > > Indeed. In my backup scripts, I like to use something like the following > (from memory only, beware of possible typos): > > postconf -e defer_transports=lmtp,local,virtual && postfix reload > > Now that I think of it again, I wonder if the reload command is even > necessary? If you understand: https://www.postfix.org/OVERVIEW.html#delivering and have read: https://www.postfix.org/qmgr.8.html you'll know the answer. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to temporarily pause virtual mail delivery?
* Viktor Dukhovni via Postfix-users: > https://www.postfix.org/postconf.5.html#defer_transports Indeed. In my backup scripts, I like to use something like the following (from memory only, beware of possible typos): postconf -e defer_transports=lmtp,local,virtual && postfix reload Now that I think of it again, I wonder if the reload command is even necessary? -Ralph ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to temporarily pause virtual mail delivery?
Matthias Nagel via Postfix-users wrote in <12336799.O9o76ZdvQC@matthias-pc>: |Am Mittwoch, 22. November 2023, 19:01:23 CET schrieb postfix--- via \ |Postfix-users: |>> I am looking for an option to temporarily pause delivery via LMTP \ |>> and defer mail while the Dovecot mailboxes are being backed-up in \ |>> order to get an consistent state. |> |> Just take dovecot LMTP offline. Isn't the default behavior of postfix \ |> to queue undeliverable mail and once its able to deliver, it will? \ |> No need to bounce public mail with a 4xx error. Use a filesystem with snapshot capabilities like ZFS or BTRFS. More can it now, on FreeBSD for example UFS, on DragonFly Hammer. Then copy from the snapshot, and remove the snapshot. Or base your entire backup strategy on filesystem snapshots, that is the road i went. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: www.postfix.org outage
* Bill Cole via Postfix-users: >> I am positive that I personally rebooted this server a number of times >> following Kernel updates, the last of which happened not long ago. ;-) > > If there's a virtualization layer, they are likely to be referring to > the real physical host rather than the VM running the Postfix site. I rent physical hardware for this particular server. At least that is what I see on my monthly bill. ;-) There are steps in the boot process over which I have no direct control, and rightly so. Those provide, for example, the option to boot a so-called rescue system over the hoster's internal network. Local boot from the server's storage drives happens later, or does not happen, as was the case yesterday. -Ralph ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to temporarily pause virtual mail delivery?
On Wed, Nov 22, 2023 at 07:32:06PM +, Matthias Nagel via Postfix-users wrote: > Am Mittwoch, 22. November 2023, 19:01:23 CET schrieb postfix--- via > Postfix-users: > > > I am looking for an option to temporarily pause delivery via LMTP and > > > defer mail while the Dovecot mailboxes are being backed-up in order to > > > get an consistent state. > > > > Just take dovecot LMTP offline. Isn't the default behavior of postfix to > > queue undeliverable mail and once its able to deliver, it will? No need to > > bounce public mail with a 4xx error. > > > > I don‘t want to bounce the mail publicly. I want Postfix to take it out of > the active queue, put it into the deferred queue (on the *same* mail server) > and Postfix shall attempt to re-deliver it later on. > > Taking Dovecot LMTP offline doesn‘t seem to be that easy either. So I was > looking for an alternative on the Postfix side. https://www.postfix.org/postconf.5.html#defer_transports -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to temporarily pause virtual mail delivery?
Am Mittwoch, 22. November 2023, 19:01:23 CET schrieb postfix--- via Postfix-users: > > I am looking for an option to temporarily pause delivery via LMTP and defer > > mail while the Dovecot mailboxes are being backed-up in order to get an > > consistent state. > > Just take dovecot LMTP offline. Isn't the default behavior of postfix to > queue undeliverable mail and once its able to deliver, it will? No need to > bounce public mail with a 4xx error. > I don‘t want to bounce the mail publicly. I want Postfix to take it out of the active queue, put it into the deferred queue (on the *same* mail server) and Postfix shall attempt to re-deliver it later on. Taking Dovecot LMTP offline doesn‘t seem to be that easy either. So I was looking for an alternative on the Postfix side. -- Matthias Nagel Dachtlerstr. 2, 40499 Stuttgart Festnetz: +49-711-25295180, Mobil: +49-151-15998774 E-Mail: matthias.h.na...@posteo.de, Skype: nagmat84, Threema: 86VM8KN7 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix + mysql connection lost after RCPT
On Wed, Nov 22, 2023 at 02:59:06PM -0300, Rafael Azevedo via Postfix-users wrote: > We're using Postfix + Mysql and we're getting this mysql connection > lost issue very often. > > Nov 22 14:38:28 smtp2 smtp2/smtpd[15858]: warning: > mysql:/etc/postfix/mysql_virtual_alias_maps.cf: query failed: Lost > connection to MySQL server during query Somehow you never got the message that you should be using: proxy:mysql:/path/to/table.cf rather than mysql:/path/to/table.cf Your server will be much happier when you pool MySQL connections via the proxyread(8) service. See also the documentation of proxy_read_maps (which you don't need to change in the most cases, just helpful context). -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix + mysql connection lost after RCPT
We're using Postfix + Mysql and we're getting this mysql connection lost issue very often. Our mysql settings are ok, running using IP instead of the host so no DNS request is made. Can you use unix socket instead of IP? Or other machine? Since you are going over IP, are you using the proxy: feature of postfix causing it to hold on to connections? One area i would investigate would be any kind of OS TCP timeouts. The next thing i would look at is MySQL also has a connection timeout default. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to temporarily pause virtual mail delivery?
I am looking for an option to temporarily pause delivery via LMTP and defer mail while the Dovecot mailboxes are being backed-up in order to get an consistent state. Just take dovecot LMTP offline. Isn't the default behavior of postfix to queue undeliverable mail and once its able to deliver, it will? No need to bounce public mail with a 4xx error. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Postfix + mysql connection lost after RCPT
Hi there, We're using Postfix + Mysql and we're getting this mysql connection lost issue very often. Nov 22 14:38:28 smtp2 postfix/submission/smtpd[16064]: disconnect from unknown[177.128.116.180] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8 Nov 22 14:38:28 smtp2 smtp2/smtpd[15858]: warning: mysql:/etc/postfix/mysql_virtual_alias_maps.cf: query failed: Lost connection to MySQL server during query Nov 22 14:38:28 smtp2 smtp2/smtpd[15858]: warning: mysql:/etc/postfix/mysql_virtual_alias_maps.cf lookup error for "x...@y.com" Nov 22 14:38:28 smtp2 smtp2/smtpd[15858]: NOQUEUE: reject: RCPT from unknown[35.198.27.151] 451 4.3.0 : Temporary lookup failure; from= proto=ESMTP helo=<[127.0.0.1]> --- Nov 22 14:52:58 smtp2 smtp2/smtpd[17751]: connect from unknown[200.219.223.242] Nov 22 14:52:58 smtp2 smtp2/smtpd[17751]: warning: mysql:/etc/postfix/mysql_virtual_alias_maps.cf lookup error for "x...@y.com" Nov 22 14:52:58 smtp2 smtp2/smtpd[17751]: NOQUEUE: reject: RCPT from unknown[200.219.223.242]: 451 4.3.0 : Temporary lookup failure; from= to= proto=ESMTP helo= Nov 22 14:52:58 smtp2 smtp2/smtpd[17751]: lost connection after RCPT from unknown[200.219.223.242] Our mysql settings are ok, running using IP instead of the host so no DNS request is made. After we get this error, restarting postfix returns to normal stage and after 5-10 minutes, new errors occurs. Any clue? Thanks Rafael ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] How to temporarily pause virtual mail delivery?
I am using Posfix with virtual mailboxes. Dovecot hosts these mailboxes and Posfix delivers mails via the LMTP delivery agent to Dovecot. I am looking for an option to temporarily pause delivery via LMTP and defer mail while the Dovecot mailboxes are being backed-up in order to get an consistent state. After the backup has been completed, I want to re-enable mail delivery. Delivery via the LMTP delivery agent shall be paused independently from how the mail got into Postfix. This means, even if a mail has been picked up locally (from sendmail) and the mail's destination is a virtual mailbox, the mail shall be deferred. At the same time, mails which are supposed to be sent off the machine shall still be delivered via the SMTP delivery agent normally. What is the best way to configure that behavior? In the following, I'll present my approach as far as I got. According to my understanding of the Postfix architecture the correct place to do that is after the incoming queue. (Most solutions from the Internet tinker with the configuration of the SMTPD, but this does not suit my objectives.) I assume that the better solution is to use the `transport_maps` and to override the LMTP delivery agent with the ERROR delivery agent for the virtual mailbox delivery. My current configuration is ``` virtual_mailbox_domains = my-domain.de virtual_transport = lmtp:unix:private/dovecot-lmtp virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap/virtual-mailboxes.cf virtual_alias_maps = proxy:ldap:/etc/postfix/ldap/virtual-aliases.cf ``` I am planning to use ``` transport_maps = hash:/etc/postfix/transport ``` with `/etc/postfix/transport` something like ``` my-domain error:4.2.1 Mailbox read-only, not accepting messages ``` At the beginning of the backup process, the backup program would write the line into `/etc/postfix/transport` and remove that line after the backup has been completed. Is that approach possible? Better ideas? Specific questions: - I would like to encode the status code 4.2.1 acc. to RFC 3463 Sec. 3.3 into the error response. Is the shown syntax of `/etc/postfix/transport` correct? - Which Postfix daemon uses `transport_maps` and how fast does the daemon pick-up changes to the map? Do I need a `postfix reload` or is `postmap /etc/postfix/transport` enough? - Does Postfix keep the mails in it own deferred queue and delivers the deferred mail later or does Postfix bounce the mail back to the original sender? Bests and thank you for any help in advance, Matthias -- Matthias Nagel Dachtlerstr. 2, 40499 Stuttgart Festnetz: +49-711-25295180, Mobil: +49-151-15998774 E-Mail: matthias.h.na...@posteo.de, Skype: nagmat84, Threema: 86VM8KN7 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: www.postfix.org outage
On 2023-11-22 at 09:40:48 UTC-0500 (Wed, 22 Nov 2023 15:40:48 +0100) Ralph Seichter via Postfix-users is rumored to have said: * Jaroslaw Rafa via Postfix-users: Maybe it wasn't rebooted until now? (as PXE is a boot-related feature) :) I am positive that I personally rebooted this server a number of times following Kernel updates, the last of which happened not long ago. ;-) If there's a virtualization layer, they are likely to be referring to the real physical host rather than the VM running the Postfix site. I know from managing that sort of environment that PXE (netboooting) makes sense for physical hosts AND they may go a very long time between upgrades & reboots. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: www.postfix.org outage
* Jaroslaw Rafa via Postfix-users: > Maybe it wasn't rebooted until now? (as PXE is a boot-related feature) :) I am positive that I personally rebooted this server a number of times following Kernel updates, the last of which happened not long ago. ;-) My guess is that the hosting company made changes to their boot process, possibly not tested fully with all of the older server models. I cannot be certain, but it would match what I have seen using a remote console. -Ralph ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: www.postfix.org outage
Dnia 22.11.2023 o godz. 04:46:36 Ralph Seichter via Postfix-users pisze: > The Postfix website is available again. The company hosting the server > hardware informed me that there are "some issues with the PXE feature > with this server model", whatever that means exactly, which their staff > was able to fix in the meantime. I find it interesting how this > particular server has been running for years without these issues > manifesting, until yesterday. Maybe it wasn't rebooted until now? (as PXE is a boot-related feature) :) -- 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
