[pfx] Re: Fun with line endings, was Re: Mail text wrapping

[Doug Hardie via Postfix-users]

-- 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

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

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

[Doug Hardie via Postfix-users]

> 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

[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:

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?

[Doug Hardie via Postfix-users]

> 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?

[Doug Hardie via Postfix-users]

> 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=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

[Doug Hardie via Postfix-users]

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

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

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

[Doug Hardie via Postfix-users]

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

[Doug Hardie via Postfix-users]

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

[Doug Hardie via Postfix-users]

> 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 Hardie via Postfix-users]

-- 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?

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

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

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

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

[Doug Hardie via Postfix-users]

> 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 Hardie via Postfix-users]

-- 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 = 
> per

[pfx] Re: Blocked Sender

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

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

[Doug Hardie via Postfix-users]

> 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

[Doug Hardie via Postfix-users]

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: issue warning for deferred emails

[Doug Denault]

On Tue, 21 Feb 2023, Wietse Venema wrote:


Doug Denault:

On Mon, 20 Feb 2023, Wietse Venema wrote:


Doug Denault:

On Mon, 20 Feb 2023, Wietse Venema wrote:


Doug Denault:

The most current message (edited for privacy):

Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC: 
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport postfix/smtp[67456]: 7883F510EBC: 
to=, relay=none, delay=329206,
  delays=329205/0.08/0.27/0, dsn=4.4.1, status=deferred (connect to 
mcahd.com[10.86.238.4]:25: Connection refused)


Where is the proof that the message actually had delay_warning_time on?

postcat -eq 7883F510EBC | grep warning_message_time


lighthouse:/usr/l|ocal/etc/postfix> postconf -n

  |
No, I asked for po|stcat output.

|
What option? I did t|hem all and did not see anything I thought shed any
more light on this. |I can send any option but need to edit out the email
body if you need one| of those options.

 |
This command:-+

postcat -eq 7883F510EBC | grep warning_message_time

If the output is empty, then you did not enable delay warnings.

You may have to specify a different queue ID than 7883F510EBC, if
that message has already been returned to the sender.


Thank you. It is not empty but I am not sure what I am looking at:

postcat -eq 7883F510EBC | grep warning_message_time
warning_message_time: Wed Dec 31 18:59:59 1969

postcat -eq 7883F510EBC | grep -B 2 -A 2 warning_message_time
named_attribute: protocol_name=ESMTP
named_attribute: client_address_type=2
warning_message_time: Wed Dec 31 18:59:59 1969
named_attribute: dsn_orig_rcpt=rfc822;mwplach...@yahoo.com
original_recipient: mwplach...@yahoo.com

postcat -eq 7883F510EBC | egrep "\ .+:.+:.+"
message_arrival_time: Thu Feb 16 13:58:29 2023
create_time: Thu Feb 16 13:58:29 2023
warning_message_time: Wed Dec 31 18:59:59 1969

The email was sent to a number of people. Only the one address did not set 
delivered. Size of attachment is my working guess. Probably disappears from 
the queue today, but it's still there now.


mailq | grep -A 2 7883F510EBC
7883F510EBC 1943447 Thu Feb 16 13:58:29  i...@bcr-dc.com
   (connect to mcahd.com[154.86.238.4]:25: Connection refused)
 smacdon...@mcahd.com

So this means the message was sent? Don't know what to make of the date. 
The sender claims not to have received it but I know to search the mail 
logs 8 hours after the original time.


The `postcat -qe 7883F510EBC` had 151 lines so I missed the thing you were 
looking for. Thank you, learned lots of useful commands from this.


Doug

_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

Re: issue warning for deferred emails

[Doug Denault]

On Mon, 20 Feb 2023, Wietse Venema wrote:


Doug Denault:

On Mon, 20 Feb 2023, Wietse Venema wrote:


Doug Denault:

The most current message (edited for privacy):

Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC: 
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport postfix/smtp[67456]: 7883F510EBC: 
to=, relay=none, delay=329206,
  delays=329205/0.08/0.27/0, dsn=4.4.1, status=deferred (connect to 
mcahd.com[10.86.238.4]:25: Connection refused)


Where is the proof that the message actually had delay_warning_time on?

postcat -eq 7883F510EBC | grep warning_message_time


lighthouse:/usr/local/etc/postfix> postconf -n


No, I asked for postcat output.


What option? I did them all and did not see anything I thought shed any 
more light on this. I can send any option but need to edit out the email 
body if you need one of those options.



_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

Re: issue warning for deferred emails

[Doug Denault]

On Mon, 20 Feb 2023, Rob McGee wrote:


On 2/20/2023 4:20 PM, Doug Denault wrote:

On Mon, 20 Feb 2023, Wietse Venema wrote:


Doug Denault:

