RE: whitelist for single reject

> > ${config_directory}/reject1_map > > # These hosts are whitelisted from this test only > > 192.0.2.1 OK > > 192.0.2.2 OK > > # Everyone else gets this test > > 0.0.0.0/0 reject1 > > To make "from this test only", it would have to be "DUNNO", > rather than

RE: whitelist for single reject

> > Suppose I have the following general case: > > > > /etc/postfix/whitelist1: > > OK > > OK > > > > /etc/postfix/whitelist2: > > OK > > > > How would I accomplish the following? > > > > smtpd_*_restrictions = > > . . . > > reject_[type1] . . . (except

RE: whitelist for single reject

> Since hostname based whitelists are fragile in the face of transient > DNS failures, and many users struggle with regular expression correctness. > A CIDR map is more appropriate here: > Viktor. Excellent. Thanks. Michael

RE: whitelist for single reject

> In addition to defining alternative restriction lists and classes as > Wietse noted, you can keep all of your restrictions in the standard > smtpd_*_restrictions lists if you prefer and can accept the limitation > of having each type of whitelisting applied to a trailing sublist of >

whitelist for single reject

I'm pretty sure I've seen this documented somewhere, but I can't find it. What I'd like to do is have a whitelist apply to only a specific reject. For example: smtpd_*_restrictions = . check_*_access . reject_. reject_...

RE: SSL_accept error on just one of several similar servers

> > > On Mar 26, 2018, at 1:07 AM, Michael Fox <n...@mefox.org> wrote: > > > > Any idea of what's wrong? Or how to find out what's wrong? > > Most likely a firewall is (mis)configured to block STARTTLS. > > -- > Viktor. You were correct! Th

SSL_accept error on just one of several similar servers

I have several Postfix servers with virtually identical configurations. That is, they have their own hostnames, IP addresses, etc. But the rest of main.cf and master.cf and various *_access, etc. files are the same. I recently started having a problem with SSL_accept errors on just one of the

RE: Header-Name: capitalization

> https://tools.ietf.org/html/rfc5322#section-1.2.2 > Ah! Thanks Viktor. Michael

Header-Name: capitalization

I'm working on a milter that checks for certain headers. The RFCs specify header names with specific capitalization. For example: "Message-ID". I don't see anything the RFCs that indicates that alternate capitalization should be accepted, such as "Message-Id". But perhaps I missed it. So,

RE: RESOLVED: RE: wrong From: and Return Path: address

> > On Sep 26, 2017, at 11:23 PM, Michael Fox <n...@mefox.org> wrote: > > > > BTW, the mail provider found that the default sendmail config and their > own > > customized config both rewrote the From: header when the From: address > was > > for a

RESOLVED: RE: wrong From: and Return Path: address

> > Michael Fox skrev den 2017-09-21 19:52: > > > I have a problem that seems to have started when I upgraded from > Ubuntu > > > 14.04/Postfix 2.11.0 to Ubuntu 16.04/Postfix 3.1.0. It involves the > > > From: > > > and Return Path: addresses seen by

RE: wrong From: and Return Path: address

> sorry for late reply on this here, No problem Benny. Thanks for taking the time to review ... > i noted from logs that you use > mimedefang and amavisd for same mails, why ? amavisd runs spamassassin and clamav. No difference in setup between Postfix 2.11 and 3.1. I just added

RE: wrong From: and Return Path: address

> Michael Fox skrev den 2017-09-21 19:52: > > I have a problem that seems to have started when I upgraded from Ubuntu > > 14.04/Postfix 2.11.0 to Ubuntu 16.04/Postfix 3.1.0. It involves the > > From: > > and Return Path: addresses seen by recipients of mail sent fr

wrong From: and Return Path: address

I have a problem that seems to have started when I upgraded from Ubuntu 14.04/Postfix 2.11.0 to Ubuntu 16.04/Postfix 3.1.0. It involves the From: and Return Path: addresses seen by recipients of mail sent from a virtual domain on that machine. Clients of Google, Yahoo, Rackspace, . see the From:

RE: chroot setting in master.cf

> I wrote README.postfix.html for amavisd-new many years ago and I don't > recall > why master.cf was in the state it was by then. I wouldn't say it the > documentation is in error - it's has simply not seen any update in many > years. Ah, OK. Thanks. That explains the differences. >

RE: chroot setting in master.cf

> With Postfix 3, chroot is no longer the default. It remains an > available option for people who want to go through the effort. > > Wietse Yes, but that wasn't my question. Again, my question was: I'm configuring master.cf to add amavisd-new. The amavisd-new documentation

RE: chroot setting in master.cf

> The default master.cf as distributed by postfix has all services as > chroot "n", and that is the recommended setting. > -- Noel Jones Thanks Noel. Interesting. From http://www.postfix.org/BASIC_CONFIGURATION_README.html#chroot_setup, the recommendation seems to be to use chroot wherever

chroot setting in master.cf

I'm configuring master.cf to add amavisd-new. The amavisd-new documentation (/usr/share/doc/amavisd-new/README.postfix.html) differs from the default master.cf file regarding the chroot setting for the cleanup (and pre-cleanup) service. I presume that the amavisd-new documentation is in error

RE: reloading postfix with systemd

> Well at least in Redhat, if you do systemctl reload postfix it just > executes postfix reload internally. So it makes absolutely no > difference. > > # cat /usr/lib/systemd/system/postfix.service > [Unit] > Description=Postfix Mail Transport Agent > After=syslog.target network.target >

reloading postfix with systemd

In v16.04 LTS, Ubuntu has switched to systemd. "postfix reload" still seems to work just fine. But I wonder if I should be using "systemctl reload postfix" instead. Which method is preferred on systems that use systemd? And if either method works, are there differences or reasons to prefer one

RE: postfix check warnings on new Ubuntu 16.04 install

fix check warnings on new Ubuntu 16.04 install > > > > On August 9, 2017 2:03:47 PM EDT, Michael Fox <n...@mefox.org> wrote: > >I'm building a new 16.04 machine using the distro package for postfix > >(v3.1.0). The main.cf and master.cf files are still at default

postfix check warnings on new Ubuntu 16.04 install

I'm building a new 16.04 machine using the distro package for postfix (v3.1.0). The main.cf and master.cf files are still at defaults. I ran "postfix check" and it's listing warnings about some library files. This didn't happen on Ubuntu 14.04. I don't understand what it's trying to tell me

RE: simultaneous sessions from old client

> The same client can send the same message a thousand times if it > wants to, though perhaps not all at the same time. > OK Thanks.

simultaneous sessions from old client

I've got some very old clients that takes a message to multiple recipients at the same destination domain and separates the TO recipients and the CC recipients into two messages and then sends them separately. Until recently, the message to the TO address would go out in one queue run and the

RE: request improved logging for postfix.

> No fixes are necessary, other than maybe I should write a tutorial > on reading logs. > > -- Noel Jones +1 In particular, your writing style is exceptionally clear! Michael

checking file references

Is there a command that can check if all files referenced in main.cf are present? Currently, if my manual/visual review misses something, I don't find out until postfix tries to process a message and discovers the missing file. postfix check doesn't do this. Thanks, Michael

RE: milter to decode quoted-printable, base64, ...

> -Original Message- > An ideal tool for that is MIMEDefang, ... Thanks. After a very quick look at the project website, this looks like what I need. > "groff -T ascii" is your friend (if you befriend berserker vandals...) ... and another great hint. Thanks. > If you did this

RE: milter to decode quoted-printable, base64, ...

> > I've got some clients that are really simple and don't understand > > various > > message encoding types, such as quoted-printable, base64, possibly > > others. > > They understand plain text only. So, for users in specific domains, > > I'd > > like to convert quoted-printable, base64 and

milter to decode quoted-printable, base64, ...

I've got some clients that are really simple and don't understand various message encoding types, such as quoted-printable, base64, possibly others. They understand plain text only. So, for users in specific domains, I'd like to convert quoted-printable, base64 and possibly other encoded messages

RE: generic main.cf files

> > Only the documented behavior is supported. That means that bugs are > fixed, backwards compatibility is maintained as Postfix evolves. > > ... You skipped over the apparent discrepancy that I pointed out. I'll try to word it differently: You and Viktor and several others suggest creating

RE: generic main.cf files

> It is not documented, therefore it is not supported. Thanks and understood. And BTW, the documentation is excellent -- the best I've seen anywhere. Not to quibble, but the reason I double checked was that there DO appear to be supported features that are either not documented or else I

RE: generic main.cf files

> On 25/07/16 05:19, Michael Fox wrote: > > What about viewing the value which is set by reading a file? > > For example: mynetworks = ${config_directory}/filename > > Look at postmap(1) to see how you can do map lookups from the command > line. To clarify, I'm not t

RE: generic main.cf files

Michael: > > Ubuntu Postfix package sets myorigin to /etc/mailname, which seems to work Weitse: > The documented behavior is supported, as in, bugs fixed and backwards > compatibility provided as Postfix evolves. Undocumented behavior is > unsupported. Peter: > This is a debian modification, it

generic main.cf files

I've got several postfix systems which all have the same configuration except for a few host-specific parameters like: -- myhostname -- mynetworks -- mydestination -- myorigin -- inet_interfaces -- proxy_interfaces -- relay_domains -- virtual_mailbox_domains Typically, I copy the main.cf to

RE: smtpd restrictions on mail that comes from certain servers

> Does anyone have any ideas how I'd specify this? Would I have to use a > pcre like the following? > > /[^e][^x][^a][^m][^p][^l][^e][^\.][^c][^o][^m]$/WARN If you choose to use pcre, see: http://www.postfix.com/pcre_table.5.html It includes an example: !// Note that by default,

RE: (OT)Ham Radio + SMTP (was Re: How to restrict encrypted email)

> My understanding is that packet radio has been allowed in part of the > HAM band and in part of the Marine SSB band for quite a long time. > > Curtis That's correct Curtis. In fact, worldwide electronic mail was possible with packet and the worldwide BBS network long before commercial

smtpd_relay_restrictions clarification

Moving from a pre-v2.10 to post-v2.10 environment, I'd like make sure I understand the meaning/context of smtpd_relay_restrictions. Can someone give me a sanity check? http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions says: "By default, the Postfix SMTP server accepts: * Mail from

RE: How to restrict encrypted email

> You could use iptables to look for: > "--BEGIN" > "--END" > "/signed" > "/encrypted" > "/pkcs7" > "/pgp" Thanks to all. I've got enough to get me started with my homework. Lots to learn. Regards, Michael

RE: How to restrict encrypted email

Michael Fox: > > So, are there other obvious ways to recognize encrypted contents, other > than > > "Content-Type: multipart/encrypted"? Albrecht: > Basically, you need to check for > - OpenPGP/Inline (inspect every body, see rfc 2440, sect. 6.2) > - OpenPGP/

RE: How to restrict encrypted email

> minimize it with some filtering for the obvious cases > as you propose. Thanks Marco. I hadn't thought of some of those cases. But I would still like to block the obvious cases, as you say. So, are there other obvious ways to recognize encrypted contents, other than "Content-Type:

How to restrict encrypted email

I'd like to be able to reject mail that contains encrypted content. This is to satisfy US FCC rules against encrypted content on amateur radio frequencies. Some of our clients may connect via amateur radio. I'd like to be able to restrict it only for certain clients. But, as I understand it,

RE: auth/tls combinations sanity check

> > I can make up any variable name I want and assign a value to > > it main.cf, and then reference its value in main.cf and master.cf? > > Yes. > > -- > Viktor. Ah. That is indeed powerful. And now I understand your suggested solution, Viktor. It even solves a problem I didn't

RE: auth/tls combinations sanity check

> > But looking at http://www.postfix.org/postconf.5.html, I don't find > > mua_discard_ehlo_keyword_address_maps or mua_sender_restrictions. Are > > those > > literal names? Where can I find documentation? > > trick here is that we only ask for postconf -n, this will not display > postconf -Mf

RE: auth/tls combinations sanity check

> > So, I'm thinking I need three submission ports: > > * one for AUTH but no TLS > > * one for AUTH with opportunistic TLS > > * one for AUTH with enforced TLS > > You can combine these into just one service by using: > > main.cf: > mua_discard_ehlo_keyword_address_maps = >

auth/tls combinations sanity check

I have a possibly unusual AUTH/TLS combination requirement. As a newbie, I could use a sanity check. Requirements: * All virtual mail clients will use SASL AUTH * Virtual mail clients on specific internal networks MUST NOT be offered TLS. This is to satisfy FCC requirements prohibiting the use

RE: smtpd_sasl_security_options clarification

> Yes, again from the quote from Wietse that you snipped out: > > > Dovecot tells Postfix the supported mechanism names and their > > security properties. O.K. Thanks. I read but did not understand the quote above. Your explanation was clearer and I understood it the first time. Thanks

RE: smtpd_sasl_security_options clarification

> > > > I think the actual security features list is dependant on the SASL > > implementation, and which mechs satisfy each security feature is defined > > in cyrus and dovecot sasl. Ah. So you're saying that for each auth mechanism configured in the SASL implementation (dovecot in my case), the

RE: smtpd_sasl_security_options clarification

> > This is standard terminology, and therefore not defined in either > Postfix or SASL RFC. > > Active network attack: an attacker modifies the communication between > parties. > > Mutual authentication: each party authenticates to the other party. Thanks. But again, the question is *NOT*

RE: smtpd_sasl_security_options clarification

> In other words, how do I know which mechanisms will be > > disallowed with "noactive" or "nodictionary" or allowed by > "forward_secrecy" > > or "mutual_auth"? I'm unable to connect the dots. > > You can find out about SASL active etc. attacks in RFC 4422 > https://tools.ietf.org/html/rfc4422

RE: smtpd_sasl_security_options clarification

> > Michael Fox: > > http://www.postfix.org/postconf.5.html#smtpd_sasl_security_options says > "the > > following security features are defined for the cyrus server .". > Dovecot is > > not mentioned. So, is it correct to interpret this to mean that

smtpd_sasl_security_options clarification

http://www.postfix.org/postconf.5.html#smtpd_sasl_security_options says "the following security features are defined for the cyrus server .". Dovecot is not mentioned. So, is it correct to interpret this to mean that this postfix setting is a noop when dovecot is used for sasl authentication?

RE: Newbie SASL Auth with Dovecot problem

> > > I also tried port 25 and 587 from a separate machine that has an IP > > address > > in mynetworks. In that case, EHLO is not even recognized: > > > > telnet 587 > > 220 ESMTP Postfix (Ubuntu) > > EHLO client.example.com > > 502 5.5.2 Error: command not recognized > > HELO

RE: reject_sender_login_mismatch

> > Specify, for example: > > smtpd_sender_login_maps = hash:/etc/postfix/sasl_senders, >pcre:/etc/postfix/sasl_default_senders > > Where the contents of sasl_default_senders is, for example: > > root# cat sasl_default_senders > /^(.*)@domain$/ $1 > > Which

reject_sender_login_mismatch

I'm confused about how the reject_sender_login_mismatch restriction works. "reject_sender_login_mismatch Reject the request when $smtpd_sender_login_maps specifies an owner for the MAIL FROM address, but the client is not

RE: how to prevent MX lookup of virtual_mailbox_domain

> > Jun 30 20:12:31 myhost postfix/submission/smtpd[28379]: warning: Unable > to > > look up MX host for my.virtual.domain: Host not found, try again > > > > Why is this happening? > > Because YOU configured something that requires MX lookups: > check_*_mx_access, reject_unknown_sender_domain, >

how to prevent MX lookup of virtual_mailbox_domain

I have defined: virtual_alias_maps = hash:/etc/postfix/virtual virtual_mailbox_domains = my.virtual.domain (sanitized) virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_transport = lmtp:unix:private/dovecot-lmtp I'm still testing/configuring locally, so I haven't created the DNS

RE: Newbie SASL Auth with Dovecot problem

> > I don't see any > > smtpd_sasl_auth_enable = yes > > in your `postconf -n` output although you claim to have set it. The > default would be "no". > > Matthias Oh, jeez. How embarrassing. Thanks Matthias. I had entered smtp_... instead of smtpd_... And no matter how many times I

RE: Newbie SASL Auth with Dovecot problem

> > There is no AUTH on port 25, take 587. > > Suomi According to http://www.postfix.org/SASL_README.html#server_sasl_authc I should see AUTH on port 25. I also tried port 587. Same result. $ telnet localhost 587 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is

Newbie SASL Auth with Dovecot problem

I've been using Postfix for a while with no client submission. I'm trying to set up SASL for the first time, using Dovecot, to support virtual users. When I connect with EHLO, I do NOT see "AUTH" capabilities. Of course, I'm following: http://www.postfix.org/SASL_README.html First of

RE: RBLs in postscreen AND smtpd_*_restrictions

tscreen AND smtpd_*_restrictions > > On 05/06/16 17:10, Michael Fox wrote: > > Right. As I mentioned, I understand that part. My question was about > v3.1+ > > where the default for postscreen_dnsbl_min_ttl is only 60s. And, as I > > understand it, the defaults for v3.1 wo

RE: RBLs in postscreen AND smtpd_*_restrictions

> If postscreen_dnsbl_ttl or postscreen_dnsbl_min_ttl is 3600 (1 hour) but > the minimum TTL field of the DNSBL's SOA record is 10 (as it is for the > SBL) then postscreen will cache the lack of a DNSBL entry for as much as > 59 minutes and 50 seconds longer than a proper caching resolver, which

RE: RBLs in postscreen AND smtpd_*_restrictions

> > And, conversely, DNSBLs with > > weights < postscreen_dnsbl_threshold should not be listed in > > smtpd_*_restrictions because they could block an email on their own, > > even > > though they are not trusted to do so by postscreen. > > Not in all cases. Where postscreen by necessity offers

RE: RBLs in postscreen AND smtpd_*_restrictions

> postscreen will query the DNS when the client connects after > postscreen_dnsbl_ttl has expired. With Postfix 3.1 and later, > that time is (also) determined by a TTL in the DNS response. Thanks for the clarification Wietse. 2 questions: 1) Given that DNSBLs in postscreen_dnsbl_sites and

