Re: Unexpected record type 'X'

[J Doe]

On 2022-09-06 23:18, Viktor Dukhovni wrote:


On Tue, Sep 06, 2022 at 09:43:38PM -0400, J Doe wrote:


Out of curiosity ... why do queue files require the execute bit ?


That's how they're marked "complete".  A partially written queue file is
just read-write.  When a queue is committed it is marked executable and
synced to disk, at that point the SMTP server can tell the remote client
that the file is safely persisted in the queue.


Hi Viktor,

Ah, neat!  Thanks for satisfying my curiosity.

- J

Re: Unexpected record type 'X'

[J Doe]

On 2022-08-30 10:35, Viktor Dukhovni wrote:

On Tue, Aug 30, 2022 at 02:25:20PM +, Frank Brendel wrote:


So I can try to reproduce it by simply putting that file into the
incoming queue?


Within the same filesystem, yes.


Our test system has FreeBSD 13.1 and Postfix 3.7.2 installed.  I'd try
to resend a mail via that system.


If you're copying queue files between systems, make sure to stop Postfix
on the target system, and run "postsuper -s" as root after copying the
queue file.  Queue file permissions need to be 0700 to make the message
deliverable, the owner needs to be the "$mail_owner" user (typically
"postfix").



Hi,

Out of curiosity ... why do queue files require the execute bit ?

Thanks,

- J

Re: AW: Spam pass the filter

[J Doe]

On 2021-09-18 6:10 p.m., Christian Schmitz wrote:


On Saturday 18 September 2021 10:13:41 ludic...@gmail.com wrote:

Hi,

pcre header checks we use. Not all the time, depends on spam volume from
these valuable enterprises.

#/sjmedia.us/   REJECT A mass mail service abused by criminals
#/bmsend.com/   REJECT A mass mail service abused by criminals
#/mailgun.net/  REJECT A mass mail service abused by criminals
#/rsgsv.net/REJECT A mass mail service abused by criminals
#/mcsv.net/ REJECT A mass mail service abused by criminals
#/sendgrid.net/ REJECT A mass mail service abused by criminals
#/crsend.com/   REJECT A mass mail service abused by criminals
#/zcsend.net/   REJECT A mass mail service abused by criminals

I forgot if all those can be catched by limiting it to the Received-Line.

Greets,
Ludi


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im
Auftrag von Christian Schmitz
Gesendet: Freitag, 17. September 2021 14:41
An: postfix-users@postfix.org
Betreff: Spam pass the filter

Hi everyone:
Normally when i identify a host spammer i block entire server. Today
i receive one spam email. The origin is "mailgun.net", i already have a
rule to block him, but the email pass with no problem. I want stop the
email, what is wrong?

The header, config and rules are the following.

Best Regards and thanks in advance
Christian


Thanks to all. I do not use spamassasin since the spam and mail level is too
low in my server ( 2~5 emails at day). I take the policy of block entire
spammer mail server.

I will read and adapt my rules.

Thanks to everyone.
Christian


Hi Christian,

It's still worth running SpamAssassin on a low volume server.  You are 
correct that you will not have enough spam to train Bayes but 
SpamAssassin ships with rules that can catch spam based on regex's, 
DNSBL queries and do forth.


It's also a handy platform for writing your own site-specific rules, 
which also function in the absence of Bayes.


- J

Re: Problems emailing bell.net or sympatico.ca addresses

[J Doe]

On 2021-09-17 5:48 p.m., Ian Evans wrote:
Just curious if anyone on the list has ever had issues with their 
postfix server communicating with bell.net  or their 
related sympatico.ca  email addresses?


I've been trying to send to a few but keep getting "421 Connection limit 
reached" followed by an eventual failure days later. I've seen people 
post about this issue on discussion boards, but no clear idea of the fix 
or issue.


Thanks for any insight.


Hi Ian,

I've encountered this with a low-volume e-mail server that additionally 
only delivers to two Sympatico addresses roughly once a week.


The delay interval that is applied appears to be variable - I've seen 
times ranging from minutes to roughly 8 hours.


As best I can tell this is a reputation issue, wherein my server is not 
generating enough traffic for Sympatico to judge it non-spam.


- J

Re: STARTTLS abuse

[J Doe]

On 2021-09-07 7:11 p.m., Bill Cole wrote:

On 2021-09-07 at 14:42:33 UTC-0400 (Tue, 7 Sep 2021 19:42:33 +0100)
Adam Weremczuk 
is rumored to have said:


Hi all,

It's postfix 3.1.6-0+deb9u1 on Debian 9.

Since enabling STARTTLS on port 25 I'm getting lots of traffic looking 
like this (relay attempts?):


This does not actually have anything to do with STARTTLS.

Sep  6 09:17:42 localhost postfix/smtpd[14622]: connect from 
unknown[77.247.110.240]
Sep  6 09:17:42 localhost postfix/smtpd[14622]: setting up TLS 
connection from unknown[77.247.110.240]
Sep  6 09:17:42 localhost postfix/smtpd[14622]: 
unknown[77.247.110.240]: TLS cipher list 
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
Sep  6 09:17:42 localhost postfix/smtpd[14622]: 
unknown[77.247.110.240]: Issuing session ticket, key expiration: 
1630916885
Sep  6 09:17:42 localhost postfix/smtpd[14622]: Anonymous TLS 
connection established from unknown[77.247.110.240]: TLSv1.2 with 
cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Sep  6 09:17:42 localhost postfix/smtpd[14622]: lost connection after 
AUTH from unknown[77.247.110.240]
Sep  6 09:17:42 localhost postfix/smtpd[14622]: disconnect from 
unknown[77.247.110.240] ehlo=2 starttls=1 auth=0/1 commands=3/4
Sep  6 09:17:42 localhost postfix/smtpd[14592]: connect from 
unknown[77.247.110.240]
Sep  6 09:17:42 localhost postfix/smtpd[14592]: setting up TLS 
connection from unknown[77.247.110.240]
Sep  6 09:17:42 localhost postfix/smtpd[14592]: 
unknown[77.247.110.240]: TLS cipher list 
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"


grep 77.247.110.240 /var/log/mail.log | wc -l
16735


That's AUTH probing. A bot on 77.247.110.240 has a big list of usernames 
and password and is testing them one at a time.


It's a different IP(s) every day so banning them manually is not going 
to work well.


If you only offer AUTH on submission services (ports 465 and 587) you 
can safely block large chunks of network space from accessing those 
ports. The networks were these sorts of bots are common are almost 
certain to never have one of your legitimate users on them trying to 
authenticate. In fact, for most mail systems, one can safely drop 
packets headed to 465 and 587 for the overwhelming bulk of the Internet 
and never cause trouble.


I've tried fail2ban but the postfix and postfix-rbl jails seem to be 
based on sever error codes which are not produced here e.g:


As has been suggested, looking for 'auth=0/' in the log is a useful 
pattern for fail2ban or other log-scanning tools.



Any idea how to effectively ban these abusers?


To start, disable AUTH on port 25. You may need to get users (and 
devices that generate mail) to change their configs to use port 587 
(with STARTTLS & AUTH) or 465 (with implicit TLS & AUTH) before making 
that change.


With no legitimate users trying to authenticate on port 25 and no 
advertisement of AUTH on port 25, you should see a huge reduction in 
port 25 AUTH probing. You will still see probes on 465/587 but you can 
block those either with something like fail2ban looking for 'auth=0/' 
repeatedly from the same address and/or by manually finding those 
addresses and passing your own judgment on whether the enclosing /24 (or 
even /4!) can be safely blocked from those ports.


Hi,

In this case, is the botnet actually trying credentials ?  It looks to 
me that it is establishing a TLS connection and then dropping it (or am 
I mistaken ?).


If it is just establishing TLS and is not actually trying credentials, 
why would a botnet do that ?


Thanks,

- J

Re: Question about service daemon man pages

[J Doe]

On 2021-05-22 8:05 a.m., Wietse Venema wrote:


J Doe:

A section that is shared in all of the service daemon man pages is
"CONFIGURATION PARAMETERS".  In bounce(8) there are parameters under
this section that relate to delivery status notifications.  For
instance: delay_notice_recipient.  This made me think that bounce(8) is
solely responsible for DSN's.


Wietse:

No it's not. The bounce daemon *uses* the time to warn in notifications
(your message could not be delivered for more than
$delay_warning_time_hours hours).

The cleanup daenon *stores* the time to warn in queue files.

Additionally, the queue manager *enforces* the time to warn by
requesting that a warning notification is sent.


J Doe:

Ok, would the more accurate takeaway be that more than one daemon can
consult/consume a parameter in main.cf and the fact that a parameter is
listed in a service daemon man page does _not_ mean that that one daemon
"owns" the parameter ?


It means that the parameter setting is *used* by the program. There
are dozens of parameters that are used in more than one program.
queue_directory, soft_bounce, myhostname, mail_name, line_length_limit,
and many more.

Wietse


Hi Wietse,

Ok, great - thank you for clarifying that for me.

- J

Re: Question about service daemon man pages

[J Doe]

On 2021-05-21 7:34 p.m., Wietse Venema wrote:

J Doe:

Hello,

I have a question about the man pages for the service daemons that are
executed via master(8).

A section that is shared in all of the service daemon man pages is
"CONFIGURATION PARAMETERS".  In bounce(8) there are parameters under
this section that relate to delivery status notifications.  For
instance: delay_notice_recipient.  This made me think that bounce(8) is
solely responsible for DSN's.


No it's not. The bounce daemon *uses* the time to warn in notifications
(your message could not be delivered for more than
$delay_warning_time_hours hours).


When I check cleanup(8) under "CONFIGURATION PARAMETERS" I see:
delay_warning_time which also relates to DSN's.


The cleanup daenon *stores* the time to warn in queue files.

Additionally, the queue manager *enforces* the time to warn
by requesting that a warning notification is sent.

Wietse



Hi Wietse,

Thanks for your reply.

Ok, would the more accurate takeaway be that more than one daemon can 
consult/consume a parameter in main.cf and the fact that a parameter is 
listed in a service daemon man page does _not_ mean that that one daemon 
"owns" the parameter ?


Thanks again,

- J

Question about service daemon man pages

[J Doe]

Hello,

I have a question about the man pages for the service daemons that are 
executed via master(8).


A section that is shared in all of the service daemon man pages is 
"CONFIGURATION PARAMETERS".  In bounce(8) there are parameters under 
this section that relate to delivery status notifications.  For 
instance: delay_notice_recipient.  This made me think that bounce(8) is 
solely responsible for DSN's.


When I check cleanup(8) under "CONFIGURATION PARAMETERS" I see: 
delay_warning_time which also relates to DSN's.


I understand that both of these parameters are configured in one place: 
main.cf but my questions are:


1. When a parameter is listed under "CONFIGURATION PARAMETERS" does that 
mean it _only_ applies to its' service daemon ?  This would mean that: 
delay_notice_recipient is "owned" via bounce(8) and: delay_warning_time 
is "owned" via cleanup(8)
2. If question 1 is correct why does DSN functionality have it's 
implementation divided between 2 daemons ?

3. Do other service daemons subdivide responsibility for a function ?

For clarity - questions 2 and 3 aren't a critique of the design; it's 
more to help my brain understand things (one functionality provided by 
one service daemon is currently more understandable to my confused brain!).


Thanks,

- J

Re: Submission and milter_macro_daemon_name parameter

[J Doe]

On 2021-05-15 12:08 a.m., Benny Pedersen wrote:

On 2021-05-15 04:30, J Doe wrote:


    1.  Why was the magic value of "ORIGINATING" used in the Digital
Ocean example ?
    2.  Can I allow the default value of: milter_macro_daemon_name to
be used _WITHOUT_ affecting OpenDKIM and ClamAV ?


in opendkim.conf use this in MTA

MTA=ORIGINATING

then opendkim will only dkim sign on originating mails, not incomming in 
port 25


hopefully guides at DO is not say all mta must use submission for 
outgoing mails, i see the problem here, mta must only use port 25 for 
all outbound mails, any guide that says otherwize is badly writed


clamav milter supports SASL auth

do not use it in clamav milter if its not used for developing new virus 
signatures


note i do not use milters anymore, fuglu is better atleast for me :=)


Hi Benny,

Thanks for your reply.

I haven't changed the OpenDKIM configuration script to have: 
MTA=ORIGINATING and my mail flows still seem to work:


1. Clients submitting e-mail via submission have their e-mail DKIM signed.
2. Mail from the world has SPF, DKIM and DMARC validated.

The Digital Ocean tutorial does not say that e-mail has to be submitted 
only via submission, but all my clients submit it this way with SASL 
AUTH.  I do not have SASL AUTH on my port 25 e-mail.


Thanks,

- J

Re: Submission and milter_macro_daemon_name parameter

[J Doe]

On 2021-05-14 11:38 p.m., Bill Cole wrote:

On 2021-05-14 at 22:30:18 UTC-0400 (Fri, 14 May 2021 22:30:18 -0400)
J Doe 
is rumored to have said:


My questions are:

    1.  Why was the magic value of "ORIGINATING" used in the Digital 
Ocean example ?


It's not 'magic' but it is the value that Postfix uses as an example in 
master.cf.


    2.  Can I allow the default value of: milter_macro_daemon_name to 
be used _WITHOUT_ affecting OpenDKIM and ClamAV ?


That depends on what you want to do with those milters.

If you want to handle incoming (smtp) and outgoing (smtps and/or 
sumbission) mail differently in your milters, you need a way for the 
milters to tell the difference. The ${daemon_name} macro is the usual 
way for a milter to make that differentiation. It is almost certain that 
you want OpenDKIM to deal with inbound and outbound mail differently 
(signing or verifying.) Using the default value of 
milter_macro_daemon_name for all of the smtp-like services that use 
milters eliminates the ability of your milters to make that 
differentiation. Check the documentation  of your milters for details.





Hi Bill,

Thanks for your reply.

You're right - I didn't realize that the master.cf file that ships with 
Postfix uses the same value of "ORIGINATING" for both submission and 
smtps.  With that being the case I can see that Digital Ocean is 
including this as well and is not an arbitrary value introduced by their 
tutorial.


Yes, I have different functionality for different mail flows.  For 
submission, where clients are submitting e-mail to be relayed, I make 
use of OpenDKIM to DKIM sign those messages and the ClamAV milter to see 
if anyone submitting e-mail is in fact sending attachments with malware 
(which would indicate that those clients are infected).