The most current message (edited for privacy):

Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC: 
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport postfix/smtp[67456]: 7883F510EBC: 
to=, relay=none, delay=329206,
  delays=329205/0.08/0.27/0, dsn=4.4.1, status=deferred (connect to 
mcahd.com[10.86.238.4]:25: Connection refused)


Where is the proof that the message actually had delay_warning_time on?

postcat -eq 7883F510EBC | grep warning_message_time


This was empty, because ...


lighthouse:/usr/local/etc/postfix> postconf -n


snip


delay_warning_time = 8h html_directory = /usr/local/share/doc/postfix


This indicates a typo in main.cf: no newline, or leading whitespace on the 
line for html_directory.  Prove it to yourself:


postconf delay_warning_time


lighthouse:/usr/local/etc/postfix> postconf delay_warning_time
delay_warning_time = 8h
lighthouse:/usr/local/etc/postfix>

I made a cut & paste mistake. I should read all my messages before 
responding. You guys are beyond helpful. I am very sorry for all the extra 
emails and my postconf server error.


_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

Re: issue warning for deferred emails

[Doug Denault]

On Mon, 20 Feb 2023, Rob McGee wrote:


On 2/20/2023 9:25 AM, Doug Denault wrote:

On Mon, 20 Feb 2023, Wietse Venema wrote:


Doug Denault:

On Sun, 19 Feb 2023, Viktor Dukhovni wrote:


On Sun, Feb 19, 2023 at 10:35:43PM -0500, Doug Denault wrote:


With my setup no warning is deferred errors such as 'time out' or
'Connection refused' until the message is delete from the queue.



snip


The most current message (edited for privacy):

Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC: 
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport postfix/smtp[67456]: 7883F510EBC: 
to=, relay=none, delay=329206,
  delays=329205/0.08/0.27/0, dsn=4.4.1, status=deferred (connect to 
mcahd.com[10.86.238.4]:25: Connection refused)


The mailq output:

7883F510EBC 1943447 Thu Feb 16 13:58:29  i...@bcr-dc.com
    (connect to domain2.com[10.86.238.4]:25: Connection refused)
    some...@domain2.com


It appears that the real issue here may be a port 25 block placed by your 
provider. Postfix settings can't change that. You would have to contact your 
provider and ask to be unblocked.


I did make a mistake but port 25 is not the issue we run our mailservers. 
My mistake was posting the wrong postconf. It also has the 
'delay_warning_time = 8h' statement but other changes.


freeport:~doug# postconf -n
allow_untrusted_routing = no
broken_sasl_auth_clients = yes
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

delay_warning_time = 8h
html_directory = /usr/local/share/doc/postfix
inet_interfaces = $myhostname, 127.0.0.1
inet_protocols = ipv4
local_recipient_maps =
mail_owner = postfix
mailbox_size_limit = 2
mailbox_transport = lmtp:unix:/var/imap/socket/lmtp
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 1
meta_directory = /usr/local/libexec/postfix
mynetworks = 147.160.157.114/32, 127.0.0.0/8, 147.160.157.240/32, 
147.160.157.31/32 198.74.231.101/32 147.160.157.15/32 173.79.46.3/32

mynetworks_style = subnet
myorigin = $myhostname
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination mail2.safeport.com bucksport.safeport.com 
dovecot.safeport.com

sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
shlib_directory = /usr/local/lib/postfix
smtp_generic_maps = hash:/usr/local/etc/postfix/generic
smtpd_enforce_tls = no
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = freeport.safeport.com
smtpd_sasl_path = smtpd
smtpd_tls_CAfile = /usr/local/etc/postfix/ssl/ov_safeport_ca-bundle.crt
smtpd_tls_ask_ccert = no
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/postfix/ssl/ov_safeport_com.crt
smtpd_tls_key_file = /usr/local/etc/postfix/ssl/ov_safeport_com.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
unknown_local_recipient_reject_code = 550
virtual_alias_domains = $virtual_alias_maps
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual 
regexp:/usr/local/etc/postfix/virtual.regexp

freeport:~doug#

I apologize for that error.

_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

Re: issue warning for deferred emails

[Doug Denault]

On Mon, 20 Feb 2023, Wietse Venema wrote:


Doug Denault:

The most current message (edited for privacy):

Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC: 
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport postfix/smtp[67456]: 7883F510EBC: 
to=, relay=none, delay=329206,
  delays=329205/0.08/0.27/0, dsn=4.4.1, status=deferred (connect to 
mcahd.com[10.86.238.4]:25: Connection refused)


Where is the proof that the message actually had delay_warning_time on?

postcat -eq 7883F510EBC | grep warning_message_time