RE: RBLs in postscreen AND smtpd_*_restrictions

> On 02/06/16 17:45, Michael Fox wrote: > > If a DNSBL in postscreen_dnsbl_sites has a weight >= > > postscreen_dnsbl_threshold, then is there any advantage to also > > listing it in smtpd_*_restrictions? For example, is there some failure > > mode that having the DNS

RE: RBLs in postscreen AND smtpd_*_restrictions

> Michael Fox: > > Clarification: I seem to recall someone asking whether they should > leave > > RBLs in the smtpd_*_restrictions now that they've added them to > postscreen. > > And I seem to recall that the answer was something like "why not, it > doe

RBLs in postscreen AND smtpd_*_restrictions

I think I recall seeing something about this a while ago, but I can't find it in the archives. If I'm using several RBLs in postscreen_dnsbl_sites, each with its own weighting, then what is the best practice for using at least some of those RBLs in smtpd_*_restrictions, or not? Thanks,

RE: Need clarification of lookup table result values

> The access(5) manpage is for the Postfix SMTP DAEMON. It says so > on the first line of the manpage, and it says so again in the first > paragraph. > > The postscreen_access_list parameter, as the name suggests, is for > the POSTSCREEN DAEMON. This name is as explicit as it can be, without >

RE: Need clarification of lookup table result values