Mail to and from "the world" is via an smtpd instance,  For inbound 
e-mail from "the world" I use a Python policy program to check SPF, 
OpenDKIM to validate DKIM signatures and OpenDMARC to check DMARC.


As it stands right now I have not changed any of the milters to examine 
the daemon name of "ORIGINATING" and everything is working.


Is this because I have separate flows - submission and smtpd ?

Thanks,

- J

Submission and milter_macro_daemon_name parameter

[J Doe]

Hello,

I have a question regarding configuring submission with Postfix.

I am dusting off a configuration for a server that has been functioning 
well for the past three years.  When I set up submission, I used the 
example from Digital Ocean here: 
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-postfix-e-mail-server-with-dovecot


This article was helpful, but it is:

1. From November 14, 2013
2. Refers to Postfix 2.9.6

In particular, it lists one parameter that I was uncertain about:

/etc/postfix/master.cf
submission inet  n   -   y   -   -   smtpd
-o milter_macro_daemon_name=ORIGINATING
. . .

I checked: man 5 postconf and milter_macro_daemon_name states:

The {daemon_name} macro value for Milter (mail filter) applications.
See MILTER_README for a list of available macro names and their
meanings.

I consulted MILTER_README at: http://www.postfix.org/MILTER_README.html 
but I am still uncertain why "ORIGINATING" is being used for the 
Sendmail macro of {daemon_name}.


I use the following milters with submission:

-o 
smtpd_milters=unix:/var/run/opendkim/opendkim.sock,unix:/var/run/clamav/clamav-milter.sock


... for DKIM signing (OpenDKIM), and checking for viruses from infected 
submitters (ClamAV).


My questions are:

1.  Why was the magic value of "ORIGINATING" used in the Digital 
Ocean example ?
2.  Can I allow the default value of: milter_macro_daemon_name to 
be used _WITHOUT_ affecting OpenDKIM and ClamAV ?


Thanks,

- J

Re: Postfix delay notifications

[J Doe]

On 2021-05-14 5:17 p.m., Wietse Venema wrote:

> J Doe:
>> Hello,
>>
>> I have been experimenting with DSN's regarding delayed e-mails.
>>
>> My current config is:
>>
>>   /etc/postfix/main.cf
>>   delay_notice_recipient = postmaster
>>
>>   notify_classes = delay
>>
>>   delay_warning_time = 15m
>>   confirm_delay_cleared = yes
>>   . . .
>>
>> ... and this works, sending the postmaster a notification as well as the
>> original sender.
>>
>> I note in: man 5 postconf that notify_classes mentions for delay that
>> "The notification is sent to the address specified with the
>> delay_notice_recipient configuration parameter...".
>>
>> My question is - if I only want delay DSN's to go to the postmaster and
>> _NOT_ the original sender, how do I configure that ?
>
> Not possible. The xxx_notice_recipient parameters are for postmaster
> notifications *in addition to* the notifications to the sender.
>
> If you want to be informed when mail is piling up in the queue,
> perhaps "postqueue -j | jq ..." can give you the mail that
> arfrived before some point in time.
>
> Wietse

Hi Wietse,

Ah, I see.

Thanks for the suggestion about: postqueue -j.  I didn't realize there 
was JSON output for queue items.  I see man says that it's been 
available since Postfix 3.1 so this will work for me.


- J

Postfix delay notifications

[J Doe]

Hello,

I have been experimenting with DSN's regarding delayed e-mails.

My current config is:

/etc/postfix/main.cf
delay_notice_recipient = postmaster

notify_classes = delay

delay_warning_time = 15m
confirm_delay_cleared = yes
. . .

... and this works, sending the postmaster a notification as well as the 
original sender.


I note in: man 5 postconf that notify_classes mentions for delay that 
"The notification is sent to the address specified with the 
delay_notice_recipient configuration parameter...".


My question is - if I only want delay DSN's to go to the postmaster and 
_NOT_ the original sender, how do I configure that ?


Thanks,

- J

Re: Postfix -> Whatapp

[J Doe]

On 2020-05-26 1:52 p.m., Phil Stracchino wrote:

On 2020-05-26 13:42, Jos Chrispijn wrote:

Is there a way of Postfix sending a Whatsapp message to a user when
there came in email for her/him?

Thanks, Jos

No.  That is utterly and totally not Postfix's, or any MTA's, job.  Period.

If you wanted to get a WhatsApp notification when you receive new mail,
you'd need to find a mail *client* that has some kind of WhatsApp
notification plugin.  (Good luck with that.)


Hi Jos,

You may want to investigate doing this at the MDA.  If you run Dovecot 
in conjunction with Postfix, you could write a Sieve script that calls a 
shell script that then sends the notification to whatever third-party 
service you would like.


As a side-note - there actually is a Sieve RFC that covers notifications 
via XMPP / Jabber, but that isn't available in Dovecot at the moment.


- J

Re: Unusual TLS setting logged by Postfix

[J Doe]

> On Oct 22, 2019, at 9:08 PM, Viktor Dukhovni  
> wrote:
> 
> You see them not used.  Kx=RSA.  See ciphers(1):

Hi Viktor,

Thank you for sending this - for some reason, I had it in my mind that key 
distribution was only via DH/DHE/ECDHE and I completely forgot about RSA (as 
well as a couple of others, which are also helpfully displayed in the TLS 
article on Wikipedia[1]).

- J

[1] See: 
https://en.wikipedia.org/wiki/Transport_Layer_Security#Key_exchange_or_key_agreement

Re: Unusual TLS setting logged by Postfix

[J Doe]

> On Oct 22, 2019, at 1:18 AM, Viktor Dukhovni  
> wrote:
> 
>$ openssl ciphers -stdname -s -tls1 -V AES256-SHA
>0x00,0x35 - TLS_RSA_WITH_AES_256_CBC_SHA - AES256-SHA  SSLv3 
> Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1

Hi Viktor,

Ah, cool - I did not realize I could use the openssl command to “translate” the 
string that way.

I see the AES mode, now, but I still can’t see whether DH/DHE/ECDHE was used 
for negotiation (or am I missing that in the output) ?

Thanks,

- J

Unusual TLS setting logged by Postfix

[J Doe]

Hello,

I am aware that this is not an error on Postfix’s fault, but I found the 
following entry in one of mail server’s logs confusing.  I am using Postfix 
3.3.0:

Oct 21 06:09:51 server postfix/smtpd[31405]: Anonymous TLS connection 
established from unknown[77.120.120.29]:33126: TLSv1 with cipher AES256-SHA 
(256/256 bits)

From what I gather, a TLS v1.0 connection was made with AES256 for the 
symmetric cipher and SHA-1 for integrity, but:

— There is neither DH/DHE/ECDHE at the start.  What public key negotiation was 
done ?
— There is no mode for AES256 (neither old CBC or newer, recommended GCM).  
What mode was used ?

Thanks,

- J

Re: EHLO restrictions and address literals

[J Doe]

> On Sep 11, 2019, at 6:15 PM, Bill Cole 
>  wrote:
> 
> On 11 Sep 2019, at 17:05, J Doe wrote:
> 
>> I glanced briefly to see if there were any other ways to restrict this but 
>> none seemed evident to me.
> 
>> Is there a way to achieve this ?
> 
> As Viktor noted: a pcre check_helo_access map is useful.
> 
> I have such a map with a few dozen lines of patterns that only ever match 
> spam sources or are logically bogus (e.g. hostname.local) plus a handful of 
> exemptions for non-spam sources who are easier to whitelist than educate. It 
> catches rather less than it did before postscreen but it's still doing a 
> substantial bit of cheap spam blocking.
> 
>> Alternatively, should I not be attempting to do this because legitimate 
>> server’s sometimes EHLO address literals ?
> 
> As long as you have any initial submission segregated to ports 465 or 587, 
> you shouldn't see any port 25 traffic EHLOing with address literals. It is 
> formally allowable (just as it is formally allowable to EHLO as 
> 'localhost.localdomain') but no legitimate mail server speaking to the world 
> at large should ever be doing that.

Hi Bill,

In regards to the map with a few dozen patterns that only ever match spam 
sources . . . would you be able to share that with me ?

Ok, good - I do separate out e-mail to submission, so I should be ok.

Thanks,

- J

Re: EHLO restrictions and address literals

[J Doe]