lighthouse:/usr/local/etc/postfix> postconf -n
allow_untrusted_routing = no
broken_sasl_auth_clients = yes
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
delay_warning_time = 8h 
html_directory = /usr/local/share/doc/postfix

inet_interfaces = $myhostname, localhost
inet_protocols = ipv4
local_recipient_maps =
mail_owner = postfix
mailbox_size_limit = 2
mailbox_transport = lmtp:unix:/var/imap/socket/lmtp
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 1
meta_directory = /usr/local/libexec/postfix
mynetworks = 147.160.157.16/32, 127.0.0.0/8
mynetworks_style = subnet
myorigin = $myhostname
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination mail2.safeport.com
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
shlib_directory = /usr/local/lib/postfix
smtpd_enforce_tls = no
smtpd_recipient_restrictions = permit_mynetworks, 
permit_sasl_authenticated, reject_invalid_hostname, reject_non_fqdn_sender, 
reject_non_fqdn_recipient, reject_unknown_recipient_domain, 
reject_unknown_sender_domain, reject_unauth_destination, 
check_client_access hash:/usr/local/etc/postfix/access, 
reject_unauth_pipelining, reject_rbl_client bl.spamcop.net

smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = lighthouse.safeport.com
smtpd_sasl_path = smtpd
smtpd_sasl_type = cyrus
smtpd_tls_CAfile = /usr/local/etc/postfix/ssl/ov_safeport_ca-bundle.crt
smtpd_tls_ask_ccert = no
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/postfix/ssl/ov_safeport_com.crt
smtpd_tls_key_file = /usr/local/etc/postfix/ssl/ov_safeport_com.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
unknown_local_recipient_reject_code = 550
virtual_alias_domains = $virtual_alias_maps
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual 
regexp:/usr/local/etc/postfix/virtual.regexp

lighthouse:/usr/local/etc/postfix>

_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

Re: issue warning for deferred emails

[Doug Denault]

On Mon, 20 Feb 2023, Wietse Venema wrote:


Doug Denault:

On Sun, 19 Feb 2023, Viktor Dukhovni wrote:


On Sun, Feb 19, 2023 at 10:35:43PM -0500, Doug Denault wrote:


With my setup no warning is deferred errors such as 'time out' or
'Connection refused' until the message is delete from the queue.

I added:

   delay_warning_time = 8h

to main.cf. This made no difference so I assume an additional setting is
required, but I could not find anything.


This setting only affects *new* messages.  Messages already in the queue
will not elicit the warning.  There's a queue-file record for that...


I'm sorry I was not clear. New messages do not get the warning.

This is a FreeBSD 12.2-RELEASE-p7. postfix 3.6.2_1


Postfix does not immediately send "delayed mail" warnings as soon
as a message exceeds the warning time limit. That would not scale.

Instead, Postfix attempts to deliver a message, and when that attempt
fails, it sends a "delayed mail" warning message once.


Thank you. If I understand your answer, I do not think that is what I am 
seeing. What is happening is an email that gets a 'time out' or some such 
will continuusly give deferred messages for five days and then, if I let 
things go that long, remove the email and send the bounce message.


A crrent example follows. I rotate logs daily so this gives a daily count 
of the number of messages.


bzgrep -c 7883F510EBC maillog maillog.?.bz2
maillog:18-- today
maillog.0.bz2:42  -- 2/19
maillog.1.bz2:42  -- 2/18
maillog.2.bz2:42  -- 2/17
maillog.3.bz2:75  -- 2/16

The most current message (edited for privacy):

Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC: 
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport postfix/smtp[67456]: 7883F510EBC: 
to=, relay=none, delay=329206,
 delays=329205/0.08/0.27/0, dsn=4.4.1, status=deferred (connect to 
mcahd.com[10.86.238.4]:25: Connection refused)

The mailq output:

7883F510EBC 1943447 Thu Feb 16 13:58:29  i...@bcr-dc.com
   (connect to domain2.com[10.86.238.4]:25: Connection refused)
   some...@domain2.com

_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

Re: issue warning for deferred emails

[Doug Denault]

On Sun, 19 Feb 2023, Viktor Dukhovni wrote:


On Sun, Feb 19, 2023 at 11:03:31PM -0500, Doug Denault wrote:


I added:

   delay_warning_time = 8h

to main.cf. This made no difference so I assume an additional setting is
required, but I could not find anything.


This setting only affects *new* messages.  Messages already in the queue
will not elicit the warning.  There's a queue-file record for that...


I'm sorry I was not clear. New messages do not get the warning.

This is a FreeBSD 12.2-RELEASE-p7. postfix 3.6.2_1


   https://www.postfix.org/DEBUG_README.html#mail
   https://www.postfix.org/DEBUG_README.html#logging


postfinger - postfix configuration on Mon Feb 20 09:48:38 EST 2023
version: 1.30