> What is a valid result depends on what the result is used for: an > access table expects results as described in the access(5) manpage, > a virtual aliases table expects the results as described in the > virtual(5) manpage, a transport table expects results as described > in the transport(5)

Need clarification of lookup table result values

I need some help understanding the valid "result" values that can be used in Postfix lookup tables and what the result values do. The examples I see in various places in the docs seem to contradict each other. As just one example, I'd like to configure postscreen_access.cidr. But I also need

RE: Header Filtering

/^Received:\s+from\s+domain\.example\s+/ ... I may be the least expert on this list so take what I say with a grain of salt. But this observation may be helpful: I have seen several cases where there was no space between the Header-name: and the header value. In particular, I have seen

RE: Bandwidth choke issue between remote offices and SMPT server.

I am facing problem of bandwidth choke issue between remote location and SMPT server. Please giude for below. Want to know how the other busy servers are handling such issues. Jayesh, this is what QoS/prioritization are for on your routers. The specifics will depend on what type of

RE: postscreen vs. fail2ban

Sebastian, Wietse, Noel: thanks for your responses re Postscreen vs. Fail2ban. Michael

postscreen vs. fail2ban

I haven't implemented postscreen yet, but plan to. So this question is for the postscreen experts here. As I understand it from the documentation, postscreen protects postfix from having to deal with most attack vectors, including higher volume attacks. So, does it make sense to also use