> On Sep 11, 2019, at 5:25 PM, Viktor Dukhovni  
> wrote:
> 
>> On Sep 11, 2019, at 5:05 PM, J Doe  wrote:
>> 
>> Is there a way to achieve this ?  Alternatively, should I not be attempting 
>> to do this because legitimate server’s sometimes EHLO address literals ?
> 
> You could try something like:
> 
>   ...
>   warn_if_reject check_helo_access pcre:${config_directory}/helo-access
>   ...
> 
>helo-access:
>   /^\[/   454 4.7.1 EHLO domain-literals not accepted here
> 
> And see whether that'll work out for you.  This only logs warnings
> when EHLO domain-literals would be rejected, but the message may
> still be rejected by later restrictions.  If you see enough warnings
> for messages that are not in any case rejected, and no false positives,
> you could try removing the 'warn_if_reject', and watch the soft rejects
> for a while.  If that works out, change the '4XX' to '5XX'.
> 
> -- 
>   Viktor.

Hi Viktor,

Thanks for your reply.  Ok, I was thinking a regex solution might be possible, 
but I had not thought of using warn_if_reject to monitor for false positives - 
thanks!

- J

EHLO restrictions and address literals

[J Doe]

Hi,

I have a question regarding restrictions I can place on EHLO in the 
smtpd_helo_restrictions parameter.

I have a Postfix server that is Internet facing.  I periodically receive e-mail 
where the other MTA sends a EHLO of an address literal.  I checked RFC 5321 
(SMTP), and confirmed that this is valid (because I imagine someone might have 
a MTA internal to their network and they might not have DNS names for 
everything), however in nearly almost every case that an address literal is 
presented, it’s from someone attempting to deliver spam.

My initial thought was I could stop this with:

main.cf
. . .
smtpd_helo_restrictions = 
. . .
reject_non_fqdn_helo_hostname,
. . .

…however when I checked the Postfix documentaion[1] for this parameter I read:

Reject the request when the HELO or EHLO hostname is not in 
fully-qualified domain *or address literal form* . . .

I glanced briefly to see if there were any other ways to restrict this but none 
seemed evident to me.

Is there a way to achieve this ?  Alternatively, should I not be attempting to 
do this because legitimate server’s sometimes EHLO address literals ?

Thanks,

- J

[1] http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions

Re: Question regarding DNSBL behaviour

[J Doe]

> On Sep 10, 2019, at 4:41 PM, Bill Cole 
>  wrote:
> 
>> Hello,
>> 
>> I have a question regarding DNSBL usage with the main.cf 
>> smtpd_client_restrictions parameter.
>> 
>> I have a server configured to check SpamHaus:
>> 
>> main.cf
>>  . . .
>>  smtpd_client_restrictions = reject_rbl_client 
>> zen.spamhaus.org=127.0.0.[2..11],
>>  . . .
>> 
>> This has been working very well, although I noticed the following error in 
>> my syslog:
>> 
>> Sep  7 16:13:08 server postfix/smtpd[28363]: warning: 
>> 188.50.102.94.zen.spamhaus.org: RBL lookup error: Host or domain name not 
>> found. Name service error for name=188.50.102.94.zen.spamhaus.org type=A: 
>> Host not found, try again
> 
> A common cause of this is is if your DNS resolver thinks that you have IPv6 
> connectivity (e.g. because you have an autoconfigured interface or a VPN with 
> an IPv6 address) but you really do not. The extensive collection of DNS 
> servers handling the zen.spamhaus.org  zone 
> includes many names that have as many  records as they do A records and 
> if your resolvers tries one of those, you get a message as above.

Hi Bill,

Thanks for your reply.  Interesting.  In this case, the DNS resolver I use is 
one that I run on the mailserver itself, which has IPv4/IPv6 connectivity.  I 
know this host can successfully access both as we send and receive Gmail mostly 
over IPv6 whereas most other traffic is delivered over IPv4.  With the SMTP 
traffic handling both ok I would assume that my DNS resolver is also ok (I 
haven’t made any configuration changes to Bind to make it prefer IPv4 or IPv6 
when it performs recursive lookups) ?

Thanks,

- J

Re: Question regarding DNSBL behaviour

[J Doe]

>> Sep  7 16:13:08 server postfix/smtpd[28363]: warning: 
>> 188.50.102.94.zen.spamhaus.org: RBL lookup error: Host or domain name not 
>> found. Name service error for name=188.50.102.94.zen.spamhaus.org type=A: 
>> Host not found, try again
>> 
>> I am wondering - in normal checks against SpamHaus, if a host is not listed 
>> and the result is NXDOMAIN, I am assuming that Postfix interprets that the 
>> host is ?ok? and does not log any information.  In this case, though, it has 
>> logged the information and I am wondering if this is because Postfix was 
>> unable to contact SpamHaus at all, not just regarding the record: 
>> 188.50.102.94.zen.spamhaus.org ?
>> 
> 
> This service is free for low-volume clients only. If you send your
> Spamhaus queries through a shared DNS resolver (like an ISP), then
> you may exceed their 'free service' limits. You may be better off
> using your own DNS resolver.
> 
>   Wietse

Hi Wietse,

Yes, that is a good point.  I believe I’m ok regarding query limits - I do run 
my own resolver for this server and the amount of e-mail that transits this 
particular server is very low.

- J

Re: Question regarding DNSBL behaviour

[J Doe]

>> Hello,
>> I have a question regarding DNSBL usage with the main.cf 
>> smtpd_client_restrictions parameter.
>> I have a server configured to check SpamHaus:
>> main.cf
>>  . . .
>>  smtpd_client_restrictions = reject_rbl_client 
>> zen.spamhaus.org=127.0.0.[2..11],
>>  . . .
>> This has been working very well, although I noticed the following error in 
>> my syslog:
>> Sep  7 16:13:08 server postfix/smtpd[28363]: warning: 
>> 188.50.102.94.zen.spamhaus.org: RBL lookup error: Host or domain name not 
>> found. Name service error for name=188.50.102.94.zen.spamhaus.org type=A: 
>> Host not found, try again
>> I am wondering - in normal checks against SpamHaus, if a host is not listed 
>> and the result is NXDOMAIN, I am assuming that Postfix interprets that the 
>> host is “ok” and does not log any information.  In this case, though, it has 
>> logged the information and I am wondering if this is because Postfix was 
>> unable to contact SpamHaus at all, not just regarding the record: 
>> 188.50.102.94.zen.spamhaus.org ?
>> Thanks,
>> - J
> 
> 
> Lookup error: means something didn't work; your DNS told postfix it couldn't 
> find spamhaus at all, but it was a temporary error so try again.  Postfix 
> will ignore the result.
> 
> If you get this rarely, it's nothing to worry about.  If it happens often, 
> there may be a problem with your DNS server or network connection.
> 
>  -- Noel Jones

Hi Noel,

Thanks for your reply.  Ok, that’s what I was thinking - that it was a 
temporary DNS error for contacting SpamHaus, not SpamHaus saying that address 
was not listed.  Just wanted to double-check.

- J

Question regarding DNSBL behaviour

[J Doe]

Hello,

I have a question regarding DNSBL usage with the main.cf 
smtpd_client_restrictions parameter.

I have a server configured to check SpamHaus:

main.cf
. . .
smtpd_client_restrictions = reject_rbl_client 
zen.spamhaus.org=127.0.0.[2..11],
. . .

This has been working very well, although I noticed the following error in my 
syslog:

Sep  7 16:13:08 server postfix/smtpd[28363]: warning: 
188.50.102.94.zen.spamhaus.org: RBL lookup error: Host or domain name not 
found. Name service error for name=188.50.102.94.zen.spamhaus.org type=A: Host 
not found, try again

I am wondering - in normal checks against SpamHaus, if a host is not listed and 
the result is NXDOMAIN, I am assuming that Postfix interprets that the host is 
“ok” and does not log any information.  In this case, though, it has logged the 
information and I am wondering if this is because Postfix was unable to contact 
SpamHaus at all, not just regarding the record: 188.50.102.94.zen.spamhaus.org ?

Thanks,

- J

DKIM signing of bounce back messages

[J Doe]

Hello,

I have a question regarding DKIM signing on Postfix bounce back messages.

I was tuning my Dovecot installation around quotas.  I sent a test message from 
Hotmail to a test account on my server to test generation of a bounce back when 
a user exceeds their quota.  The message was successfully generated and then 
relayed via Postfix back to the Hotmail account, but I noticed the bounce back 
message went into the Hotmail junk folder.

Inspecting the message I saw that I was not DKIM signing messages generated by 
Postfix or via sendmail.  I changed my Postfix config to include:

/etc/postfix/main.cf
internal_mail_filter_classes = bounce
non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock

Generating a new test message confirmed that bounce back messages are now DKIM 
signed . . . BUT I noticed this line in: man 5 postconf

internal_mail_filter_classes
NOTE: It's generally not safe to enable content inspection of 
Postfix-generated email messages.

My question is - will enabling DKIM on bounce back messages cause me problems 
or is that warning more for content filters that attempt to mangle/modify the 
bounce back messages ?

Thanks,

- J

Connections from "unknown"

[J Doe]

Hello,

I noticed something interesting in my logs today.  I am running Postfix 3.3.1:

Aug 24 21:09:25 server postfix/submission/smtpd[10256]: connect from 
unknown[unknown]:unknown
Aug 24 21:09:25 server postfix/submission/smtpd[10256]: lost connection 
after CONNECT from unknown[unknown]:unknown
Aug 24 21:09:25 server postfix/submission/smtpd[10256]: disconnect from 
unknown[unknown]:unknown commands=0/0

It is clear that this was a bad connection, but under what circumstances does 
Postfix consider a remote connection’s address as “unknown” ?  Wouldn’t Postfix 
always know the remote IPv4/IPv6 address because when a client connects to the 
server the address is passed from the OS to Postfix ?

Thanks,

- J

Re: Best place for DNSBL restrictions

[J Doe]

> Hi Bill and Wietse,
> 
> Thank you for your replies.
> 
> Ah, thank you for the warning regarding SpamCop - and also for the note about 
> weighting being a postscreen only feature.
> 
> I was wondering if perhaps one of the reasons why people tend to use SMTP 
> restrictions instead of postscreen is related
> to history - IIRC, postscreen came later, so perhaps the reason why I see 
> many examples advocating SMTP restrictions
> is because that’s how people kept spam away before the release of postscreen ?
> 
> In terms of weighting, I am assuming that one thing I could do when I have 
> more than one DNSBL (say, 2) is to set a threshold of
> 2 and have each list weighted as 1 (the default).  That would mean that an IP 
> address would have to be listed on both
> lists before being banned, correct ?

As a follow-on - I have migrated the DNSBL blocking to SMTPD restrictions to 
see what SMTP transaction data is recorded.
I may revert that back to postscreen, with weighting, but as this is a lower 
volume server I thought it would be interesting
to try this out and gather some data.

I note, though, that I can place a reject_rbl_client statement in multiple 
places (ie: smtpd_client_restrictions, smtpd_recipient_restrictions).
For spam, wouldn’t I always want this in smtpd_client_restrictions because the 
senders IP address is presented here and can be
looked up on the DNSBL ?  Why would I want to put it later in the transaction 
at say: smtpd_recipient_restrictions ?

Thanks,

- J

Re: Best place for DNSBL restrictions

[J Doe]

> On Jun 24, 2018, at 9:37 AM, Wietse Venema  wrote:
> 
> J Doe:
>> Hello,
>> 
>> I manage a small mail server and have been using Spamcop as a DNSBL?s via 
>> postscreen:
>> 
>>/etc/postfix/main.cf
>>postscreen_dnsbl_sites = bl.spamcop.net
>>postscreen_dnsbl_action = drop
> 
> spamcop is not system that flags spambots (systems that send spam
> ONLY); it also flags sites that send mostly legitimate mail.
> 
> If you must use spamcop (I would not), you might want to use that
> with a small weight so that spamcop alone cannot veto your mail.
> Note that postscreen supports weights, while smtpd does not.
> 
>   Wietse

Hi Bill and Wietse,

Thank you for your replies.

Ah, thank you for the warning regarding SpamCop - and also for the note about 
weighting being a postscreen only feature.

I was wondering if perhaps one of the reasons why people tend to use SMTP 
restrictions instead of postscreen is related
to history - IIRC, postscreen came later, so perhaps the reason why I see many 
examples advocating SMTP restrictions
is because that’s how people kept spam away before the release of postscreen ?

In terms of weighting, I am assuming that one thing I could do when I have more 
than one DNSBL (say, 2) is to set a threshold of
2 and have each list weighted as 1 (the default).  That would mean that an IP 
address would have to be listed on both
lists before being banned, correct ?

Thanks,

- J

Best place for DNSBL restrictions

[J Doe]

Hello,

I manage a small mail server and have been using Spamcop as a DNSBL’s via 
postscreen:

/etc/postfix/main.cf
postscreen_dnsbl_sites = bl.spamcop.net
postscreen_dnsbl_action = drop

After reading RFC 5782 “DNS Blacklists and Whitelists”, I decided to add some 
more 
DNSBL’s and specify filters and weighting.  While looking at various samples of 
main.cf 
using DNSBL’s, I came back to an old question - where should I implement DNSBL 
restrictions ?

On this list I seem to recall that using a DNSBL via postscreen is discouraged. 
 Many examples
place a DNSBL entry in smtpd_recipient_restrictions:

/etc/postfix/main.cf
. . .
smtpd_recipient_restrictions = . . . reject_rbl_client bl.spamcop.net 


However, isn’t it better to place this in postscreen, as a SMTP transaction 
will not be started
when a spammer listed on the DNSBL connects ?  Or are smtpd restrictions 
preferred
as there is more metadata about the mail transaction which I can check to see 
if a false
positive listing on a DNSBL has taken place ?

This confuses me as whether I place a DNSBL in postscreen or SMTP restrictions, 
in both
cases the message is blocked.  What are the advantages of placing in SMTP 
restrictions ?

Thanks,

- J

Re: Question regarding OpenDKIM milter with Postfix 3.1.0

[J Doe]

Hi Andreas,

> 
> yes, the OpenDKIM lists are unfortunately broken since a long time. I hope I 
> could push the list admin to fix that.
> 

Ok, thank you for confirming that.  I was wondering if it was just my attempts 
to post to the list

> I never used caching in OpenDKIM and disable it where ever possible. I prefer 
> a local DNS resolver and a fast/local database (for signing).

It would appear that the starting and stopping of OpenDKIM has solved this; 
there are no further aberrations with the statistics.  

I will be implementing a local resolver with caching - thank you for mentioning 
that.

- J

Question regarding OpenDKIM milter with Postfix 3.1.0

[J Doe]

Hi,

I apologize for asking a question that is only tangentially related to Postfix, 
however the OpenDKIM mailing lists do not appear to be accessible.

I am using Postfix 3.1.0 and OpenDKIM 2.10.3.  Upon reboot of my server, I 
noticed “normal” stats regarding caching (which I have enabled in 
opendkim.conf), in OpenDKIM:

May 14 20:10:45 server opendkim[1950]: cache: 0 queries, 0 hits (0%), 16 
expired, 0 keys

..however, after a connection, I receive the following:

May 14 20:16:35 server opendkim[1950]: cache: 32563 queries, 1104666192 
hits (94967%), 16 expired, 0 keys

I stopped and restarted OpenDKIM via systemd as I assume that would empty the 
in memory cache and any possible corruption, but a spurious number returns.

My questions are:

[1] Has anyone ever seen this happen ?

[2] Is there a persistent data store that stores stats and should be 
purged ?

Thanks,

- J

Postfix, milters and quarantine actions

[J Doe]

Hello,

I had some questions regarding milters in general, with the questions initially 
focused on the OpenDKIM milter (version 2.10.3), on Postfix 3.1.0

In man 5 opendkim.conf, under the CaptureUnknownErrors parameter, it specifies:

When set, and on systems where MTA quarantine is available, the 
filter will request quarantine of a message that results in an internal
error or resource exhaustion.

My questions are:

1. Is this supported on Postfix 3.1.0 and later ?

2. If it is supported on Postfix 3.1.0, is this because quarantine 
functionality is exposed to milters ?
(ie: I know quarantine functionality is not a part of SMTP, so it’s not the 
milter talking via
SMTP to Postfix)

3. If it is supported, is this available for other milters that request 
quarantine (ie: OpenDMARC, etc.) ?

Thanks,

- J

Re: Removing trace records on submission MSA

[J Doe]

Hi Viktor,

> On Apr 7, 2018, at 1:32 PM, Viktor Dukhovni  
> wrote:
> 
> It is now portable POSIX.  For the record, in email the allowed whitespace is 
> more narrow than
> is recognized by [[:space:]], you're not likely to run into any false 
> positives.  The email
> header whitespace consists of just SPACE, TAB, CR and LF.  VT and FF 
> (vertical tab and form feed)
> are not valid whitespace in email headers.

Ok, great!  Thank you for those observations about whitespace

Thanks to everyone else on this thread who also provided examples and 
suggestions.  Going forward I will take the advice to install PCRE support.

- J

Re: Removing trace records on submission MSA

[J Doe]

Hi Viktor and Dominic,

> On Apr 7, 2018, at 2:46 AM, Dominic Raferd <domi...@timedicer.co.uk> wrote:
> 
> On 7 April 2018 at 07:39, J Doe <gene...@nativemethods.com 
> <mailto:gene...@nativemethods.com>> wrote:
> Hi Viktor and Dominic,
> 
> If I do the following on Ubuntu 16.04 LTS:
> 
> $ echo "1 2" | egrep '[[:digit:]]\s[[:digit:]]’
> 1 2
> 
> … where “1 2” are highlighted in bash
> 
> Am I correct that since this POSIX regex for the digits AND the \s is still 
> being interpreted, my system must support the GNU regex extensions ?
> 
> ​It is standard Ubuntu it will support GNU regex extensions, but why not use 
> pcre? It is more powerful, more standardised, and - my impression​ - more 
> widely used for Postfix tables. Just do:
> $ sudo apt-get install postfix-pcre

Thank you for your reply.

It occurred to me that I could side-step the issue of GNU extensions and 
whether they’re supported by converting the string I e-mailed a couple of 
e-mails back to full POSIX regex (in this case removing the \s).  I ended up 
with:


/^(Received:[[:space:]]from)[^;]+(;[[:space:]][A-Z]{1}[a-z]{2,3},)[[:space:]]+([[:digit:]]{1,2}[^\n]+)/
REPLACE $1 [127.0.0.1] (localhost [127.0.0.1]) by myserver.com$2 $3

…and it works.

Have I missed anything else that needs to be converted so that the regular 
expression is POSIX only ?

- J

Re: Removing trace records on submission MSA

[J Doe]

Hi Viktor and Dominic,

If I do the following on Ubuntu 16.04 LTS:

$ echo "1 2" | egrep '[[:digit:]]\s[[:digit:]]’
1 2

… where “1 2” are highlighted in bash

Am I correct that since this POSIX regex for the digits AND the \s is still 
being interpreted, my system must support the GNU regex extensions ?

Thanks,

- J

Re: Removing trace records on submission MSA

[J Doe]

Hi Viktor,

> On Apr 7, 2018, at 2:04 AM, Viktor Dukhovni  
> wrote:
> 
> FreeBSD 11 (POSIX):
> 
>  $ echo "1 b" | egrep '\d\s\w'
>  $
> 
> MacOS High Sierra (POSIX with GNU or similar extensions):
> 
>  $ echo "1 b" | egrep '\d\s\w'
>  1 b
>  $
> 
> Your Ubuntu system most likely will match the MacOS results.  Which means 
> that your regexp table is not portable, but happens to work on your system.

I can confirm the expected result for MacOS High Sierra . . . but interestingly 
enough, I get the FreeBSD 11 results on Ubuntu 16.04 LTS.

Are there any other tests I can try to confirm the existence of GNU extensions 
to POSIX regular expressions ?

Thanks,

- J

Re: Removing trace records on submission MSA

[J Doe]

Hi Viktor,

> On Apr 7, 2018, at 1:50 AM, Viktor Dukhovni <postfix-us...@dukhovni.org> 
> wrote:
> 
>> On Apr 7, 2018, at 1:34 AM, J Doe <gene...@nativemethods.com> wrote:
>> 
>> mmm.  I just sent a test message via submission to a Gmail account and 
>> checked the headers and the replacement works.
>> 
>> According to the site [1]   \s is shorthand for POSIX regular expressions.
>> 
>> Perhaps the POSIX regex library compiled with Postfix now supports this ?
> 
> No "\s" is not a POSIX feature, it is however a GNU extension, so you may have
> a GNU regexp library, that supports "\s" (outside bracket expressions):
> 
>   https://www.regular-expressions.info/gnu.html

Ah, interesting - that must be it, then.

This is on an Ubuntu 16.04 LTS server.  I can see the dependencies compiled in 
from Ubuntu’s page [1] and GNU libc is listed.  [2] seems to suggest that 
regular expressions are part of GNU libc.

Is there another way I can confirm that ?

Thanks,

- J

Sources:

[1] https://packages.ubuntu.com/xenial/postfix 
<https://packages.ubuntu.com/xenial/postfix>
[2] https://www.gnu.org/software/libc/manual/html_node/Regular-Expressions.html 
<https://www.gnu.org/software/libc/manual/html_node/Regular-Expressions.html>

Re: Removing trace records on submission MSA

[J Doe]

Hi Viktor,

> On Apr 7, 2018, at 1:26 AM, Viktor Dukhovni <postfix-us...@dukhovni.org> 
> wrote:
>> On Apr 7, 2018, at 1:23 AM, J Doe <gene...@nativemethods.com> wrote:
>> 
>> I did some Googling for doing PCRE to POSIX regular expressions and updated 
>> the string:
>> 
>>   
>> /^(Received:\sfrom)[^;]+(;\s[A-Z]{1}[a-z]{2,3},)\s+([[:digit:]]{1,2}[^\n]+)/ 
>> REPLACE $1 [127.0.0.1] (localhost [127.0.0.1]) by myserver.com$2 $3
>> 
>> … and it works!
> 
> It can't, the above is still PCRE, "\s" for whitespace is PCRE, not "regexp". 
>  Perhaps that's no the string you're using.
> 
> My advice is to ditch regexp and use PCRE.  Install the package that adds 
> PCRE support.

Hmmm.  I just sent a test message via submission to a Gmail account and checked 
the headers and the replacement works.

According to the site [1]   \s is shorthand for POSIX regular expressions.

Perhaps the POSIX regex library compiled with Postfix now supports this ?

Sources:

[1] https://www.regular-expressions.info/posixbrackets.html 

Re: Removing trace records on submission MSA

[J Doe]

Hi Viktor,

> On Apr 7, 2018, at 12:36 AM, Viktor Dukhovni  
> wrote:
> 
> That's PCRE syntax.
> 
>> Does anyone know what I’m doing wrong and/or is there a way to make Postfix 
>> provide more debug output for a regexp: operation ?
> 
> You're using a "regexp" table, those don't support PCRE.

Thanks for your response and that’s definitely the problem I had.

I did some Googling for doing PCRE to POSIX regular expressions and updated the 
string:


/^(Received:\sfrom)[^;]+(;\s[A-Z]{1}[a-z]{2,3},)\s+([[:digit:]]{1,2}[^\n]+)/ 
REPLACE $1 [127.0.0.1] (localhost [127.0.0.1]) by myserver.com$2 $3

… and it works!

Not sure why I had it in my head that regexp: was PCRE (especially when there’s 
another dictionary type that explicitly says pcre:), but at least I’ve learned 
something.

- J

Re: Removing trace records on submission MSA

[J Doe]

Hi Karol,

> I am using this:
> 
> /^(Received:) from.*]\).*(.{2}by mail\.nimitz\.pl.*Postfix.*) (with
> [E]{0,1}SMTP[S]{0,1}[A]{0,1}) (.*)/ REPLACE $1 from mail.nimitz.pl
> (localhost [127.0.0.1])$2 with SMTP $4
> 
> Just change 'mail.nimitz.pl' with FQDN of your server. This expression
> works for me and also removes information about the connection, which in
> my case can tell if the mail was sent from webmail (unencrypted
> connection from webmail host to postfix host) or client's MUA
> (encrypted).
> 
> It can probably fail on some systems due to .* matching, which is
> greedy, but I wrote it many years ago and it works, so I am not fixing
> it.


