[pfx] Re: Fun with line endings, was Re: Mail text wrapping
-- Doug > On Apr 24, 2024, at 09:05, John Levine via Postfix-users > wrote: > > It appears that Viktor Dukhovni via Postfix-users > said: >> On Wed, Apr 24, 2024 at 01:01:46AM -, John Levine via Postfix-users >> wrote: >> I must be interpreting this wrong because it appears postfix is not accepting that. Here is the complete process. A message arrives at my MTA addressed to a specific address. Postfix delivers that message to a pipe to my process which reads the pipe and stores everything in a file. Portions of the text of that message are extracted and then sent using SMTP to port 25 on my MTA with new recipients. ... >>> >>> Oh, there's your problem. If you are talking directly to an SMTP >>> server, you have to use SMTP line endings \r\n rather than the \n used >>> in files on Unix systems. >> >> Maybe, but perhaps this is too literal a reading of the OP's anecdotal >> description of the message handling. One might equally expect that the >> problem is with some parser of the message content not expecting to decode >> quoted-printable MIME bodies. > > I suppose, but sending bare LF in SMTP is definitely wrong, so he needs to > fix that first. > Well, the header lines are properly terminated by CRLF. However, the text lines are whatever I get from postfix. Generally that is just a LF. I copied the text and inserted the CRs and sent it to see what happens. I get the same result: = signs at each fold point. The solution was to replace all the =LFs with a couple spaces. Postfix/receiving MUA wraps the text of long lines properly (e.g., without and =). There was one other = occurance that I found a replaced with spaces. This solution was easy to accomplish since the text of the message is accessed via mmap. I expected to see some extraneous spaces in the message, but something is optimizing them out. — Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Mail text wrapping
> On Apr 23, 2024, at 12:08, Viktor Dukhovni via Postfix-users > wrote: > > On Tue, Apr 23, 2024 at 11:46:22AM -0700, Doug Hardie via Postfix-users wrote: > >>> RFC 3676 addresses this. >> >> That was an amazing and helpful response. RFC 2045 showed exactly >> what caused the problem. When the message was delivered to a file, >> the CRLFs were replaced by \n. An = followed by a \n is not a valid >> soft return. I am going to have to parse the text and fix that. > > In a quoted-printable MIME body that is stored in a UNIX mailbox file, > "=" *is* a soft line break. Your MIME parser should treat it as > such, accepting not only "=", but also "=". > I must be interpreting this wrong because it appears postfix is not accepting that. Here is the complete process. A message arrives at my MTA addressed to a specific address. Postfix delivers that message to a pipe to my process which reads the pipe and stores everything in a file. Portions of the text of that message are extracted and then sent using SMTP to port 25 on my MTA with new recipients. The > Content-Type: text/plain; > charset=us-ascii > Content-Transfer-Encoding: quoted-printable > are forwarded exactly as received. The resulting message is delivered to multiple recipients including me. There I see the =LF in the message text. If I edit the file before it is sent and replace the =LF with 2 spaces, then it works properly. I'm confident the issue is not in postfix. However, I can't find where it is. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Mail text wrapping
> On Apr 22, 2024, at 23:31, Matus UHLAR - fantomas via Postfix-users > wrote: > > On 22.04.24 22:55, Doug Hardie via Postfix-users wrote: >> This is probably not the right place to be asking this as it is not directly >> Postfix related, but I don't know a better group to ask. For years I have >> sent text messages and just let the lines run on. Only inserting a \n for >> the start of a new paragraph. I never exceed the 988 line length limit. My >> mail client does it's magic to make it smaller line lengths and the >> recipient's puts it back together again so that it fills whatever window >> size they are using. However, in the last couple days, something has >> changed. Looking at the raw sent text of the message, the lines are less >> than 80 bytes with an "=" at the end of each line that is not a line end. >> Going back through some of my email history, I see that occurring for years. >> It was never visible to me or any of my recipients. > > > >> I have a process that takes a portion of a received email and distributes it >> to a small recipient list. I am one of the recipients and It arrived with >> no cleanup. The = was at the end of every line. There was no reassembly of >> the original lines. The outgoing email had the following headers: >> >> Content-Type: text/plain; >> charset=us-ascii >> Content-Transfer-Encoding: quoted-printable >> >> I have searched the internet for some discussion of this and find nothing. >> The RFCs don't seem to address it either. Given the normal thoroughness of >> the RFCs I believe that just means I haven't found the right one. What >> controls this behavior and what is needed to get the reassembly to work >> again? > > this is quoted-printable MIME formatting which wraps lines to <80 characters > per line and uses = at the end of line as continuation character. > > see RFC 2045 section 6.7 for its definnition > > > I also recommend to look at the "format=flowed" option which is nicer > approach. > > RFC 3676 addresses this. > That was an amazing and helpful response. RFC 2045 showed exactly what caused the problem. When the message was delivered to a file, the CRLFs were replaced by \n. An = followed by a \n is not a valid soft return. I am going to have to parse the text and fix that. Thanks, -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Mail text wrapping
This is probably not the right place to be asking this as it is not directly Postfix related, but I don't know a better group to ask. For years I have sent text messages and just let the lines run on. Only inserting a \n for the start of a new paragraph. I never exceed the 988 line length limit. My mail client does it's magic to make it smaller line lengths and the recipient's puts it back together again so that it fills whatever window size they are using. However, in the last couple days, something has changed. Looking at the raw sent text of the message, the lines are less than 80 bytes with an "=" at the end of each line that is not a line end. Going back through some of my email history, I see that occurring for years. It was never visible to me or any of my recipients. I have a process that takes a portion of a received email and distributes it to a small recipient list. I am one of the recipients and It arrived with no cleanup. The = was at the end of every line. There was no reassembly of the original lines. The outgoing email had the following headers: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I have searched the internet for some discussion of this and find nothing. The RFCs don't seem to address it either. Given the normal thoroughness of the RFCs I believe that just means I haven't found the right one. What controls this behavior and what is needed to get the reassembly to work again? -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Understanding log entries
> On Feb 10, 2024, at 15:55, Wietse Venema via Postfix-users > wrote: > > Doug Hardie via Postfix-users: >> I used Viktor's collate to trace a specific email handling. There were a >> number of these entries. However, I am only showing 2 of them: >> > > This is host mx01.t-online.de[194.25.134.72]: > >> Feb 10 03:15:40 mail postfix/smtp[60428]: 4TWjVT5qz7z2gF8w: >> to=, >> orig_to=, >> relay=mx01.t-online.de[194.25.134.72]:25, delay=59371, >> delays=59369/0.02/1.5/0, dsn=4.0.0, status=deferred (host >> mx01.t-online.de[194.25.134.72] refused to talk to me: 554 >> IP=47.181.130.121 - None/bad reputation. Ask your postmaster for >> help or to contact t...@rx.t-online.de for reset. (NOWL)) > > With "smtp_skip_5xx_greeting = yes" (the default) Postfix > will skip to an alternate MX address. > > And this is mx03.t-online.de[194.25.134.73]: > >> Feb 10 03:20:21 mail postfix/smtp[60525]: 4TWjVT5qz7z2gF8w: >> to=, >> orig_to=, >> relay=mx03.t-online.de[194.25.134.73]:25, delay=59652, >> delays=59651/0/1.4/0, dsn=4.0.0, status=deferred (host >> mx03.t-online.de[194.25.134.73] refused to talk to me: 554 >> IP=47.181.130.121 - None/bad reputation. Ask your postmaster for >> help or to contact t...@rx.t-online.de for reset. (NOWL)) >> >> I am a bit confused as it appears that the receiving MTA is returning >> a 554 and a 4.0.0 which appears inconsistent. Obviously postfix >> is using the temp failure as it continues to retry periodically. >> From the text, it appears that this should be a permanent failure, >> not temporary. Is the receiving MTA confused or am I? > > You can configure this to be permanent. But, as you see, even > different MTAs of the same provider differ in their responses. If I am understanding correctly, that means that if I set smtp_skip_5xx_greeting to "no", then postfix would stop after the first 5xx and terminate the email. That seems like it might open up some issues where a provider with multiple MTAs might have one in problem state, but the others working fine. If postfix tried the problem MTA first, the email would never get delivered. Is there a way to configure postfix to drop the email if all the providers MTAs return a 5xx response? -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Understanding log entries
I used Viktor's collate to trace a specific email handling. There were a number of these entries. However, I am only showing 2 of them: Feb 10 03:15:40 mail postfix/smtp[60428]: 4TWjVT5qz7z2gF8w: to=, orig_to=, relay=mx01.t-online.de[194.25.134.72]:25, delay=59371, delays=59369/0.02/1.5/0, dsn=4.0.0, status=deferred (host mx01.t-online.de[194.25.134.72] refused to talk to me: 554 IP=47.181.130.121 - None/bad reputation. Ask your postmaster for help or to contact t...@rx.t-online.de for reset. (NOWL)) Feb 10 03:20:21 mail postfix/smtp[60525]: 4TWjVT5qz7z2gF8w: to=, orig_to=, relay=mx03.t-online.de[194.25.134.73]:25, delay=59652, delays=59651/0/1.4/0, dsn=4.0.0, status=deferred (host mx03.t-online.de[194.25.134.73] refused to talk to me: 554 IP=47.181.130.121 - None/bad reputation. Ask your postmaster for help or to contact t...@rx.t-online.de for reset. (NOWL)) I am a bit confused as it appears that the receiving MTA is returning a 554 and a 4.0.0 which appears inconsistent. Obviously postfix is using the temp failure as it continues to retry periodically. From the text, it appears that this should be a permanent failure, not temporary. Is the receiving MTA confused or am I? -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: ARC or DKIM or SRS?
> On Feb 8, 2024, at 01:56, Matus UHLAR - fantomas via Postfix-users > wrote: > > On 07.02.24 21:51, Christophe Kalt via Postfix-users wrote: >> +1 on setting up SRS, it helps with Gmail and I believe ARC does too >> (although I don't have hard data on this). Interesting note about postgrey, >> I didn't think that was effective any longer but maybe it is. > > I have removed postgrey from servers I manage a few years ago. > - without good exemption lists, you'll run into hours long waiting for email > from various mail services that attempt multiple times from multiple IP > addresses, e.g. microsoft or google. > > I implemented postscreen instead that has similar functionality but is a bit > more safe to use. I implemented postscreen quite a while ago. I don't see where or how it introduces a delay to force the originating MTA to queue and try later. That seems to be what is benefiting me. So far, there have not been any complaints of desired mail not being delivered. There were only 6 defers yesterday. Normally there are a couple hundred. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: ARC or DKIM or SRS?
> On Feb 7, 2024, at 17:23, Alex via Postfix-users > wrote: > > Hi, > > I'm hoping I could ask for some advice. We have a pretty large percentage of > users who forward mail through our systems to personal Gmail accounts. > Sometimes it is mail from bulk senders like mailgun and lanyon/cvent. > > Would ARC help here, or is DKIM enough for DMARC alignment with forwarded > messages? Perhaps ARC will help in those cases where DKIM fails with > forwarded messages? Is it used on the sending server or on the relay? Is it > installed using a milter alongside openSPF/DKIM using openarc? > https://github.com/trusteddomainproject/OpenARC/issues/139 > > I've also thought about implementing SRS over the years, but it has its own > problems, so I wondered if people were still implementing that? > > This has become particularly important with the recent news about Google > requiring senders (or forwarders, in my case) to do more to ensure delivery. > https://support.google.com/a/answer/81126?visit_id=638429520681370280-1110640002&rd=1#zippy=%2Crequirements-for-all-senders I won't claim to be an expert on this, but I have the same situation except I am forwarding mail to dozens of different MTAs. GMail is the most popular destination. I ran into numerous problems with forwarding to Google until I implemented SRS. postsrsd works fine. However, even after that, I still had long delays in forwarding mail. Recently I added postgrey into the mix. I didn't expect it to do much. Back in the early 2000s, it eliminated about 90% of received mail and really helped the spam problem. However, as storage space became cheaper and larger, its effectiveness went way down. Five years ago or so, I no longer saw and improvement from greylisting and removed it. I just added it back a few days ago, and the number of delayed emails dropped to almost zero. mailq shows only 2 emails waiting. That is very unusual as usually it was around 100. I have never tried ARC, DKIM, or DMARC. I suppose that somewhere down the road I will need to start down those paths. -- Doug___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Logging received from address
I am using postfix with postsrsd. Is there a way for postfix to log the from address as originally received? The only addresses I find in postfix's log are the converted addresses from postsrsd. Both addresses are logged by postsrsd, but there is no way to tie it back to the postfix logs for that email. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postsrsd
> On Dec 7, 2023, at 00:27, patpro--- via Postfix-users > wrote: > > December 7, 2023 9:12 AM, "Doug Hardie via Postfix-users" > wrote: > >> Indeed: postsrsd upgraded: 1.10 -> 2.0.8_1,1 > > OK. I’m still running 1.10 : it does not use a config file. Configuration is > only in /etc/rc.conf. > It’s normal that config files for 2.0.8 are new and not tunned. That is useful information. Thanks. I'll have to read the Upgrading document again. There were 70 some ports upgraded and I missed this change. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postsrsd
> On Dec 6, 2023, at 23:48, patpro--- via Postfix-users > wrote: > > December 6, 2023 10:00 AM, "Doug Hardie via Postfix-users" > wrote: > >> I just upgraded FreeBSD from 13.2 to 14.0. Postfix just picked up and ran >> fine. However postsrsd is >> causing me a few issues. I get the impression that postsrsd got updated, but >> I can't tell for sure. > > FreeBSD does not work like this. Ah, but it does if you follow all the instructions. > > postsrsd is not part of the «base system» so it’s not upgraded automatically > when you upgrade from FreeBSD 13.2 to 14.0. It’s standard procedure, though, > to reinstall every ports/pkg after a system upgrade but that particular step > is explicit and up to you. All of that is correct and that is exactly what I did. The instructions said to do that and I did. I'ts part of the upgrade process even though it's a separate step. > > You might find in your /var/log/messages the log of `pkg` actions. Indeed: postsrsd upgraded: 1.10 -> 2.0.8_1,1 That explains why there were issues. It was a major revision. > > Any way, a pkg upgrade SHOULD NOT replace your config file. > And you SHOULD use ZFS snapshots (install zfsnap, setup periodic.conf.local > and forget about it) AND backups. I can't say if there was a config file before or not. But both config and config.sample have exactly the same dates as reported by stat (1). They were also identical. Diff showed no differences. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postsrsd
No backups for that file that I can find. Although there probably are on one of the other systems. Have to check. There is over 400 GB of space available on the disk. Now for the interesting part. At 1 am this morning, postsrsd was not working so i removed it from main.cf. At noon today, I reenabled it again on the test system and it just worked. I then enabled it on the production system and it worked. All I did was to enable syslog logging, add a couple local domains, and disabled chroot. None of those should have changed anything, but it did - or it just needed more time to think about what it should be doing ;-) -- Doug > On Dec 6, 2023, at 09:07, Bill Cole via Postfix-users > wrote: > > On 2023-12-06 at 04:00:21 UTC-0500 (Wed, 6 Dec 2023 01:00:21 -0800) > Doug Hardie via Postfix-users > is rumored to have said: > >> I just upgraded FreeBSD from 13.2 to 14.0. Postfix just picked up and ran >> fine. However postsrsd is causing me a few issues. I get the impression >> that postsrsd got updated, but I can't tell for sure. At the moment, the >> version is 2.0.8. The config files (conf and conf.sample) all had dates of >> 14 Nov so I suspect they were replaced. I don't know what the original files >> contained anymore. > > And you have no backups? > > This is actually my most common reason for needing backups: when I've whacked > a config file and need to get back to a last working config. It's not exactly > common, but it is more frequent than catastrophic disk death... > >> main.conf included: >> >> sender_canonical_maps = tcp:localhost:10001 >> sender_canonical_classes = envelope_sender >> recipient_canonical_maps = tcp:localhost:10002 >> recipient_canonical_classes= envelope_recipient,header_recipient >> >> I got errors that postfix couldn't connect to 10001. There was nothing >> listening to either port. >> >> I changed postsrsd.conf: >> >> chroot-dir = "" >> >> That got rid of the port errors. But now postfix gave an error about the >> tcp mapping. >> >> >> I changed main.conf to: >> >> sender_canonical_maps = socketmap:unix:srs:forward >> sender_canonical_classes = envelope_sender >> recipient_canonical_maps = socketmap:unix:srs:reverse >> recipient_canonical_classes = envelope_recipient, header_recipient >> >> and now postifx logs: Dec 6 00:02:44 test postfix/cleanup[2365]: warning: >> socketmap:unix:srs:forward lookup error for "wa6...@arrl.net". Postfix >> returns: 451 4.3.0 Error: queue file write error. > > I have no positive suggestions of a solution but that error does not seem > like something a socketmap error should be able to generate from the service > side, as opposed to Postfix itself. How is your disk space doing? > > > -- > 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 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postsrsd
Not that I can find > On Dec 6, 2023, at 02:49, Jaroslaw Rafa via Postfix-users > wrote: > > Dnia 6.12.2023 o godz. 01:00:21 Doug Hardie via Postfix-users pisze: >> The config files (conf and conf.sample) all had dates >> of 14 Nov so I suspect they were replaced. I don't know what the original >> files contained anymore. > > Does the upgrade save the previous config files anywhere as backups? It > should. > -- > 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] postsrsd
I just upgraded FreeBSD from 13.2 to 14.0. Postfix just picked up and ran fine. However postsrsd is causing me a few issues. I get the impression that postsrsd got updated, but I can't tell for sure. At the moment, the version is 2.0.8. The config files (conf and conf.sample) all had dates of 14 Nov so I suspect they were replaced. I don't know what the original files contained anymore. main.conf included: sender_canonical_maps = tcp:localhost:10001 sender_canonical_classes = envelope_sender recipient_canonical_maps = tcp:localhost:10002 recipient_canonical_classes= envelope_recipient,header_recipient I got errors that postfix couldn't connect to 10001. There was nothing listening to either port. I changed postsrsd.conf: chroot-dir = "" That got rid of the port errors. But now postfix gave an error about the tcp mapping. I changed main.conf to: sender_canonical_maps = socketmap:unix:srs:forward sender_canonical_classes = envelope_sender recipient_canonical_maps = socketmap:unix:srs:reverse recipient_canonical_classes = envelope_recipient, header_recipient and now postifx logs: Dec 6 00:02:44 test postfix/cleanup[2365]: warning: socketmap:unix:srs:forward lookup error for "wa6...@arrl.net". Postfix returns: 451 4.3.0 Error: queue file write error. Turning debug on in postsrsd.conf does not generate any additional information. I believe something is not configured properly for postsrd, but have not been able to locate the problem. I added my local domain to domains, and mail to those addresses get delivered locally. So it appears that postfix is talking to postsrsd properly. It's just not working for non-local addresses. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: GMail is rejecting mail I forward
> On Oct 31, 2023, at 03:37, Matus UHLAR - fantomas via Postfix-users > wrote: > >>> On Oct 29, 2023, at 10:59, Matus UHLAR - fantomas via Postfix-users >>> wrote: >>> I did SRS by using postsrs, see https://github.com/roehling/postsrsd >>> >>> This way, even forwarding using ~user/.forward will get SRS'ed. >>> >>> However, any mail from foreign domains without DKIM may still get rejected. > > On 29.10.23 11:57, Doug Hardie via Postfix-users wrote: >> I run a similar mail server. I use SRS and it "works" - well sort of. Most >> of the mail gets eventually accepted although it is delayed many hours. The >> delay range is about 1.5 to 27 hours. > > Delayed how? Is the destination mailserver refusing the mail with temporary > error? > Yes. >> I am pretty sure that much of the long delayed mail is actually spam. I >> created a log scanner to find the sources for the messages that are delayed >> to see if there is any conistency but there are no significant differences >> in the number of delayed mail baed on source IP. > -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: GMail is rejecting mail I forward
-- Doug > On Oct 29, 2023, at 10:59, Matus UHLAR - fantomas via Postfix-users > wrote: > > On 29.10.23 16:43, Robert Inder via Postfix-users wrote: >> For 10 years now I've been running a Linux (CentOS 7) server, using >> Postfix to handle mail for a handful of users. >> Specifically, I'm running Postfix 2.2, because that is the most recent >> version yum will fetch >> from the current/default set of repositories. >> >> Some users want to use GMail, so I have used an alias (in an aliases file) >> to forward their mail to their GMail account, making >> person at my.domain >> an alias for >> same_person at gmail.com >> >> Recently, users have told me they have discovered that mail has not reached >> them because it was rejected by GMail. >> >> The rejection mail I have seen says GMail rejected the message because the >> IP address of my server did not pass >> DKIM or SPF for the source of the email. > >> Can I do that with Postfix 2.2? > > not with postfix itself. > I did SRS by using postsrs, see https://github.com/roehling/postsrsd > > This way, even forwarding using ~user/.forward will get SRS'ed. > > However, any mail from foreign domains without DKIM may still get rejected. I run a similar mail server. I use SRS and it "works" - well sort of. Most of the mail gets eventually accepted although it is delayed many hours. The delay range is about 1.5 to 27 hours. I am pretty sure that much of the long delayed mail is actually spam. I created a log scanner to find the sources for the messages that are delayed to see if there is any conistency but there are no significant differences in the number of delayed mail baed on source IP. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behaviour change between 3.2.2 and 3.7.4?
> On May 2, 2023, at 16:14, kwoody--- via Postfix-users > wrote: > >>> Log for the nightly cron job run: >>> >>> 03:01:09 mail sendmail[10703]: 342A19Wv010703: from=root, >> size=14672, >>> class=0, nrcpts=1, >>> msgid=<202305021001.342a19wv010...@mail.citytel.net>, >>> relay=root@localhost >> >> This is sent by Sendmail(TM), not Postfix. You need to run whatever system >> utility FreeBSD uses to switch the default mailer. Note the mail already > is >> addressed to @mail.citytel.net, so that's happening before postfix ever > sees >> the mail. > > I caught that too and was unsure of why it was showing sendmail there or if > it was relevant. But it is so will go down that path. > > Always just do a pkg install of postfix on new systems, but in this case it > didn't > replace sendmail like I thought it did. > > Thanks. The FreeBSD handbook has a section that shows how to replace sendmail with postfix, Section 30.4 Changes are needed to /etc/rc.conf and /etc/mail/mailer.conf -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Reply To header
> On Apr 29, 2023, at 00:06, Roger Klorese via Postfix-users > wrote: > > Reply-To, not Reply To. > What a bone-head mistake. Thanks. Now it works just fine. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Reply To header
> On Apr 28, 2023, at 23:13, Noel Jones via Postfix-users > wrote: > > > >> On Apr 29, 2023, at 12:43 AM, Doug Hardie via Postfix-users >> wrote: >> >> I have an app that sends SMTP to post fix to deliver an email. The first >> line it sends after the DATA command is a Reply To line. However, that >> causes postfix to terminate the headers and puts the Reply To line after the >> blank line at the end of theheaders. As a result, none of the following >> header lines are in the header and only show up in the text. Is this >> normal, or have I done something wrong? >> > > Sounds like your app is inserting a blank line where it shouldn’t. A tcp > capture will show what’s actually being sent. > That's what I thought also. I checked and can't find one Here is the tcpdump output from the DATA through the Reply to line which is the first line sent after the DATA. 23:42:59.591170 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 58, bad cksum 0 (->3cbc)!) localhost.24534 > localhost.smtp: Flags [P.], cksum 0xfe2e (incorrect -> 0x49b2), seq 69:75, ack 103, win 1277, options [nop,nop,TS val 2735927841 ecr 2347198655], length 6: SMTP, length: 6 DATA 0x: 4500 003a 4000 4006 7f00 0001 E..:..@.@... 0x0010: 7f00 0001 5fd6 0019 1d84 3332 0c8e 3d62 _.32..=b 0x0020: 8018 04fd fe2e 0101 080a a312 f221 ...! 0x0030: 8be7 68bf 4441 5441 0d0a ..h.DATA.. 23:42:59.591781 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 89, bad cksum 0 (->3c9d)!) localhost.smtp > localhost.24534: Flags [P.], cksum 0xfe4d (incorrect -> 0xbe3b), seq 103:140, ack 75, win 1277, options [nop,nop,TS val 2347198656 ecr 2735927841], length 37: SMTP, length: 37 354 End data with . 0x: 4500 0059 4000 4006 7f00 0001 E..Y..@.@... 0x0010: 7f00 0001 0019 5fd6 0c8e 3d62 1d84 3338 .._...=b..38 0x0020: 8018 04fd fe4d 0101 080a 8be7 68c0 .Mh. 0x0030: a312 f221 3335 3420 456e 6420 6461 7461 ...!354.End.data 0x0040: 2077 6974 6820 3c43 523e 3c4c 463e 2e3c .with..< 0x0050: 4352 3e3c 4c46 3e0d 0a CR>.. 23:42:59.592129 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 94, bad cksum 0 (->3c98)!) localhost.24534 > localhost.smtp: Flags [P.], cksum 0xfe52 (incorrect -> 0x1809), seq 75:117, ack 140, win 1277, options [nop,nop,TS val 2735927842 ecr 2347198656], length 42: SMTP, length: 42 Reply To: t...@vintagecorvettessocal.com 0x: 4500 005e 4000 4006 7f00 0001 E..^..@.@... 0x0010: 7f00 0001 5fd6 0019 1d84 3338 0c8e 3d87 _.38..=. 0x0020: 8018 04fd fe52 0101 080a a312 f222 .R." 0x0030: 8be7 68c0 5265 706c 7920 546f 3a20 7465 ..h.Reply.To:.te 0x0040: 7374 4076 696e 7461 6765 636f 7276 6574 st@vintagecorvet 0x0050: 7465 7373 6f63 616c 2e63 6f6d 0d0a tessocal.com.. There is nothing between the DATA and Reply to except for the CRLF at the end of the DATA. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Reply To header
I have an app that sends SMTP to post fix to deliver an email. The first line it sends after the DATA command is a Reply To line. However, that causes postfix to terminate the headers and puts the Reply To line after the blank line at the end of theheaders. As a result, none of the following header lines are in the header and only show up in the text. Is this normal, or have I done something wrong? If I leave out the Reply To line, then everything works fine. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Headers and Forwarding
> On Apr 8, 2023, at 13:15, Viktor Dukhovni via Postfix-users > wrote: > > On Sat, Apr 08, 2023 at 12:16:30PM -0700, Doug Hardie via Postfix-users wrote: > >>>> Are there any others and how close am I? >>> >>> >>> https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-7 >> >> Wow, I never would have guessed there would be that many. Thanks. > > For SMTP (as opposed to LMTP), you were only off by a factor of ~2, > there's a second "base" value of "UTF8SMTP". The full set for SMTP is: > >SMTP Simple Mail Transfer Protocol [RFC5321] >ESMTP SMTP with Service Extensions [RFC5321] >ESMTPA ESMTP with AUTH [RFC3848] >ESMTPS ESMTP with STARTTLS [RFC3848] >ESMTPSA ESMTP with both STARTTLS and AUTH [RFC3848] >UTF8SMTP ESMTP with SMTPUTF8 [RFC6531] >UTF8SMTPA ESMTP with SMTPUTF8 and AUTH [RFC4954][RFC6531] >UTF8SMTPS ESMTP with SMTPUTF8 and STARTTLS [RFC3207][RFC6531] >UTF8SMTPSA ESMTP with SMTPUTF8 and both STARTTLS and AUTH > [RFC3207][RFC4954][RFC6531] > > These are correctly used in Postfix and a few other MTAs, and then > there's Microsoft, where even the basic atom syntax is violated: > >with Microsoft SMTP Server > > or MessageLabs: > >with AES128-GCM-SHA256 encrypted SMTP > > c.f. > >https://www.rfc-editor.org/rfc/rfc5321#section-4.4 > > Protocol = "ESMTP" / "SMTP" / Attdl-Protocol > Attdl-Protocol = Atom > ; Additional standard names for protocols are > ; registered with the Internet Assigned Numbers > ; Authority (IANA) in the "mail parameters" > ; registry [9]. SMTP servers SHOULD NOT > ; use unregistered names. > > other violations are less severe: > >with HTTP >with mapi >with bizsmtp >with ngmta Thanks for that info. I don't think that will affect me as the first Received header in the message (last in time) will always be from postfix . I only need postfix's queue id so I can trace what happened if required. >... > > Apparently, reading RFC5321 and RFC5322 is too tedious. Reading is not tedious. You can't force everyone to use your software if you follow the standards. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Headers and Forwarding
> On Apr 8, 2023, at 11:59, Viktor Dukhovni via Postfix-users > wrote: > > On Sat, Apr 08, 2023 at 11:51:06AM -0700, Doug Hardie via Postfix-users wrote: > >> A couple of questions. Looking in the postfix generated Received: >> header, the SMTP id often has a few other letters included: ESMTPA >> etc. I am guessing that the extra letters mean: >> >> E - EHLO used rather the HELO >> S - SSL was used in the connection >> A - the originator was authenticated >> >> Are there any others and how close am I? > > > https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-7 Wow, I never would have guessed there would be that many. Thanks. > >> When the alias file pipes an email to a program, does it expect any >> response from that program, > > Only a 0 exit status code, in which case the program should not generate > any output. > >> or would it do anything with a response? > > If an error occurs some of the output might be included in the bounce. Now that sounds like a useful feature. I'll have to try it out. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Headers and Forwarding
A couple of questions. Looking in the postfix generated Received: header, the SMTP id often has a few other letters included: ESMTPA etc. I am guessing that the extra letters mean: E - EHLO used rather the HELO S - SSL was used in the connection A - the originator was authenticated Are there any others and how close am I? When the alias file pipes an email to a program, does it expect any response from that program, or would it do anything with a response? Thanks, -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Blocked Sender
> On Mar 26, 2023, at 16:23, Viktor Dukhovni via Postfix-users > wrote: > >> ... > > Well, this does not have the "inline:{{...}}" guard. > >>> incoming_smtpd_restrictions = >>> check_policy_service inet:127.0.0.1:10040, >>> reject_invalid_hostname, >>> reject_non_fqdn_sender, >>> reject_non_fqdn_recipient, >>> check_sender_access inline:{ >>> {digitalinsight.firefightersfirstcreditunion.org = >>> permit_auth_destination} >>> }, >>> reject_unknown_sender_domain, > >> > > You can now either whitelist the client IP, or the exclude the domain > name from tests of DNS existence. Use whatever you think is most > manageable (I'd go with exempting the name). I decided to go with exempting the name as shown above. It works. However, I have been studying the recommended: http://www.postfix.org/ADDRESS_REWRITING_README.html I am beginning to understand how the tables are used now. I made a list in the order shown in that page and came to the initial conclusion that all I needed was the virtual aliasing tables. I don't need any of the canonical, masquerading, or bcc functions. That should be all I need to get a received email into the queue properly. To test this, I started up ktrace on the master process and all it's siblings, and then sent in an email. Grabbing the NAMI entries from the output, removing the non-postfix entries and the duplicates yields a small list: 18128 postscreen NAMI "/var/db/postfix" 18128 postscreen NAMI "/var/db/postfix/postscreen_cache.db" 18129 smtpdNAMI "/usr/local/etc/postfix/aliases.db" 18129 smtpdNAMI "/usr/local/etc/postfix/vmail_aliases.db" 18129 smtpdNAMI "/usr/local/etc/postfix/vcsc_aliases.db" 18129 smtpdNAMI "/usr/local/etc/postfix/lafn_aliases.db" 18129 smtpdNAMI "/usr/local/mailman/data/aliases.db" 18129 smtpdNAMI "/usr/local/etc/postfix/vmail_mailbox.db" 18129 smtpdNAMI "/usr/local/etc/postfix/tempfail.db" 18131 trivial-rewrite NAMI "/usr/local/etc/postfix/vmail_aliases.db" 18131 trivial-rewrite NAMI "/usr/local/etc/postfix/vcsc_aliases.db" 18131 trivial-rewrite NAMI "/usr/local/etc/postfix/lafn_aliases.db" 18131 trivial-rewrite NAMI "/usr/local/mailman/data/aliases.db" 18131 trivial-rewrite NAMI "/usr/local/etc/postfix/vmail_domains.db" 18131 trivial-rewrite NAMI "/usr/local/etc/postfix/relocated.db" 18132 cleanup NAMI "/usr/local/etc/postfix/vmail_aliases.db" 18132 cleanup NAMI "/usr/local/etc/postfix/vcsc_aliases.db" 18132 cleanup NAMI "/usr/local/etc/postfix/lafn_aliases.db" 18132 cleanup NAMI "/usr/local/mailman/data/aliases.db" 18133 localNAMI "/usr/local/etc/postfix/aliases.db" 18133 localNAMI "/usr/local/etc/postfix/aliases.db" The first thing I noticed is that smtpd accesses some of the tables. That I didn't expect based on the README. I don't think it is using those tables to rewrite addresses, but it is not obvious why it accesses them. The aliases, vmail_aliases, lafn_alises,and mailman/data/aliases are all in the virtual_address_maps. I have them split into multiple files to make maintenance easier. smtpd accesses the vmail_mailbox table (virtual_mailbox_maps) also. It would appear that is required, but I don't see why. trivial-rewrite appears to be what I expected. I don't use relocated entries at this time, but I can see why it would use them. The rest of the entries seem obvious. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Blocked Sender
-- Doug > On Mar 26, 2023, at 15:04, Viktor Dukhovni via Postfix-users > wrote: > > On Sun, Mar 26, 2023 at 02:53:42PM -0700, Doug Hardie wrote: > >>> inline:{{digitalinsight.firefightersfirstcreditunion.org = >>> permit_auth_destination}} >>> or >>> >>> inline:{digitalinsight.firefightersfirstcreditunion.org=permit_auth_destination} >>> >>> Per the documentation: >>> >>> http://www.postfix.org/DATABASE_README.html >>> >>> "inline:{ key=value, { key = text with whitespace or comma }} >> >> >> I found the = didn't work. > > This is sadly without any configuration or error message details. So not > actionable. The suggested inline:{{key = value}} replacement will work > if implemented correctly. Mar 26 15:42:30 mail postfix/smtpd[15243]: NOQUEUE: reject: RCPT from mx4.messageprovider.com[156.55.193.213]: 450 4.1.8 : Sender address rejected: Domain not found; from= to= proto=ESMTP helo= mail# postconf -n alias_maps = hash:/usr/local/etc/postfix/aliases bounce_queue_lifetime = 1d command_directory = /usr/local/sbin compatibility_level = 3.7 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 1 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 default_privs = mailnull dovecot_destination_recipient_limit = 1 enable_long_queue_ids = yes header_checks = pcre:/usr/local/etc/postfix/header_checks.pcre home_mailbox = Maildir/ html_directory = /usr/local/share/doc/postfix incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, check_sender_access hash:/usr/local/etc/postfix/access reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unlisted_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit inet_protocols = ipv4 local_recipient_maps = unix:passwd.byname $alias_maps mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_size_limit = 0 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man max_use = 5 message_size_limit = 102400 mydestination = localhost.$mydomain, localhost mydomain = sermon-archive.info mynetworks = 10.0.1.0/24, 127.0.0.0/8 mynetworks_style = host newaliases_path = /usr/local/bin/newaliases postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr postscreen_greet_action = enforce queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix recipient_canonical_classes = envelope_recipient,header_recipient recipient_canonical_maps = tcp:localhost:10002 relocated_maps = hash:/usr/local/etc/postfix/relocated sample_directory = /usr/local/etc/postfix sender_canonical_classes = envelope_sender sender_canonical_maps = tcp:localhost:10001 sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtp_destination_concurrency_limit = 2 smtp_destination_recipient_limit = 25 smtp_generic_maps = hash:/usr/local/etc/postfix/generic smtpd_authorized_xclient_hosts = 10.0.1.0/24 smtpd_client_auth_rate_limit = 10 smtpd_client_connection_rate_limit = 10 smtpd_command_filter = pcre:/usr/local/etc/postfix/quote smtpd_error_sleep_time = 10 smtpd_hard_error_limit = 10 smtpd_milters = unix:/var/run/clamav/clmilter.sock smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_soft_error_limit = 1 smtpd_tls_cert_file = /etc/ssl/certs/mail.pem smtpd_tls_key_file = /etc/ssl/private/mail.key smtpd_tls_loglevel = 1 smtpd_tls_security_level = may unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/usr/local/etc/postfix/vmail_aliases, hash:/usr/local/etc/postfix/vcsc_aliases, hash:/usr/local/etc/postfix/lafn_aliases, hash:/usr/local/mailman/data/aliases virtual_gid_maps = static: virtual_mailbox_base = /var/mail/ virtual_mailbox_domains = hash:/usr/local/etc/postfix/vmail_domains virtual_mailbox_limit = 102400 virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmail_mailbox virtual_minimum_uid = virtual_transport = dovecot virtual_uid_maps = static: > ># Best to rename to "incoimg_recipient_restrictions", here, and in > master.cf. Good suggestion. >incoming_smtpd_restrictions = >check_policy_service inet:127.0.0.1:10040, >reject_invalid_hostname, >reject_non_fqdn_sender, >reject_non_fqdn_recipient, >check_sender_access inline:{ >{digitalinsight.firefightersfirstcreditunion.org = >
[pfx] Re: Blocked Sender
> On Mar 26, 2023, at 14:27, Viktor Dukhovni via Postfix-users > wrote: > > On Sun, Mar 26, 2023 at 02:15:27PM -0700, Doug Hardie via Postfix-users wrote: > >> Thanks Viktor. I went with the first approach and am getting errors: >> >> warning: inline:{DigitalInsight.firefightersfirstcreditunion.org = >> permit_auth_destination} is unavailable. missing '=' after attribute name: >> "inline:{DigitalInsight.firefightersfirstcreditunion.org = >> permit_auth_destination}"; need "inline:{name=value...} >> >> and others like: >> >> warning: inline:{DigitalInsight.firefightersfirstcreditunion.org = >> permit_auth_destination} lookup error for "file...@crytech.il" >> >> I think that message is saying the : after inline should be an =. I'll give >> that a try. > > No, the syntax should instead be: > >inline:{{digitalinsight.firefightersfirstcreditunion.org = > permit_auth_destination}} > or > > inline:{digitalinsight.firefightersfirstcreditunion.org=permit_auth_destination} > > Per the documentation: > >http://www.postfix.org/DATABASE_README.html > >"inline:{ key=value, { key = text with whitespace or comma }} I found the = didn't work. So I tried the example in the access(5) man page. That doesn't give any errors, but the domain is still rejected. Here is the master.cf extract for smtpd: smtpd pass - - n - 50 smtpd -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions Here is the main.cf extract: incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, check_sender_access hash:/usr/local/etc/postfix/access reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unlisted_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit the contents of access: # Firefighters CU has missing DNS 156.55.193.213 OK -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Blocked Sender
> On Mar 26, 2023, at 13:28, Viktor Dukhovni via Postfix-users > wrote: > > On Sun, Mar 26, 2023 at 12:52:01PM -0700, Doug Hardie via Postfix-users wrote: > >> I don't want to remove the "reject_unknown_sender_domain" function as >> it gets used properly a lot. Is there some way I can get postfix to >> accept these for local delivery? > >smtpd_sender_restrictions = >check_sender_access inline:{bogus.example.org = > permit_auth_destination}, >reject_unknown_sender_domain > > Alternatively, if you prefer RE tables: > >main.cf: >smtpd_mumble_restrictions = >... prior restrictions ... >check_sender_access pcre:${config_directory}/sender-access.pcre >... later restrictions ... > >sender-access.pcre: ># Single "node.example.org" domain >/@node\.example\.org$/ DUNNO ># The "tree.example.org" domain or any subdomain >/(?:@|\.)tree\.example\.org$/ DUNNO ># ... more exceptions here ... ># Everyone else'd better be valid >/^/ reject_unknown_sender_domain > > This has the advantage that the verdict for "bogus.example.com" is not > final, later restrictions in the same restriction list are still > evaluated. The downside is that most users are sloppy with regular > expressions, when using regular expressions you are quite likely to make > mistakes. For example, Thanks Viktor. I went with the first approach and am getting errors: warning: inline:{DigitalInsight.firefightersfirstcreditunion.org = permit_auth_destination} is unavailable. missing '=' after attribute name: "inline:{DigitalInsight.firefightersfirstcreditunion.org = permit_auth_destination}"; need "inline:{name=value...} and others like: warning: inline:{DigitalInsight.firefightersfirstcreditunion.org = permit_auth_destination} lookup error for "file...@crytech.il" I think that message is saying the : after inline should be an =. I'll give that a try. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Blocked Sender
I have a specific email sender that is getting the error "Sender addresses rejected: Domain not found". Sure enough DNS provides no response for that domain. If I drop off the first part of the domain name, then DNS returns a response. However, the organization is using the complete name which means the emails are dropped. I know the proper solution is to have the originator fix their DNS, but that is not going to happen in the near term. I have tried various ways for a temporary fix, but none have worked so far. I don't want to remove the "reject_unknown_sender_domain" function as it gets used properly a lot. Is there some way I can get postfix to accept these for local delivery? -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Debugging options
> On Mar 19, 2023, at 18:26, Viktor Dukhovni via Postfix-users > wrote: > > On Sun, Mar 19, 2023 at 03:48:07PM -0700, Doug Hardie via Postfix-users wrote: > >> Is there a debug setting that will show which tables are searched when >> an incoming email is received and delivered to a mailbox? > > The best answer to that is the documentation: > >http://www.postfix.org/ADDRESS_REWRITING_README.html > > You could run Postfix in verbose mode, but learning how the various > tables are used from verbose logging is challenging. Thanks Viktor. I tried the debug approach before posting. That's why I made the request. The web page requires a lot of parsing too though. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Debugging options
Is there a debug setting that will show which tables are searched when an incoming email is received and delivered to a mailbox? -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: Integrating mailman with postfix
> On Feb 9, 2023, at 12:25 AM, Jaroslaw Rafa wrote: > > Dnia 8.02.2023 o godz. 23:15:37 Doug Hardie pisze: >> >> The message is delivered to a mailbox on the host, not sent to mailman. > > Maybe I'm missing something, but I don't see anywhere in your configuration > a part that actually would send the mail to mailman. > > I use mailman on my server, and every mailing list defined in mailman needs > to have an appropriate set of aliases (local aliases, not virtual ones) that > pipe mail to appropriate mailman programs. Mailman generates this file, but > you need to include it manually somewhere in your configuration. > > In my case it looks like this: > > virtual_alias_maps = hash:/etc/postfix/virtual > alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases > > The second file in "alias_maps" is the one generated by mailman. For each > mailman list, it contains lines similar to those below (for the list named > test-l): > > test-l: "|/var/lib/mailman/mail/mailman post test-l" > test-l-admin: "|/var/lib/mailman/mail/mailman admin test-l" > test-l-bounces: "|/var/lib/mailman/mail/mailman bounces test-l" > test-l-confirm: "|/var/lib/mailman/mail/mailman confirm test-l" > test-l-join:"|/var/lib/mailman/mail/mailman join test-l" > test-l-leave: "|/var/lib/mailman/mail/mailman leave test-l" > test-l-owner: "|/var/lib/mailman/mail/mailman owner test-l" > test-l-request: "|/var/lib/mailman/mail/mailman request test-l" > test-l-subscribe: "|/var/lib/mailman/mail/mailman subscribe test-l" > test-l-unsubscribe: "|/var/lib/mailman/mail/mailman unsubscribe test-l" > > I have my mailman lists in the real server's domain, ie. one that is in > $mydestination. If you want to host your lists in a virtual domain, it will > probably require to integrate mailman in a different way, but it must be > integrated with Postfix config somehow, and I don't see it in your config. > -- I have in main.cf: alias_maps = hash:/etc/aliases /etc/aliases contains: test: "|/usr/local/mailman/mail/mailman post test" I understand that the alias_maps is used for local deliveries and the list is a virtual list. Those were in the config when I ran the test. Ktrace shows the aliases file is opened and a small part of it is read, but because it is hashed I can't tell what part of it was read. I don't see how the virtual address t...@lafn.org would get forwarded to mailman either. I don't believe that the pipe can be put in the virtual_alias file. I am wondering if I need to make the domain for the list a local domain. -- Doug
Integrating mailman with postfix
I am trying to setup a static maillist. My first approach was to just include the addresses in a list in the virtual_alias file. That works properly if the original message is being sent from someone authorized to send through my mail server. However, the users of this list are all outside my domains and postfix rightlfully denies them relay privileges. I am supporting a few domains for mail. All of them are virtual domains. There are a couple of addresses that have their mailboxes on my server. Those are configured a virtual also. Some of them have addresses in multiple domains. My second approach was to install and setup mailman. I am using the instructions from /usr/local/share/doc/mailman/mailman-install.txt. Obviously I am getting something wrong as postfix never seems to send an email to mailman. From main.cf: myhostname is not specified. mydomain = sermon-archive.info mydestination = localhost.$mydomain, localhost virtual_alias_maps = hash:/usr/local/etc/postfix/vmail_alias, hash:/usr/local/etc/postfix/lafn_alias, hash:/usr/local/etc/postfix/vcsc_alias The only test entry is in lafn_alias: t...@lafn.org test Sending a message from the host master to t...@lafn.org gives the following log entries: Feb 8 23:06:29 mail postfix-submission/smtpd[10647]: connect from master[10.0.1.250] Feb 8 23:06:29 mail postfix-submission/smtpd[10647]: Anonymous TLS connection established from master[10.0.1.250]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 Feb 8 23:06:29 mail postfix-submission/smtpd[10647]: 4PC7Fd2yDbz2fjQ8: client=master[10.0.1.250], sasl_method=CRAM-MD5, sasl_username=doug Feb 8 23:06:29 mail postsrsd[10652]: srs_forward: rewritten as Feb 8 23:06:29 mail postsrsd[10652]: srs_forward: not rewritten: Valid SRS address for Feb 8 23:06:29 mail postfix/cleanup[10651]: 4PC7Fd2yDbz2fjQ8: message-id=<63e49b75.97dc8a.5f43d...@master.sermon-archive.info> Feb 8 23:06:29 mail clamd[1202]: fd[11]: Unable to determine the filepath given the file descriptor. Feb 8 23:06:29 mail postfix/qmgr[10640]: 4PC7Fd2yDbz2fjQ8: from=, size=612, nrcpt=1 (queue active) Feb 8 23:06:29 mail postfix-submission/smtpd[10647]: disconnect from master[10.0.1.250] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8 Feb 8 23:06:29 mail dovecot[10655]: lda(t...@mail.sermon-archive.info)[]<0fouIHWb5GOfKQAAZU03Dg>: msgid=<63e49b75.97dc8a.5f43d...@master.sermon-archive.info>: saved mail to INBOX Feb 8 23:06:29 mail postfix/pipe[10654]: 4PC7Fd2yDbz2fjQ8: to=, orig_to=, relay=dovecot, delay=0.15, delays=0.1/0.02/0/0.03, dsn=2.0.0, status=sent (delivered via dovecot service) Feb 8 23:06:29 mail postfix/qmgr[10640]: 4PC7Fd2yDbz2fjQ8: removed The message is delivered to a mailbox on the host, not sent to mailman. Here is the postconf -n output: alias_maps = hash:/etc/aliases bounce_queue_lifetime = 1d command_directory = /usr/local/sbin compatibility_level = 3.6 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 dovecot_destination_recipient_limit = 1 enable_long_queue_ids = yes header_checks = pcre:/usr/local/etc/postfix/header_checks.pcre home_mailbox = Maildir/ html_directory = /usr/local/share/doc/postfix incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unlisted_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit inet_protocols = ipv4 local_recipient_maps = unix:passwd.byname $alias_maps mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_size_limit = 0 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man max_use = 5 message_size_limit = 102400 mydestination = localhost.$mydomain, localhost mydomain = sermon-archive.info mynetworks = 10.0.1.205, 10.0.1.230, 10.0.1.250, 10.0.1.200, 10.0.1.235, 127.0.0.0/8 mynetworks_style = host newaliases_path = /usr/local/bin/newaliases postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr postscreen_greet_action = enforce queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix recipient_canonical_classes = envelope_recipient,header_recipient recipient_canonical_maps = tcp:localhost:10002 relocated_maps = hash:/usr/local/etc/postfix/relocated sample_directory = /usr/local/etc/postfix sender_canonical_classes = envelope_sender sender_canonical_maps = tcp:localhost:10001 sendmail_path = /usr/local/s
Re: RBL timing
On Nov 24, 2022, at 07:05, Matus UHLAR - fantomas wrote: > > >> >> Matus UHLAR - fantomas: > > Doug: > > There's implicit reject_unlisted_recipient at the end of rules when > smtpd_reject_unlisted_recipient=on (default). > > However when this one hits, DNS queries were already sent. > > the reject_unlisted_recipient makes sense when delivering mail to another > servers or processes/sockets where list of recipients can't be easily found > out Thanks to all for the assistance. It now works properly. I never found reject_unlisted_recipient as it only exists on https://www.postfix.com/SMTPD_ACCESS_README.html where it says it is on by default. The description above should be included in the documentation. — Doug
Re: RBL timing
> On Nov 23, 2022, at 23:27, Phil Biggs wrote: > > Thursday, November 24, 2022, 5:24:12 PM, Doug Hardie wrote: > > >> I am trying with the postscreen dns lookup disabled. Here is the main.cf >> section: > >> # postscreen spam filtering >> postscreen_greet_action = enforce >> #postscreen_dnsbl_action = enforce >> #postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] >> b.barr >> acudacentral.org >> postscreen_access_list = permit_mynetworks, >>cidr:/usr/local/etc/postfix/access.cidr >> # >> # Use long queue ids for uniqueness >> enable_long_queue_ids = yes >> # >> # Incoming restrictions and Implement postfwd >> incoming_smtpd_restrictions = >>check_policy_service inet:127.0.0.1:10040, >>reject_invalid_hostname, >>reject_non_fqdn_sender, >>reject_non_fqdn_recipient, >>reject_unknown_sender_domain, >>reject_unknown_recipient_domain, >>reject_unauth_pipelining, >>permit_mynetworks, >>check_recipient_access hash:/usr/local/etc/postfix/tempfail, >>reject_unauth_destination, >>reject_unverified_recipient >>reject_rbl_client bl.spamcop.net, >>reject_rbl_client b.barracudacentral.org, >>reject_rbl_client zen.spamhaus.org, >>permit >> # > > >> Here is main.cf for smtpd: > >> smtpd pass - - n - 50 smtpd >> -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions > > >> However, I seem to be doing the dns for all received emails. I see the log >> message for user User unknown in virtual alias table, and dns requests with >> that same timestamp for spamcop, barracudacentral and spamhaus. I am >> suspecting I am missing a reject statement that will reject the email when >> the user is not in the virtual alias table that needs to be before the rbl >> rejects. I thought that reject_unverified_recipient would do that, but >> apparently not.' > >> -- Doug > > Never heard of the parameter "incoming_smtpd_restrictions" > > Is that really what you have in main.cf Yes - that is a macro that is referenced in main.cf as shown above — Doug
Re: RBL timing
> On Nov 23, 2022, at 4:49 AM, Matus UHLAR - fantomas wrote: > > On 23.11.22 01:58, Doug Hardie wrote: >> I originally had incoming_smtpd_restrictions set to: >> >> reject_unverified_recipient >> reject_rbl_client bl.spamcop.net, >> reject_rbl_client dnsbl.sorbs.net, >> reject_rbl_client zen.spamhaus.org, >> permit >> >> Later I added postscreen and commented out the reject_rbl_... entries. I >> included in main.cf: >> >> postscreen_dnsbl_action = enforce >> postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] >> b.barracudacentral.org > >> This works as expected. However, I believe that postscreen is processed >> prior to smtpd. I am experiencing a lot of emails that are being sent to >> non-existent users. I don't have accurate counts, but the vast majority of >> email is that. Postscreen is doing a DNS lookup for every one of those. It >> seems it might be better to remove the dnsrbl from postscreen and reinstate >> the reject_rbl statements into incoming_smtpd_restrictions. I believe that >> way, only the mail that has a valid recipient will have the dns rbls >> checked. Am I understanding this correctly? Thanks, > > If you want to spare yourself from DNS lookups, you can do that. > > Note that you may be careful and not to reject mail unless it appears in more > than one DNSBL, or if it appears in e.g. DNSWL, in which case postcreen is > better. > > Also, postscreen is great at rejecting bots that talk prior to ESMTP banner > is sent to them. > > so I personally risk a few DNS lookups but benefit of weighing DNSBLs and use > lookups at postscreen level. > I am trying with the postscreen dns lookup disabled. Here is the main.cf section: # postscreen spam filtering postscreen_greet_action = enforce #postscreen_dnsbl_action = enforce #postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] b.barr acudacentral.org postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr # # Use long queue ids for uniqueness enable_long_queue_ids = yes # # Incoming restrictions and Implement postfwd incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit # Here is main.cf for smtpd: smtpd pass - - n - 50 smtpd -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions However, I seem to be doing the dns for all received emails. I see the log message for user User unknown in virtual alias table, and dns requests with that same timestamp for spamcop, barracudacentral and spamhaus. I am suspecting I am missing a reject statement that will reject the email when the user is not in the virtual alias table that needs to be before the rbl rejects. I thought that reject_unverified_recipient would do that, but apparently not.' -- Doug
RBL timing
I originally had incoming_smtpd_restrictions set to: reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, permit Later I added postscreen and commented out the reject_rbl_... entries. I included in main.cf: postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] b.barracudacentral.org This works as expected. However, I believe that postscreen is processed prior to smtpd. I am experiencing a lot of emails that are being sent to non-existent users. I don't have accurate counts, but the vast majority of email is that. Postscreen is doing a DNS lookup for every one of those. It seems it might be better to remove the dnsrbl from postscreen and reinstate the reject_rbl statements into incoming_smtpd_restrictions. I believe that way, only the mail that has a valid recipient will have the dns rbls checked. Am I understanding this correctly? Thanks, -- Doug
Logged Recipient
I have an interesting question about logging. Postfix is working fine. I have one domain, sermon-archive.info, as mydomain. All other domains are listed in vmail_domains, for example: lafn.orgOK vmail_users contains: bc...@lafn.org home_mail/doug/ vmail_alias contains: bc...@lafn.org doug When email is sent to bc...@lafn.org, the following line is logged: Aug 15 11:56:15 mail postfix/pipe[63616]: 4GnmjC1J7cz2fjRj: to=, orig_to=, relay=dovecot, delay=0.16, delays=0.08/0.02/0/0.06, dsn=2.0.0, status=sent (delivered via dovecot service) That line has the to field as mail.sermon-archive.info. I am a bit confused as to why it would be that. It's not wrong, and it works fine. It's just that the log scanners pick up that as the to address and not the original to so it looks like everything was sent to the sermon-archive.info address. I would like to be able to figure out the original to field. Looking through the man page for pipe, it appears that master.cf has the default arguments of: -f ${sender} -d ${recipient} If I replaced recipient with original_recipient, would that affect the log message, or cause any issues with delivery to dovecot? Would I be better off patching the log scanner to pick up the orig_to field? -- Doug
Re: Bypass postscreen
> On 14 July 2021, at 06:12, Wietse Venema wrote: > > Doug Hardie: >> >>> On 12 July 2021, at 18:27, Wietse Venema wrote: >>> >>> Doug Hardie: >>>> I have a postfix server that uses postscreen. However, occasionally >>>> a needed mail is blocked by one of the spam services. Is there a >>>> way to bypass postscreen for just one or more specific addresses >>>> for a short time? >>> >>> http://www.postfix.org/postconf.5.html#postscreen_access_list >>> http://www.postfix.org/POSTSCREEN_README.html#quick >>> >> >> I went through those earlier. I have configured: >> >> postscreen_access_list = permit_mynetworks, >>cidr:/usr/local/etc/postfix/access.cidr > > You also need to set postscreen_denylist_action (or > postscreen_blacklist_action). > > Wietse Perhaps I am a bit confused. The web page says: To use the postscreen(8) service to block mail, edit main.cf and specify one or more of: • "postscreen_dnsbl_action = enforce", to reject clients that are on DNS blocklists, and to log the helo/sender/recipient information. With good DNSBLs this reduces the amount of load on Postfix SMTP servers dramatically. • "postscreen_greet_action = enforce", to reject clients that talk before their turn, and to log the helo/sender/recipient information. This stops over half of all known-to-be illegitimate connections to Wietse's mail server. It is backup protection for zombies that haven't yet been denylisted. I have both of those set to enforce. Here is the complete postscreen section of main.cf: # postscreen spam filtering postscreen_greet_action = enforce postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org b.barracudacentral.org postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr # That seems to work as I see numerous spam being blocked by those dnsbl sites. Am I missing something? -- Doug
Re: Bypass postscreen
> On 12 July 2021, at 18:27, Wietse Venema wrote: > > Doug Hardie: >> I have a postfix server that uses postscreen. However, occasionally >> a needed mail is blocked by one of the spam services. Is there a >> way to bypass postscreen for just one or more specific addresses >> for a short time? > > http://www.postfix.org/postconf.5.html#postscreen_access_list > http://www.postfix.org/POSTSCREEN_README.html#quick > I went through those earlier. I have configured: postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr mail# vi access.cidr 10.0.1.0/24 permit 23.242.169.27/32permit 206.248.190.153/32 reject 123.108.97.201/32 reject 91.238.134.134/32 reject ~ mynetworks = 10.0.1.205, 10.0.1.230, 10.0.1.250, 10.0.1.200, 10.0.1.235, 127.0.0 .0/8 I figured the postscreen_access_List was the place, but I added the needed address with permit and did a postfix reload. It still blocked the desired email. Perhaps there was a typo somewhere, so I will run another set of tests and see what I get. -- Doug
Bypass postscreen
I have a postfix server that uses postscreen. However, occasionally a needed mail is blocked by one of the spam services. Is there a way to bypass postscreen for just one or more specific addresses for a short time? -- Doug
Re: Stucked with "unable to look up host"
> On 9 February 2021, at 02:58, @lbutlr wrote: > > zgrep TLSv1 /var/log/mail.log.* | egrep -v '(TLSv1.3|TLSv1.2)' | egrep -o > 'established from [^:]*' | sort -u For the last week of my maillogs, I get 298 entries. Some of them are from the US Census, several health organizations, a mail server that is normally not sending spam, some California legislators, but I believe probably 80% are spam. I am not ready to block those yet. If that is the best they can do, then it's better than in the clear. -- Doug
Re: Send only configuration best practices?
> On 23 September 2020, at 22:32, Bob Proulx wrote: > > John Stoffel wrote: >> Bob> What's the best configuration for a web server that does not >> Bob> receive mail but needs to send mail? Password resets. Bug >> Bob> ticket update notifications. That type of email. >> >> I would push all the email to the mailserver for the domain served by >> that web server and let it deal with this issue. Make the client (web >> server) only send emails through the mail gateway which is setup >> properly. > > Sigh. I was hoping to be able to avoid this. But both of the > responses were basically, set up something to handle incoming mail. > >> No need to replicate the pain again and again for individual servers. > > But your answer assumes there is already an incoming email system set > up for that domain somewhere. But since that isn't always true it > means that one would always need to be set up for it. And if there is > only one single server for the project then that is the server it will > land on. My preference would be not to do it at all. Check and see if DMA, Dragonfly mail agent, is available for your machine. It is a very simple send only mail server. It is easy to setup and run. Only sends mail. Nothing else other than DNS resolution is required. -- Doug
Re: Questions about the master.cf file
Having recently gone through this same confusion, perhaps some of what I figured out might help. The first column of the master.cf file is the port number for each of the ports that postfix will listen to, or the name of an internal postfix process. In the distributed file, the names from the /etc/services file are used rather than the port numbers. For example, smtp is port 25. However, looking down you will see one line for port 628 (commented out though). The last argument on each line tells postfix which process to send the request to. Thats why postscreen replaces the smtp line with the postscreen process. Postscreen is smart - it injects messages into the system by sending them to smtpd. There is an entry for smtpd (the postfix process) that lets you add restrictions for smptd. Here is a portion of my master.cf: smtpd pass - - n - 50 smtpd -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions smtp inet n - n - 1 postscreen dnsblogunix - - n - 0 dnsblog tlsproxy unix - - n - 0 tlsproxy submission inet n - n - 10 smtpd -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix-submission dovecotunix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient} I use macros defined in main.cf for the restrictions on port 25 (smtp after postscreen) and port 587 (submission). dnsblog and tlsproxy are internal postscript processes. dovecot is a local delivery via dovecot. It's a bit difficult at first to see the forrest through the trees as the documentation is detailed and complete. However, once you discover the forrest, then the documentation will be quite helpful. -- Doug > On 9 June 2020, at 14:26, Scott A. Wozny wrote: > > In the context of looking at implementing Postscreen, I’ve read through the > postscreen readme, the master.cf man page, and postfix architectural overview > docs, but I have some remaining service related questions I might appeal to > one of the gurus on the list to help me with. > > In a default master.cf file’s first non-comment line, the smtp service uses > the smtpd command. I’m not clear why the smtp (client) service would use the > smtpd (server) binary. Is there an old convention that drives the naming to > be apparently contradictory or am I missing something in my interpretation? > > In the postscreen instructions, one of the first steps is to comment out the > smtp service line above and uncomment the one that uses the postscreen > command instead. I get why, since postscreen is supposed to “screen” out bad > clients before letting them talk to smtpd later. Is there anything in this > configuration file that indicates this or is the handoff to smtpd built into > postscreen itself? > > Why is there an smtpd service that gets enabled during a postscreen > implementation when there wasn’t one before? More specifically, without an > smtpd service before, what service was serving smtpd for new smtp > connections? The “smtp” service (that seems to actually be smtpd) listed > first in the file? > > In the smtpd service I just mentioned, this type is pass and not unix. When I > looked up the 2 service types in the documentation, they both say, “The > service listens on a UNIX-domain stream socket, and is accessible to local > clients only.” but the pass type goes on to say, “It receives one open > connection (file descriptor passing) per connection request.” I’ve done some > further googling, but I can’t figure out what this means in terms of > practical use. Can someone explain the practical difference between a unix > type service and a pass type service? > > Finally, there is ANOTHER service named smtp further down the file between > proxywrite and relay that ACTUALLY uses smtp as the command but is of type > unix (which, for a client, makes sense). What is the purpose of this instance > of service named smtp (like, is it the “real” smtp service used for packaging > and sending smtp messages?) and how is it that it does not “conflict” with > the instance of smtp service discussed above? Under what conditions am I > allowed to create services that have names which conflict? Only when the > types are different (and then, only with certain “different type” > combinations)? Or is there a first use rule on services which means that the > smtp service above is the only one that get used? > > I’m sorry if I’m being obtuse, but some elements of this file are a real > head-scratcher for me. If this is covered somewhere outside of > http://www.postfix.org/master.5.htmlhttp://www.postfix.org/OVERVIEW.html > orhttp://www.postfix.org/POSTSCREEN_README.html or is discussed in more > detail elsewhere on the
Re: Preferred/maintained greylisting options?
> On 25 May 2020, at 12:00, Chris Wedgwood wrote: > >> Greylisting has become pretty much useless. When I disabled it a >> couple years ago, the spam levers did not increase by any measurable >> amount. We now use just 3 RBLs and that seems to be a relatively >> acceptable level of spam. > > Checking for %ge of messages that "return after defer" I see: > >WeekOf PctReturned >-- --- >2020-04-30 22.1 >2020-05-07 26.5 >2020-05-14 21.2 >2020-05-21 26.5 I would guess that our users were hit by spammers with more resources ;-) I would have kept greylisting if we had seen numbers like that. -- Doug
Re: Preferred/maintained greylisting options?
> On 24 May 2020, at 13:05, Charles Sprickman wrote: > > > >> On May 24, 2020, at 3:59 PM, Laura Smith >> wrote: >> >>> >>> I’ve been sort of opposed to greylisting in the past due to a userbase >>> that’s sensitive to delays, but… the spam is worse. >>> >> >> >> IMHO Greylisting is rather pointless. Its a blunt tool, and not only that it >> does that unforgivable thing of annoying genuine people. >> >> I would hazard a guess that if you are being innundated with spam, then your >> RBL setup is less than adequate. Both the choice of RBLs ***AND*** the >> correct configuration thereof is critical. > > As I described in my original email, this isn’t a failure of RBL setup. I’m > just being inundated with: > > - Correctly configured hosts that don’t fail any obvious protocol checks > - Hosts that are not on any RBLs until 5-10 minutes after delivering > > As I see it, I have limited options: > > - Do more filtering on content (blech - these only score +1 or so in SA) > - Delay the mail (from non-whitelisted senders) until the hosts are listed. > >> I should also add that you should not be afraid to pay for access. The good >> lists will (a) block you if you hammer them with high volumes of requests >> (b) save some of their better content (or new innovations) for their paid >> subscribers. > > I’ve trialed the major ones with no improvement. The greylisting suggestion > came from Abusix because they looked up a day of “leaks” and found they were > simply delivering before they were being listed. > >> RBLs these days are pretty darn good, with everything setup correctly you >> can easily be in the very high 90-percentiles of catching spam and pretty >> much zero false-positives. > > Sadly, we seem to be at the head of most spammer’s lists. One of these “paid” > services should give us free access in return for a spamtrap. :) > > It’s also incredibly obvious there are some colos that are catering to these > people, esp. that firm out of Buffalo… I ran an ISP for a number of years and we had to deal with a lot of spam. When greylisting first became available, I added it into our mix of spam protection. While I don't recall the exact number, over 95% of received mail was blocked. There were a few issues with some legitimate mailers who refused to retry, eventually we whitelisted enough that our users had no issues. This worked because at that time virtually all spammers were drive-by spammers. They sent the email once, and didn't bother to queue it if it couldn't be delivered. The cost of diskspace and internet connections were too high for them. With time, those costs came down. Effectively today there is no additional cost to queue spam. Hence, virtually all the spammers are now using high quality mail servers like postfix. They seem to retry forever. Greylisting has become pretty much useless. When I disabled it a couple years ago, the spam levers did not increase by any measurable amount. We now use just 3 RBLs and that seems to be a relatively acceptable level of spam. -- Doug
Re: Disabling TLSv1
> On 5 March 2020, at 17:15, Viktor Dukhovni wrote: > > On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote: > >> Small mail server with 3 weeks of logs: >> >> 1761 TLSv1 >> 18 TLSv1.1 >> 20414 TLSv1.2 >> 6343 TLSv1.3 >> >> That's not what I expected. I thought v1 and v1.1 would be reversed. >> There is a complete spectrum of ciphers being used with v1 including >> some of the most recent. I am using the defaults for the protocols >> and ciphers. > > The reversal is expected, the most widely used TLS implementations that > support TLSv1.1 also support TLSv1.2, and so you see very little use of > TLSv1.1. The ancient stacks that haven't yet adopted TLS1.2, mostly > never got to TLSv1.1 either. > > An interesting question in your case is what fraction of the TLSv1 > connections are non-spam. Perhaps you're able to correlate the TLSv1 > connections with legitimate vs. junk email. Results for 3 weeks of log files: TLSv1 spam = 1182 ham = 1147 TLSv1.1 spam = 74 ham = 6 TLSv1.2 spam = 24355ham = 10461 TLSv1.3 spam = 4453 ham = 2305 Note, that the definition of spam is there is a NOQUEUE entry for that IP address in the log files. Hence this is an approximation as it is possible that the RBLs entries could have changed during those 3 weeks. Also, I don't know what emails the recipients considered spam. Only 2 users have mailboxes on my servers. The others are elsewhere. -- Doug
Re: Disabling TLSv1
> On 5 March 2020, at 17:15, Viktor Dukhovni wrote: > > On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote: > >> Small mail server with 3 weeks of logs: >> >> 1761 TLSv1 >> 18 TLSv1.1 >> 20414 TLSv1.2 >> 6343 TLSv1.3 >> >> That's not what I expected. I thought v1 and v1.1 would be reversed. >> There is a complete spectrum of ciphers being used with v1 including >> some of the most recent. I am using the defaults for the protocols >> and ciphers. > > The reversal is expected, the most widely used TLS implementations that > support TLSv1.1 also support TLSv1.2, and so you see very little use of > TLSv1.1. The ancient stacks that haven't yet adopted TLS1.2, mostly > never got to TLSv1.1 either. > > An interesting question in your case is what fraction of the TLSv1 > connections are non-spam. Perhaps you're able to correlate the TLSv1 > connections with legitimate vs. junk email. The code to scan the logs is a bit convoluted. I have it running, but there are 44K connections to check so it will undoubtly run all night. It has completed 1200 so far in about 11 minutes. So it will take over 6.5 hours to complete. -- Doug
Re: Disabling TLSv1
> On 5 March 2020, at 15:26, ratatouille wrote: > > Viktor Dukhovni schrieb am 05.03.20 um 16:44:14 > Uhr: > >> On Thu, Mar 05, 2020 at 09:08:43PM +0100, ratatouille wrote: >> >>> Don't know why TLSv1 is still offered on our servers running >> >> Probably because you're not changing the configuration in the right >> place. Double-check that you're configuring the correct Postfix >> instance (if using multiple instances) and that there are no >> master.cf overrides that trump the main.cf settings. >> >>> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1 >>> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1 > > Found out if I want to disable TLSv1.1 too I just have to do so. > smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 > and suddenly it works ;) > >> Other than test TLS connections, do you still legitimate inbound email >> in your logs (looking over a week or more of logs) delivered with TLSv1? > > I have just too TLSv1 connections this month: > ... > 11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits) > 9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits) > 9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits) > 9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits) > 8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits) > 8 TLSv1.1 with cipher AES256-SHA (256/256 bits) > 8 TLSv1.1 with cipher AES128-SHA (128/128 bits) > 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits) > 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits) > 7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits) > 7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits) > 7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits) > 4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits) > 2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits) > 1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) > 1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits) Small mail server with 3 weeks of logs: 1761 TLSv1 18 TLSv1.1 20414 TLSv1.2 6343 TLSv1.3 0 SSL That's not what I expected. I thought v1 and v1.1 would be reversed. There is a complete spectrum of ciphers being used with v1 including some of the most recent. I am using the defaults for the protocols and ciphers. -- Doug >
Re: What is this?
> On 26 February 2020, at 02:54, Jaroslaw Rafa wrote: > > My Postfix log is full of repeated connections and disconnections from the > same machine: > > Feb 26 11:43:41 rafa postfix/submission/smtpd[13829]: connect from > unknown[92.118.38.42] > Feb 26 11:43:52 rafa postfix/submission/smtpd[13829]: disconnect from > unknown[92.118.38.42] > Feb 26 11:44:04 rafa postfix/submission/smtpd[13829]: warning: hostname > ip-38-42.ZervDNS does not resolve to address 92.118.38.42: Name or service > not known > > This repeats over and over (I already blocked this IP on firewall). I wonder > what this attacker(?) is trying to do - the client doesn't attempt AUTH or > anything (it would be logged). It just connects and disconnects. And so on > and on... One of my mail servers showed the same thing. Tcpdump showed they are sending SYN after SYN, nothing else. You didn't indicate which firewall you are using, but when I went to block them with pf I found that they send often enough that pf's state stays active. I had to manually remove that state entry to stop the logging. That won't stop their sending the SYNs though. It almost appears to be a really poor attempt at a denial of service. I did find 2 other sites sending the same thing. -- Doug
Re: Corrupt message
> On Feb 13, 2020, at 16:05, Wietse Venema wrote: > > Doug Hardie: >> Thanks. I finally understand it. Interestingly enough, both of >> the corrupt/* files had zero length. > > Did the files have permissions rwx? Then at some point they contained > an email message, before the file system lost the data. > >Wietse Don’t recall. I already deleted them
Re: Corrupt message
On 13 February 2020, at 03:28, Viktor Dukhovni wrote: > > On Wed, Feb 12, 2020 at 07:43:59PM -0800, Doug Hardie wrote: > >> I seem to have a couple corrupt messages. Restarting postfix gives: >> >> service postfix restart >> postfix/postfix-script: stopping the Postfix mail system >> postfix/postfix-script: warning: damaged message: corrupt/44t83n4KNbz2fjQV >> postfix/postfix-script: warning: damaged message: corrupt/46jP9V452yz2fjRb >> postfix/postfix-script: starting the Postfix mail system > >1. Use "postcat" to check that the partially collected content has > no value: > > # postcat /var/spool/postfix/corrupt/$qid > >SYNOPSIS > postsuper > [-psSv] [-c config_dir] [-d queue_id] > [-h queue_id] [-H queue_id] > > [-r queue_id] [directory ...] > ... > > -d queue_id > Delete one message with the named queue ID from the named mail > queue(s) (default: hold, incoming, active and deferred). > ... > > So postsuper(1) does not look in the "corrupt" directory, but even if > you explicitly try: > ># postsuper -d $qid corrupt > > you'll get an error message, because "corrupt" is not a message queue, > it is just a directory, with detritus, that may or may not be safe to > remove. Therefore, once you're sure you want to remove it: > >2. # /bin/rm /var/spool/postfix/corrupt/$qid > > -- >Viktor. Thanks. I finally understand it. Interestingly enough, both of the corrupt/* files had zero length. -- Doug
Corrupt message
I seem to have a couple corrupt messages. Restarting postfix gives: service postfix restart postfix/postfix-script: stopping the Postfix mail system postfix/postfix-script: warning: damaged message: corrupt/44t83n4KNbz2fjQV postfix/postfix-script: warning: damaged message: corrupt/46jP9V452yz2fjRb postfix/postfix-script: starting the Postfix mail system I have tried postsuper -d 44t83n4KNbz2fjQV and it gives no errors, but doesn't remove the corrupt message. I have found both of them in my cur mailbox and they are unimportant so I would like to get rid of them. Clearly I am missing something on how to do that. Thanks, -- Doug
Re: about MTA's 4xx response code
> On 28 August 2019, at 19:50, Eliza wrote: > > Hello, > > on 2019/8/29 10:42, Andrew Bernard wrote: >> 421 Temporary System Problem. Try again later. >> 421 Try again later, closing connection. >> 421 Server busy, try again later. >> The SMTP error 421 is normally used for temporary problems on the mail >> server or a problem with the recipients email account. >> Some mail providers might also return 421 after you reached a limit >> (restriction) on your mail account (see SMTP Error 451 below). > > But I know some antispam systems get abused to return 4xx even there is > neither temporary system problem nor server busy. They just doubt this is > suspicious message and return 4xx codes. Greylisting used to be a very effective approach to spam blocking. When I first implemented it a number of years ago, it blocked about 95% of the incoming mail. I believe the number of false positives was under 10. However, greylisting was based on the high cost of queueing (disk space and internet bandwidth). When the cost of those fell, spammers were able to implement queueing at very little cost. As a result greylisting became fairly ineffective. It was blocking less than 5% of the spam when I discontinued it. I suspect that most of us who implemented greylisting considered the receipt of spam to be a system problem and hence the 400 series codes were appropriate. YMMV. -- Doug
Re: Delays in receiving mail
On Jun 30, 2019, at 20:42, Viktor Dukhovni wrote: >> On Jun 30, 2019, at 8:14 PM, Doug Hardie wrote: >> >>> By default, the Postfix SMTP server invokes the proxymap >>> service for local user lookup, because the default >>> local_recipient_maps setting looks like this: >>> >>> local_recipient_maps = proxy:unix:passwd.byname $alias_maps >>> >>> Try, as a root user: >>> >>> postmap -q nosuchuser proxy:unix:passwd.byname >>> postmap -q root proxy:unix:passwd.byname >>> >>> I suspect that your proxymap service is busted. >>> >> >> brain# postmap -q nosuchuser proxy:unix:passwd.byname >> postmap: fatal: proxymap service is not configured for table >> "unix:passwd.byname" >> brain# postmap -q root proxy:unix:passwd.byname >> postmap: fatal: proxymap service is not configured for table >> "unix:passwd.byname" > > Not surprising, since you're not the default local_recipient_maps setting. Thanks Viktor and Wietse. This was a strange one. I finally found the problem and it was not with the postfix configuration. Ypbind failed to start up correctly. I don’t quite understand how that could happen, but by restarting it, mail started flowing in correctly. All of the user id’s and passwords are found via YP.
Re: Delays in receiving mail
> On Jun 30, 2019, at 19:22, Wietse Venema wrote: > > Doug Hardie: >> This is a small server with a few users that are all local. There >> are several domain names that point to this server, but all of >> them are just aliases for the main name. Received mail stops at >> the rcpt to: line. There is no OK that occurs until shortly after >> 3 minutes from that line being received. During that time ktrace >> shows multiple calls and sleeps for proxymap. After the 3+ minute >> delay, it issues the OK and then they rest proceeds normally. I >> suspect this is a configuration error since this server was just >> updated to 3.3.4 from an earlier version. The earlier version >> worked fine. This problem started when the upgrade completed. > > By default, the Postfix SMTP server invokes the proxymap > service for local user lookup, because the default > local_recipient_maps setting looks like this: > >local_recipient_maps = proxy:unix:passwd.byname $alias_maps > > Try, as a root user: > > postmap -q nosuchuser proxy:unix:passwd.byname > postmap -q root proxy:unix:passwd.byname > > I suspect that your proxymap service is busted. > brain# postmap -q nosuchuser proxy:unix:passwd.byname postmap: fatal: proxymap service is not configured for table "unix:passwd.byname" brain# postmap -q root proxy:unix:passwd.byname postmap: fatal: proxymap service is not configured for table "unix:passwd.byname"
Delays in receiving mail
This is a small server with a few users that are all local. There are several domain names that point to this server, but all of them are just aliases for the main name. Received mail stops at the rcpt to: line. There is no OK that occurs until shortly after 3 minutes from that line being received. During that time ktrace shows multiple calls and sleeps for proxymap. After the 3+ minute delay, it issues the OK and then they rest proceeds normally. I suspect this is a configuration error since this server was just updated to 3.3.4 from an earlier version. The earlier version worked fine. This problem started when the upgrade completed. brain# postmap -n postmap: fatal: usage: postmap [-NfinoprsuUvw] [-c config_dir] [-d key] [-q key] [map_type:]file... brain# postconf -n command_directory = /usr/local/sbin compatibility_level = 2 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debug_peer_list = faxage.com debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $proce html_directory = /usr/local/share/doc/postfix inet_protocols = ipv4 local_recipient_maps = unix:passwd.byname $alias_maps mail_owner = postfix mail_spool_directory = /var/mail/ mailbox_size_limit = 0 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man message_size_limit = 10240 mydestination = $myhostname, localhost.$mydomain, localhost, remotesupportservicesllc.com, rssllc.us, mail.rem .us mydomain = remotesupportservicesllc.com mynetworks_style = host newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtpd_authorized_xclient_hosts = 10.0.1.0/24 smtpd_error_sleep_time = 10 smtpd_hard_error_limit = 10 smtpd_milters = unix:/var/run/clamav/clmilter.sock smtpd_recipient_restrictions = reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_soft_error_limit = 1 smtpd_tls_cert_file = /etc/mail/certs/mail.pem smtpd_tls_key_file = /etc/mail/certs/mail.key smtpd_tls_loglevel = 1 smtpd_tls_security_level = may unknown_local_recipient_reject_code = 550 -- Doug
Re: Installing LetsEncrypt For Postfix and Dovecot
> On 28 November 2018, at 01:03, Matus UHLAR - fantomas > wrote: > > On 27.11.18 10:52, Asai wrote: >> With Mozilla recently dropping support for all Symantec certs, our security >> cert now throws errors on Thunderbird clients. We’d like to install >> certbot on Centos 6, but I’m not sure if it’s going to interfere with >> Postfix (2.11) or Dovecot (2.2.18). Does anybody have experience with >> this? > > I have no problem with Let's Encrypt certificates and postfix/whatever. > I'm just not sure if iphones have the root CA (DST Root CA X3) installed - > just yesterday noticed a complaint. > The latest version of iOS have the proper root certificate. I am using Let's Encrypt certificates for dovecot and postfix. I access and send mail frequently using an iPhone and iPad. If you are dealing with an older version, the user can accept the certificate and that will also work.
Re: Log Messages
> On 23 May 2018, at 13:41, Viktor Dukhovni wrote: > > > >> On May 23, 2018, at 4:10 PM, Doug Hardie wrote: >> >> incoming_smtpd_restrictions = >> check_policy_service inet:127.0.0.1:10040, >> reject_invalid_hostname, >> reject_non_fqdn_sender, >> reject_non_fqdn_recipient, >> reject_unknown_sender_domain, >> reject_unknown_recipient_domain, >> reject_unauth_pipelining, >> permit_mynetworks, >> check_recipient_access hash:/usr/local/etc/postfix/tempfail, >> reject_unauth_destination, >> reject_unverified_recipient >> permit > > It is far from clear why you'd want "reject_unverified_recipient" > here. Do you have sort of wildcard aliasing or other reason to > expect your recipient validation tables to accept ultimately > invalid recipients? Reading the Prefix Address Verification Howto madeit seem like it would be useful. I think I see now how it works. I don't expect the recipient validation tables to have invalid recipients so I have removed that. -- Doug
Re: Log Messages
> On 23 May 2018, at 13:17, Viktor Dukhovni wrote: > > > >> On May 23, 2018, at 4:10 PM, Doug Hardie wrote: >> >> I would think that cache would be cleared with a restart. > > No. The verification cache survives restart. This is intentional. There sure is a lot to learn about postfix... > >> Vmail_alias is dated 28 Apr. That's almost 2 months ago. > > In this version of the multiverse Apr/28 is 3.5 weeks ago. :-) Oops... > The relevant parameters are: > > http://www.postfix.org/postconf.5.html#address_verify_positive_expire_time > http://www.postfix.org/postconf.5.html#address_verify_positive_refresh_time > > With the defaults one would expect stale positive entries to go away > after ~7 days... I haven't touched those defaults. I didn't even know they existed till now. I am going to let this sit for another 3 weeks as I will be on other things and we will see what happens by then. Thanks for the assistance and information. > > -- > Viktor. >
Re: Log Messages
> On 23 May 2018, at 11:43, Viktor Dukhovni wrote: > > > >> On May 23, 2018, at 2:23 PM, Doug Hardie wrote: >> >> It is a non-existent address and is fine. It's just surprising that one of >> the non-existent addresses gets a different log message. The only thing I >> can think of is that the originator has a non-printing character somewhere >> in the address. > > No, the reason is that the address existed in the past, and > so is cached as verified. That cached value will expire at > some point, and then it will become unverified. Not clear > why you use recipient verification... I would think that cache would be cleared with a restart. Vmail_alias is dated 28 Apr. That's almost 2 months ago. Recipient verification seemed like a good idea from reading the documentation. I take it from your comment that it duplicates one of the other checks? incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unverified_recipient permit
Re: Log Messages
> On 23 May 2018, at 09:24, /dev/rob0 wrote: > > On Wed, May 23, 2018 at 08:39:08AM -0700, Doug Hardie wrote: >> I am running a mail server that has a few local recipients and a >> bunch of forwarded recipients for one domain. All is working >> properly. However, there are some log messages that I find >> confusing. The server receives many messages delivery attempts >> where the user is not included in the virtual_alias_maps. All but >> one of them receive log messages like >> >> Recipient address rejected: unverified address > > This was rejected by the reject_unverified_recipient smtpd > restriction, after an attempt to verify the address failed. > >> That makes sense. However, one of them receives >> >> Recipient address rejected: User unknown in virtual alias table > > This was rejected by the reject_unauth_destination smtpd > restriction, probably in smtpd_relay_restrictions, and means that > the domain was found in virtual_alias_domains, but the address did > not resolve via v_a_maps to an address NOT in v_a_domains. > >> I don't see what is different for this particular user. > > Is it a "user" or just a non-existent address? If the former, you > have a problem. If the latter, it's fine. It is a non-existent address and is fine. It's just surprising that one of the non-existent addresses gets a different log message. The only thing I can think of is that the originator has a non-printing character somewhere in the address.
Log Messages
I am running a mail server that has a few local recipients and a bunch of forwarded recipients for one domain. All is working properly. However, there are some log messages that I find confusing. The server receives many messages delivery attempts where the user is not included in the virtual_alias_maps. All but one of them receive log messages like Recipient address rejected: unverified address That makes sense. However, one of them receives Recipient address rejected: User unknown in virtual alias table I don't see what is different for this particular user. They all have the same domain which is the only one in virtual_alias_domains. It appears that that message made it through the smtpd check as if the user was in the virtual_alias_maps. That user id does not appear anywhere in the postfix configuration. Am I interpreting these messages correctly? One possible issue with this user was that that id was originally not in virtual_alias_maps and was added. There were no such log messages before that. They were listed in the unverified address listing. After adding the user, there were no log messages and mail was delivered. Later the address was removed from virtual_alias_maps and then the unknown messages started. Postfix was re-started after that change was made (not a reload). -- Doug
Re: dnsblog lifetime
> On 24 April 2018, at 13:48, Wietse Venema wrote: > > Doug Hardie: >>> On 22 April 2018, at 05:50, Wietse Venema wrote: >>> >>> Doug Hardie: >>>> I understood from the dnsblog man page that each dnsblog process >>>> only lives for a "limited amount of time". I noticed this because >>>> I have over 50 dnsblog processes running on a fairly light duty >>>> postfix server. Some of them are over a week old. At first I >>>> thought they must have been orphaned, but looking through maillog, >>>> I find entries in the last few minutes from the oldest and the >>>> newest. I didn't check all of them, but it appears they are all >>>> in use. Looking at the source for postfix-3.3-20180114 (on web), >>>> it appears dnsblog checks one IP address and then exits. I believe >>>> I can limit the number of dnsblog processes in master.cf (currently >>>> set to 0), but I am not sure that is a good idea. How long are >>>> these processes supposed to live? >>> >>> According to source, dnsblog processes exclude themselves from the >>> max_use limit (max_idle remains in effect). I suppose I turned off >>> max_use because these processes are postscreen helpers. Postscreen >>> was designed to handle a much larger client load than to the rest >>> of Postfix. Under extreme loads like 1+ connections/second, >>> one does not want to be creating 100+ processes/second, as that >>> would limit scalability. >>> >>> The dnsblog processes still terminate after 100s idle time. On my >>> lightly-loaded server, there currently is no dnsblog process running. > > I think that we can avoid the need for warnings in documentation, > by making the dnsblog service act according to the spirit of the > max_idle and max_use settings, even if it cannot act by the letter. > > With a given max_idle and max_use setting, a process is expected > to terminate within approximately (max_idle * max_use) seconds. > That is, on a low-volume (but not too low) server, a process may > hang around for a few hours (100*100 = 1 seconds). > > Even if the dnsblog process cannot enforce max_use literally (because > dbsnlog may have to handle a huge number of requests during peak > load), the process could still retire voluntarily after (max_idle > * max_use) seconds, without any negative performance impact. > > I'll look into implementing that. Either way works for me. I just got confused when I saw the durations of the processes and then read the man page. I thought I had configured something incorrectly as they didn't match. If I had your first response in the man page I would have said ahhh, now I understand. -- Doug
Re: dnsblog lifetime
> On 22 April 2018, at 05:50, Wietse Venema wrote: > > Doug Hardie: >> I understood from the dnsblog man page that each dnsblog process >> only lives for a "limited amount of time". I noticed this because >> I have over 50 dnsblog processes running on a fairly light duty >> postfix server. Some of them are over a week old. At first I >> thought they must have been orphaned, but looking through maillog, >> I find entries in the last few minutes from the oldest and the >> newest. I didn't check all of them, but it appears they are all >> in use. Looking at the source for postfix-3.3-20180114 (on web), >> it appears dnsblog checks one IP address and then exits. I believe >> I can limit the number of dnsblog processes in master.cf (currently >> set to 0), but I am not sure that is a good idea. How long are >> these processes supposed to live? > > According to source, dnsblog processes exclude themselves from the > max_use limit (max_idle remains in effect). I suppose I turned off > max_use because these processes are postscreen helpers. Postscreen > was designed to handle a much larger client load than to the rest > of Postfix. Under extreme loads like 1+ connections/second, > one does not want to be creating 100+ processes/second, as that > would limit scalability. > > The dnsblog processes still terminate after 100s idle time. On my > lightly-loaded server, there currently is no dnsblog process running. > > Apparently your server has enough traffic to keep postscreen alive, > and as a consequence, a collection of dnsblog processes. > > I suppose you could reduce max_idle, but don't go overboard and > set it to something small like 1s. That would be counterproductive. Thanks for the info. I never would have expected my server to be that busy. I would suggest that the man page for dnsblog be updated in the first paragraph of configuration parameters to something like: Changes to main.cf are picked up automatically as the dnsblog processes are started. The dnsblog processes terminate after 100 seconds of idle time. That is the default value and can be changed with the max idle configuration parameter. However, reducing it to a small value is likely to be counterproductive. Use the command "postfix reload" to speed up a change. -- Doug
dnsblog lifetime
I understood from the dnsblog man page that each dnsblog process only lives for a "limited amount of time". I noticed this because I have over 50 dnsblog processes running on a fairly light duty postfix server. Some of them are over a week old. At first I thought they must have been orphaned, but looking through maillog, I find entries in the last few minutes from the oldest and the newest. I didn't check all of them, but it appears they are all in use. Looking at the source for postfix-3.3-20180114 (on web), it appears dnsblog checks one IP address and then exits. I believe I can limit the number of dnsblog processes in master.cf (currently set to 0), but I am not sure that is a good idea. How long are these processes supposed to live? -- Doug
Re: undisclosed-recipients
> On 20 April 2018, at 01:30, Karel wrote: > > Hello, > > is it legitimate to use "To: undisclosed-recipients", or is to only > (mainly) used by spammers ? > > Seems to me, if I get an email, I should also know who else was the > email sent to. > Its like having a conference call and you don't know who's participating. > > If I wanted to block emails without any recipient, what would be the > best way to do it ? One good use of that is to prevent spam. If you are sending an email to a number of people (announcements etc.) then the normal response is for people to reply-all. That spams a lot of people who don't want to see those, or don't want their email address published. By using BCCs, you avoid both issues. -- Doug
Re: Certificate Replacement
> On 12 April 2018, at 16:35, Viktor Dukhovni > wrote: > > > >> On Apr 12, 2018, at 7:29 PM, Ian R. Bennett wrote: >> >>> I am needing to replace the certificate and key. Are they read and >>> cached when postfix starts, or are they read during normal mail >>> handling? In other words, can I replace the files or do I need to do >>> a reload or restart of the service afterwards? >> >> You'll need to restart postfix. > > That's false. Each smtpd(8) process handles a limited number of > connections ($max_use, default 100) and exits. It also exits when > idle for sufficiently long ($max_idle, default 100s). > > Since each smtpd(8) process reads the certificates for itself, unless > the cert/key rotation is extremely urgent (the current cert is > expired and causes problems, i.e. key rotation is too already too > late) there no need for a restart. > > And even when the key rotation is urgent "postfix reload" is sufficient, > you don't need to restart. This allows existing connections to finish > gracefully. That is even better. Thanks for the correction. Since the replacement is not time critical, the old certificates will have a few days validity remaining. One of those limits will certainly be reached by then. -- Doug
Re: Certificate Replacement
-- Doug > On 12 April 2018, at 16:29, Ian R. Bennett wrote: > > On 2018-04-12 16:25, Doug Hardie wrote: >> I am needing to replace the certificate and key. Are they read and >> cached when postfix starts, or are they read during normal mail >> handling? In other words, can I replace the files or do I need to do >> a reload or restart of the service afterwards? > > You'll need to restart postfix. Thanks. I suspect then the best approach is to stop the service, replace the certificates, and then start the service again. That is what I am having to do for dovecot anyway. -- Doug
Certificate Replacement
I am needing to replace the certificate and key. Are they read and cached when postfix starts, or are they read during normal mail handling? In other words, can I replace the files or do I need to do a reload or restart of the service afterwards? -- Doug
Re: Mail Routing Question
> On 16 November 2017, at 14:45, Viktor Dukhovni > wrote: > > > >> On Nov 16, 2017, at 5:32 PM, Doug Hardie wrote: >> >> I have a domain, say: aaa.com for which I receive mail. Currently I have A >> records in DNS for aaa.com and mail.aaa.com as well as a MX record for >> aaa.com. All three of them point to the same IP address which is where >> postfix is running. There is a political issue with the A record for >> aaa.com and it "needs" to be changed to elsewhere. I somehow seem to recall >> that there are some MTAs that do not use the MX records, but only check the >> A records. > > Any MTA that fails to check MX records is badly broken, and can barely > deliver email to any domains that matter (all the big players have > MX hosts separate from their A/ records used primarily for HTTP). > >> Will changing the A record for aaa.com cause the loss of some incoming mail > > No. > > -- > Viktor. > Thanks to all. I have changed the A record.
Mail Routing Question
I have a domain, say: aaa.com for which I receive mail. Currently I have A records in DNS for aaa.com and mail.aaa.com as well as a MX record for aaa.com. All three of them point to the same IP address which is where postfix is running. There is a political issue with the A record for aaa.com and it "needs" to be changed to elsewhere. I somehow seem to recall that there are some MTAs that do not use the MX records, but only check the A records. Will changing the A record for aaa.com cause the loss of some incoming mail? -- Doug
Re: Chinese Spam
Thanks. I went with: IF /^Message-id:/ /@qq\.com/ Reject ENDIF It's not all that pretty, but it works fine. I have been watching the logs and those messages are now being rejected. Thanks for all the help. -- Doug > On 7 September 2017, at 15:50, pgndev wrote: > > I missed the "message id" ... > > You should be able to match/block any valid header name. > > Add it to, or replace, what's in the match -- up to you. Personally, I've > never received a valid email from 'anything' @qq.com. YMMV. > > If you're shutting down a flood, more extreme, blunt instrument measures @ > the firewall (e.g. GeoIP blocking) can be put in place.
Re: Chinese Spam
> On 7 September 2017, at 15:28, pgndev wrote: > > It ain't pretty, or recommended for the long term, but something like this > should slow it down > > /etc/postfix/main.cf > header_checks = pcre:/etc/postfix/header_checks.pcre > > /etc/postfix/header_checks.pcre > IF /^(To|From|Cc|Reply-To|Sender|Return-Path): / > /@qq\.com/i REJECT > ENDIF > > (check the syntax!) > To block the message-id field shouldn't that be: IF /(Message-id):/ /@qq\.com/i REJECT ENDIF The qq.com only appears in the message-id, never in any of the addresses.
Chinese Spam
My server is being hit pretty hard by spam from China. Every email is from a different IP address. The only common item is the message id ends in @qq.com. Is there any way to block those with that ID? -- Doug
Re: Configuration Syntax
> On 7 July 2017, at 08:44, Noel Jones wrote: > > On 7/7/2017 12:37 AM, Doug Hardie wrote: >> >>> On 6 July 2017, at 12:40, Doug Hardie wrote: >>> >>>> >>>> On 6 July 2017, at 12:06, Noel Jones wrote: >>>> >>>> main.cf doesn't allow spaces in the options. The supported syntax >>>> is to either use commas "," rather than spaces; enclose the option >>>> in braces "{ ... }"; or the preferred method of defining a macro in >>>> main.cf and reference it in master.cf. See the master.cf man page. >>>> >>>> # main.cf >>>> my_smtpd_restrictions = >>>> check_policy_service inet:127.0.0.1:10040 >>>> reject_invalid_hostname, >>>> reject_non_fqdn_sender, >>>> reject_non_fqdn_recipient, >>>> reject_unknown_sender_domain, >>>> reject_unknown_recipient_domain, >>>> reject_unauth_pipelining, >>>> permit_mynetworks, >>>> reject_unauth_destination, >>>> reject_rbl_client bl.spamcop.net >>>> permit >>>> >>>> # master.cf >>>> smtpd pass - - n - - smtpd >>>> -o smtpd_recipient_restrictions=$my_smtpd_restrictions >>> >>> >>> Thanks. That makes sense now. >> >> Well, I thought I understood it, but now am not so sure so here is what I >> have ready to try. I still am a bit confused in the macro in main.cf some >> of the lines have a comma at the end and others do not. When is the comma >> needed? > > main.cf treats comma, space, tab, and newline, all as whitespace, > and they can be used interchangeably. Insert commas as desired for > readability. See the main.cf manpage. > >> >> main.cf >> # Incoming restrictions and Implement postfwd >> incoming_smtpd_restrictions = >>check_policy_service inet:127.0.0.1:10040 >>reject_invalid_hostname, >>reject_non_fqdn_sender, >>reject_non_fqdn_recipient, >>reject_unknown_sender_domain, >>reject_unknown_recipient_domain, >>reject_unauth_pipelining, >>permit_mynetworks, >>check_recipient_access hash:/usr/local/etc/postfix/tempfail >>reject_unauth_destination, >>reject_rbl_client bl.spamcop.net >>permit >> >> Virtual_alias_maps file: >> bc97...@lafn.orgdoug >> ... >> >> tempfail file: >> bc97...@lafn.org450 4.2.1 This mailbox is unavailable today >> >> >> master.cf: >> smtpd pass - - n - - smtpd >> submission inet n - n - - smtpd >>-o smtpd_recipient_restrictions=permit_mynetworks >> > > Your submission options must have a reject at the end. Most folks > use permit_sasl_authenticated instead of permit_mynetworks on > submission, but use whatever is correct for your server. > -o smtpd_recipient_restrictions=permit_mynetworks,reject > > Note master.cf syntax difference; no spaces around the comma. > > > -- Noel Jones Thank you. That was a clear explanation.
Re: Configuration Syntax
> On 6 July 2017, at 12:40, Doug Hardie wrote: > >> >> On 6 July 2017, at 12:06, Noel Jones wrote: >> >> main.cf doesn't allow spaces in the options. The supported syntax >> is to either use commas "," rather than spaces; enclose the option >> in braces "{ ... }"; or the preferred method of defining a macro in >> main.cf and reference it in master.cf. See the master.cf man page. >> >> # main.cf >> my_smtpd_restrictions = >> check_policy_service inet:127.0.0.1:10040 >> reject_invalid_hostname, >> reject_non_fqdn_sender, >> reject_non_fqdn_recipient, >> reject_unknown_sender_domain, >> reject_unknown_recipient_domain, >> reject_unauth_pipelining, >> permit_mynetworks, >> reject_unauth_destination, >> reject_rbl_client bl.spamcop.net >> permit >> >> # master.cf >> smtpd pass - - n - - smtpd >> -o smtpd_recipient_restrictions=$my_smtpd_restrictions > > > Thanks. That makes sense now. Well, I thought I understood it, but now am not so sure so here is what I have ready to try. I still am a bit confused in the macro in main.cf some of the lines have a comma at the end and others do not. When is the comma needed? main.cf # Incoming restrictions and Implement postfwd incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040 reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail reject_unauth_destination, reject_rbl_client bl.spamcop.net permit Virtual_alias_maps file: bc97...@lafn.orgdoug ... tempfail file: bc97...@lafn.org450 4.2.1 This mailbox is unavailable today master.cf: smtpd pass - - n - - smtpd submission inet n - n - - smtpd -o smtpd_recipient_restrictions=permit_mynetworks
Re: Returning an Error Response
Thanks for the pointers on that. I spent a couple days digging around and never found it. On 6 July 2017, at 12:06, /dev/rob0 wrote: > > > On Thu, Jul 06, 2017 at 11:45:01AM -0700, Doug Hardie wrote: >> When using virtual domains, > > (That part is not relevant.) > >> is there a way to return a temp fail message for a specific >> user in a domain? I am not finding anything about that in the >> documentation. > > http://www.postfix.org/SMTPD_ACCESS_README.html > http://www.postfix.org/access.5.html > http://www.postfix.org/postconf.5.html#check_recipient_access > > main.cf : > > ... > smtpd_recipient_restrictions = ... >check_recipient_access hash:/path/to/rcpt-tempfail >... > ... > > /path/to/rcpt-tempfail : > > u...@example.com 450 4.2.1 This mailbox is unavailable > > Don't forget: "postmap /path/to/rcpt-tempfail" > -- > http://rob0.nodns4.us/ > Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Configuration Syntax
I tried to implement RBL and postfwd. I placed everything in main.cf: smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040 reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, reject_unauth_destination, reject_rbl_client bl.spamcop.net permit That worked, but it affected both the smtp and submission ports. I expected that, but it made it easier to test. However, I then needed to make the submission port work properly. So I made the following change to master.cf and removed those lines from main.cf: smtpd pass - - n - - smtpd -o smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040 reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, reject_unauth_destination, reject_rbl_client bl.spamcop.net permit After a postfix reload basically everything stopped working. There were no errors reported in maillog. Basically, nothing was going into maillog. So I went back to the original configuration and it started working again. I then added the following to master.cf to remove those from submission port: submission inet n - n - - smtpd -o smtpd_recipient_restrictions=permit_mynetworks This approach works, but it seems to me that the first approach should have worked. Apparently I have formatted the options incorrectly. What did I do wrong? -- Doug
Returning an Error Response
When using virtual domains, is there a way to return a temp fail message for a specific user in a domain? I am not finding anything about that in the documentation.
Mail Forwarding
I thought I had everything working, but something broke. What I need to do is to accept mail for local delivery for several users on a couple domains (sermon-archive.info and one other) and relay mail for a number of users on domain (lafn.org) to a variety of different locations. Each user could be on a different server. My tests seemed to work, but when adding in the full tables, it broke. Here are the various config files etc: mail# postconf -n command_directory = /usr/local/sbin compatibility_level = 2 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 dovecot_destination_recipient_limit = 1 enable_long_queue_ids = yes home_mailbox = Maildir/ html_directory = /usr/local/share/doc/postfix inet_protocols = ipv4 local_recipient_maps = unix:passwd.byname $alias_maps mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_size_limit = 0 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man max_use = 5 message_size_limit = 102400 mydestination = localhost.$mydomain, localhost mydomain = sermon-archive.info mynetworks_style = host newaliases_path = /usr/local/bin/newaliases postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr postscreen_greet_action = enforce queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtp_destination_recipient_limit = 25 smtpd_authorized_xclient_hosts = 10.0.1.0/24 smtpd_command_filter = pcre:/usr/local/etc/postfix/quote smtpd_error_sleep_time = 10 smtpd_hard_error_limit = 10 smtpd_milters = unix:/var/run/clamav/clmilter.sock smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_soft_error_limit = 1 smtpd_tls_cert_file = /etc/ssl/certs/mail.pem smtpd_tls_key_file = /etc/ssl/private/mail.key smtpd_tls_loglevel = 1 smtpd_tls_security_level = may unknown_local_recipient_reject_code = 550 virtual_alias_domains = hash:/usr/local/etc/postfix/vmail_domains virtual_alias_maps = hash:/usr/local/etc/postfix/vmail_alias virtual_gid_maps = static: virtual_mailbox_base = /var/mail/ virtual_mailbox_domains = hash:/usr/local/etc/postfix/local_domains virtual_mailbox_limit = 102400 virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmail_mailbox virtual_minimum_uid = virtual_transport = dovecot virtual_uid_maps = static: mail# more local_domains sermon-archive.info OK mail.sermon-archive.infoOK second.domain OK mail# more vmail_alias postmaster doug bc979 doug bc979-1 edward bc979-4 jeanne user1 mailb...@gmail.com user2 mailb...@aol.com refund mailb...@hotmail.com Plus a bunch more. Other than postmaster, I thought that the left names should have @lafn.org, but that didn't seem to work either. mail# more vmail_domains lafn.orgOK mail# more vmail_mailbox d...@sermon-archive.infohome_mail/doug/ d...@mail.sermon-archive.info home_mail/doug/ I also wanted to be able to have different users with the same name of different addresses such as d...@sermon-archive.info and doug@second.domain and have them go to different places. Both seem to get local delivery to doug. I am sure I have something configured wrong. When I try to send from a non-local system I get the following: brain% telnet sermon-archive.info 25 Trying 71.177.216.148... Connected to sermon-archive.info. Escape character is '^]'. 220 mail.sermon-archive.info ESMTP Postfix helo me 250 mail.sermon-archive.info mail from:wa6...@arrl.net 250 2.1.0 Ok rcpt to:ref...@lafn.org 550 5.1.1 : Recipient address rejected: User unknown in virtual alias table — Doug
Re: Problems with aliases
> On 9 May 2017, at 22:19, James B. Byrne wrote: > > > On Wed, May 10, 2017 00:48, Doug Hardie wrote: >> I have a situation that is most likely a problem with my understanding >> of postfix and not a code problem. I am getting ready to take over a >> domain name for mail service. A number of new addresses in that >> domain need to be forwarded to other mail servers. I setup postfix to >> do that and it worked fine. However, there is still some time before >> I actually take over the domain. In the meantime I was entering some >> of the addresses and forwarding addresses into the vmail alias file. >> Each entry was preceded by "# ". My understanding was that lines >> starting with a # would be ignored. I did not bother to run postmap >> as it would do nothing useful. >> >> Several hours later I noticed that no outgoing mail was going out. >> Everything was receiving an error in maillog: >> > > If the source file has an mtime later than the resulting map file then > postfix will treat this as an error condition. At least this is my > experience so far. That is what I noticed although I didn't expect postfix to do anything different in that situation. > If you check your maillog file you will find > entries if this is the case. Several hours after I changed the file, those messages began to appear. > Further, if you rebuild a mapfile then > you must reload postfix for it to recognize the changes contained > therein. That doesn't seem correct. I just ran another test and added a valid forward in vmail_alias file and ran postmap on it. Then I sent to that address and sure enough it was delivered to the forward address. I did not run postfix reload or restart the service.
Problems with aliases
I have a situation that is most likely a problem with my understanding of postfix and not a code problem. I am getting ready to take over a domain name for mail service. A number of new addresses in that domain need to be forwarded to other mail servers. I setup postfix to do that and it worked fine. However, there is still some time before I actually take over the domain. In the meantime I was entering some of the addresses and forwarding addresses into the vmail alias file. Each entry was preceded by "# ". My understanding was that lines starting with a # would be ignored. I did not bother to run postmap as it would do nothing useful. Several hours later I noticed that no outgoing mail was going out. Everything was receiving an error in maillog: May 8 00:02:49 mail postfix/error[83540]: 8A72B114C3EE: to=, relay=none, delay=94792, delays=94792/0.03/0/0, dsn=4.3.0, status=deferred (mail transport unavailable) Note, this address was not in the vmail alias file. It appears to have affected all outgoing mail. Incoming mail was processed normally. In addition there were a number of these messages (starting hours later in the day): May 8 23:44:57 mail postfix/smtpd[95331]: warning: database /usr/local/etc/postfix/vmail_alias.db is older than source file /usr/local/etc/postfix/vmail_alias To restore service, I removed all these entries, ran post map and did postfix restart. Problem continued until I terminated postfix and restarted it. Then outgoing mail resumed delivery properly. mail# postconf -n command_directory = /usr/local/sbin compatibility_level = 2 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 dovecot_destination_recipient_limit = 1 home_mailbox = Maildir/ html_directory = /usr/local/share/doc/postfix inet_protocols = ipv4 mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_size_limit = 0 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man max_use = 5 message_size_limit = 10240 mydestination = localhost.$mydomain, localhost mydomain = sermon-archive.info mynetworks_style = subnet newaliases_path = /usr/local/bin/newaliases postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtp_destination_recipient_limit = 25 smtpd_authorized_xclient_hosts = 10.0.1.0/24 smtpd_command_filter = pcre:/usr/local/etc/postfix/quote smtpd_error_sleep_time = 10 smtpd_hard_error_limit = 10 smtpd_milters = unix:/var/run/clamav/clmilter.sock smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_soft_error_limit = 1 smtpd_tls_cert_file = /etc/ssl/certs/mail.pem smtpd_tls_key_file = /etc/ssl/private/mail.key smtpd_tls_loglevel = 1 smtpd_tls_security_level = may unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/usr/local/etc/postfix/vmail_alias virtual_gid_maps = static: virtual_mailbox_base = /var/mail/ virtual_mailbox_domains = hash:/usr/local/etc/postfix/vmail_domains virtual_mailbox_limit = 10240 virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmail_mailbox virtual_minimum_uid = virtual_transport = dovecot virtual_uid_maps = static: mail# mail# postconf -Mf smtpd pass - - n - - smtpd smtp inet n - n - 1 postscreen dnsblogunix - - n - 0 dnsblog tlsproxy unix - - n - 0 tlsproxy submission inet n - n - - smtpd dovecotunix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient} pickup unix n - n 60 1 pickup cleanupunix n - n - 0 cleanup qmgr unix n - n 300 1 qmgr tlsmgr unix - - n 1000? 1 tlsmgr rewriteunix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp showq unix n - n -