RE: Recipient address rejected: Domain not found

PM To: postfix-users@postfix.org Subject: Re: Recipient address rejected: Domain not found On Mon, Jan 19, 2015 at 12:12:34PM -0800, Michael Fox wrote: 450 4.1.2 u...@nohow.noway.org: Recipient address rejected: Domain not found Turn off the default safety net, I have

Recipient address rejected: Domain not found

I have a question about the situation where postfix receives a connection from a client trying to send to an invalid recipient address such as u...@nohow.noway.org. Currently, postfix responds with: 450 4.1.2 u...@nohow.noway.org: Recipient address rejected: Domain not found What seems

RE: header checks for a relay client

What you can do is create a restriction class to check the sender and the recipient, and reject the message if both match. The general procedure is outlined here, with some examples similar to what you're asking: http://www.postfix.org/RESTRICTION_CLASS_README.html I don't see how this

RE: header checks for a relay client

-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Michael Fox Sent: Wednesday, September 24, 2014 10:24 AM To: 'postfix users' Subject: RE: header checks for a relay client What you can do is create a restriction

RE: header checks for a relay client

Thanks much. That looks about right. Good Practice Note: anchor/narrow your expressions to make them as specific as possible to prevent unexpected behavior. This is especially important if you intend to discard mail: /@client[1-6]\.domain2\.com$/ /@yahoogroups\.com$/ -- Noel Jones