Thanks for this.  I’m looking to mask out the DDNS name of a xDSL connection.

I tried the following with a visual regex program (to make checking captures 
easier):

/etc/postfix/submission_privacy_header
/(Received\:\s*from)[^\;]+(\;\s[A-Z]{1}[a-z]{2,3}\,)\s+(\d{1,2}[^\n]+)/ 
   REPLACE $1 [127.0.0.1] (localhost [127.0.0.1]) by myserver.com$2 $3

…however this does not match when Postfix evaluates it.  I am attempting three 
captures:

1. Received: from
2. The first part of the date from the ; to the , after the day (eg: “Fri”)
3. The last part of the date from the numerical day number to the end

The reason for the two part handling of the date is I want to strip out 
whitespace between “Day,  6 Apr . . .”.  If I don’t strip this out it puts a 
line break inline in the Received: header that breaks the date over two lines.

Does anyone know what I’m doing wrong and/or is there a way to make Postfix 
provide more debug output for a regexp: operation ?

Thanks,

- J

Re: Removing trace records on submission MSA

[J Doe]

Hi Philip,

>> Thank you for your reply.
>> 
>> I currently use DKIM and as per the RFC for DKIM, I don’t include trace 
>> headers in the message hash that makes up the DKIM signature.  I am under 
>> the impression that my DKIM signatures should be correct in this case if I 
>> use your solution and it re-writes the first trace header - is that true or 
>> are there any other DKIM issues I might run into ?
> 
> Unless you have specifically configured your DKIM setup to include trace 
> headers in the hash (which you should not do according to the RFC), your DKIM 
> signatures will continue to be correct if you anonymise the first trace 
> header like I do.

Thank you for your reply.

I configured master.cf and created the regular expression lookup table, but my 
installation of Postfix (3.1.0), does not appear to support PCRE as placing 
“pcre:” as the dictionary type in master.cf generated an error that "this 
dictionary type is unsupported".

Some Googling revealed that I may be able to install support for that, but 
rather than install something else I switched to “regexp:”.  Unfortunately, 
regexp stated there was an error in the regular expression string (the error 
indicated the line but not the character in the regexp that it did not like).

My regular expression skills are rusty, so I went with an unoptimized search 
string:

/etc/postifx/submission_header_rules

/Received: from/ REPLACE Received: from [127.0.0.1] (localhost 
[127.0.0.1]) by server.com 

… where server.com  is the FQDN for my mail server.

As I have this configured for submission, I then tested sending e-mail to Gmail 
and can confirm that my DKIM is still valid (as expected - I don’t include 
Received: headers in the DKIM hash, as the DKIM RFC recommends), and this is 
not doing any unwanted edits on mail over port 25.

I figured this was sufficient but further reading indicates that some anti spam 
software pays attention to the Received: headers (although most sources noted 
this was an issue when configuring Postfix to *DELETE* the first header, which 
I don’t want to do).

With that in mind, I had two questions:

** Is there any anti spam software that checks for the date and time at the end 
of the Received: string ?  My very basic search string does not capture the 
date and time after the semicolon and therefore does not show up.

** If there is anti spam software that looks for the date and time, could you 
help me construct a “regexp:” compatible search string ?  I experimented with 
captures but again, my regular expression skills are bad at the moment.

Thanks,

- J

Re: Removing trace records on submission MSA

[J Doe]

Hi Phillip,