Warning: postfinger output may show private configuration information,
such as ip addresses and/or domain names which you do not want to show
to the public.  If this is the case it is your responsibility to modify
the output to hide this private information.  [Remove this warning with
the --nowarn option.]

--System Parameters--
mail_version = 3.6.2
hostname = lighthouse.safeport.com
uname = FreeBSD lighthouse.safeport.com 12.2-RELEASE-p7 FreeBSD 
12.2-RELEASE-p7 GENERIC  amd64


--Packaging information--

--main.cf non-default parameters--
broken_sasl_auth_clients = yes
compatibility_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
$daemon_directory/$process_name $process_id & sleep 5

delay_warning_time = 8h
inet_interfaces = $myhostname, localhost
inet_protocols = ipv4
local_recipient_maps =
mailbox_size_limit = 2
mailbox_transport = lmtp:unix:/var/imap/socket/lmtp
message_size_limit = 1
mynetworks = 147.160.157.16/32, 127.0.0.0/8
mynetworks_style = subnet
recipient_delimiter = +
relay_domains = $mydestination mail2.safeport.com
smtpd_recipient_restrictions = permit_mynetworks, 
permit_sasl_authenticated, reject_invalid_hostname, reject_non_fqdn_sender, 
reject_non_fqdn_recipient, reject_unknown_recipient_domain, 
reject_unknown_sender_domain, reject_unauth_destination, 
check_client_access hash:/usr/local/etc/postfix/access, 
reject_unauth_pipelining, reject_rbl_client bl.spamcop.net

smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = lighthouse.safeport.com
smtpd_tls_CAfile = /usr/local/etc/postfix/ssl/ov_safeport_ca-bundle.crt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/postfix/ssl/ov_safeport_com.crt
smtpd_tls_key_file = /usr/local/etc/postfix/ssl/ov_safeport_com.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_use_tls = yes
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual 
regexp:/usr/local/etc/postfix/virtual.regexp


--master.cf--
smtp  inet  n   -   n   -   -   smtpd
submission inet n   -   n   -   -   smtpd
smtps inet  n   -   n   -   -   smtpd
pickupunix  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  unix  n   -   n   300 1   qmgr
tlsmgrunix  -   -   n   1000?   1   tlsmgr
rewrite   unix  -   -   n   -   -   trivial-rewrite
bounceunix  -   -   n   -   0   bounce
defer unix  -   -   n   -   0   bounce
trace unix  -   -   n   -   0   bounce
verifyunix  -   -   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
-o syslog_name=postfix/$service_name
showq unix  n   -   n   -   -   showq
error unix  -   -   n   -   -   error
retry unix  -   -   n   -   -   error
discard   unix  -   -   n   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   n   -   -   lmtp
anvil unix  -   -   n   -   1   anvil
scacheunix  -   -   n   -   1   scache
postlog   unix-dgram n  -   n   -   1   postlogd

-- end of postfinger output --



_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

Re: issue warning for deferred emails

[Doug Denault]

On Sun, 19 Feb 2023, Viktor Dukhovni wrote:


On Sun, Feb 19, 2023 at 10:35:43PM -0500, Doug Denault wrote:


With my setup no warning is deferred errors such as 'time out' or
'Connection refused' until the message is delete from the queue.

I added:

   delay_warning_time = 8h

to main.cf. This made no difference so I assume an additional setting is
required, but I could not find anything.


This setting only affects *new* messages.  Messages already in the queue
will not elicit the warning.  There's a queue-file record for that...


I'm sorry I was not clear. New messages do not get the warning.

This is a FreeBSD 12.2-RELEASE-p7. postfix 3.6.2_1

_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

issue warning for deferred emails

[Doug Denault]

With my setup no warning is deferred errors such as 'time out' or 
'Connection refused' until the message is delete from the queue.


I added:

  delay_warning_time = 8h

to main.cf. This made no difference so I assume an additional setting is 
required, but I could not find anything.



_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

Re: Integrating mailman with postfix

[Doug Hardie]

> 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

[Doug Hardie]

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
send

Re: RBL timing

[Doug Hardie]

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

[Doug Hardie]

> 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

[Doug Hardie]

> 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

[Doug Hardie]

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

Re: postfix will not send

[Doug Denault]

On Fri, 31 Dec 2021, Wietse Venema wrote:


John Fawcett:

On 31/12/2021 10:36, Doug Denault wrote:

This is a postfix/cyrus/mysql system running in a FreeBSD jail. It is
(as far as I can make it) identical to a bare metal with the same
configuration. Delivery & reading email works fine, the jailed system
will not send email failing with:

cyrus postfix/smtpd[51745]: warning: SASL: Connect to smtpd failed: No
such file or directory
cyrus postfix/smtpd[51745]: fatal: no SASL authentication mechanisms