header checks for a relay client

Sanity check please: I have a relay machine: relay.domain1.com And a client: client.domain2.com I'd like to filter (silently discard) messages at the relay machine from going to any account on the client machine if the From: address is: groupsupda...@yahoogroups.com

RE: header checks for a relay client

What you can do is create a restriction class to check the sender and the recipient, and reject the message if both match. The general procedure is outlined here, with some examples similar to what you're asking: http://www.postfix.org/RESTRICTION_CLASS_README.html Alternately, you can

Restricting relay of attachments

Sorry if this is a bit simple, but I can't seem to figure out how the components fit together. Given the following: 1) MX/Relay machine running postfix: relay.domain1.com 2) Client machine: client.domain2.com I'd like to restrict/deny (5xx permanent error) incoming messages from the

RE: Restricting relay of attachments

. Michael -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Wietse Venema Sent: Wednesday, September 10, 2014 6:54 AM To: Postfix users Subject: Re: Restricting relay of attachments On 9/10/2014 1:24 AM, Michael Fox wrote

RE: Restricting relay of attachments

, Sep 10, 2014 at 09:55:16AM -0700, Michael Fox wrote: Hmmm. O.K. Thanks to both of you. It will take me some time to think this through. The level of indirection between main.cf and master.cf sure adds flexibility. But, as someone who doesn't work in postfix every day or even

Need help with canonical maps

I'm having difficulty getting the canonical_maps function to work as needed to repair some incorrect addresses from a legacy client. Here's the situation and what I've tried so far: Legacy client (oldhost.legacy.org) does not append its domain (legacy.org) to addresses in the envelope or the

RE: Need help with canonical maps

Thanks much, Wietse. A couple of follow-ups: As documented in ADDRESS_REWRITING_README, canonical mapping happens after append_dot_mydomain. O.K. I read that document but did not see that statement. I just went back and read it again and I still don't see that. Perhaps the order of

RE: Need help with canonical maps

Thanks again Wietse. Hmm. ADDRESS_REWRITING_README describes the address manipulations in the order as executed. Presenting these descriptions in a different order would be misleading. Yes. And it's very well written. But assuming or inferring information that is not in a technical document