>> I have a question in regards to removing some trace records when providing 
>> submission on Postfix 3.1.x and later.
>> 
>> While reading RFC 6409 (“Message Submission for Mail”), I note that the RFC 
>> observes that:
>> 
>>   "Even when submitted messages are complete, local site policy may
>> dictate that the message text be examined or modified in some way,e.g., 
>> to conceal local name or address spaces.”
>> 
>> By this I take it that I could remove perhaps the initial trace message that 
>> returns information about internal addresses and network names.  It seems to 
>> me that both Hotmail/Outlook and Gmail do this.
>> 
>> Is this acceptable ?  The only bad side to it would appear to be possibly 
>> some increased difficulty in troubleshooting.
>> 
>> If it is an acceptable process, how would I configure Postfix to do this 
>> only on submission ?
> 
> I anonymise the initial Received: header with a header_checks on the 
> submission service.
> 
> In master.cf, I add `-o cleanup_service_name=subcleanup` to the submission 
> service.  That service is defined as:
> 
>   subcleanup  unix n   -   n   -   0   cleanup
> -o syslog_name=postfix/subcleanup
> -o header_checks=pcre:$config_directory/submission_header_checks.pcre
> 
> The submission_header_checks.pcre file contains:
> 
>   /^\s*(Received: from .+?(?=\s\())[^\n]*(.*for <.*)/ REPLACE $1 
> (localhost [127.0.0.1])$2
> 
> I'm sure there are better ways to do this, but this works for me.
> 
> It doesn't interfere with debugging much because the logs will mentain the 
> replacement and it's easy to grep for.

Thank you for your reply.

I currently use DKIM and as per the RFC for DKIM, I don’t include trace headers 
in the message hash that makes up the DKIM signature.  I am under the 
impression that my DKIM signatures should be correct in this case if I use your 
solution and it re-writes the first trace header - is that true or are there 
any other DKIM issues I might run into ?

Thanks,

- J

Re: domain email autoconfiguration

[J Doe]

Hi David,

> On Mar 31, 2018, at 8:52 PM, Wietse Venema  wrote:
> 
> David Mehler:
>> Hello,
>> 
>> If anyone has autoconfiguration going with their email domain please
>> email me privately. I'd like to ask you some questions about your
>> setup. What do you use?
> 
> Perhaps you can explain what you mean.
> Automatic configuration of Postfix to send mail through an ISP?
> Automatic configuration of clients to send mail through Postfix?
> 
>   Wietse

Are you perhaps referring to auto configuration of a client’s MUA (like how
on Apple iOS devices you enter the e-mail address and password and 
then Apple Mail discovers submission, IMAP, etc. settings and so forth) ?

The RFC that covers that is RFC 6186 - “Use of SRV Records for Locating
E-mail Submission/Access Services”.

This is done in DNS and is not Postfix-specific.

If I recall correctly, one restriction is that the SMTP AUTH account name
that is used must be the same as the e-mail address - so if you have AUTH
account names that differ from the e-mail address, this is an issue.

Regards,

- J

Re: Forcing TLS 1.2 on submission

[J Doe]

Hi Viktor

> On Mar 29, 2018, at 3:15 PM, Viktor Dukhovni <postfix-us...@dukhovni.org> 
> wrote:
> 
> 
> 
>> On Mar 29, 2018, at 2:56 PM, J Doe <gene...@nativemethods.com> wrote:
>> 
>> I am attempting to restrict the TLS protocol version used by my SMTP AUTH’d 
>> clients on the submission service.
>> 
>> In master.cf I have added the following to the submission service:
>> 
>>   -o smtpd_tls_ciphers=high
>>   -o smtpd_tls_exclude_ciphers=EXPORT,MEDIUM
>>   -o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1,TLSv1.2
> 
> Given that TLS is typically mandatory for submission (you should have
> "-o smtpd_tls_security_level=encrypt" already set), it simpler to just
> set "smtpd_tls_mandatory_protocols" in main.cf.  The recommended syntax
> is to just eliminate the negative, but not accentuate the positive:
> 
>   smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
> 
> If TLS 1.3 happens someday to be supported by both ends, no need to
> preclude its use at that time.
> 
>> …however, when I test via the OpenSSL client:
>> 
>>   openssl s_client -connect example.com:587 -starttls smtp -tls1
>> 
>> …it connects and negotiates TLS 1.0.  It will also negotiate TLS 1.1 and TLS 
>> 1.2 on successive tests.
>> 
>> What am I doing wrong ?
> 
> Perhaps a missing "postfix reload" or some syntax issue with master.cf.

Thanks for your reply.

Ok, I have to say I feel pretty pleased with myself - I found a solution 
roughly around when your e-mail came it, so I tried my solution first and it 
worked!

I ran nmap against the server to enumerate the TLS versions in use and the 
output noted that the cipher preference was set to “client”.  Googling for 
server preference in Postfix brought me to the Postfix web page on TLS [1] 
which mentioned the “mandatory” set of settings.  I then edited the list I sent 
in my previous e-mail, restarted Postfix and ran the nmap enumeration again and 
it now supports only TLS 1.2.

Your e-mail confirms my results - thank you.

- J

Sources:

[1] http://www.postfix.org/TLS_README.html#server_cipher

Forcing TLS 1.2 on submission

[J Doe]

Hi,

I am attempting to restrict the TLS protocol version used by my SMTP AUTH’d 
clients on the submission service.

In master.cf I have added the following to the submission service:

-o smtpd_tls_ciphers=high
-o smtpd_tls_exclude_ciphers=EXPORT,MEDIUM
-o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1,TLSv1.2

…however, when I test via the OpenSSL client:

openssl s_client -connect example.com:587 -starttls smtp -tls1

…it connects and negotiates TLS 1.0.  It will also negotiate TLS 1.1 and TLS 
1.2 on successive tests.

What am I doing wrong ?

Thanks,

- J

Question regarding 8BITMIME / BINARYMIME

[J Doe]

Hi,

I have a question regarding 8BITMIME.

I know Postfix supports 8BITMIME and does not support BINARYMIME, but I am 
wondering why both 8BITMIME and BINARYMIME are ESMTP extensions.  It would 
appear that 8BITMIME solves the same problem as BINARYMIME (allow 8-bit 
encoding of MIME), so why wasn’t BINARYMIME made obsolete in the RFC’s ?

Also - because 8BITMIME seems to solve the problem without CHUNKING, is that 
why Postfix supports it over BINARYMIME ?

Thanks,

- J

Re: How to write a milter with access to carddav

[J Doe]

Hi Andre,

> On Mar 9, 2018, at 6:53 AM, André Rodier  wrote:
> 
> Hello,
> 
> I would like to know if there is any milter for postfix that would let
> me query a CardDav server?
> 
> The idea is to add a custom header, for instance 'X-Address-Book:
> Personal' if the from email address is referenced in a personal carddav
> address book of the recipient.
> 
> This will be used by a sieve filter, for instance to mark the emails as
> "Personal" / or "importants", al GMail, to keep them in the inbox.
> 
> Otherwise, if you can point me in a direction on how to write this, I
> will be happy. I can write it in Go, C, Perl, Python, etc.
> 
> I hope it's clear, thanks for your help.

I don’t have a solution to your question but out of curiosity, what is your 
CardDAV backend ?

- J

Removing trace records on submission MSA

[J Doe]

Hi,

I have a question in regards to removing some trace records when providing 
submission on Postfix 3.1.x and later.

While reading RFC 6409 (“Message Submission for Mail”), I note that the RFC 
observes that:

"Even when submitted messages are complete, local site policy may dictate 
that the message text be
   examined or modified in some way, e.g., to conceal local name or address 
spaces.”

By this I take it that I could remove perhaps the initial trace message that 
returns information about internal addresses
and network names.  It seems to me that both Hotmail/Outlook and Gmail do this.

Is this acceptable ?  The only bad side to it would appear to be possibly some 
increased difficulty in troubleshooting.

If it is an acceptable process, how would I configure Postfix to do this only 
on submission ?

Thanks,

- J

Re: ETRN use and Postfix configuration

[J Doe]

Hi LuKreme,

> On Mar 4, 2018, at 8:44 AM, LuKreme  wrote:
> 
> Isn't ETRN a good thing? What's the benefit from disabling it?
> -- 
> My main job is trying to come up with new and innovative and effective ways 
> to reject even more mail. I'm up to about 97% now.
> 

It’s a good thing in that it is an improvement over the original TURN verb with 
some security as opposed to no security.

RFC 1985 (ETRN) makes two use cases for this:

**  Startup conditions
**  “..mail nodes that have transient connections to their service 
providers”

The last point is referring to when someone had a gateway SMTP server that used 
to periodically dial up an ISP and exchange e-mail with it, server to server.  
That was common in the 90’s (which is when the RFC was submitted), but you’d be 
pretty hard pressed to find that now.

Postfix supports fast ETRN [1], which has performance optimizations over what 
other implementations provide, but you have to explicitly configure it to use 
it.  From my original e-mail I learned from the list how to squelch the 
advertisement on EHLO and ensure that it was not configured, either.

Sources:

[1] http://www.postfix.org/ETRN_README.html

Re: postwhite? (why not?)

[J Doe]

Hi Wietse,

> On Mar 2, 2018, at 1:49 PM, Wietse Venema  wrote:
> 
> Postscreen blocks sites based on:
> 
> - Their reputation that hey don't send legitimate mail.
>  zen.spamhaus.org and bl.spamcop.net are examples of that.
> 
> - Their behavior. The postscreen pregreet test is an example of that.
> 
>Wietse

Ok.  I am definitely making use of the zombie detection (pre-greeting, etc.), 
but I also use the DNSRBL’s on postscreen.  I was under the possibly mistaken 
impression that this was a bit more efficient instead of having a spam source 
connect, possibly negotiate STARTTLS and then start a SMTP transaction and then 
have it rejected based on smtpd restrictions.

Should I then continue to use postscreen for the zombie detection but then move 
my DNSRBL entries to smtpd restrictions ?

Apologies for belabouring the point - I’m just not understanding.

Thanks,

- J

Re: postwhite? (why not?)

[J Doe]

Hi Wietse,

> On Mar 2, 2018, at 10:15 AM, Wietse Venema  wrote:
> 
> Perhaps it is time to repeat what postscreen is and is not.
> 
> Don't use postscreen to block spam. Use postscreen to block spambots.
> Those who misunderstand the difference will be disappointed.
> 
> In particular, hotmail is not a spambot, therefore it should not
> be blocked by postscreen.
> 
>Wietse

I have been using the following in my /etc/postfix/main.cf:

postscreen_dnsbl_sites = bl.spamcop.net, zen.spamhaus.org   

postscreen_dnsbl_action = drop

While this weeds out spambots I imagine it is weeding out spam sources as well. 
 As a point of clarification, should I list DNSBL sites specifically for 
spambots here and then have a separate list of DNSBL for just spam on the smtpd 
restrictions ?

Thanks,

- J

Re: postscreen_dnsbl_whitelist_threshold and SORBS and Google

[J Doe]

Hi,

> On Mar 1, 2018, at 4:17 PM, MRob  wrote:
> Good suggestions thank you everyone. Over the last 24hours I saw clients 
> SORBS listed:
> 
> ** a few that were listed by other RBLs
> ** many that were senders I can't block or delay: facebook, google, etc
> ** one or two that looked like they could be spammy
> 
> SORBS on one hand seem a real pain to deal with on the other hand facebook 
> and google do send spam, its a known fact, doesnt someone have to step up and 
> push them a little bit especially cuz they dont even accept abuse complaints?

That’s disconcerting.  I *was* using SORBS . . . 

I have temporarily removed SORBS from my postscreen DNS BL lists.  I know there 
are a number of lists of publicly available DNS BL’s but is there a list of 
BL’s that have a low false-positive history ?  I’m aware that false positives 
do happen, but blacklisting Gmail seems to be avoidable.

Thanks,

- J

ESMTP CHUNKING

[J Doe]

Hi,

I have been reading about the ESMTP CHUNKING extension (RFC 3030), after 
noticing that both Hotmail and Gmail advertise it on EHLO.  

I checked the Postfix man pages (man 5 postconf), as well as the Postfix 
documentation at postfix.org [1] and can’t see any documentation related to it.

Some Googling of the mail archives showed posts from 2014, while another Google 
showed a reference [2] to Postfix from 2017:

“IMSVA (SMTP server) uses Postfix as its MTA, which doesn’t support 
CHUNKING”

Given Postfix’s excellent security track record, was this extension not 
implemented due to security concerns or is it obsolete (I checked the RFC and 
didn’t see a notice of being obsolete), and Hotmail and Gmail advertise it for 
legacy support ?

Genuinely curious and not an implementation request or criticism.

Thanks,

- J

Sources:
[1] www.postfix.org/documentation.html
[2] 
https://success.trendmicro.com/solution/1118615-does-interscan-messaging-security-virtual-appliance-imsva-support-binary-data-bdat-command

Re: Question regarding VRFY

[J Doe]

Hi John,

> On Feb 27, 2018, at 3:25 PM, John Fawcett  wrote:
> I can't think of a compelling reason either to enable VRFY or to disable
> it. Disabling it stops people abusing it, but then they can just use
> RCPT TO to get the same information in most cases. I disabled it since I
> can't see any use for it.
> 
> John

That is a valid point - I believe the VRFY RFC observed the same thing: that 
RCPT TO can be used in a similar fashion.

Performing an EHLO to both Gmail and Hotmail/Outlook shows that they both 
disable it, which I would expect, but do they implement a policy of a certain 
number of invalid RCPT TO cause the connection to terminate ?

I know there is a setting for the number of “junk commands” received in 
Postfix, but that is different.  Is there a method via main.cf for restricting 
RCPT TO abuse ?

Thanks,

- J

Re: ETRN use and Postfix configuration

[J Doe]

Hi Noel,

> On Feb 27, 2018, at 10:18 PM, Noel Jones  wrote:
>> ** Is Postfix logging that ETRN is disabled on the first, unencrypted SMTP 
>> session and then logging this again for the encrypted session (ie: Postfix 
>> is just logging I disabled this and Google is not attempting to issue ETRN 
>> each time) ?
> 
> Yes, this. The informative message is logged as soon as the client
> sends EHLO, and before the client sends any other commands.
> 
> Now that you know it's working, you can use the silent_discard
> keyword to clean up the logs.
> 
>  -- Noel Jones

Thanks for you reply.  Ok, good to know; I will prepend silent_discard to the 
list.

- J

ETRN use and Postfix configuration

[J Doe]

Hello,

I read the “Postfix ETRN Howto” [1] as well as man 5 postconf with regards to:

postscreen_discard_ehlo_keywords
smtpd_discard_ehlo_keywords

... and disabled the announcement of ETRN via:

postscreen_discard_ehlo_keywords = ETRN
smtpd_discard_ehlo_keywords = ETRN

I then restarted the server and observed an inbound connection from Gmail:

Feb 27 21:12:19 server postfix/smtpd[2369]: connect from 
mail-oi0-x22f.google.com
Feb 27 21:12:19 server postfix/smtpd[2369]: discarding EHLO keywords: ETRN
Feb 27 21:12:19 server postfix/smtpd[2369]: Trusted TLS connection established 
...
Feb 27 21:12:19 server postfix/smtpd[2369]: discarding EHLO keywords: ETRN

My question is:

** Is the Gmail SMTP server attempting to use ETRN on the first, unencrypted 
SMTP session with my server and then attempting to request it again after 
STARTTLS when the TLS connection is established and this is why it is logging 
that it is discarding ETRN each time or ...

** Is Postfix logging that ETRN is disabled on the first, unencrypted SMTP 
session and then logging this again for the encrypted session (ie: Postfix is 
just logging I disabled this and Google is not attempting to issue ETRN each 
time) ?

Thanks,

- J

Sources:
[1] www.postfix.org/ETRN_README.html

Question regarding VRFY

[J Doe]

Hi,

I read in both the Postfix man file (man 5 postconf), and the SMTP RFC (5321), 
that VRFY can be disabled on a site-by-site basis.

I disabled this on my server for port 25 but am wondering if I should leave 
this enabled on my Postfix instance that provides submission (587) ?  I have 
confirmed that by editing main.cf and master.cf it is only available on 
submission and requires SASL authentication before working.

Are there modern MUA’s that authenticated users may use that make use of VRFY 
(perhaps by checking e-mail address validity before sending, while the message 
body is still being composed), or am I better off leaving it disabled 
everywhere ?

Thanks,

- J

General websites on e-mail administration that also cover Postfix ?

[J Doe]

Hi,

I was looking for some websites that covered e-mail administration in general 
and that also mentioned Postfix.

I checked the Postfix homepage [1] and on the link “Howtos and FAQs” there are 
two links at the bottom under the heading “General E-mail/System 
Administration”.  Unfortunately the first link appears to be dead and the 
second link is more of a discussion of the C10K problem, which appears to be 
more of use to people writing software on the scale of Postfix.

Can anyone recommend any good sites that cover e-mail administration in general 
?  I’d like one that makes use of Postfix but if it also covers Exim or 
Exchange Server, that would be great as well.

Thanks,

- J

Sources: [1] www.postfix.org

IP ACL’s for smtpd port 25 and not submission

[J Doe]

Hi,

I currently use postscreen on my Postfix version 3.1.0 mail server.  I 
implement IP ACL’s via it to ban malicious connections (generally from xDSL IP 
blocks), against smtpd running on port 25.

I have recently configured and turned on submission with SASL.  With submission 
available, I don’t want to ban any particular xDSL IP blocks as clients that 
are travelling around the world may make use of Internet in cafes, hotels, etc. 
to connect to submission that themselves are xDSL connections.

With postscreen doing the IP ACL work, from what I understand this extends to 
*both* smtpd and submission smtpd.  Is there a way where I can have separate IP 
ACL lists for smtpd on port 25 and smtpd on submission ?  Is this possible via 
postscreen or is there another way of achieving this ?

Thanks,

- J

Diffing man 5 postconf changes between releases

[J Doe]

Hi,

I currently use Postfix version 3.1.0.  I know that there are announcements of 
feature changes between each release of Postfix via e-mail and I read these, 
but I was wondering if there was an easy way to see the changes to the main.cf 
configuration parameters between versions ?

For example, can I somehow diff the difference between man 5 postconf on 
version 3.1.0 and the current release of Postfix ?  When I say diff, I am 
hoping to be able to see just the new configuration parameters.

The only way I can think of doing this is to dump the default configuration 
from postconf from one version and then diff that against the default 
configuration from postconf from the current version.  That will tell me new 
parameters, but it won’t show me if the documentation for existing parameters 
has changed.

If there isn’t an easy way to do this, is this in fact documented somewhere 
(perhaps a list of configuration parameter changes on the website that I just 
haven’t found yet) ?

Thanks,

- J

Question regarding smtpd DNS resolution

[J Doe]

Hello,

I had a question about Postfix’s smtpd DNS resolution.

In my logs (generally from spam sources), I see the following:

Feb 4 15:05:46 server postfix/smptd[718]: warning: hostname 1-2-3-4.dyn.isp.net 
does not resolve to address 1.2.3.4: Name or service not known

Does this mean that:

1. smtpd receives a connection from an smtp client and does a reverse DNS lookup
2. smtpd performs a forward DNS lookup on the result and compares the resulting 
IP address to the initial IP
3. If the IP addresses don’t match it reports this error

... or is some other logic used to generate the error message ?

Thanks,

- J

Re: submission configuration in master.cf

[J Doe]

Hi Noel,

> On Jan 23, 2018, at 4:39 PM, Noel Jones  wrote:
> 
>> I was wondering about a configuration parameter listed with the default 
>> submission configuration in master.cf.
>> 
>> One of the parameters that overrides the settings in main.cf 
>> “milter_macro_daemon_name” is set to “ORIGINATING” instead of the default 
>> value in main.cf.
>> 
>> Why is this done ?
>> 
>> Thanks,
>> 
>> - J
>> 
> 
> Some milters use that to change their behavior, such as dkim to sign
> instead of verify.

Ah, that makes sense - verifying DKIM on mail that one of my trusted clients 
generated would be wasted effort.

Thank you!

- J

submission configuration in master.cf

[J Doe]

Hi,

I was wondering about a configuration parameter listed with the default 
submission configuration in master.cf.

One of the parameters that overrides the settings in main.cf 
“milter_macro_daemon_name” is set to “ORIGINATING” instead of the default value 
in main.cf.

Why is this done ?

Thanks,

- J

Re: Request for feedback on SMTPD restrictions

[J Doe]

Hi,

> On Jan 22, 2018, at 8:43 AM, Matus UHLAR - fantomas  wrote:
> 
>> smtpd_helo_required = yes
>> smtpd_helo_restrictions = permit_mynetworks,
>>reject_unauth_pipelining,
>>   reject_invalid_helo_hostname,
>>reject_non_fqdn_helo_hostname,
>>check_helo_access hash:/etc/postfix/helo_acl,
>>reject_unknown_helo_hostname,
>>permit
> 
> I'd put check_helo_access before reject_invalid_helo_hostname and
> reject_non_fqdn_helo_hostname, so I could allow some hosts use HELO string
> that would otherwise be rejected.
> 
> You can sometimes get a machine with hardcoded and unconfigurable HELO
> string.

Ok.  

The idea behind this was that the only legitimate server I have seen connecting 
that: a) has a transient reverse DNS lookup problem and b) sometimes passes 
that but gives a HELO/EHLO hostname that Postfix 3.1.0 rejects is Outlook.com.

So for a client restriction I whitelist a client that has a reverse DNS lookup 
of:

outbound.protection.outlook.compermit

I then whitelist the EHLO/HELO hostname with the helo_acl list:

outbound.protection.outlook.compermit

This works regardless of the Outlook.com server connecting as the names 
partially match (ie: a real Outlook server might be 
server-1234.outbound.protection.outlook.com, another might be 
server-5678.outbound.protection.outlook.com and so forth).

Is this not a good idea, though ?

Also, the last part where you state “You can sometimes get a machine with 
hard-corded and un-configurable HELO string”, is that you can sometimes get 
this from a *legitimate*  server ?