The warning message (at least in the latest version of postfix) is given
only for smtpd_sasl_type = dovecot, so seems that dovecot SASL is
configured, not cyrus SASL and postfix is interpreting "smtpd" which is
your smtpd_sasl_path setting as the dovecot socket path to connect to
for authentication.


That message neewds to be improved. As of Postfix 3.7 it will be:

   warning: SASL: Connect to Dovecot auth socket 'smtpd' failed: ...

which would save some head scratching.


Thank you all. That is indeed the problem. My problem is further compounded 
by FreeBSD in postfix-3.5.6,1 the package is built with cyrus support 
however postfix-3.6.2_1,1 is apparently built without cyrus support.


cyrus:~> postconf -A
cyrus:

cyrus:~> postconf -a
dovecot

setting smtpd_sasl_type = cyrus begets
   warning: unsupported SASL server implementation: cyrus
   fatal: SASL per-process initialization failed

Fix is trivial but not without the help I got here, Thank again to all and 
Happy New Year


Doug

_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

postfix will not send

[Doug Denault]

This is a postfix/cyrus/mysql system running in a FreeBSD jail. It is (as 
far as I can make it) identical to a bare metal with the same 
configuration. Delivery & reading email works fine, the jailed system will 
not send email failing with:


cyrus postfix/smtpd[51745]: warning: SASL: Connect to smtpd failed: No such 
file or directory
cyrus postfix/smtpd[51745]: fatal: no SASL authentication mechanisms

postconf -n
allow_untrusted_routing = no
broken_sasl_auth_clients = yes
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

html_directory = /usr/local/share/doc/postfix
inet_interfaces = $myhostname, localhost
inet_protocols = ipv4
local_recipient_maps =
mail_owner = postfix
mailbox_size_limit = 2
mailbox_transport = lmtp:unix:/var/imap/socket/lmtp
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 1
meta_directory = /usr/local/libexec/postfix
mynetworks = xxx.xxx.157.16/32, 127.0.0.0/8
mynetworks_style = subnet
myorigin = $myhostname
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination mail2.safeport.com
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
shlib_directory = /usr/local/lib/postfix
smtpd_enforce_tls = no
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = cyrus.safeport.com
smtpd_sasl_path = smtpd
smtpd_tls_CAfile = /usr/local/etc/postfix/ssl/ov_safeport_ca-bundle.crt
smtpd_tls_ask_ccert = no
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/postfix/ssl/ov_safeport_com.crt
smtpd_tls_key_file = /usr/local/etc/postfix/ssl/ov_safeport_com.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
unknown_local_recipient_reject_code = 550
virtual_alias_domains = $virtual_alias_maps
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual 
regexp:/usr/local/etc/postfix/virtual.regexp


don't see it and all the internet seems to use dovecot but I don't see how 
whatever imap impacks smtp. Thanks for any thoughts


_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

RE: postscreen_dnsbl_reply_map & rbl_reply_maps

[Doug Sampson]

> Doug Sampson:
> > I've opened an account with Spamhaus to use their Data Query
> > Service. I've reconfigured the main.cf to incorporate the necessary
> > adjustments.
> >
> > One thing I've noticed that when the maps (postscreen_dnsbl_reply_map
> > & rbl_reply_maps) as recommended by Spamhaus are implemented, the
> > results of these DQS tests aren't published in the mail log.
> > Consequently the spamrep_today report is missing such information.
> 
> What results?
> What are DQS test

Spamhaus provides enhanced real-time blocklists. See 
https://www.spamhaus.com/product/data-query-service/ for more information.

~D

RE: postscreen_dnsbl_reply_map & rbl_reply_maps

[Doug Sampson]

> I have followed their manual and it works.
> 
>  postfix/dnsblog[6907]: addr 116.255.29.67 listed by domain MY-API-
> KEY.zen.dq.spamhaus.net as 127.0.0.3
>  postfix/dnsblog[6907]: addr 116.255.29.67 listed by domain MY-API-
> KEY.zen.dq.spamhaus.net as 127.0.0.4
>  postfix/dnsblog[6909]: addr 116.255.29.67 listed by domain
> hostkarma.junkemailfilter.com as 127.0.0.3
>  postfix/dnsblog[6909]: addr 116.255.29.67 listed by domain
> hostkarma.junkemailfilter.com as 127.0.1.1
>  postfix/postscreen[6901]: DNSBL rank 7 for [116.255.29.67]:25749
>  postfix/postscreen[6901]: DISCONNECT [116.255.29.67]:25749
> 
> 
> The API key is only printed to the logs replies go as zen.spamhaus.org
[> ] 