>> smtpd_sender_restrictions = permit_mynetworks,
>>reject_unauth_pipelining,
>>reject_non_fqdn_sender,
>>check_sender_access hash:/etc/postfix/sender_acl,
>>   reject_unknown_sender_domain,
>>   permit
> 
> Here I recommend the opposite - putting reject_unknown_sender_domain before
> check_sender_access, unless you have sane reason to accept mail from invalid
> domains (maybe one like the above).

Ah, right - good catch.

>> smtpd_recipient_restrictions = permit_mynetworks,
>>permit_auth_destination,
>>reject
>> 
>> smtpd_relay_restrictions = permit_mynetworks,
>>permit_auth_destination,
>>   reject
> 
> I believe putting "reject_unauth_destination, permit" is better than
> "permit_auth_destination, reject", if you put any kind of restrictions in
> the future.
> 
> Also, with "reject_unauth_destination" you can skip the default "permit"

Ok.  One thing that confused me even though it works - why is permitting an 
authorized destination (either through permit_auth_destination or via 
reject_unauth_destination), required for relaying if I want people to be able 
to deliver to recipients at my domain ?

If I remove the permission of authorized destinations and if I host mail for 
say example.com, I cannot receive mail for whoe...@example.com without the 
permission of authorized destinations for smtpd_relay_restrictions.  I tested 
this by sending mail to whoe...@example.com and it would reject it without this 
permission.

Thanks again,

- J

Re: Request for feedback on SMTPD restrictions

[J Doe]

Hi Noel,

> On Jan 21, 2018, at 3:35 PM, Noel Jones  
>> smtpd_client_restrictions = permit_mynetworks,
>>reject_unauth_pipelining,
>>check_client_access hash:/etc/postfix/client_acl,
>>reject_unknown_client_hostname,
>>permit
> 
> reject_unknown_client_hostname is likely to reject legit mail.  Use
> with caution.
> 
> Consider instead using reject_unknown_reverse_client_hostname, which
> rejects clients with no PTR record.  This is similar to what many
> large providers do and is fairly low risk.

Thank you for your feedback.

Ok, I will move from: reject_unknown_client_hostname to: 
reject_unknown_reverse_client_hostname as I am looking to block senders that do 
not provide reverse DNS lookup.  These usually show up in my logs with Postfix 
identifying their connecting IP address but a DNS value of “unknown”.

> The "permit" at the end is unnecessary, but doesn't break anything.
> Same with all the other "permit" in restrictions below

Interesting.  Ok, I had thought it was required.  I think I may keep them, even 
though they’re redundant, as it seems to document the intent a bit better.

>> smtpd_helo_required = yes
>> smtpd_helo_restrictions = permit_mynetworks,
>>reject_unauth_pipelining,
>>reject_invalid_helo_hostname,
>>reject_non_fqdn_helo_hostname,
>>check_helo_access hash:/etc/postfix/helo_acl,
>>reject_unknown_helo_hostname,
>>permit
> 
> reject_unknown_helo_hostname is likely to reject legit mail.  Use
> with caution.

Ok, although I checked man 5 postconf again for the definition:

“Reject the request when the HELO or EHLO hostname has no DNS A or MX record.”

Is there ever a case where a legitimate mail sender would not have either an A 
(and I assume if it is an IPv6 sender an  record), or a MX record ?

The other way I had looked at it was that since the SMTP error code for this is 
4xx, if it does reject a legitimate sender the sender would queue the message 
and try again.  I would assume that not having A/ or MX would be transient 
for a legitimate sender.

- J

Request for feedback on SMTPD restrictions

[J Doe]

Hi,

I have a basic SMTP server set up with what I believe to be good smtpd_*_ 
restrictions, but I was wondering if anyone could provide any insight on how to 
improve them or if I have been redundant in the restrictions.  Even with 
reading the man pages, I find some of the restrictions tricky.

I am eventually having a submission service (with an -o 
smtpd_relay_restrictions=permit_sasl_authenticated in master.cf), for this 
server but right now what follows is just for a SMTP server on port 25.

smtpd_client_restrictions = permit_mynetworks,
reject_unauth_pipelining,
check_client_access hash:/etc/postfix/client_acl,
reject_unknown_client_hostname,
permit

smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
reject_unauth_pipelining,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
check_helo_access hash:/etc/postfix/helo_acl,
reject_unknown_helo_hostname,
permit

smtpd_sender_restrictions = permit_mynetworks,
reject_unauth_pipelining,
reject_non_fqdn_sender,
check_sender_access hash:/etc/postfix/sender_acl,
reject_unknown_sender_domain,
permit

smtpd_recipient_restrictions = permit_mynetworks,   
permit_auth_destination,
  
reject  
  

 
smtpd_relay_restrictions = permit_mynetworks,   
 
permit_auth_destination,
  
reject

Thanks,

- J

Question regarding SASL auth only over TLS in SMTP server

[J Doe]

Hi,

I have a question about enabling SASL authentication in the Postfix SMTP server 
*ONLY* over TLS.

In the documentation [1] under the “Encrypted SMTP session (TLS)” heading, it 
lists recommended configurations for SASL auth that restrict the SASL 
mechanisms to noanonymous and noplaintext:

A more sophisticated policy . . . but only over a TLS-encrypted connection:

/etc/postfix/main.cf
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous

It then lists the following:

To offer SASL authentication only after a TLS-encrypted session . . .

/etc/postfix/main.cf
smtpd_tls_auth_only = yes

Does this mean that the smtpd_tls_auth_only parameter supersedes the mechanism 
configuration options, or do I need the following if I want to have noanonymous 
and noplaintext mechanism only over TLS:

/etc/postfix/main.cf
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_tls_auth_only = yes

Thanks,

- J

Notes:

[1] Closest section is: 
http://www.postfix.org/SASL_README.html#smtpd_sasl_security_options

Cyrus vs Dovecot for SASL AUTH and IMAP

[J Doe]

Hi,

I am looking to use either Cyrus or Dovecot for both SASL authentication and 
IMAP.  While Postfix 3.1.0 supports both, I was wondering which to prefer if 
security is my most important deciding factor ?  Does one have a better track 
record than the other ?

Thanks,

- J

Questions about auto replying in VIRTUAL_README

[J Doe]

Hi,

I have two questions about the “Autoreplies” section in the VIRTUAL_README [1].

If I was setting up auto replies for the virtually hosted domain of 
“example.com”, would the correct configuration be:

/etc/postfix/main.cf
virtual_alias_maps = hash:/etc/postfix/virtual
transport_maps = hash:/etc/postfix/transport

/etc/postfix/virtual
u...@example.com u...@example.com,
u...@example.com@autoreply.example.com

/etc/postfix/transport
autoreply.example.com autoreply:

/etc/postfix/master.cf
autoreply  unix  -  n  n  -  -  pipe  flags=  user=nobody  
argv=/path/to/autoreply  $sender  $mailbox

Secondly, is there a sample script available ?  I checked the documentation for 
pipe(8), master.cf and the default master.cf that ships with Postfix version 
3.1.0 and did not see references to a sample script.

Thanks,

- J

Notes:

[1] http://www.postfix.org/VIRTUAL_README.html

Questions about mailing list managers in VIRTUAL_README

[J Doe]

Hi,

I have a question about the “Mailing List” section in the VIRTUAL_README [1].

The third paragraph states:

“This example assumes that in main.cf, $myorigin is listed under the
mydestination parameter setting...”

Because the mailing list is being set up with virtual hosting, doesn’t this 
cause problems ?  I note that the three previous virtual hosting examples on 
the same page state:

“NEVER list a virtual_alias_domain name as a mydestination domain!”

Secondly, the third paragraph continues:

“If that is not the case [you don’t have myorigin set to $mydestination], 
specify 
an explicit domain name on the right-hand side of the virtual alias table 
entries...”

Does that mean that virtual from the example should be:

/etc/postfix/virtual
listname-requ...@example.comlistname-requ...@example.com
listn...@example.comlistn...@example.com
owner-listn...@example.com.   owner-listn...@example.com

Thanks,

- J

Notes:

[1] http://www.postfix.org/VIRTUAL_README.html

Questions regarding ecliptic curve support

[J Doe]

Hi,

I had two short questions regarding Postfix’s elliptic curve support for the 
SMTP server.

1.  Under the man documentation for: tls_eecdh_strong_curve the documentation 
states “...approximately 128-bit security...”.  Is that saying that it is 
equivalent to 128-bits RSA or it provides an elliptic curve key size of nearly 
128-bits ?

2. To make use of ecliptic curve encryption a TLS certificate must have been 
made with support for ecliptic curves, correct ?  A TLS certificate using RSA 
keys will not work ?

Thanks,

- J

Re: Minor grammar mistake in man 5 postconf

[J Doe]

> On Jan 8, 2018, at 8:55 PM, Wietse Venema <wie...@porcupine.org> wrote:
> 
> J Doe:
>> This should be changed to:
>> 
>>?When this constraint is violated, or any of the digest records are 
>> malformed,
>>digest algorithm agility will *BE* disabled?
> 
> Fixed in Postfix 3.2 and later...
> 
>Wietse

Hi Wietse,

Ah, yes - I should have checked if this was already a part of later versions, 
as this was: man 5 postconf on Postfix 3.1.

- J

Minor grammar mistake in man 5 postconf

[J Doe]

Hi,

I noticed a very small grammatical error under: man 5 postconf

Under the configuration parameter: tls_dane_digest_agility under the “maybe” 
option, the second last sentence states:

“When this constraint is violated, or any of the digest records are 
malformed,
digest algorithm agility will disabled.”

This should be changed to:

“When this constraint is violated, or any of the digest records are 
malformed,
digest algorithm agility will *BE* disabled”

- J

TLS session tickets versus TLS session cache

[J Doe]

Hi,

I have noticed in the Postfix documentation (man 5 postconf), that the 
smtpd_tls_session_cache_database parameter notes:

“As of Postfix 2.11 the preferred mechanism for session resumption is RFC 5077 
TLS session tickets...for Postfix >= 2.11 this parameter should generally be 
left empty”

I note that this text is NOT in the smtp_tls_session_cache_database parameter 
notes.

For Postfix version 2.11 and later, should BOTH smtp_tls_session_cache_database 
and smtpd_tls_session_cache_database be left empty to use session tickets, 
instead, or is that only for the SMTP SERVER ?

Thanks,

- J

Question regarding smtpd_recipient_restrictions

[J Doe]

Hi,

I have a basic question regarding the smtpd_recipient_restrictions parameter.

From what I understand, these are restrictions applied to the SMTP RCP TO 
command. 

In the case of a server that receives mail for a domain and also allows clients 
to send mail through it (via AUTH’d clients), does smtpd_recipent_restrictions 
apply to recipients at the domain or to recipients of mail sent by the AUTH’d 
clients or both ?

So, as an example, if the server handles mail for example.com, do the 
restrictions apply to:

1. Recipients at example.com (example: u...@example.com is recipient)

2. Recipients of mail from people at example.com (example: u...@example.com -> 
u...@gmail.com where u...@gmail.com is recipient)

3. Both cases

Thanks,

- J

Re: Distinction between next-hop and nexthop ?

[J Doe]

> On Dec 15, 2017, at 5:38 PM, Viktor Dukhovni <postfix-us...@dukhovni.org> 
> wrote:
> 
>> On Dec 15, 2017, at 5:37 PM, J Doe <gene...@nativemethods.com> wrote:
>> 
>> Example:
>> 
>>   “Match against the next-hop domain...”
>> 
>>   “When MX lookups are not suppressed, this is the original nexthop 
>> domain...”
>> 
>> Up until this point, I had been viewing them as interchangeable, but are 
>> they in fact referring to two different things/terms ?
> 
> Same.

Hi Viktor,

Ok, thanks.

- J

Distinction between next-hop and nexthop ?

[J Doe]

Hi,

I was reading the documentation for the smtp_tls_verify_cert_match parameter in 
man 5 postconf and noted under the “nexthop” strategy that both next-hop and 
nexthop are specified.

Example:

“Match against the next-hop domain...”

“When MX lookups are not suppressed, this is the original nexthop domain...”

Up until this point, I had been viewing them as interchangeable, but are they 
in fact referring to two different things/terms ?

Thanks,

- J

Re: Question regarding use of amavisd-new

[J Doe]

On Dec 12, 2017, at 11:12 AM, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:

>>> On 2017-12-12 10:55, J Doe wrote:
>>> I was wondering if fellow Postfix users would still recommend using 
>>> amavisd-new when integrating AV (ClamAV), and spam filtering (SpamAssasin) ?
> 
>> On 12.12.17 16:12, Sven Schwedas wrote:
>> There's nothing wrong with Amavis. The only decent alternative I know of
>> is Rspamd.
> 
> maybe mimedefang and sagator.
> 
>>> The site I have this in mind for receives a moderate amount of e-mail per 
>>> day.
> 
>> IMO I'd stick to amavis – while Rspamd /can/ perform better at large
>> scale, the documentation is awful. So stick to what you know.
> 
> not that amavisd couldn't have better docs :-)

Hi everyone,

Ok, good to know that amavisd-new is still a reasonable solution!

Thank you for mentioning rspamd.  I had only briefly checked that out (I really 
like that Lua is the integrated scripting language - I’ve used Lua on a number 
of other projects), but the fact that the documentation is lacking is a show 
stopper for me.  I definitely agree with the sentiment that incomplete 
documentation is a bug.

Thanks again for your feedback,

- J

Question regarding use of amavisd-new

[J Doe]

Hi,

I was wondering if fellow Postfix users would still recommend using amavisd-new 
when integrating AV (ClamAV), and spam filtering (SpamAssasin) ?

The site I have this in mind for receives a moderate amount of e-mail per day.

This appears to be the most mentioned configuration via web searches, but I was 
wondering if this still held true for 2017/2018 (amavisd-new’s last release was 
2016/04/26) ?

Thanks,

- J

Re: Question about CA’s for the smtp client

[J Doe]

Hi Victor,

> On Dec 11, 2017, at 6:13 PM, Viktor Dukhovni <postfix-us...@dukhovni.org> 
> wrote:
> 
>> On Dec 11, 2017, at 5:40 PM, J Doe <gene...@nativemethods.com> wrote:
>> 
>> I have a question regarding specifying where the list of trusted CA’s are in 
>> regards to the smtp client.
> 
> The recommended set of trusted CAs for the Postfix SMTP client is
> *empty*.  TLS in SMTP is opportunistic, and email sent whether or
> not the peer appears to be authenticated.  So any trusted CAs you
> might configure are largely just wasted memory and CPU.

Ok.  If I am understanding you correctly, you are saying that if the SMTP 
client is configured to use opportunistic TLS, the mail will be delivered 
regardless of whether the remote peer is *authenticated* ?

In my case, I use opportunistic TLS for the SMTP client:

/etc/postfix/main.cf
smtp_tls_security_level = may

I then had the CA list set up:

/etc/postfix/main.cf
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

I did not have any per-destination rules set up - all mail via the SMTP client 
used these settings.  When I send a test message in to my server and the SMTP 
client sends it out to my test Gmail address, I note that the TLS log line in 
mail.log is:

Dec 11 20:40:44 server postfix/smtp[2559]: Trusted TLS connection . . .

But when I remove the CA list the log line is:

Dec 11 20:40:44 server postfix/smtp[2559]: Untrusted TLS connection . . .

*HOWEVER* you are saying that the authentication status (“Trusted” / 
“Untrusted”), is actually irrelevant as the mail will still be delivered to 
Gmail regardless.  The fact that I receive successful authentication 
(“trusted”), is irrelevant compared to no authentication (“untrusted”), because 
the mail goes through either way so in effect all I am doing is wasting compute 
resources ?

Apologies if this is a basic question - I do appreciate your help.  

After Postfix configuration ins and outs, I have a book ready on cryptography 
that I am going to read to get a better handle on this.

- J

Question about CA’s for the smtp client

[J Doe]

Hi,

I have a question regarding specifying where the list of trusted CA’s are in 
regards to the smtp client.

In man 5 postconf, I can see there are two configuration parameters regarding 
this:

smtp_tls_CAfile
smtp_tls_CApath

The documentation (as I understand it), notes that:

1. smtp_tls_CAfile

— Specifies file that contains CA certs of root CA’s trusted to sign either 
remote SMTP server certificates or intermediate CA certificates

2. smtp_tls_CApath

— Specifies directory with PEM format CA certs that smtp client uses to verify 
remote SMTP server certificate
— Preferred over smtp_tls_CAfile when the number of trusted roots is large

On one of my installations of Postfix 3.1.0 on Ubuntu 16.04 LTS, I use CAfile 
to specify the file that stores all the CA certs:

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

My questions are:

1. Is that correct ?

2. Is there any other guidance on when to prefer smtp_tls_CApath over 
smtp_tls_CAfile ?

Thanks,

- J

Re: Question regarding smtp_per_record_deadlne parameter

[J Doe]

Hi Wietse,

> On Dec 6, 2017, at 8:00 AM, Wietse Venema  wrote:
> 
> Viktor Dukhovni:
> 
> With TLS turned on, the deadline is enforced per TLS message, which
> can be up to 16kbytes. 16kbytes in 10s would be difficult with a
> dialup or low-tech cellular network.
> 
>Wietse
> 
>Wietse

I am guessing that would extend to most SATCOM connections (Iridium, etc.), as 
well ?

Thanks,

- J

Re: Question regarding smtp_per_record_deadlne parameter

[J Doe]

> On Dec 5, 2017, at 1:46 PM, Noel Jones  wrote:
> 
> If you're only connecting to google over a decent internet link, I
> doubt you'll see any effect whatsoever.  Kinda like me using polar
> bear bait in Tennessee.
> 
>  -- Noel Jones

Hi Noel,

That actually reminded me of something that crossed my mind, today - I forgot 
about the inherently dynamic nature of routing.

Even though my server is within North America and it is extremely likely that I 
am hitting the closest node of Google’s GMail servers in North America, as 
routes are updated over time, there’s the possibility of the mail going over a 
poor connection in a worst case scenario.

I know that’s less likely given the North American scenario, but it helped me 
understand even more why this setting would not be enabled by default.

- J

PS - Polar bear bait in Tennessee is actually very effective against the rare 
and elusive country music polar bear, a breed seldom seen but known to frequent 
those parts on vacation, in search of some tunes . . .

Re: Question regarding smtp_per_record_deadlne parameter

[J Doe]

Hi Noel and Wietse,

Thank you for your prompt feedback.

I think (in the quest to explore this more fully), I will try enabling this for 
a short term and see what sort of TLS issues I may have.  The server I 
described in previous mails is low volume so I believe it’s ideal for testing 
something like this.

If anyone’s interested, I can always report back to the list about it.

- J

> On Dec 4, 2017, at 7:39 PM, Wietse Venema <wie...@porcupine.org> wrote:
> 
> Noel Jones:
>>> On 12/4/2017 3:35 PM, J Doe wrote:
>>> Hello,
>>> 
>>> I currently have a server that is configured as a mail forwarding domain 
>>> [1].  Using example.com as an example:
>>> 
>>>/etc/postfix/main.cf
>>>virtual_alias_domains = example.com
>>>virtual_alias_maps = hash:/etc/postfix/virtual
>>> 
>>>/etc/postfix/virtual
>>>u...@example.com users-gmail-addr...@gmail.com
>>> 
>>> As such, the SMTP client is used to forward the messages to each user?s 
>>> existing Gmail addresses.
>>> 
>>> I was reading more about the smtp client parameters and read about 
>>> smtp_per_record_deadline.  In postconf(5) it states that the time limits 
>>> are changed and that this ?...limits the impact from hostile peers that 
>>> trickle data one byte at a time?
>>> 
>>> Since my peer for the smtp client is always Gmail, this isn?t an issue for 
>>> me, but I was wondering - why does this default to ?no? ?  I note the 
>>> warning in postconf(5) that states for slow network connections this can 
>>> cause problems with TLS, but I am assuming that this doesn?t apply to most 
>>> configurations.  
>>> 
>>> Why wouldn?t I want this normally enabled ?
> 
> It's not safe to make this the Postfix default, but you're welcome
> to override that if you are sure that connections will never be
> slow.
> 
>Wietse

Question regarding smtp_per_record_deadlne parameter

[J Doe]

Hello,

I currently have a server that is configured as a mail forwarding domain [1].  
Using example.com as an example:

/etc/postfix/main.cf
virtual_alias_domains = example.com
virtual_alias_maps = hash:/etc/postfix/virtual

/etc/postfix/virtual
u...@example.com users-gmail-addr...@gmail.com

As such, the SMTP client is used to forward the messages to each user’s 
existing Gmail addresses.

I was reading more about the smtp client parameters and read about 
smtp_per_record_deadline.  In postconf(5) it states that the time limits are 
changed and that this “...limits the impact from hostile peers that trickle 
data one byte at a time”

Since my peer for the smtp client is always Gmail, this isn’t an issue for me, 
but I was wondering - why does this default to “no” ?  I note the warning in 
postconf(5) that states for slow network connections this can cause problems 
with TLS, but I am assuming that this doesn’t apply to most configurations.  

Why wouldn’t I want this normally enabled ?

Thanks,

- J

Sources
[1] www.postfix.org/VIRTUAL_README.html 

Re: Question about postscreen_cache.db

[J Doe]

Hi,

> On Nov 11, 2017, at 7:24 PM, Wietse Venema  wrote:
> 
> Or you can use 'lmdb:' instead 'btree:'. LMDB support was added in Postfix 
> 2.11.
> It's a totally different implementation.

That’s a great idea - that will side-step any Berkeley DB specific bugs.

Thanks,

- J

Re: Question about postscreen_cache.db

[J Doe]

Hi Wietse,

> On Nov 11, 2017, at 8:37 AM, Wietse Venema <wie...@porcupine.org> wrote:
> 
> J Doe:
>> Is this really the only way to fix this, though ?  This feels a bit like a 
>> workaround as opposed to the ?correct? solution (assuming that there is a 
>> ?more correct? solution).
> 
> Why bother with all this? The database is synced without error.
> It is in a consistent state. Only the close operation complains
> because of some DB bug. This does not affect correctness.

Thanks for your reply.

When Googling for this problem, a number of the posts I found referenced this 
situation happening in jailed deployments and that’s what I’m running.  Most of 
these posts are from some time ago, so I assumed that with me running Postfix 
3.1 on a modern distro, the bug(s) in the Berkeley DB libraries that cause this 
issue would be fixed by the Berkeley DB developers.

The other reason is that the volume of these warnings seemed quite large.  I 
can, of course, filter that out, but I wondered if there was a workaround for 
this to suppress the warnings.  The workaround that I found works, I just 
wasn’t sure if it was the best solution.

- J

Re: Question about postscreen_cache.db

[J Doe]

Hi,

> On Nov 11, 2017, at 3:06 AM, J Doe <gene...@nativemethods.com> wrote:
> 
> Hello,
> 
> I have an admittedly basic question, but I have been trying to troubleshoot 
> this for a while with no success.
> 
> I have enabled postscreen(8) on Postfix 3.1 and receive a warning in 
> mail.log: 
> 
> “close database /var/spool/postfix/var/lib/postscreen_cache.db: No such file 
> or directory (possible Berkeley DB bug)”
> 
> A quick Google of this returns that this is caused on Debian systems that run 
> Postfix in a jail (which matches my system).  The most recent post regarding 
> this appears to be here: 
> https://tech.feedyourhead.at/content/postscreen_cache_db_no_such_file
> 
> As per the blog posting, I stopped Postfix and created a directory in the 
> jail for the postscreen_cache.db:
> 
> $ sudo systemctl stop postfix.service
> $ sudo mkdir -p /var/spool/postfix/var/lib/postfix
> 
> I moved the postscreen_cache.db file to this location:
> 
> $ sudo mv /var/lib/postfix/postscreen_cache.db 
> /var/spool/postfix/var/lib/postfix
> 
> I set the permission and ownership on this file:
> 
> $ sudo chown postfix:postfix 
> /var/spool/postfix/var/lib/postfix/postscreen_cache.db
> $ sudo chmod 0660 /var/spool/postfix/var/lib/postfix/postscreen_cache.db
> 
> I checked that the postfix user can access this file:
> 
> $ sudo -u postfix namei -m 
> /var/spool/postfix/var/lib/postfix/postscreen_cache.db
> 
> I *DIFFER* from the blog in that I do not create a symbolic link - I use the 
> Postfix main.cf configuration parameter below:
> 
> postscreen_cache_map = 
> btree:/var/spool/postfix/var/lib/postfix/postscreen_cache
> 
> I then start Postfix:
> 
> $ sudo systemctl start postfix.service
> 
> When I check: /var/spool/postfix/var/lib/postfix I can see that 
> postscreen_cache.db is updated as time progress, but I still get the warning 
> about not being able to close the postscreen_cache.db database.

An update on this initial e-mail ...

Checking mail.log, Postfix outputted a helpful warning about me attempting the 
following in main.cf:

postscreen_cache_map = btree:/var/spool/postfix/var/lib/postfix/postscreen_cache

Postfix notes that the path I created in the jail does not point to the 
expected Postfix data directory.  It then displayed that the data directory 
was: /var/lib/postfix

My initial response was to update the data_directory in main.cf to point to the 
jail path:

data_directory = /var/spool/postfix/var/lib/postfix

...however this caused other parameters to display warnings because the jail 
path I specified was not expected.  I checked the default setting:

$ postconf | grep -i data_directory

...which revealed that it was: /var/lib/postfix

I then tried setting the postscreen_cache_map to this in main.cf:

postscreen_cache_map = btree:/var/lib/postfix/postscreen_cache

...but received the original warning message when postscreen(8) attempted to 
close the postscreen cache map.

I went back and moved the postscreen_cache.db to the jail location and created 
a symbolic link (as per the instructions in the blog I referenced in the 
original e-mail):

$ sudo mv /var/lib/postfix/postscreen_cache.db 
/var/spool/postfix/var/lib/postfix
$ sudo ln -s /var/spool/postfix/var/lib/postfix/postscreen_cache.db 
/var/lib/postfix/postscreen_cache.db

...and restarted Postfix . . . and the warnings from postscreen stop (success) !

Is this really the only way to fix this, though ?  This feels a bit like a 
workaround as opposed to the “correct” solution (assuming that there is a “more 
correct” solution).

Thanks,

- J

Question about postscreen_cache.db

[J Doe]

Hello,

I have an admittedly basic question, but I have been trying to troubleshoot 
this for a while with no success.

I have enabled postscreen(8) on Postfix 3.1 and receive a warning in mail.log: 

“close database /var/spool/postfix/var/lib/postscreen_cache.db: No such file or 
directory (possible Berkeley DB bug)”

A quick Google of this returns that this is caused on Debian systems that run 
Postfix in a jail (which matches my system).  The most recent post regarding 
this appears to be here: 
https://tech.feedyourhead.at/content/postscreen_cache_db_no_such_file

As per the blog posting, I stopped Postfix and created a directory in the jail 
for the postscreen_cache.db:

$ sudo systemctl stop postfix.service
$ sudo mkdir -p /var/spool/postfix/var/lib/postfix

I moved the postscreen_cache.db file to this location:

$ sudo mv /var/lib/postfix/postscreen_cache.db 
/var/spool/postfix/var/lib/postfix

I set the permission and ownership on this file:

$ sudo chown postfix:postfix 
/var/spool/postfix/var/lib/postfix/postscreen_cache.db
$ sudo chmod 0660 /var/spool/postfix/var/lib/postfix/postscreen_cache.db

I checked that the postfix user can access this file:

$ sudo -u postfix namei -m 
/var/spool/postfix/var/lib/postfix/postscreen_cache.db

I *DIFFER* from the blog in that I do not create a symbolic link - I use the 
Postfix main.cf configuration parameter below:

postscreen_cache_map = btree:/var/spool/postfix/var/lib/postfix/postscreen_cache

I then start Postfix:

$ sudo systemctl start postfix.service

When I check: /var/spool/postfix/var/lib/postfix I can see that 
postscreen_cache.db is updated as time progress, but I still get the warning 
about not being able to close the postscreen_cache.db database.

What am I missing ?

Thanks,

- J

Question about message_drop_headers and DKIM

[J Doe]

Hi,

I have a question regarding the message_drop_headers main.cf configuration 
parameter.

The man page states that it:

“[specifies] names of message headers that the cleanup(8) daemon will
 remove after applying header_checks(5) and *BEFORE* invoking Milter
 applications...”

Checking man 8 cleanup I note this relates to:

“...inbound mail...inserting into incoming mail queue...”

On the smtpd(8) server process, I have OpenDKIM configured to run as a Miller.  
It currently notifies me in the log if DKIM signatures on incoming mail were 
found and if it was able to validate them.