Alas, it seems I spoke too soon. I am seeing the zen.dq.spamhaus.net entries 
with my API key embedded. Sorry for the noise!

~D

postscreen_dnsbl_reply_map & rbl_reply_maps

[Doug Sampson]

I've opened an account with Spamhaus to use their Data Query Service. I've 
reconfigured the main.cf to incorporate the necessary adjustments.

One thing I've noticed that when the maps (postscreen_dnsbl_reply_map & 
rbl_reply_maps) as recommended by Spamhaus are implemented, the results of 
these DQS tests aren't published in the mail log. Consequently the 
spamrep_today report is missing such information.

Is there a way to incorporate these maps and publish the test results in the 
mail log?

~Doug

Logged Recipient

[Doug Hardie]

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

[Doug Hardie]

> 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

[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


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

[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?

-- Doug

Re: Stucked with "unable to look up host"

[Doug Hardie]

> 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?

[Doug Hardie]

> 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: can not send mail was Postfix users not listening ...

[Doug Denault]

On Mon, 31 Aug 2020, Noel Jones wrote:

Staring at postconf (or somewhat easier, postconf -n) output is unlikely to 
fix this without clues in the log of what the problem is.


Start here:
http://www.postfix.org/DEBUG_README.html#logging

If you need more help from us:
http://www.postfix.org/DEBUG_README.html#mail


Thank you, links did the trick as you suggested

_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

can not send mail was Postfix users not listening ...

[Doug Denault]

On Mon, 31 Aug 2020, Bill Cole wrote:


On 30 Aug 2020, at 20:24, Doug Denault wrote:



working system:
   lighthouse:~> sockstat | egrep "postfix|master" | egrep ":[2\5]+"
   postfix  smtpd  98709 6  tcp4   *:25  *:*
   postfix  smtpd  98656 6  tcp4   *:25  *:*
   postfix  smtpd  98656 19 tcp4   127.0.0.1:53654
   127.0.0.1:10023
   postfix  smtpd  98612 6  tcp4   *:25  *:*
   root master 52014 12 tcp4   *:25  *:*
   root master 52014 16 tcp4   *:587 *:*

The one in question
   freeport:~> sockstat | egrep "postfix|master" | egrep ":[2\5]+"
   root master 3938  13 tcp4   *:25  *:*
   root master 3938  17 tcp4   *:587 *:*


That's absolutely normal. Postfix's 'master' process only spawns smtpd 
processes as needed to handle SMTP sessions. As shown, it listens on any 
ports that need persistent listeners, and hands off connections to child 
processes.


Actual log entries and actual configuration are essential information.


Thanks, I will look at the debugging link, perhaps I've not been there. BTW 
I fully understand it is likely I've done something really dumb. In 
comparing the setup with a kerberos system, one running webmail and a older 
version of the setup I am testing all work and I can not see/find any 
differences.


I was not clear. The system receives email just fine. It will not send. 
There are no log entries. The above output is from sockstat. I do not know 
what or if the linux equivalent is. On all the working systems the 
processes listed as postfix are present. They seem to be needed/used by the 
email clients to communicate with postfix to send mail. The sockstat output 
from a running system:


USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS
postfix  smtp   7130  6  stream private/smtp
postfix  smtp   7130  7  dgram  -> /var/run/logpriv
postfix  smtpd  7129  6  tcp4   *:587 *:*
postfix  smtpd  7129  7  dgram  -> /var/run/logpriv
postfix  smtpd  7129  18 stream -> private/anvil
postfix  lmtp   7070  6  stream private/lmtp
postfix  lmtp   7070  7  dgram  -> /var/run/logpriv
postfix  local  7069  6  stream private/local
postfix  local  7069  7  dgram  -> /var/run/logpriv
postfix  cleanup7068  6  stream public/cleanup
postfix  cleanup7068  7  dgram  -> /var/run/logpriv
postfix  cleanup7068  16 stream -> private/rewrite
postfix  smtpd  7067  6  tcp4   *:25  *:*
postfix  smtpd  7067  7  dgram  -> /var/run/logpriv
postfix  smtpd  7067  18 stream -> private/anvil
postfix  smtpd  7067  20 tcp4   127.0.0.1:57874   127.0.0.1:10023
postfix  cleanup7066  6  stream public/cleanup
postfix  cleanup7066  7  dgram  -> /var/run/logpriv
postfix  cleanup7062  6  stream public/cleanup
postfix  cleanup7062  7  dgram  -> /var/run/logpriv
postfix  cleanup7062  16 stream -> private/rewrite
postfix  trivial-re 7027  6  stream private/rewrite
postfix  trivial-re 7027  7  dgram  -> /var/run/logpriv
postfix  trivial-re 7027  128 streamprivate/rewrite
postfix  trivial-re 7027  129 streamprivate/rewrite
postfix  trivial-re 7027  129 streamprivate/rewrite
postfix  trivial-re 7027  131 streamprivate/rewrite
postfix  trivial-re 7027  132 streamprivate/rewrite
postfix  smtpd  6994  6  tcp4   *:25  *:*
postfix  smtpd  6994  7  dgram  -> /var/run/logpriv
postfix  smtpd  6994  17 stream -> private/tlsmgr
postfix  smtpd  6994  18 stream -> private/rewrite
postfix  smtpd  6994  19 stream -> private/anvil
postfix  smtpd  6994  20 tcp4   127.0.0.1:48692   127.0.0.1:10023
postfix  lmtp   6991  6  stream private/lmtp
postfix  lmtp   6991  7  dgram  -> /var/run/logpriv
postfix  lmtp   6990  6  stream private/lmtp
postfix  lmtp   6990  7  dgram  -> /var/run/logpriv
postfix  local  6989  6  stream private/local
postfix  local  6989  7  dgram  -> /var/run/logpriv
postfix  local  6988  6  stream private/local
postfix  local  6988  7  dgram  -> /var/run/logpriv
postfix  lmtp   6957  6  stream private/lmtp
postfix  lmtp   6957  7  dgram  -> /var/run/logpriv
postfix  local  6956  6  stream private/local
postfix  local  6956  7  dgram  -> /var/run/logpriv
postfix  smtpd  6936  6  tcp4   *:25  *:*
postfix  smtpd  6936  7  dgram  -> /var/run/logpriv
postfix  smtpd  6936  17 stream -> private/tlsmgr
postfix  smtpd  6936  18 stream -> private/anvil
postfix  smtpd  6936  19 stream -> private/rewrite
postfix  smtpd  6936  20 tcp4   127.0.0.1:59645   127.0.0.1:10023
postfix  smtpd  6935  6  tcp4   *:25  *:*
postfix  smtpd  6935  7  dgram  -> /var/run/

Re: postfix not listening on 25/587

[Doug Denault]

On Sun, 30 Aug 2020, Noel Jones wrote:


On 8/30/2020 2:57 PM, Doug Denault wrote:
I am upgrading from postfix-2.8.7,1 and cyrus-imapd-2.3.18 to 
postfix-3.5.6,1 and cyrus-imapd30-3.0.14. The old system uses sasldb 
authentication, the new one MySQL. This is on FreeBSD.


I have compared the conf files on two addition postfix systems and can see 
no differences of consequence. I am not sure which files or parts thereof 
to show. I am kind of surprised postfix can be encouraged not to listen on 
these ports. I am quite lost and can supply whatever information that will 
help anyone with a idea on how I messed this up.


_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
   Fax: 301-217-9277



Likely is postfix is failing to start, with clues in the logfile.
http://www.postfix.org/DEBUG_README.html#logging

If you need to ask for further help:
http://www.postfix.org/DEBUG_README.html#mail


Thank you for your thought, but not exactly. Postfix sort starts, cyrus is 
all there:


working system:
   lighthouse:~> sockstat | egrep "postfix|master" | egrep ":[2\5]+"
   postfix  smtpd  98709 6  tcp4   *:25  *:*
   postfix  smtpd  98656 6  tcp4   *:25  *:*
   postfix  smtpd  98656 19 tcp4   127.0.0.1:53654
   127.0.0.1:10023
   postfix  smtpd  98612 6  tcp4   *:25  *:*
   root master 52014 12 tcp4   *:25  *:*
   root master 52014 16 tcp4   *:587 *:*

The one in question
   freeport:~> sockstat | egrep "postfix|master" | egrep ":[2\5]+"
   root master 3938  13 tcp4   *:25  *:*
   root master 3938  17 tcp4   *:587 *:*

Any thought much appreciated. The only difference between two of the 
other postfix/cyrus systems: one use sasldb, the other kerberos. The Not 
working one uses mysql. There are some cyrus gliches not relevant to 
this list. On the post fix front, the system can receive email, that's 
what master does, it can not send email. Apparently what postfix does.


Honestly as for RTFM, been there, done that. Did little for mysql all 
help there came from /var/log/messages and sql errors.


_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

postfix not listening on 25/587

[Doug Denault]

I am upgrading from postfix-2.8.7,1 and cyrus-imapd-2.3.18 to 
postfix-3.5.6,1 and cyrus-imapd30-3.0.14. The old system uses sasldb 
authentication, the new one MySQL. This is on FreeBSD.


I have compared the conf files on two addition postfix systems and can see 
no differences of consequence. I am not sure which files or parts thereof 
to show. I am kind of surprised postfix can be encouraged not to listen on 
these ports. I am quite lost and can supply whatever information that will 
help anyone with a idea on how I messed this up.


_
Douglas Denault
http://www.safeport.com
d...@safeport.com
Voice: 301-217-9220
  Fax: 301-217-9277

Re: Questions about the master.cf file

[Doug Hardie]

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/

Re: Preferred/maintained greylisting options?

[Doug Hardie]

> 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?

[Doug Hardie]

> 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

[Doug Hardie]

> 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

[Doug Hardie]

> 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

[Doug Hardie]

> 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?

[Doug Hardie]

> 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

[Doug Hardie]

> 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

[Doug Hardie]

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

[Doug Hardie]

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

[Doug Hardie]

> 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

[Doug Hardie]

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

[Doug Hardie]

> 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

[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.

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

[Doug Hardie]

> 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

[Doug Hardie]

> On 23 May 2018, at 13:41, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> 
> 
> 
>> On May 23, 2018, at 4:10 PM, Doug Hardie <bc...@lafn.org> 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

[Doug Hardie]

> On 23 May 2018, at 13:17, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> 
> 
> 
>> On May 23, 2018, at 4:10 PM, Doug Hardie <bc...@lafn.org> 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

[Doug Hardie]

> On 23 May 2018, at 11:43, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> 
> 
> 
>> On May 23, 2018, at 2:23 PM, Doug Hardie <bc...@lafn.org> 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

[Doug Hardie]

> On 23 May 2018, at 09:24, /dev/rob0 <r...@gmx.co.uk> 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

[Doug Hardie]

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

[Doug Hardie]

> On 24 April 2018, at 13:48, Wietse Venema <wie...@porcupine.org> wrote:
> 
> Doug Hardie:
>>> On 22 April 2018, at 05:50, Wietse Venema <wie...@porcupine.org> 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

[Doug Hardie]

> On 22 April 2018, at 05:50, Wietse Venema <wie...@porcupine.org> 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

[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?

-- Doug

Re: undisclosed-recipients

[Doug Hardie]

> On 20 April 2018, at 01:30, Karel <postfix-us...@vcomp.ch> 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

[Doug Hardie]

> On 12 April 2018, at 16:35, Viktor Dukhovni <postfix-us...@dukhovni.org> 
> wrote:
> 
> 
> 
>> On Apr 12, 2018, at 7:29 PM, Ian R. Bennett <i...@maleficarum.org> 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 Hardie]

-- Doug

> On 12 April 2018, at 16:29, Ian R. Bennett <i...@maleficarum.org> 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

[Doug Hardie]

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

[Doug Hardie]

> On 16 November 2017, at 14:45, Viktor Dukhovni <postfix-us...@dukhovni.org> 
> wrote:
> 
> 
> 
>> On Nov 16, 2017, at 5:32 PM, Doug Hardie <bc...@lafn.org> 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

[Doug Hardie]

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

[Doug Hardie]

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 <pgnet@gmail.com> 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

[Doug Hardie]

> 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

[Doug Hardie]

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

[Doug Hardie]

> On 7 July 2017, at 08:44, Noel Jones <njo...@megan.vbhcs.org> wrote:
> 
> On 7/7/2017 12:37 AM, Doug Hardie wrote:
>> 
>>> On 6 July 2017, at 12:40, Doug Hardie <d...@mail.sermon-archive.info> wrote:
>>> 
>>>> 
>>>> On 6 July 2017, at 12:06, Noel Jones <njo...@megan.vbhcs.org> 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

[Doug Hardie]

> On 6 July 2017, at 12:40, Doug Hardie <d...@mail.sermon-archive.info> wrote:
> 
>> 
>> On 6 July 2017, at 12:06, Noel Jones <njo...@megan.vbhcs.org> 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

[Doug Hardie]

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 <r...@gmx.co.uk> 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

[Doug Hardie]

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

[Doug Hardie]

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

[Doug Hardie]

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 <ref...@lafn.org>: Recipient address rejected: User unknown in 
virtual alias table


— Doug

Re: Problems with aliases

[Doug Hardie]

> On 9 May 2017, at 22:19, James B. Byrne <byrn...@harte-lyne.ca> 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

[Doug Hardie]

p
showq  unix  n   -   n   -   -   showq
error  unix  -   -   n   -   -   error
retry  unix  -   -   n   -   -   error
discardunix  -   -   n   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
scache unix  -   -   n   -   1   scache
mail# 


vmail_alias file contained

# user1@domain1 user1@domain2
# user2@domain1 user2@domain3
# user3@domain1 user3@domain4

The domain names 1-4 above are not in any of the other maps, or in any file in 
the config directory.  When I had only the following in vmail_alias:

testuser@domain5testuser@domain1

Mail to testuser@domain5 was properly forwarded to testuser@domain1.  Domain5 
is in the virtual_mailbox_domains file.



— Doug