BUT . . . If message_drop_headers is extracting some header information 
*BEFORE* running the OpenDKIM Milter, how is it that DKIM is not breaking ?  
Isn’t that discarding header information that would be used in computing the 
DKIM signature ?

Thanks,

- J

Re: Removal or obfuscation of mail_name

[J Doe]

Hi Victor, 

>> I was wondering (and I know the gains would be minor given that this
>> falls into security through obscurity), is there anything to gain by
>> either removing this or specifying something false ?
> 
> There is nothing to be gained by pretending your server is not running
> Postfix.  Postfix is too easy to "fingerprint" by observing its responses
> to various SMTP commands.  Just let it be.

Ok, thanks for letting me know.

- J

Removal or obfuscation of mail_name

[J Doe]

Hello,

I was reading about the mail_name parameter in main.cf.

I was wondering (and I know the gains would be minor given that this falls into 
security through obscurity), is there anything to gain by either removing this 
or specifying something false ?

Is there any third-party servers or tools in the e-mail ecosystem that would 
depend on this being “Postfix” ?

Thanks,

- J

Question about relay_domains parameter

[J Doe]

Hello,

I currently have my server configured to perform virtual domain hosting.  It 
forwards mail addressed to addresses for my virtual domain (ex: example.com), 
to Gmail accounts.

Mail —> u...@example.com —> u...@gmail.com

I was reading more about the relay_domains parameter in “man 5 postconf”.  It 
states:

“[specifies] destination domains (and subdomains thereof) this system
will relay mail *TO*”

I note that on Postfix 3.0 and later (my server is Postfix 3.1.0), this value 
defaults to an empty value.  When I specify “postconf | grep -i relay_domains”, 
I note that if the compatibility_level is 2 or higher (which my server is 
configured to), the value defaults to $mydestination.

I have mydestination configured to “localhost”.

How is it, then, that my server is successfully forwarding to Gmail ?  Would I 
not have to specify the Gmail DNS names in relay_hosts ?  Should I explicitly 
configure that ?

Thanks,

- J

Re: Eliminating backscatter

[J Doe]

Hi Noel,

>> On Oct 30, 2017, at 6:42 PM, Noel Jones <njo...@megan.vbhcs.org> wrote:
>> 
>> On 10/30/2017 5:07 PM, J Doe wrote:
>> 
>> How do I stop backscatter generated from my server in response to the 
>> bounces from Gmail ?
> 
> This is a very difficult problem to solve.  Your choices are a)
> don't accept spam, or b) don't forward to gmail.
> 
> There may be information on the web about disabling bounces in
> postfix.  Those "solutions" that discard undeliverable mail are not
> supported and not recommended, and won't be addressed here.

Thank you for your reply.

Two things:

1. For anyone following this thread in the future, I thought I’d note that I’ve 
been doing some more reading and it turns out that my supposition in my 
previous message that I get blocking of messages to non-existent recipients 
with Postfix 2.0 and above is correct, but for a different reason than I 
thought.

I was reading more about “Rejecting Unknown Local Recipients with Postfix” [1] 
and I realized that this document is referring to e-mail to unknown recipients 
in the *local domains*.  It goes on to specify that those are domains that 
match $mydestination, IP addresses in $inet_interfaces or interfaces listed in 
$proxy_interfaces.

Because my server is configured to perform virtual domain hosting, I have the 
following:

   /etc/postfix/main.cf
   mydestination = localhost 

...but if a message is sent to a non-existent domain that I *virtually host* 
for:

/etc/postfix/main.cf
virtual_alias_domains = example.com
virtual_alias_maps = hash:/etc/postfix/virtual

...it generates a NOQUEUE and terminates the SMTP conversation by default.  To 
catch mail that is addressed to non-existent recipients, I add the following to 
my virtual_alias_maps hash file:

/etc/postfix/virtual

@example.com ADDRESS_TO_SEND_TO

...where ADDRESS_TO_SEND_TO is the e-mail address to catch e-mails addressed to 
a non-existent domain.

2. Ok, I understand not wanting to talk about disabling bounce messages 
entirely, but I wondered if there was a more “nuanced” approach to that.

Is it possible to have conditional logic on SMTP error codes ?  Going through 
my logs I noticed that when Gmail detects that a message I forward to a Gmail 
recipient is missing DKIM information, it generates an SMTP error code of: 
500-5.7.1.  Can I then configure bounce messages based on the following:

IF SMTP error code = 5.7.1
AND remote server = GMail
DON’T generate a bounce message (my server) 
ELSE
Generate bounce messages (my server)

Thanks,

- J

Sources:

[1] www.postfix.org/LOCAL_RECIPIENT_README.html

Re: Eliminating backscatter

[J Doe]

Hi Noel,

> On Oct 30, 2017, at 4:07 PM, Noel Jones <njo...@megan.vbhcs.org> wrote:
> 
>> On 10/30/2017 2:52 PM, J Doe wrote:
>> Hi,
>> 
>> One of my mail servers (Postfix 3.1.0), is configured to perform virtual 
>> domain hosting.  It forwards mail to the virtual domain to mailboxes of 
>> users on Gmail.
>> 
>> I can see in my mail log that spam with forged origin addresses sometimes 
>> comes into my server that is addressed to virtual domain addresses.  My 
>> server rejects some of this spam and then generates a non-delivery e-mail to 
>> the origin address of the spam.  Of course, as some of those addresses are 
>> forged, my server is producing backscatter.
> 
> 
> Your mail server must have a list of valid recipients and reject
> mail to unknown recipients.  Where to list the valid recipients
> depends on how the domain is defined in postfix.  Most of what you
> need can be found in
> http://www.postfix.org/ADDRESS_CLASS_README.html
> 
> Avoid any wild-card domain rewrites since those disable recipient
> validation.
> 
> If your mail server does after-queue spam scanning, it MUST NOT
> generate a bounce for unwanted mail.  Either tag-and-deliver mail or
> scan during SMTP so you can reject (not bounce) unwanted mail.

Thank you for your reply.  

Now that I think of it, I think I left out some necessary details about my 
server in my original e-mail.

In my case, with my server configured to do virtual domain hosting (let’s say 
for the domain example.com), mail addressed to a recipient on my server gets 
forwarded to the recipient’s corresponding Gmail account.

So for example:

Spam —> u...@example.com —> u...@gmail.com

When spam is sent to u...@example.com my server then tries to forward that to 
u...@gmail.com. GMail’s spam filters detect spam and generate an SMTP error 
code.  My server then generates a non-delivery status e-mail.  Because the spam 
had a forged origin e-mail address, my server then generates backscatter to 
that forged address.

With regards to your reply, I am not having spam addressed to an unknown 
recipient at the virtual domain (such as some_unknown_recipi...@example.com) - 
this e-mail is addressed to a valid recipient that gets blocked by GMail and 
then generates backscatter.

I did read the link you provided and I also looked at “Rejecting Unknown Local 
Recipients with Postfix”, but from that document I was under the impression 
that I got blocking of unknown recipients automatically in Postfix 3.1.0:

“As of Postfix version 2.0, the Postfix SMTP server rejects mail for 
unknown 
recipients in local_domains . . . This feature was optional with earlier 
Postfix 
versions” [1]

How do I stop backscatter generated from my server in response to the bounces 
from Gmail ?

Thanks again,

- J

Sources:

[1] http://www.postfix.org/LOCAL_RECIPIENT_README.html

Eliminating backscatter

[J Doe]

Hi,

One of my mail servers (Postfix 3.1.0), is configured to perform virtual domain 
hosting.  It forwards mail to the virtual domain to mailboxes of users on Gmail.

I can see in my mail log that spam with forged origin addresses sometimes comes 
into my server that is addressed to virtual domain addresses.  My server 
rejects some of this spam and then generates a non-delivery e-mail to the 
origin address of the spam.  Of course, as some of those addresses are forged, 
my server is producing backscatter.

I read the “Backscatter Howto” [1] on the Postfix website, but from what I read 
this appears to address backscatter when someone is forging the origin address 
of spam to be from my server (resulting in accounts on my server getting the 
non-delivery e-mails).  I am looking to correct backscatter that my server 
generates.

I believe I read that non-delivery e-mails should be disabled and my server 
should generate a 5.x.x SMTP error code.  Is this correct ?  If so, how do I 
implement this in main.cf ?

Thanks,

- J

Sources:

[1] http://www.postfix.org/BACKSCATTER_README.html

Re: Question about default_destination_concurrency_limit

[J Doe]

Hi Viktor,

> On Oct 30, 2017, at 12:11 AM, Viktor Dukhovni  
> wrote:
> 
>> I had a question regarding the main.cf parameter 
>> “default_destination_concurrency_limit”.  The man page (man 5 postconf), 
>> states it is: “The default maximal number of parallel deliveries to the same 
>> destination.”
> 
> Correct.
> 
>> and that this applies to the smtp(8) delivery agent.
> 
> It states no such thing, and indeed this is not the case.

Oh, perhaps I am mistaken.  When I look at that parameter using: 
http://www.postfix.org/postconf.5.html

...it states: “This is the default limit for delivery via the lmtp(8), pipe(8), 
smtp(8)and virtual(8) delivery agents.”

>> This got me wondering . . . how would one adjust this parameter ?  I am 
>> thinking it is only
>> through benchmarking trial and error, as a number of factors would seem to 
>> affect this
>> (server load, bandwidth, etc.).  But then I was thinking if it was through 
>> trial and error,
>> how was the value of “20” determined when most people running Postfix will 
>> have varying
>> equipment for their server? [1]
> 
> This parameter much less about your server's capacity that it is about
> not overwhelming remote servers with too many parallel connections.
> It should, for a transport that handles deliveries to many destinations,
> of course not consume the entire transport process limit, which as
> specified with default_process_limit or the corresponding master.cf
> entry.  The latter defaults to 100, so 20 is a reasonable fraction
> that does not result in any single destination hogging all the
> transport slots.

Ah, I see.

Thanks for your reply,

- J

Question about default_destination_concurrency_limit

[J Doe]

Hi,

I had a question regarding the main.cf parameter 
“default_destination_concurrency_limit”.  The man page (man 5 postconf), states 
it is: “The default maximal number of parallel deliveries to the same 
destination.” and that this applies to the smtp(8) delivery agent.

This got me wondering . . . how would one adjust this parameter ?  I am 
thinking it is only through benchmarking trial and error, as a number of 
factors would seem to affect this (server load, bandwidth, etc.).  But then I 
was thinking if it was through trial and error, how was the value of “20” 
determined when most people running Postfix will have varying equipment for 
their server ? [1]

Thanks,

- J

[1] I ask this as there a couple of other parameters in the main.cf config file 
that seem to fall into this category and I am wondering if there is a more 
efficient method of determining the values for my server or whether the 
solution is also through trial and error.

Re: Question regarding smtpd and log of “Untrusted TLS connection”

[J Doe]

Hi Viktor,

> On Oct 20, 2017, at 6:14 PM, Viktor Dukhovni  
> wrote:
> 
>> In the documentation I have noted that even if STARTTLS is enabled, mail
>> delivery will not be stopped even if the certificate at the other server
>> is invalid or is a self-signed certificate. As such, TLS encryption is
>> used but authentication of the remote server does not happen.
> 
> Now you've switched to talking to about outbound mail (delivery from
> your system to other systems).

Oops.  You are totally right - that terminology came from the smtp section of 
the Postfix doc’s as it was the last section I read yesterday. 

>> I have noticed in my logs today an entry:
>> 
>>   postfix/smtpd[1234]: Untrusted TLS connection established from 
>> example.com[1.2.3.4]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 
>> bits)
>> 
>> ...where example.com is not the real server name.
> 
> And now you're looking at inbound mail again, and it seems that you've
> enabled receipt of client certificates, which is generally not a good
> idea on port 25 (the default is smtpd_tls_ask_ccert = no).

Yes, I checked my main.cf and saw I had smtpd_tls_ask_ccert = yes.  I have 
since corrected it.

>> When smtpd parsed the certificate before this log entry, I noticed that
>> the subject_CN of the certificate is the same as the issuer - for example:
>> 
>>   subject_CN=example
>>   issuer=example
>> 
>> ...where example is not a FQDN but the hostname of the remote server.
>> There is also no references to certificate authorities.
> 
> Perfectly normal even for receiving server, but escpecially for SMTP
> client certificates CA-issued names are not especially meaningful.
> What would you do differently on port 25 when receiving inbound mail
> from a client with a given certificate?

Ok.  So the certificate that smtpd was presented with was a CLIENT certificate 
in this case.  Was I right that it was a self-signed certificate ?

>> I am wondering two things:
>> 
>> [1] Am I correct that the remote server has not been authenticated but
>> has used encryption ?
> 
> The transmission channel is encrypted all the way from the remote
> server to any TLS man in the middle attacker, and again all the
> way from the man in the middle attacker to you. :-)

Ahh! 

Just kidding - I am more concerned with passive wiretaps, as you mention below.

> More seriously, the channel is immune to passive wiretaps, but
> unless the client authenticated your server somehow, and would
> not have continued sans authenticated TLS, MiTM attacks cannot
> be excluded.
> 
>> [2] Is it not authenticated in this case because the remote server
>> appears to be a self-signed certificate ?

Ok.  In the context of smtpd (receiving mail), I note three states in the log:

Authenticated TLS ...
Untrusted TLS ...
Anonymous TLS ...

I am pretty sure what most of those are referring to, but not totally sure.

Thanks again,

- J

Question regarding smtpd and log of “Untrusted TLS connection”

[J Doe]

Hello,

I currently have a Postfix 3.1.0 server with smtpd configured to use 
opportunistic TLS encryption:

/etc/postfix/main.cf
smtpd_tls_security_level = may

In the documentation I have noted that even if STARTTLS is enabled, mail 
delivery will not be stopped even if the certificate at the other server is 
invalid or is a self-signed certificate.  As such, TLS encryption is used but 
authentication of the remote server does not happen.

I have noticed in my logs today an entry:

postfix/smtpd[1234]: Untrusted TLS connection established from 
example.com[1.2.3.4]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)

...where example.com is not the real server name.

When smtpd parsed the certificate before this log entry, I noticed that the 
subject_CN of the certificate is the same as the issuer - for example:

subject_CN=example
issuer=example

...where example is not a FQDN but the hostname of the remote server.  There is 
also no references to certificate authorities.

I am wondering two things:

[1] Am I correct that the remote server has not been authenticated but has used 
encryption ?

[2] Is it not authenticated in this case because the remote server appears to 
be a self-signed certificate ?

Thanks,

- J