[pfx] Re: Authentication question
michaelof--- via Postfix-users wrote: > > Thank you so much for answering, Wietse! > > Followed your recommendations, master.cf for submission and smtps now looks > as follows: > > > Opened smtps service in firewalld. > > Changed email user config for testing in Thunderbird from port 578 to 465, > and from "STARTTLS" to "SSL/TLS". Sending from Thunderbird works at once. > > Sending from NVR still fails, new msgs in log: > > 2024-02-22T17:49:57.074140+01:00 vserver postfix/smtps/smtpd[165894]: connect > from > 2024-02-22T17:49:57.177663+01:00 vserver postfix/smtps/smtpd[165894]: > warning: : SASL LOGIN authentication failed: > Invalid authentication mechanism > 2024-02-22T17:49:57.215718+01:00 vserver postfix/smtps/smtpd[165894]: > NOQUEUE: reject: RCPT from : 554 5.7.1 > < >: Client host rejected: Access denied; > from= to= proto=ESMTP helo= > 2024-02-22T17:49:57.225190+01:00 vserver postfix/smtps/smtpd[165894]: lost > connection after RCPT from > 2024-02-22T17:49:57.225497+01:00 vserver postfix/smtps/smtpd[165894]: > disconnect from ehlo=1 auth=0/1 mail=1 > rcpt=0/1 commands=2/4 > > Any idea what's wrong or missing? Can you set any other settings regarding authentication in your NVR besides user/password? Could enable verbose logging for the smtpd service on 465 or use notify_classes to get a transcript of the session. I am curious as to what authentication mechanism your NRV is trying. Cheers, Simon signature.asc Description: PGP signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Change unknown_address_reject_code on a smarthost to a 5xx reply?
Matus UHLAR - fantomas via Postfix-users wrote: > On 15.02.24 15:27, Simon Hoffmann via Postfix-users wrote: > > I have a dedicated postfix machine that I use as a smarthost for all my > > outgoing > > email from my internal servers. The smarthost even has only ports 465 and > > 587 > > enabled/opened. > > > > > > Recently we had the case that an internal used composer an email to an > > external > > recipient and had a typo in the domain. > > The internal server currently does no checks but forwards all email for > > external > > recipients to the smarthost. > > > > The smarthost then replied to the internal mailserver with > > > > Out: 450 4.1.2 : Recipient address rejected: > > Domain not found > > > > Since this was a 4xx tempfail reply, the internal mailserver tried to send > > the email > > over and over and only after 4 hours the internal mailserver send a "mail > > delivery > > delayed" email to the original sender. They then could compose the email > > again with > > the correct recipient address, but since they have no ssh root access to > > the server > > they could not remove the email with typo from the internal server's queue > > and thus > > they got even more "mail delivery delayed" notifications periodically until > > the > > message expired from the queue. > > > > There is two things that bother me: > > > > - it took 4h for the sender to get a notification that the domain was not > > found > > this should be configuable by tuning delay_warning_time yes, but this setting is "global" in the sense that I cannot restrict the warning time to be short only on "domain not found" or similar errors, and keep it longer on network timeouts or such. Neither Postfix nor my current internal server can make this distinction (and that is okay). Sometimes I take the smarthost offline because I perform maintenance on the underlying proxmox host. These are normally periods shorter than 30 mins thus I want the delay warning to be something bigger than 1h to not annoy the users, but I want the users to know immediately if they have a typo in their domain. > > > - after they "corrected" it by sending a second email with the correct > > address, they > > still got mail delivery delayed notification which leads to confusion if > > they miss > > the fact that the mail with the type was delayed, and instead think their > > new mail > > is delayed again because something is wrong > > Your user sent two mails, one to wrong address and got a deferral then a > timeout. > It's hard to solve this technically, if user can't look what address failed Sure. But even I needed to read the delay warning email my user showed me several times until i finally found the typo in the address. Having the internal server generate new warning mails after the new email has been sent (because the old mail is still in the queue because it was never officially rejected) only leads to confusion. Furthermore, since the subject says "mail delayed" the user might not even read the explanation in the body of the notification and realise that they have a typo in their recipient domain. So having the smarthost postfix permfail an email sent to a domain that does not exist means the internal user gets the notification immediately and the notification contains "failed" instead of "delayed" and the internal server does not try to send the mail over and over. > > > so tldr: can I change unknown_address_reject_code to a perm fail on a > > server thats only purpose is > > to send outgoing mails, without any unwanted effects resulting from this > > change? > > (that means the behaviour of postfix on this machine would exactly be the > > same with > > or without the change with the only difference that emails with typos would > > be > > rejected with a permfail) > > I have done this on my servers. I believe it's better when senders know > immediately that the address is not deliverable. exactly. But did you experience any unwanted side effects like the server permfailing email because of dns timeouts or something? > > > Note that you need to do this on your smarthost, not on the internal server. of course. That's where I intended it to do > Also, you can configure domain verification on that internal servers and I > recommend doing so. Currently no, as the internal server is not Postfix. Sorry, I forgot to mention that. > > > You can hypotetically override the code from your smarthost on your internal > mail server by using smtp_delivery_status_filter but you must be damn > careful about that. Same thing, internal server is not postfix. :) Besides, I am pretty sure I dont want to mess with that. :) Thanks! Cheers, Simon signature.asc Description: PGP signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Change unknown_address_reject_code on a smarthost to a 5xx reply?
Jaroslaw Rafa via Postfix-users wrote: > Dnia 15.02.2024 o godz. 15:27:48 Simon Hoffmann via Postfix-users pisze: > > > > - it took 4h for the sender to get a notification that the domain was not > > found > > - after they "corrected" it by sending a second email with the correct > > address, they > > still got mail delivery delayed notification which leads to confusion if > > they miss > > the fact that the mail with the type was delayed, and instead think their > > new mail > > is delayed again because something is wrong > > Can you configure the internal server to send the notification earlier than > after 4h and send it only once? yes, i can/could. I think I even decreased it to 1h now. But if I set this to a very short time and there is a hiccup in the network, the internal server sends lots of "mail delivery delayed". Thus I like to keep the threshold to something >1h so that notifications are only triggered if there is a serious network problem. > > I guess the internal server is not Postfix, because by default Postfix does > not send notifications about temporary failures (delay_warning_time is set > to 0 by default). That is an interesting way to come to this conclusion :) but the conclusion is in fact true: the internal server currently is not Postfix. Cheers, Simon signature.asc Description: PGP signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Change unknown_address_reject_code on a smarthost to a 5xx reply?
Hello all, I have a dedicated postfix machine that I use as a smarthost for all my outgoing email from my internal servers. The smarthost even has only ports 465 and 587 enabled/opened. Recently we had the case that an internal used composer an email to an external recipient and had a typo in the domain. The internal server currently does no checks but forwards all email for external recipients to the smarthost. The smarthost then replied to the internal mailserver with Out: 450 4.1.2 : Recipient address rejected: Domain not found Since this was a 4xx tempfail reply, the internal mailserver tried to send the email over and over and only after 4 hours the internal mailserver send a "mail delivery delayed" email to the original sender. They then could compose the email again with the correct recipient address, but since they have no ssh root access to the server they could not remove the email with typo from the internal server's queue and thus they got even more "mail delivery delayed" notifications periodically until the message expired from the queue. There is two things that bother me: - it took 4h for the sender to get a notification that the domain was not found - after they "corrected" it by sending a second email with the correct address, they still got mail delivery delayed notification which leads to confusion if they miss the fact that the mail with the type was delayed, and instead think their new mail is delayed again because something is wrong Is the "unknown_address_reject_code" only used when dns returns nxdomain and can thus be changed to a permanent fail on this server in particular or would problems like timeout for DNS requests also lead to unknown_address_reject and therefor lead to legitimate emails being rejected due to network problems? From my understanding, the latter would be a case of unknown_address_tempfail_action and thus a defer_if_permit since I have not changed this setting. so tldr: can I change unknown_address_reject_code to a perm fail on a server thats only purpose is to send outgoing mails, without any unwanted effects resulting from this change? (that means the behaviour of postfix on this machine would exactly be the same with or without the change with the only difference that emails with typos would be rejected with a permfail) Thanks! Cheers, Simon signature.asc Description: PGP signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: problem to add, alias failed
Maurizio Caloro via Postfix-users wrote: > if adding a new user with postfixadmin 3.3.8 or with cli this will run > without problem. > > > > GRANT ALL PRIVILEGES ON mailserver.* TO markus@'domain.com > <mailto:markus@'domain.com> ' IDENTIFIED BY > '***'; you now have created a database (admin) user that has all privileges on your database with the username of markus. With the @domain part you have allowed that user to remotely connect to you database if the connection comes from a host with a hostname of domain.com (unless mariadb only listens on localhost for DB connections). Please use REVOKE to delete this user. To add a new entry to the accounts or alias table, use INSERT INTO mailserver.alias VALUES ... according to the DB layout. Since you are using postfixadmin, why are you not using the Web UI to add a new mailbox? > > > but if adding with postfixadmin any alias, this will bounce, with following > error > postfix/lmtp[102470]: 3E101208A1: to= <mailto:mar...@domain.com> > mar...@domain.com, relay=mail.domain.com[private/dovecot-lmtp], markus is not a mail user, as explained above. However, you just said that adding *any* alias you cannot receive email. Have you added the other aliases with the same way as above or have you actually used the postfixadmin web ui to add those aliases. If you have used the web ui, how does you main.cf look like? Simply adding > virtual_transport = lmtp:unix:private/dovecot-lmtp to the main.cf tells postfix to deliver mail to dovecot, but it neither tells postfix nor dovecot to connect to the database to look up if a user exists or not. Since you are talking about aliases, you need to tell postfix a way to query the database to get the target email addresses to actually send the email to, and dovecot needs to know if a target user exists in order to accept email. If you send the (relevant) contents of main.cf to the list someone might be able to point out a configuration error. For the correct config of dovecot please see the dovecot documentation or ask for help on a dovecot mailing list. Cheers, Simon ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> syntax/behaviuor of virtual_alias_maps
Viktor Dukhovni via Postfix-users wrote: > On Sun, Jan 21, 2024 at 07:21:26PM +0100, Simon Hoffmann via Postfix-users > wrote: > > > The old virtual_domains file just lists all domains (one per line), and can > > directly be used in > > virtual_alias_domains. > > You're going about this the wrong way, by tryign to translate low-level > artefacts from one system to somewhat related, but different low-level > artefacts in Postfix. Instead you need to implement a functional at a > higher layer. > > Postfix support virtual alias rewriting (for all envelope recipient > addresses), and virtual alias domains (which make rewriting mandatory, > since there are no actual mailbox recipients in the domain, just aliases > to mailboxes in *other* domains). > > You need to read and understand: > > - ADDRESS_CLASS_README > - ADDRESS_REWRITING_README > - The virtual(5) manpage > - The postconf(5) descriptions of: > * virtual_alias_domains > * virtual_alias_maps > > DO NOT use the deprecated "virtual_domains" parameter, it mixes > classification of domains with address mappings. I have read that and I thought I understood it. I have also read http://www.postfix.org/VIRTUAL_README.html and this states that with virtual alias mode i can have the same local part in an email address and deliver them to different unix users, but i can still use local unix users. The first method on that page does not allow me to route localp...@domain1.com to a different user than localp...@domain2.org (with the exact same localpart) and the third mode on that page does not use unix users and their home directory to store mails but just a directory structure, which is also not what i want. > > > However, in my virtual aliases table on OpenSMTPd, I have the following > > line-types > > It is best to not use the same terminology for two different things. > Instead let go of the old terminology and focus on function. The file that maps an email address to a unix user or another email address in OpenSMTPd is literally stated in the config with the keyword "virtual". > > > si...@simonhoffmann.net simon > > > > The first line is obvious. Mail addressed to the email address is delivered > > to the > > UNIX user. > > This is an address mapping, best practice is to also specify a domain on > the RHS, which by default gets qualified with "@$myorigin", but if you > have a specific domain in mind, specify it here. > > Actually to simon@$myorigin, which may or may not go to the UNIX user, > depending on how that's handled. With the information from http://www.postfix.org/VIRTUAL_README.html I understand that this line means that this email address is delivered to the unix user on the RHS. Why would I need to specify a domain on the RHS if i want the unix user simon to get the mail? Or is specifying @$myhostname the actual (and only?) way to tell postfix to deliver to the local user? With that in mind, i am using sieve rules in dovecot and require the mails to be delivered to dovecot via lmtp. Upon reading the docs again just now it seems that i have to use virtual domains mode and virtual_mailbox_domains and virtual_mailbox_maps to be able to use virtual_transport, which in my understanding is the only way to hand mail off to dovecot. I think i just broke my brain and need to pause for a few weeks before trying to understand the config again ^^ The site also states to add the domain to the virtal_alias_domains, by the way. Is the documentation wrong? > > > @list.simonhoffmann.net simon > > > > The second line is also obvious, as this is a catchall for a domain. In > > Postfix this > > has also the lowest priority so I don't break my current alias file. > > Catchalls are best avoided. If you have a specific list of valid > addresses, best to specify each one. Well for one i am lazy and dont want to edit my map all the time. :) Secondly, aside from getting more spam (which i can live with), why is it best to avoid a catchall? > > > simon simon > > > For the third line, the documenation under > > http://www.postfix.org/virtual.5.html > > specifies > > You're looking at the wrong documentation, that line from OpenSMTPD, What would be the right documentation? Above you asked me to read virtual(5)... > what is supposed to achieve? Then figure out whether it is needed, > and how to get equivalent *functionality* (not syntax) from Postfix. > > > So I am not sure if this would work and the third line would be an accepted > > line or > > if I need to replace this line with a user@domain line for every virtual > > d
[pfx] Preparation of switch from OpenSMTPd to Postfix -> syntax/behaviuor of virtual_alias_maps
Hey all, I found a second topic where I am not sure how postfix behaves. The old virtual_domains file just lists all domains (one per line), and can directly be used in virtual_alias_domains. However, in my virtual aliases table on OpenSMTPd, I have the following line-types si...@simonhoffmann.net simon @list.simonhoffmann.net simon simon simon nore...@simonhoffmann.net /dev/null s...@simonhoffmann.net error:550 no spam here! The first line is obvious. Mail addressed to the email address is delivered to the UNIX user. The second line is also obvious, as this is a catchall for a domain. In Postfix this has also the lowest priority so I don't break my current alias file. With the following lines however, I am not sure if this is possible with postfix. For the third line, the documenation under http://www.postfix.org/virtual.5.html specifies user address, address, ... Redirect mail for user@site to address when site is equal to $myorigin, when site is listed in $mydestination, or when it is listed in $inet_interfaces or $proxy_interfaces. The virtual domain however is not part of either myorigin or mydestination, and is abviously not an IP address so inet/proxy_interfaces does not apply either. So I am not sure if this would work and the third line would be an accepted line or if I need to replace this line with a user@domain line for every virtual domain. The fourth line in the old alias file silently discard a mail. OpenSMTPd allows the right hand site to be either a unix user, a different email address or simply a path to a file to which it will append the new email. Thus /dev/null on the right hand site would mark the email as successfully received to the sending server, but then discards the mail internally. Is this possible with postfix as well? Lastly, the fifth line bounces the email with the given error code and the given message. I have used this to disable specific address on an otherwise catch all domain. The spam example above is only an example, I have used this for address that were previously used but are not any longer and I would like the sender to know that this address is no longer in use. Is something like this possible as well? And then I have read the following in the documentation: /etc/postfix/virtual: virtual-alias.domainanything (right-hand content does not matter) The virtual-alias.domain anything entry is required for a virtual alias domain. Without this entry, mail is rejected with "relay access denied", or bounces with "mail loops back to myself". Do I understand it correctly that this is only necessary if I do not use virtual_alias_domains? If I use this separate file to specify only the domain names, this line is not needed in the alias mapping file, right? Thanks for your help! Cheers, Simon signature.asc Description: PGP signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> behaviour of smtpd_sender_login_maps pattern matching
Viktor Dukhovni wrote: > > > - You may want to "preserve the envelope", by generating a > > > recipient-specific bcc address. Just "always_bcc" fails > > > to record "bcc" recipients, and may record header recipients > > > who weren't actually (envelope) recipients of the message. > > > > could you please elaborate on that (off-list is okay with me), because I > > don't seem > > to understand your point here. > > This copies only the message headers and body, but fails to capture the > message envelope, which contains the true recipient list. With > per-recipient addressing in "recipient_bcc_maps", and provided the > archive system captures the message envelope, you don't lose that (IMHO > essential) information. > > MAIL FROM: > RCPT TO: > RCPT TO: > DATA > From: > To: > Subject: Let's commit fraud > > ... > . > > With "always_bcc" one might assume that the message went to > "fake-recipient", where in real-life it was sent to "bcc1" and "bcc2". > With per-recipient bcc addresses that are captured by the archive, > this is not the case. MailStore only states the "always_bcc" approach in their manual https://help.mailstore.com/en/server/index.php?title=Archiving_Emails_from_Linux-based_Email_Servers#Archiving_Incoming_and_Outgoing_Emails_Directly AFAIK, Mailstore only support this "basic mode" where it uses the header information when importing from generic servers or the specific Exchange/Office365 Journaling format. Additionally, I have only a single destination email address available to import into the archive, as each email address specifies which (customer) archive this mail should be imported as this is a multi tenant software. With your approach, I would need a catchall at the archive software if I understand correctly. We could however try to implement the Exchange Journal format. This creates a new email, adds the envelope from and to address to the body, and then attaches the actual email as an eml attachment. So I could either write a script as a milter or use a service in master.cf that calls a script and passes the envelope and mail data to the script and the script then builds a new email in Exchange Journal format and transfers it directly to the archive gateway server without going through postfix again. If you're bored feel free to send in suggestions for the script :) ^^ Otherwise I'll use always_bcc for now and try to figure out the script in a few weeks when I have more time. Thanks! Cheers, Simon signature.asc Description: PGP signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Preparation of switch from OpenSMTPd to Postfix -> behaviour of smtpd_sender_login_maps pattern matching
ir MUA of choice or by the ticket system and
additional
internal software. There will never be another server connecting to this server
on
ports 465/587 and the logins maps will only be applied to these ports.
>
> > Another alternative I thought of would be to create three separate
> > pcre file and use a unionmap.
>
> Replacing "pcre" with better/safer equivalents as much as possible, yes.
thinking about it, even the ticket system could be a hash table, I just have to
think
about adding a new entry to that table should there be a new email address we
like
integrate into the ticket system.
>
> > In the first file I would list all named/personal users with their email
> > addresses and their login names,
>
> Using instead simple "hash" or "cdb" tables and "static" as appropriate:
>
> main.cf:
> sender_login_maps =
> unionmap: {
> ${indexed}sender-login,
> ${indexed}ticket-sender,
> static:internal-software-user
> }
>
> sender-login:
> us...@example.com user1
> us...@example.com user2
> ...
>
> ticket-sender:
> tick...@example.com ticket-system
> tick...@example.com ticket-system
> ...
>
> without any PCRE tables at all. Note that if the ticket system users
> don't have a separate individual login, they could be folded into the
> first table.
Sometimes I send notifications to customers directly without using the ticket
system
because they are just notifications and a ticket is only needed if the customer
has
questions and replies to my notification email. But I could achieve that by
stating
supp...@example.com ticket-system, myuser
in the hash map, right?
> And that a "Makefile", could generate a combined source
> file from the list of user to login pairs to make a single source file
> that avoids the need for a unionmap. Just append
>
> ,internal-software-user
>
> to each RHS value. You can create fancy run-time logic with pipemap and
> unionmap, but best to keep it simple.
Yeah, it would probably best to just use a single hash map, but for that I need
to
clean up the server and all connecting clients a bit to have strict rules and
have
dedicated auth-users for each script and not the mess I have currently. With
that,
the sender login map would even serve as a really good documentation which
internal
system has which task and therefore needs to send as which email address.
I'll add that to my endless todo list :)
>
> --
> Viktor.
Thanks for your input Viktor!
Cheers,
Simon
signature.asc
Description: PGP signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Preperation of switch from OpenSMTPd to Postfix -> behaviour of smtpd_sender_login_maps pattern matching
Hey yall, I am currently planning to switch from OpenSMTPd to postfix for two reasons - smtpd_sender_login_maps functionality not really implemented in OpenSMTPd - always_bcc not possible on OpenSMTPd While reading up on the postfix manual for smtpd_sender_login_maps I've read that postfix stops at the first match, so if you specify two files you should use a unionmap or those files may not have any pattern in common. Do I understand correctly that this behaviour also is reflected when searching within a single file? I have users on the server that should only be allowed to send with their own address, but then there is a ticket system that should impersonate a few addresses (like sales@, support@, ...). Furthermore I have a user to send email from internal software that should be able to impersonate all user accounts. So if I understand correctly, a simple pcre with the following content would not be working for me? /user@domain.com/ user@domain.com /user@domain.com/ user@domain.com /user.th...@domain.com/ user.th...@domain.com /sa...@domain.com/ zammad-user /supp...@domain.com/ zammad-user /.*/ internal-software-user EOF if the internal software would try to send as user.two postfix would start applying each pattern from top to bottom in the file, and stop once a pattern matches, correct? This would mean that only line two of the example file would be considered, which does not contain the internal software user, which means the email would be rejected with "user does not own address" error, right? what is the best practise here? surely I could add the internal software user behind each named/personal user, but I fear that this is prone to errors as there are a lot of different addresses and forwardings on the server, which means I could forget to append the internal software user to some addresses. Another alternative I thought of would be to create three seperate pcre file and use a unionmap. In the first file I would list all named/personal users with their email addresses and their login names, in the second file i would list all email addresses used by the ticket system (or a regular expression that matches all) and match it to the zammad user, and in the third file I would list the internal software user with the /.*/ pattern so that it always matches. In my understanding, this would "dynamically" combine to a mapping that allows the special users to be able to send mails in the scope defined but still allow each personal/named user to still send with their email adress without needing to to keep one very complex mapping file up to date with each combination. Would this way work as expected? With this solution I could expand my "create new user" script to automatically append the user and his email address to the first pcre file, thus never having to mess with the smtpd_sender_login_maps again unless I add a new special user. Thanks for any comments on that matter! Cheers, Simon signature.asc Description: PGP signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Queue postfix sending when on failover WAN
This is I suspect a little off-topic for here, in which case accept my apologies please. My Postfix instance is well-established on a LAN behind a WAN IP with a decent reputation. The internet router for the network has a 4G failover device for occasional downtime to ensure that critical comms can still be routed to the internet, e.g. security system notifications (not over email). When the router fails over, postfix's default route to the internet still goes through the same gateway IP and the internet is accessible - but now postfix sees the world through the router getting to the internet via a non-static IP, not reversible DNS, etc.; I'd like it to not send anything but queue until the standard route returns. Is there a postfix way to do this? Or should I be looking at lower-level network routing configuration for the server running postfix? Thanks for any ideas. -- Simon Wilson M: 0400 12 11 16
Re: ot: SPF/DKIM woes
- Message from Viktor Dukhovni - Date: Sat, 17 Sep 2022 23:26:34 -0400 From: Viktor Dukhovni Reply-To: postfix-users@postfix.org Subject: Re: ot: SPF/DKIM woes To: postfix-users@postfix.org On Sat, Sep 17, 2022 at 10:39:46AM -0400, Viktor Dukhovni wrote: If this domain was in fact served by netregistry.net, that could well have been the problem. There is an ongoing over 24hour DNS outage at netregistry.net (where, e.g., they seem to be dropping all DNS queries from most Google DNS resolvers). https://status.webcentral.au/ So any domains (mostly Australian) served by netregistry.net (directly, or indirectly, when e.g. the A records of nameservers for a domain are in turn served by netregistry, ...) fail to resolve from Google's perspective. DNS service at netregistry.net is gradually returning to normal. The majority of locations (though not yet all) where queries were previously failing now appear to be working. - End message from Viktor Dukhovni - I used Netregistry for many years for Australia-based domains, and had repeated DNS issues over several of those years - ranging from complete outage to individual record issues. I reached the point after trying to interact with their "technical" support one too many times that I did the equivalent of a table-flip and transitioned about 20 x domains to another provider in one go... life is too short for bad coffee, cheap wine and/or Netregistry tech support. YMMV. Simon. -- Simon Wilson M: 0400 12 11 16
Re: Postfix.org website
From: Ralph Seichter Sent: Friday, 9 September 2022 10:55 pm To: postfix-users@postfix.org Subject: Re: Postfix.org website * Simon Wilson: > Noting that whilst some may consider that block excessive, it does > appear that some 'authorities', including at least the Australian > government's cyber security department, Fortinet, and others, > recommend these IPs are blocked. Which just goes to show how little these so-called "authorities" understand. Tor middle nodes by design only ever connect to other Tor nodes, and no "security" whatsoever is gained from blocking their host IP addresses. Authorities simply hate that they cannot read Tor traffic. See FUD (https://de.wikipedia.org/wiki/Fear,_Uncertainty_and_Doubt). -Ralph You could well be completely right Ralph. I have no insight into why security firms, government departments, etc. recommend to block what they do. I shared what I found for awareness in case others come across a similar IPS issue in accessing the Postfix website. Whether the underlying block is FUD etc is probably offtopic for this list, so I'm going to stop here. Simon
Re: Postfix.org website
- Message from Simon Wilson - Date: Fri, 09 Sep 2022 17:26:09 +1000 From: Simon Wilson Reply-To: si...@simonandkate.net Subject: Postfix.org website To: Postfix users Yet I cannot open www.postfix.org (either over http://www.postfix.org or https://www.postfix.org) - both just timeout. - End message from Simon Wilson - Cause found, replying here for posterity. The postfix website is hosted on an IP which is also a Tor network node. My Unifi router (UDM Pro) has IDS/IPS enabled, and the standard signature set and categories block Tor nodes. Exception added, website now accessible. Noting that whilst some may consider that block excessive, it does appear that some 'authorities', including at least the Australian government's cyber security department, Fortinet, and others, recommend these IPs are blocked. E.g. "The Australian Cyber Security Centre (ACSC) recommends organisations block traffic from Tor exit nodes to their internet-exposed services provided this will not meaningfully impact accessibility for significant numbers of legitimate users" https://www.cyber.gov.au/acsc/view-all-content/publications/defending-against-malicious-use-tor-network I don't know enough about the real or imagined threat presented... but I'm thinking i'm not going to be the only one with these nodes blocked. Others with IPS on standard block lists may wish to check theirs. Simon -- Simon Wilson M: 0400 12 11 16
Postfix.org website
At this stage of my life I consider myself not a complete moron when it comes to technology. Given that I can (and do) run our own mail server, I figure I should be able to open a website... :-/ Yet I cannot get to www.postfix.org *from most* locations. From my home location, I can resolve it, whether over my own DNS or via 1.1.1.1 (so it's not that I'm getting a wrong resolution): PS C:\Users\simon> nslookup.exe www.postfix.org Server: emp81-dns.simonandkate.lan Address: 192.168.1.145 Non-authoritative answer: Name:postfix-mirror.horus-it.com Addresses: 2a01:4f9:6a:528d::a 65.108.3.114 Aliases: www.postfix.org PS C:\Users\simon> nslookup.exe www.postfix.org 1.1.1.1 Server: one.one.one.one Address: 1.1.1.1 Non-authoritative answer: Name:postfix-mirror.horus-it.com Addresses: 2a01:4f9:6a:528d::a 65.108.3.114 Aliases: www.postfix.org I can ping 65.108.3.114: PS C:\Users\simon> ping www.postfix.org Pinging postfix-mirror.horus-it.com [65.108.3.114] with 32 bytes of data: Reply from 65.108.3.114: bytes=32 time=323ms TTL=48 Reply from 65.108.3.114: bytes=32 time=321ms TTL=48 Yet I cannot open www.postfix.org (either over http://www.postfix.org or https://www.postfix.org) - both just timeout. Same on my work VPN (which goes via Singapore) - resolve, ping ok... but timeout, on http and https. But it works (http and https) from my mobile phone (Telstra network, Australia). Is there some funky local redirection happening? I know there was chat on the mailing list about http/https on www.postfix.org earlier in the year, but this seems odd. Simon. -- Simon Wilson M: 0400 12 11 16
Re: AW: MTA-STS implementation
- Message from Joachim Lindenberg - Date: Fri, 26 Aug 2022 17:00:32 +0200 From: Joachim Lindenberg Subject: AW: MTA-STS implementation To: postfix-users@postfix.org I definitely suggest to look into RFC 7672 SMTP-DANE instead of MTA-STS. SMTP-DANE is more secure than MTA-STS, and in my "samples" also more widely adopted than MTA-STS. In my view, MTA-STS is only interesting if you do not want to adopt DNSSEC. Postfix supports DANE out of the box, but you have to use a DNSSEC aware resolver and configure appropriately. Best Regards, Joachim -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org Im Auftrag von post...@ptld.com Gesendet: Freitag, 26. August 2022 16:24 An: postfix-users@postfix.org Betreff: Re: MTA-STS implementation On 08-26-2022 10:08 am, Paul Kingsnorth wrote: MTA-STS seems to be getting more widespread. I wondered how many people are using the postfix-mta-sts-resolver from Snawoot, and whether there are any standout good/bad features of it? Or whether there are any other ways of implementing MTA-STS with postfix? Wouldn't setting smtpd_tls_security_level=encrypt have the same desired effect of what MTA-STS is trying to solve? Granted you would be preventing other MTA's from delivering if they aren't using STARTTLS. Or is there more going on with MTA-STS then what I understand? - End message from Joachim Lindenberg - Wouldn't setting smtpd_tls_security_level=encrypt have the same desired effect of what MTA-STS is trying to solve? Quick comment on the above point: Setting up MTA-STS in DNS to allow for MTA-STS validation on your domain does not result in you not being able to receive non-encrypted inbound email, so it is not the same as setting smtpd_tls_security_level=encrypt (which according to postfix documentation is not recommended on publicly facing SMTP servers). MTA-STS has been getting traction... Google appear to be going all-in, although noting from my reading on the subject that as above DANE appears to be superior, e.g. [1] from Viktor. I'm in the process of adding the DNS settings and required 'bits' to allow *inbound* MTA-STS validation on my primary email domain to make it available to e.g. Google; currently it's in 'testing' mode. However based on my reading I'm not changing Postfix to alter my outbound mail process, which is based around: smtp_tls_security_level = dane smtp_dns_support_level= dnssec It appears, again from my reading and I am sure others with better knowledge will add more, that currently setting postfix to use 'outbound' MTA-STS validation means emails being sent to domains that have validation of both DANE and MTA-STS (like mine) may end up with the sending server using MTA-STS and overriding a failing DANE validation, which is not what the RFC [2] requires: "senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation". See discussion at [3]. So for now, for my very low volume personal domain/server, I'm working to offer TLS validation inbound for DANE and MTA-STS but am not changing Postfix config from DANE/DNSSEC, thus retaining DANE only for outbound. If that is not a recommended approach I'd be very welcoming of other suggestions BTW... Simon [1] https://www.isi.edu/~hardaker/news/2021-09-20-DANE-vs-STS.html [2] https://datatracker.ietf.org/doc/html/rfc8461#section-2 [3] https://serverfault.com/questions/1101533/is-it-possible-to-use-mta-sts-in-postfix-without-overriding-dane -- Simon Wilson M: 0400 12 11 16
Re: Postfix + rspamd will not rewrite sender
> On 8 Apr 2022, at 9:43 pm, Wietse Venema wrote: > > Matus UHLAR - fantomas: >>>> On 07.04.22 09:16, Horst Simon wrote: >>>>> I used to have working correctly postfix + amavisd-new + dovecot working >>>>> correctly with re-writing the sender address when forwarding email to my >>>>> ISP using sender_canonical, I am using postfix 3.7.0. >>>>> After changing from amavisd-new to rspamd it will not rewrite the sender >>>>> address and forwarding to my ISP fails. >> >>> On 8 Apr 2022, at 12:50 am, Matus UHLAR - fantomas >>> wrote: >>>> did amavis change the sender when used as milter? >>>> i'm not sure milter supports changing sender? >> >> On 08.04.22 09:10, Horst Simon wrote: >>> Haven't used milter for amavisd-new only content_filter in main.cf and >>> following in master.cf >> >> that's it - amavis was not used as milter and milter can't change mail >> sender. >> search in rspamd docs how should be changing of sender implemented. > > It's a Milter feature (SMFIR_CHGFROM) implemented in Sendmail >= 8.14 > and in Postfix >= 2.5. > > Wietse Thanks all for the replies, need now to find how to’s and config examples on configuring filter Regards, Horst
Re: Postfix + rspamd will not rewrite sender
> On 8 Apr 2022, at 1:48 am, Benny Pedersen wrote: > > On 2022-04-07 16:50, Matus UHLAR - fantomas wrote: >> On 07.04.22 09:16, Horst Simon wrote: > >>> In the main.cf I removed >>> content_filter = amavis:[127.0.0.1]:10024 >> this is not milter interface... > > an its removed :) > > more info is needed to help imho I am using sender_canonical to change address name@localdomain to name@ispdomain. It works perfect with amavisd-new, but when using rspamd it does not modify the sender address. I assume when using milter the sender_canonical_map is not used.
Re: Postfix + rspamd will not rewrite sender
> On 8 Apr 2022, at 12:50 am, Matus UHLAR - fantomas wrote:
>
> On 07.04.22 09:16, Horst Simon wrote:
>> I used to have working correctly postfix + amavisd-new + dovecot working
>> correctly with re-writing the sender address when forwarding email to my ISP
>> using sender_canonical, I am using postfix 3.7.0.
>> After changing from amavisd-new to rspamd it will not rewrite the sender
>> address and forwarding to my ISP fails.
>
> did amavis change the sender when used as milter?
> i'm not sure milter supports changing sender…
Haven't used milter for amavisd-new only content_filter in main.cf and
following in master.cf
amavis unix - - - -2 lmtp
-o max_use=20
-o lmtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o lmtp_data_done_timeout=1200
>> In the main.cf I removed
>> content_filter = amavis:[127.0.0.1]:10024
>
> this is not milter interface...
>
>> and added
>> smtpd_milters = unix:/opt/local/var/run/rspamd/milter.sock
>> non_smtpd_milters = $smtpd_milters
>> milter_protocol = 6
>> milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
>> milter_rcpt_macros = i {rcpt_addr}
>> milter_default_action = accept
>>
>> Everything is working with rspamd except for the sender rewrite. Is there
>> anything else I need to change in the postfix configuration to get this
>> working again?
>
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
> "So does syphillis. Good thing we have penicillin." - Matthew Alton
Postfix + rspamd will not rewrite sender
Hi,
I used to have working correctly postfix + amavisd-new + dovecot working
correctly with re-writing the sender address when forwarding email to my ISP
using sender_canonical, I am using postfix 3.7.0.
After changing from amavisd-new to rspamd it will not rewrite the sender
address and forwarding to my ISP fails.
In the main.cf I removed
content_filter = amavis:[127.0.0.1]:10024
and added
smtpd_milters = unix:/opt/local/var/run/rspamd/milter.sock
non_smtpd_milters = $smtpd_milters
milter_protocol = 6
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_rcpt_macros = i {rcpt_addr}
milter_default_action = accept
Everything is working with rspamd except for the sender rewrite. Is there
anything else I need to change in the postfix configuration to get this working
again?
Thanks and Regards,
Horst Simon
Re: Removing an old post
- Message from Viktor Dukhovni - Date: Tue, 15 Feb 2022 11:26:18 -0500 From: Viktor Dukhovni Reply-To: postfix-users@postfix.org Subject: Re: Removing an old post To: postfix-users@postfix.org On 15 Feb 2022, at 11:07 am, Jaroslaw Rafa wrote: It could help a bit if OP would know where exactly his security team found the posting in question. Then he should write to administrator of that particular site asking for removal. But even if it will be removed there, it is only one - as you noted - of multiple places where this post exists. But maybe his security team will be happy with removing it from that particular place where they found it... I would expect an archive operator to rightly refuse to remove archived posts. If I were an archive operator, I might suggest to the OP that a simpler solution might be to disband a security team that is blissfully ignorant of the ways of the Internet. It doesn't say anything positive about their security team does it, that their carefully corporate-risk-policy-assessed response to exposure of internal hostnames 8 years ago (wtf were they doing that someone thought this was a useful exercise lol) is to ask that it get deleted off the interwebs. Never mind horse bolted gate shutting... the gate hinges have rusted and the gate has fallen over on this one. It would be funny if it were not quite so disturbing. -- Simon Wilson M: 0400 12 11 16
Re: Logging silence
- Message from John Stoffel - Date: Sun, 28 Nov 2021 22:58:01 -0500 From: John Stoffel Subject: Re: Logging silence To: si...@simonandkate.net Cc: John Stoffel , postfix-users@postfix.org "Simon" == Simon Wilson writes: Simon> - Message from John Stoffel ----- Simon> Date: Sun, 28 Nov 2021 21:37:12 -0500 Simon> From: John Stoffel Simon> Subject: Re: Logging silence Simon> To: si...@simonandkate.net Simon> Cc: postfix-users@postfix.org Simon> "Simon" == Simon Wilson writes: Simon> I feel like I'm missing something really obvious here... :( Simon> Multiple RedHat8 servers, Postfix configured on all of them for Simon> internal network mail server (primarily server log updates, Simon> etc. to admin). Simon> Have you restarted syslog (or syslog-ng, or rsyslog, etc) on the Simon> problematic server? Simon> Yes, the server has been rebooted *many* times, and I have also Simon> tried restarting rsyslog. selinux running on there? Is it impossible to just clone one of the good systems and replace this problematic one? Compare the installed packages between the systems, along with the 'systemctl' output to look for differences. More details would help us help you. John I worked it out. journald.conf was set to MaxLevelStore=notice, so it wasn't just postfix not logging, just that was the symptom picked up. I really was missing something obvious. Now I need to work back to see how / who changed that. Thank you for support. Simon ___ Simon Wilson
Re: Logging silence
- Message from John Stoffel - Date: Sun, 28 Nov 2021 21:37:12 -0500 From: John Stoffel Subject: Re: Logging silence To: si...@simonandkate.net Cc: postfix-users@postfix.org "Simon" == Simon Wilson writes: Simon> I feel like I'm missing something really obvious here... :( Simon> Multiple RedHat8 servers, Postfix configured on all of them for Simon> internal network mail server (primarily server log updates, Simon> etc. to admin). Have you restarted syslog (or syslog-ng, or rsyslog, etc) on the problematic server? Yes, the server has been rebooted *many* times, and I have also tried restarting rsyslog. Simon - End message from John Stoffel ----- ___ Simon Wilson M: 0400 12 11 16
Logging silence
I feel like I'm missing something really obvious here... :( Multiple RedHat8 servers, Postfix configured on all of them for internal network mail server (primarily server log updates, etc. to admin). On all of them bar one, I get relevant logging in /var/log/maillog. On the one - maillog remains empty, even though mail is being sent OK. I've diff-compared main.cf, master.cf and rsyslog.conf on one that logs to maillog and the one that doesn't. Main.cf has a different hostname specified, master.cf is identical. Both rsyslogd.conf have the following setup for mail: *.info;mail.none;authpriv.none;cron.none/var/log/messages mail.* -/var/log/maillog Yet nothing gets logged to /var/log/maillog on ONE of them. Mail is getting sent and received from the server. Logging is working for other services. journalctl -u postfix shows (at the end): Jan 09 03:43:06 emp80.simonandkate.lan postfix/pickup[3162096]: 35E30201E928: uid=0 from= Jan 09 03:43:06 emp80.simonandkate.lan postfix/cleanup[3169954]: 35E30201E928: message-id=<20210108174306.35e30201e...@emp80.simonandkate.lan> Jan 09 03:43:06 emp80.simonandkate.lan postfix/qmgr[1989]: 35E30201E928: from=, size=102096, nrcpt=1 (queue active) Jan 09 03:43:06 emp80.simonandkate.lan postfix/smtp[3169963]: 35E30201E928: to=, relay=192.168.1.235[192.168.1.235]:25, delay> Jan 09 03:43:06 emp80.simonandkate.lan postfix/qmgr[1989]: 35E30201E928: removed -- Reboot -- Jan 18 02:05:45 emp80.simonandkate.lan postfix/qmgr[1958]: warning: backward time jump detected -- slewing clock Jan 18 02:11:25 emp80.simonandkate.lan postfix/qmgr[1958]: warning: backward time jump recovered -- back to normality -- Reboot -- Jan 25 03:04:36 emp80.simonandkate.lan postfix/qmgr[1968]: warning: backward time jump detected -- slewing clock Jan 25 03:08:02 emp80.simonandkate.lan postfix/qmgr[1968]: warning: backward time jump recovered -- back to normality -- Reboot -- Mar 07 05:35:51 emp80.simonandkate.lan postfix/qmgr[1965]: warning: backward time jump detected -- slewing clock Mar 07 05:39:01 emp80.simonandkate.lan postfix/qmgr[1965]: warning: backward time jump recovered -- back to normality -- Reboot -- Apr 11 05:04:12 emp80.simonandkate.lan postfix/qmgr[2009]: warning: backward time jump detected -- slewing clock Apr 11 05:11:53 emp80.simonandkate.lan postfix/qmgr[2009]: warning: backward time jump recovered -- back to normality -- Reboot -- Jun 07 22:40:56 emp80.simonandkate.lan postfix/qmgr[1975]: warning: backward time jump detected -- slewing clock Jun 07 22:49:31 emp80.simonandkate.lan postfix/qmgr[1975]: warning: backward time jump recovered -- back to normality -- Reboot -- Nov 04 17:58:53 emp80.simonandkate.lan postfix/qmgr[2047]: warning: backward time jump detected -- slewing clock Nov 04 18:00:01 emp80.simonandkate.lan postfix/qmgr[2047]: warning: backward time jump recovered -- back to normality ...where as can be seen it was logging OK in January, then it stopped. Permissions on the log file: -rw--- 1 root root0 Nov 28 03:27 maillog What am I missing?? -- Simon Wilson
Re: Using a different DNS to ask zen.spamhaus.org for DNSBL info?
- Message from Wietse Venema - Date: Thu, 21 Oct 2021 08:35:20 -0400 (EDT) From: Wietse Venema Reply-To: Postfix users Subject: Re: Using a different DNS to ask zen.spamhaus.org for DNSBL info? To: Postfix users Gerben Wierda: My standard DNS forwards to cloud9 (9.9.9.9) because cloud9 blocks bad actors. But that means that DNSBL from spamhaus doesn?t work as the query to comes from a public DNS server. I am using: # Drop any SMTP client that talks before its turn (spam botnets in a hurry) postscreen_greet_action = drop # Drop any SMTP client that is in the DNSBL postscreen_dnsbl_sites = zen.spamhaus.org*2 postscreen_dnsbl_action = drop I have a secondary resolver that doesn?t forward to cloud9. Can I use that local DNS instead of the standard one in postfix, preferably for postscreen DNSBL only? Postfix does not choose its DNS resolvers. Instead, Postfix uses the libresolv system library. Historically, that library has no API to specify resolver IP address(es), and it is unlikely that Postfix will implement its own libresolv functionality. On the wishlist is to have a Postfix resolver *plugin* API, like Postfix has the XSASL API for different SASL backends (Cyrus, Dovecot). Then, Postfix could call into alternative resolver libraries. Meanwhile could you dnsmasq et al. to manage how queries are routed? Wietse - End message from Wietse Venema - I asked a similar question to this list a while ago. I use BIND with a very tight RPZ setup to assist with risk management for our local network, but wanted to have Postfix have completely open DNS - Wietse advised then as he has now that Postfix uses libresolv. I have now setup Unbound as a caching name server on the Postfix server so it can resolve *anything*, but with Unbound configured to fwd to my local network BIND server for local domain addresses (private-address, private-domain, local-zone, stub-zone, etc.). End result is that Postfix can resolve any valid address but can still identify all of the local network, including some local zone RPZ overrides that I have. Simon. -- Simon Wilson M: 0400 12 11 16
Re: STARTTLS abuse
- Message from Wietse Venema - Date: Thu, 9 Sep 2021 18:58:21 -0400 (EDT) From: Wietse Venema Subject: Re: STARTTLS abuse To: Jaroslaw Rafa Cc: postfix-users@postfix.org Jaroslaw Rafa: I also don't have the summary part "ehlo=xxx starttls=xxx ..." etc. in my disconnect message, the log line is just "disconnect from static.148.188.201.195.clients.your-server.de[195.201.188.148]". The commands=x/y counts were added in Postfix 3.0, released in 2015. They may not have made it into RHEL yet. They have, e.g.: Sep 9 04:20:39 emp87 postfix/smtpd[817446]: disconnect from scanner21.about.spyse.com[165.227.159.53] auth=0/1 commands=0/1 (RHEL 8) -- Simon Wilson M: 0400 12 11 16
Re: reject_sender_login_mismatch
- Message from Wietse Venema - Date: Sat, 31 Jul 2021 09:45:00 -0400 (EDT) From: Wietse Venema Reply-To: Postfix users Subject: Re: reject_sender_login_mismatch To: Postfix users Simon Wilson: A quick query on?smtpd_sender_login_maps format. I have this working well on port 587 to ensure that specified SASL-authenticated users only can send emails from their owned email addresses. So I have in a file 'controlled_envelope_senders' this, as an example: @simonandkate.net simon ...and I have reject_sender_login_mismatch set in master.cf for port 587. Then in main.cf: smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders Perfect... I am disabling a couple of email addresses as a first step along the way to deleting some accounts and domain names. I've disabled inbound emails fine, and now need to prevent the users sending, while still being able to access webmail for a few days. The question: Within the smtpd_sender_login_maps file, is an empty RH side valid so *NO* SASL users can send from that (domain) address? Or does it need to have *something* on the RHS? Maps can't return an empty result but you have other options: 1) Return a bogus login name. This is perhaps the easiest. 2) Return 'not found'. When you use a pcre map instead of hash, you have negative patterns, IF/ELSE/ENDIF. See http://www.postfix.org/pcre_table.5.html. This will not search by "@domain" use bare "user", only with the full sender address. Wietse Just what I needed to know, thanks Wietse. I'm just using a hashed file, so will go with the simple option 1. I've put my login in there for now, but perhaps a "disabled" or something along those lines will be more intuitive. Thanks again. -- Simon Wilson M: 0400 12 11 16
Re: reject_sender_login_mismatch
- Message from tobi - Date: Sat, 31 Jul 2021 06:49:48 + From: tobi Subject: Re: reject_sender_login_mismatch To: postfix-users@postfix.org you could add a sender access map in your relay config which rejects those domains. Place it before your sender login maps Am 31. Juli 2021 06:06:17 UTC schrieb Simon Wilson : A quick query on smtpd_sender_login_maps format. I have this working well on port 587 to ensure that specified SASL-authenticated users only can send emails from their owned email addresses. So I have in a file 'controlled_envelope_senders' this, as an example: @simonandkate.net simon ...and I have reject_sender_login_mismatch set in master.cf for port 587. Then in main.cf: smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders Perfect... I am disabling a couple of email addresses as a first step along the way to deleting some accounts and domain names. I've disabled inbound emails fine, and now need to prevent the users sending, while still being able to access webmail for a few days. The question: Within the smtpd_sender_login_maps file, is an empty RH side valid so *NO* SASL users can send from that (domain) address? Or does it need to have *something* on the RHS? Thanks Simon - End message from tobi - Yes, thank you - that would work... but it's adding another step and another lookup file, which would be done *every* email send, and would become an additional process to manage. If I can do with the lookup which is happening already to validate user login --> sending domain that would be my preference. -- Simon Wilson M: 0400 12 11 16
reject_sender_login_mismatch
A quick query on smtpd_sender_login_maps format. I have this working well on port 587 to ensure that specified SASL-authenticated users only can send emails from their owned email addresses. So I have in a file 'controlled_envelope_senders' this, as an example: @simonandkate.net simon ...and I have reject_sender_login_mismatch set in master.cf for port 587. Then in main.cf: smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders Perfect... I am disabling a couple of email addresses as a first step along the way to deleting some accounts and domain names. I've disabled inbound emails fine, and now need to prevent the users sending, while still being able to access webmail for a few days. The question: Within the smtpd_sender_login_maps file, is an empty RH side valid so *NO* SASL users can send from that (domain) address? Or does it need to have *something* on the RHS? Thanks Simon -- Simon Wilson M: 0400 12 11 16
Re: Mail not being sent to file
- Message from Damian - Date: Thu, 17 Jun 2021 12:22:28 +0200 From: Damian Subject: Re: Mail not being sent to file To: postfix-users@postfix.org That's interesting... 8.4 saw the upgrade to Postfix 3.5.8 (from 3.3.1 I believe) http://rpmfind.net/linux/centos/8.3.2011/BaseOS/x86_64/os/Packages/postfix-3.3.1-12.el8.x86_64.rpm already had PrivateTmp. Yes... and going back further as far as I can see every version of Postfix used on Centos 8 has had it: https://git.centos.org/rpms/postfix/releases Oldest C8 Postfix is 3.3.1-8, which had it: https://git.centos.org/rpms/postfix/blob/aebf407fea0eeff2335e0d09c70514d7046e7cad/f/SOURCES/postfix.service Standing by earlier comment - this was a change from C7 to C8, not a change within C8. Simon. -- Simon Wilson M: 0400 12 11 16
Re: Mail not being sent to file
It broke because as Bastian pointed out in CentOS 8 the Postfix service definition (postfix.service) changed with the addition of PrivateTmp=true. CentOS 7 did not have that so used the "standard" /tmp. Your process WAS WORKING - just not writing to the /tmp you were looking at, but to the postfix service's private /tmp. Pardon me, what I meant was that this used to work with CentOS 8. That's interesting... 8.4 saw the upgrade to Postfix 3.5.8 (from 3.3.1 I believe) which was a major change, but nothing in the release notes (see /usr/share/doc/postfix/README-RedHat.txt on an 8.4 system) mentions a change to the .service file, nor at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.4_release_notes/new-features#enhancement_infrastructure-services. And the changelog only refers to the one bugzilla: * Fri Nov 13 2020 Jaroslav Škarvada - 2:3.5.8-1 - New version Resolves: rhbz#1688389 When did you first see the change? We are possibly straying a little from this mailing list's function... Simon. -- Simon Wilson M: 0400 12 11 16
Re: Mail not being sent to file
>Just don't assume /tmp or /var/tmp are the same between services.
>
>Postfix on RHEL 8 is configured with private /tmp. To be exact:
>| PrivateTmp=true
>| CapabilityBoundingSet=~ CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_BOOT
>CAP_SYS_MODULE
>| ProtectSystem=true
>| PrivateDevices=true
>
>Bastian
- End message from Bastian Blank
-
Yup.
Using a directory other than /tmp works fine on RHEL8:
[root@emp87 ~]# chmod 1777 /home/simon
[root@emp87 ~]# echo "somealias: /home/simon/somefile" >>
/etc/aliases && newaliases
[root@emp87 ~]# echo "test" | mail somealias@localhost
[root@emp87 simon]# cat /home/simon/somefile
{content as expected}
Thanks guys. You are right -- this does work.
My previous example worked for a long time. Not sure why it suddenly became
broken but I will try to dig into that some more.
It broke because as Bastian pointed out in CentOS 8 the Postfix
service definition (postfix.service) changed with the addition of
PrivateTmp=true. CentOS 7 did not have that so used the "standard"
/tmp. Your process WAS WORKING - just not writing to the /tmp you were
looking at, but to the postfix service's private /tmp.
You *could* return it to the way it worked before by changing the
service definition file and removing privatetmp - assuming you were
comfortable with opening up postfix /tmp to be normal system /tmp -
others far smarter than I with Postfix would be better placed to
comment on any risks so introduced.
Simon.
--
Simon Wilson
M: 0400 12 11 16
Re: Mail not being sent to file
- Message from Bastian Blank
-
Date: Thu, 17 Jun 2021 07:59:10 +0200
From: Bastian Blank
Subject: Re: Mail not being sent to file
To: postfix-users@postfix.org
On Wed, Jun 16, 2021 at 05:59:16PM -0700, Jeremiah Rothschild wrote:
To triple check my sanity, I created a brand new VM and confirmed the
behavior.
So anyone should be able to easily reproduce this.
* Fresh CentOS 8.4 install
* Choose "Minimal" base environment
* Defaults for everything else
# yum -y update
# yum -y install postfix mailx
# systemctl start postfix
# echo "somealias: /tmp/somefile" >> /etc/aliases && newaliases
# echo "test" | mail somealias@localhost
# ls /tmp/somefile
Just don't assume /tmp or /var/tmp are the same between services.
Postfix on RHEL 8 is configured with private /tmp. To be exact:
| PrivateTmp=true
| CapabilityBoundingSet=~ CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_BOOT
CAP_SYS_MODULE
| ProtectSystem=true
| PrivateDevices=true
Bastian
- End message from Bastian Blank
-
Yup.
Using a directory other than /tmp works fine on RHEL8:
[root@emp87 ~]# chmod 1777 /home/simon
[root@emp87 ~]# echo "somealias: /home/simon/somefile" >> /etc/aliases
&& newaliases
[root@emp87 ~]# echo "test" | mail somealias@localhost
[root@emp87 ~]# cd /home/simon
[root@emp87 simon]# cat /home/simon/somefile
{content as expected}
Simon.
--
Simon Wilson
M: 0400 12 11 16
Re: Mail not being sent to file
- Message from Jeremiah Rothschild - Date: Wed, 16 Jun 2021 17:59:16 -0700 From: Jeremiah Rothschild Subject: Re: Mail not being sent to file To: Postfix users On Wed, Jun 16, 2021 at 04:48:09PM -0700, Jeremiah Rothschild wrote: On Wed, Jun 16, 2021 at 07:13:18PM -0400, Wietse Venema wrote: > Is the 'lost file' problem reproducible? Yes, the time gap is a red herring. First the issue was noticed in production then I tested with this VM. To triple check my sanity, I created a brand new VM and confirmed the behavior. So anyone should be able to easily reproduce this. * Fresh CentOS 8.4 install * Choose "Minimal" base environment * Defaults for everything else # yum -y update # yum -y install postfix mailx # systemctl start postfix # echo "somealias: /tmp/somefile" >> /etc/aliases && newaliases # echo "test" | mail somealias@localhost # ls /tmp/somefile j - End message from Jeremiah Rothschild - Confirmed and reproducible. On RHEL 8: [root@emp87 ~]# echo "somealias: /tmp/somefile" >> /etc/aliases && newaliases [root@emp87 ~]# echo "test" | mail somealias@localhost [root@emp87 ~]# ls /tmp/somefile ls: cannot access '/tmp/somefile': No such file or directory Jun 17 12:38:57 emp87 postfix/local[2333723]: B92E199511: to=, relay=local, delay=0.02, delays=0.01/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to file: /tmp/somefile) On CentOS 7: [root@emp75 ~]# echo "somealias: /tmp/somefile" >> /etc/aliases && newaliases [root@emp75 ~]# echo "test" | mail somealias@localhost [root@emp75 ~]# ls /tmp/somefile /tmp/somefile (contents as expected) Simon. -- Simon Wilson M: 0400 12 11 16
Re: Disable Logging By Host
With rsyslog, use something like this near the top of rsyslog.conf. :msg, contains, "whatever" ~ One minor comment on this. Use of ~ in rsyslog.conf to suppress is deprecated in recent versions. If you get warnings, e.g. on RHEL 8 the following error is thrown: rsyslogd[945534]: warning: ~ action is deprecated, consider using the 'stop' statement instead [v8.1911.0-7.el8 try https://www.rsyslog.com/e/2307 ], it will still work, just with the warnings. To remove the warnings use 'stop' instead. :msg, contains, "whatever" stop -- Simon Wilson M: 0400 12 11 16
Re: discarding EHLO keywords: CHUNKING
https://bugzilla.redhat.com/show_bug.cgi?id=1688389 Sorry for mobile client top post. RH have just jumped version of postfix to 3.5.8. Whilst this is a welcome step, they have chosen to set some postfix configuration items to non-standard to work around "incompatibilities". There is a Bugzilla with the info, I'll see if I can find it again. One of them is to set CHUNKING off by default, so unless you are already explicitly setting smtpd_discard_ehlo_keywords in your config the new default will be applied. Simon Wilson M: 0400 121 116 From: Viktor Dukhovni Sent: Monday, 24 May 2021 7:51 am To: postfix-users@postfix.org Subject: Re: discarding EHLO keywords: CHUNKING > On Sun, May 23, 2021 at 02:16:24PM -0700, Greg Sims wrote: > >> # postconf | grep chunking >> smtpd_discard_ehlo_keywords = chunking >> >> # journalctl -u postfix | grep CHUNKING >> May 23 03:40:59 mail01.raystedman.org postfix/smtpd[401681]: >> discarding EHLO keywords: CHUNKING >> <> > > That means that you're spawning a new smtpd(8) process roughly once an > hour, with connections otherwise handled by an existing process, which > already logged the disabled ESMTP feature with the first connection it > handled. > >> We are running the latest version of RHEL 8. I believe a number of us >> will be seeing this entry in our logs. What are the negative side >> effects beyond the log entries? > > There are no negative side-effects, but the logs record that you've > chosen to disable a default ESMTP feature, presumably as a work-around > for some issue. Once the issue is no longer pertinent, you can turn the > workaround off. > >> Is "smtpd_discard_ehlo_keywords = chunking, silent-discard" the >> recommended solution? > > Well, the recommended solution is to not disable CHUNKING, but if > you must disable it for some reason, you get to choose whether to > be reminded of this in your logs, or not. > > -- > Viktor. >
Re: discarding EHLO keywords: CHUNKING
Sorry for mobile client top post. RH have just jumped version of postfix to 3.5.8. Whilst this is a welcome step, they have chosen to set some postfix configuration items to non-standard to work around "incompatibilities". There is a Bugzilla with the info, I'll see if I can find it again. One of them is to set CHUNKING off by default, so unless you are already explicitly setting smtpd_discard_ehlo_keywords in your config the new default will be applied. Simon Wilson M: 0400 121 116 From: Viktor Dukhovni Sent: Monday, 24 May 2021 7:51 am To: postfix-users@postfix.org Subject: Re: discarding EHLO keywords: CHUNKING On Sun, May 23, 2021 at 02:16:24PM -0700, Greg Sims wrote: # postconf | grep chunking smtpd_discard_ehlo_keywords = chunking # journalctl -u postfix | grep CHUNKING May 23 03:40:59 mail01.raystedman.org postfix/smtpd[401681]: discarding EHLO keywords: CHUNKING <> That means that you're spawning a new smtpd(8) process roughly once an hour, with connections otherwise handled by an existing process, which already logged the disabled ESMTP feature with the first connection it handled. We are running the latest version of RHEL 8. I believe a number of us will be seeing this entry in our logs. What are the negative side effects beyond the log entries? There are no negative side-effects, but the logs record that you've chosen to disable a default ESMTP feature, presumably as a work-around for some issue. Once the issue is no longer pertinent, you can turn the workaround off. Is "smtpd_discard_ehlo_keywords = chunking, silent-discard" the recommended solution? Well, the recommended solution is to not disable CHUNKING, but if you must disable it for some reason, you get to choose whether to be reminded of this in your logs, or not. -- Viktor.
Re: Briteverify
To date here are the IPs used by briteverify.com that I have marked to drop in my firewall... ## briteverify.com (Amazon AWS) 34.195.68.199 50.19.103.141 50.19.103.149 50.19.105.217 50.19.253.57 52.1.117.226 52.3.174.189 52.203.39.60 54.83.44.163 54.83.54.115 54.197.230.106 54.197.250.255 54.225.108.187 54.235.119.112 107.20.134.42 107.20.207.58 107.20.218.183 107.20.232.98 107.20.235.139 107.20.249.220 107.21.204.157 107.22.212.75 184.72.250.175 184.73.205.138 Thanks David, this was very useful. Simon -- Simon Wilson M: 0400 12 11 16
Re: Briteverify
My guess is that the 5.2-second null connections are significant. I
suspect that you can fix this without significantly damaging the
effect of the postscreen PREGREET test by reducing the wait time to
never exceed that 5.2 seconds, e.g.:
postconf -e 'postscreen_greet_wait = ${stress?{2}:{4}}s'
That will probably reduce your overall PREGREET rejections by <1%
but IF that is the cause of the null sessions from Briteverify, it
should fix them.
I've pulled back the postscreen delay per your suggestion and will test that.
Results of testing:
4s, no difference in end result, but different log entries:
May 23 09:41:55 emp87 postfix/postscreen[982010]: CONNECT from
[107.20.237.69]:57014 to [192.168.1.230]:25
May 23 09:41:55 emp87 postfix/dnsblog[982012]: addr 107.20.237.69
listed by domain hostkarma.junkemailfilter.com as 127.0.1.1
May 23 09:41:59 emp87 postfix/postscreen[982010]: PASS NEW
[107.20.237.69]:57014
May 23 09:42:00 emp87 postfix/smtpd[982879]: connect from
smtpout11.briteverify.com[107.20.237.69]
May 23 09:42:00 emp87 postfix/smtpd[982879]: lost connection after
CONNECT from smtpout11.briteverify.com[107.20.237.69]
May 23 09:42:00 emp87 postfix/smtpd[982879]: disconnect from
smtpout11.briteverify.com[107.20.237.69] commands=0/0
I thought Hmm that's interesting, dropped back to 6s... and got the
same reduced set of connection attempts.
May 23 09:43:24 emp87 postfix/postscreen[985482]: CONNECT from
[107.20.232.98]:60420 to [192.168.1.230]:25
May 23 09:43:25 emp87 postfix/dnsblog[985496]: addr 107.20.232.98
listed by domain hostkarma.junkemailfilter.com as 127.0.1.1
May 23 09:43:30 emp87 postfix/postscreen[985482]: PASS OLD
[107.20.232.98]:60420
May 23 09:43:30 emp87 postfix/smtpd[985542]: connect from
smtpout9.briteverify.com[107.20.232.98]
May 23 09:43:30 emp87 postfix/smtpd[985542]: lost connection after
CONNECT from smtpout9.briteverify.com[107.20.232.98]
May 23 09:43:30 emp87 postfix/smtpd[985542]: disconnect from
smtpout9.briteverify.com[107.20.232.98] commands=0/0
So same config as yesterday, but a different set of attempts.
Then I dropped to 3 seconds, and the validation passes:
May 23 09:44:44 emp87 postfix/postscreen[985956]: CONNECT from
[107.20.223.96]:57264 to [192.168.1.230]:25
May 23 09:44:44 emp87 postfix/dnsblog[985976]: addr 107.20.223.96
listed by domain hostkarma.junkemailfilter.com as 127.0.1.1
May 23 09:44:47 emp87 postfix/postscreen[985956]: PASS NEW
[107.20.223.96]:57264
May 23 09:44:47 emp87 postfix/smtpd[985992]: connect from
smtpout45.briteverify.com[107.20.223.96]
May 23 09:44:50 emp87 policyd-spf[986011]: prepend
Authentication-Results: mail.simonandkate.net; spf=pass (mailfrom)
smtp.mailfrom=origindata.com (client-ip=107.20.223.96;
helo=smtpout.briteverify.com; envelope-from=ad...@origindata.com;
receiver=si...@simonandkate.net)
May 23 09:44:50 emp87 postfix/smtpd[985992]: 1253660BA:
client=smtpout45.briteverify.com[107.20.223.96]
May 23 09:44:50 emp87 postfix/smtpd[985992]: disconnect from
smtpout45.briteverify.com[107.20.223.96] helo=1 mail=1 rcpt=1 quit=1
commands=4
So it looks like they are failing on delay - which is completely
stupid. Posting the results back here in case anyone else ever wonders
about the cowboys at briteverify.
I'm assuming a 50% reduction in postscreen delay may have an unwanted
impact on inbound spam :(
I'll see how it goes.
Thanks again Bill.
Simon
--
Simon Wilson
M: 0400 12 11 16
Re: Briteverify
Simon Wilson is rumored to have said: Question about one of those services that validates email addresses on the fly when you fill in a form... There is one (Briteverify) which seems to fail email addresses at our postfix server for an unknown reason. Let's start with 2 stipulations: 1. Briteverify has a history as an abusive facilitator of spammers. They have a history of attempting to verify bogus addresses harvested from things like ancient Usenet message IDs at DoS rates. Whether they are still doing that, I cannot say for sure, but they have been a bad actor in the past. 2. Everything I postulate below are educated guesses. I put my email in the form (it's used by a local food delivery service), and in the background I see this on my server: May 22 17:17:44 emp87 postfix/postscreen[805286]: CONNECT from [184.72.250.175]:35556 to [192.168.1.230]:25 May 22 17:17:44 emp87 postfix/postscreen[805286]: CONNECT from [107.20.235.139]:41162 to [192.168.1.230]:25 May 22 17:17:44 emp87 postfix/dnsblog[805300]: addr 184.72.250.175 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1 May 22 17:17:44 emp87 postfix/dnsblog[805318]: addr 107.20.235.139 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1 May 22 17:17:49 emp87 postfix/postscreen[805286]: HANGUP after 5.2 from [184.72.250.175]:35556 in tests before SMTP handshake May 22 17:17:49 emp87 postfix/postscreen[805286]: DISCONNECT [184.72.250.175]:35556 Interesting... 184.72.250.175 (smtpout37.briteverify.com) connected for 5.2 seconds and did nothing. I suspect that they got tired of waiting for a banner, since that's less than the default banner delay for postscreen. May 22 17:17:50 emp87 postfix/postscreen[805286]: PASS NEW [107.20.235.139]:41162 May 22 17:17:52 emp87 postfix/smtpd[805371]: connect from smtpout10.briteverify.com[107.20.235.139] OK, so THAT host waited long enough to get past postscreen. May 22 17:17:54 emp87 postfix/smtpd[805371]: NOQUEUE: reject: RCPT from smtpout10.briteverify.com[107.20.235.139]: 550 5.1.1 : Recipient address rejected: User unknown in virtual alias table; from= to= proto=SMTP helo= May 22 17:17:54 emp87 postfix/smtpd[805371]: lost connection after RCPT from smtpout10.briteverify.com[107.20.235.139] May 22 17:17:54 emp87 postfix/smtpd[805371]: disconnect from smtpout10.briteverify.com[107.20.235.139] helo=1 mail=1 rcpt=0/1 commands=2/3 Checking for a random (and exceedingly unlikely) address. Determining whether your domain has a catchall, i.e. eliminating services like Mailinator. May 22 17:17:54 emp87 postfix/postscreen[805286]: CONNECT from [50.19.110.184]:41342 to [192.168.1.230]:25 May 22 17:17:54 emp87 postfix/dnsblog[805319]: addr 50.19.110.184 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1 May 22 17:17:58 emp87 postfix/postscreen[805286]: CONNECT from [184.72.250.175]:35616 to [192.168.1.230]:25 May 22 17:17:58 emp87 postfix/dnsblog[805317]: addr 184.72.250.175 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1 May 22 17:18:00 emp87 postfix/postscreen[805286]: PASS OLD [50.19.110.184]:41342 Apparently you've seen 50.19.110.184 recently. So postscreen lets it through. May 22 17:18:01 emp87 postfix/smtpd[805371]: connect from smtpout29.briteverify.com[50.19.110.184] May 22 17:18:03 emp87 postfix/postscreen[805286]: HANGUP after 5.2 from [184.72.250.175]:35616 in tests before SMTP handshake May 22 17:18:03 emp87 postfix/postscreen[805286]: DISCONNECT [184.72.250.175]:35616 Once again, 184.72.250.175 shows up and stares at you blankly for 5.2 seconds before walking away. May 22 17:18:03 emp87 policyd-spf[805831]: prepend Authentication-Results: mail.simonandkate.net; spf=pass (mailfrom) smtp.mailfrom=origindata.com (client-ip=50.19.110.184; helo=smtpout.briteverify.com; envelope-from=ad...@origindata.com; receiver=postmas...@simonandkate.net) May 22 17:18:03 emp87 postfix/smtpd[805371]: E32D89606: client=smtpout29.briteverify.com[50.19.110.184] May 22 17:18:04 emp87 postfix/smtpd[805371]: disconnect from smtpout29.briteverify.com[50.19.110.184] helo=1 mail=1 rcpt=1 quit=1 commands=4 Meanwhile, 50.19.110.184 makes it through to a successful RCPT command for postmaster before politely declining to send email. ...and the webpage pops up an error about it being an invalid email address. I can use my work email address and it validates and I can order dinner :-D "Work" email systems tend to avoid (or not even have support for) anything that intentionally delays mail. Yes, and given my work email system is not an open relay I can only assume, per your conclusions here, that the difference is postscreen. Has anyone else any experience on what exactly they are looking for to actually validate? They don't actually appear to test for my email address, rather the non-valid recipient address which is rejected, then postmaster which pa
Re: Briteverify
> May 22 17:17:54 emp87 postfix/smtpd[805371]: NOQUEUE: reject: RCPT > from smtpout10.briteverify.com[107.20.235.139]: 550 5.1.1 > : > Recipient address rejected: User unknown in virtual alias table; > from= > to= > proto=SMTP > helo= Is that your email adrress? Wietse No. My email used is the same one I use on this list. That string is not in the virtual users list, so postfix rejects it. What am I missing, as a commercial email verification service what are they trying to validate? Simon
Briteverify
Question about one of those services that validates email addresses on the fly when you fill in a form... There is one (Briteverify) which seems to fail email addresses at our postfix server for an unknown reason. I put my email in the form (it's used by a local food delivery service), and in the background I see this on my server: May 22 17:17:44 emp87 postfix/postscreen[805286]: CONNECT from [184.72.250.175]:35556 to [192.168.1.230]:25 May 22 17:17:44 emp87 postfix/postscreen[805286]: CONNECT from [107.20.235.139]:41162 to [192.168.1.230]:25 May 22 17:17:44 emp87 postfix/dnsblog[805300]: addr 184.72.250.175 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1 May 22 17:17:44 emp87 postfix/dnsblog[805318]: addr 107.20.235.139 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1 May 22 17:17:49 emp87 postfix/postscreen[805286]: HANGUP after 5.2 from [184.72.250.175]:35556 in tests before SMTP handshake May 22 17:17:49 emp87 postfix/postscreen[805286]: DISCONNECT [184.72.250.175]:35556 May 22 17:17:50 emp87 postfix/postscreen[805286]: PASS NEW [107.20.235.139]:41162 May 22 17:17:52 emp87 postfix/smtpd[805371]: connect from smtpout10.briteverify.com[107.20.235.139] May 22 17:17:54 emp87 postfix/smtpd[805371]: NOQUEUE: reject: RCPT from smtpout10.briteverify.com[107.20.235.139]: 550 5.1.1 : Recipient address rejected: User unknown in virtual alias table; from= to= proto=SMTP helo= May 22 17:17:54 emp87 postfix/smtpd[805371]: lost connection after RCPT from smtpout10.briteverify.com[107.20.235.139] May 22 17:17:54 emp87 postfix/smtpd[805371]: disconnect from smtpout10.briteverify.com[107.20.235.139] helo=1 mail=1 rcpt=0/1 commands=2/3 May 22 17:17:54 emp87 postfix/postscreen[805286]: CONNECT from [50.19.110.184]:41342 to [192.168.1.230]:25 May 22 17:17:54 emp87 postfix/dnsblog[805319]: addr 50.19.110.184 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1 May 22 17:17:58 emp87 postfix/postscreen[805286]: CONNECT from [184.72.250.175]:35616 to [192.168.1.230]:25 May 22 17:17:58 emp87 postfix/dnsblog[805317]: addr 184.72.250.175 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1 May 22 17:18:00 emp87 postfix/postscreen[805286]: PASS OLD [50.19.110.184]:41342 May 22 17:18:01 emp87 postfix/smtpd[805371]: connect from smtpout29.briteverify.com[50.19.110.184] May 22 17:18:03 emp87 postfix/postscreen[805286]: HANGUP after 5.2 from [184.72.250.175]:35616 in tests before SMTP handshake May 22 17:18:03 emp87 postfix/postscreen[805286]: DISCONNECT [184.72.250.175]:35616 May 22 17:18:03 emp87 policyd-spf[805831]: prepend Authentication-Results: mail.simonandkate.net; spf=pass (mailfrom) smtp.mailfrom=origindata.com (client-ip=50.19.110.184; helo=smtpout.briteverify.com; envelope-from=ad...@origindata.com; receiver=postmas...@simonandkate.net) May 22 17:18:03 emp87 postfix/smtpd[805371]: E32D89606: client=smtpout29.briteverify.com[50.19.110.184] May 22 17:18:04 emp87 postfix/smtpd[805371]: disconnect from smtpout29.briteverify.com[50.19.110.184] helo=1 mail=1 rcpt=1 quit=1 commands=4 ...and the webpage pops up an error about it being an invalid email address. I can use my work email address and it validates and I can order dinner :-D Has anyone else any experience on what exactly they are looking for to actually validate? They don't actually appear to test for my email address, rather the non-valid recipient address which is rejected, then postmaster which passes early tests but is disconnected by the client before being fully sent. Simon. -- Simon Wilson M: 0400 12 11 16
Re: RHEL packaged postfix jump
- Message from Viktor Dukhovni - Date: Wed, 19 May 2021 00:46:08 -0400 From: Viktor Dukhovni Reply-To: postfix-users@postfix.org Subject: Re: RHEL packaged postfix jump To: postfix-users@postfix.org On Wed, May 19, 2021 at 12:01:00PM +1000, Simon Wilson wrote: Before I hit the GO button, I have had a look at the changelog lists and I think we should be OK with a straight upgrade, but if anyone has any other comments on the large version change to be aware of please feel free to reply! :) I'm currently at compatibility_level = 2 on 3.3, and will happily provide details of postconf if needed, but if there are any obvious gotchas will look at those first. The suggested post-upgrade ompatibility_level has not changed between 3.3 and 3.5. That's a hint that there are no major barriers to upgrades. And even if there were some preferred configuration changes, they'd be guarded by the compatibility_level. By all means, do read the release notes, but you can expect Postfix to be backwards-compatible. https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.4 https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.5 Thank you Viktor. -- Simon Wilson M: 0400 12 11 16
Re: RHEL packaged postfix jump
Correction, 3.3.1 to 3.5.8 Hi list, RH have just dropped RHEL 8.4 and it appears to have jumped Postfix from 3.3.5 to 3.5.8: Installed Packages postfix.x86_64 2:3.3.1-12.el8_3.1 @rhel-8-for-x86_64-baseos-rpms Available Packages postfix.x86_64 2:3.5.8-1.el8 rhel-8-for-x86_64-baseos-rpms Before I hit the GO button, I have had a look at the changelog lists and I think we should be OK with a straight upgrade, but if anyone has any other comments on the large version change to be aware of please feel free to reply! :) I'm currently at compatibility_level = 2 on 3.3, and will happily provide details of postconf if needed, but if there are any obvious gotchas will look at those first. Thanks Simon. - End message from Simon Wilson - -- Simon Wilson M: 0400 12 11 16
RHEL packaged postfix jump
Hi list, RH have just dropped RHEL 8.4 and it appears to have jumped Postfix from 3.3.5 to 3.5.8: Installed Packages postfix.x86_64 2:3.3.1-12.el8_3.1 @rhel-8-for-x86_64-baseos-rpms Available Packages postfix.x86_64 2:3.5.8-1.el8 rhel-8-for-x86_64-baseos-rpms Before I hit the GO button, I have had a look at the changelog lists and I think we should be OK with a straight upgrade, but if anyone has any other comments on the large version change to be aware of please feel free to reply! :) I'm currently at compatibility_level = 2 on 3.3, and will happily provide details of postconf if needed, but if there are any obvious gotchas will look at those first. Thanks Simon. -- Simon Wilson M: 0400 12 11 16
Re: Milters and policy
Pypolicyd-spf then tags what has driven the result for later use: E.g. Apr 3 11:19:23 emp87 policyd-spf[1336326]: prepend Authentication-Results: mail.simonandkate.net; spf=pass (mailfrom) Apr 2 12:32:51 emp87 policyd-spf[1255235]: prepend Authentication-Results: mail.simonandkate.net; spf=pass (helo) Just out of curiosity, how do you get policyd-spf to prepend 2 headers? Have you created two separate entries in master.cf, each using separate configuration files (i.e. one configured to only do HELO checks and the other configured to do MAILFROM)? Or some other trickery? (AFAIK each invocation of a policy server can only return a single action?) Hi Nick, Those are two lines from two different emails - even my slow system doesn't take 24 hours to process an email :-D Unless I am misunderstanding your question? Simon. -- Simon Wilson M: 0400 12 11 16
Re: Specific DNS server
- Message from Wietse Venema - Date: Thu, 22 Apr 2021 10:01:09 -0400 (EDT) From: Wietse Venema Subject: Re: Specific DNS server To: si...@simonandkate.net Cc: postfix-users@postfix.org Simon Wilson: Is there a way to make Postfix/postscreen use a specific DNS server? Edit /etc/resolv.conf. No kidding - Postfix uses the SYSTEM LIBRARY for DNS lookups, and the SYSTEM LIBRARY uses the resolv.conf file. Theree are no plans to re-implement this part of the SYSTEM LIBRARY in Postfix. Wietse Thank you. I have implemented unbound as the local nameserver, running in caching mode but with a stub-zone to refer to my network-wide server for local name resolution. Simon. -- Simon Wilson M: 0400 12 11 16
Specific DNS server
Is there a way to make Postfix/postscreen use a specific DNS server? Reason for the question: My network has an internal (non-ISP forwarding) DNS server for both internal and external resolution, and that is default nameserver across the network including for the mail server. That DNS server includes a broad set of applied RPZ restrictions (which remove the vast majority of ads and trackers - a very popular addition). The RPZ zone has though on very rare occasions resulted in Postfix getting SERVFAIL and rejecting domains (reject_unknown_sender_domain), which could be classed as false positives - not for critical emails, but occasionally for retail mail-outs etc. I provide a fully "clean and complete" DNS for spamassassin DNSBL lookups by running a recursive caching nameserver on-localhost (SA has an defined option to specify a DNS server). As noted above the mail server as a whole does not use this - it uses the network-wide local nameserver, ensuring that it can resolve local As CNAMEs etc as needed. Note: I realise one option is that I could probably add local domain resolution to the localhost nameserver and use it as the default for the mail server... but my first question is whether postfix has or could have ability to have a specific nameserver (as Spamassassin does), or if this would be a Bad Idea (TM) for reasons unknown to me. Simon. -- Simon Wilson M: 0400 12 11 16
Re: Opendmarc in after-Amavis smtpd fails
- Message from Jesper Dybdal - Date: Tue, 13 Apr 2021 12:03:33 +0200 From: Jesper Dybdal Subject: Re: Opendmarc in after-Amavis smtpd fails To: postfix-users@postfix.org I did not get any replies to the message below. So I'm trying again, with a few additional details and questions added at the end. On 2021-04-04 15:13, I wrote: I use postfix 3.4.14 (Debian Buster) with amavisd-new as a pre-queue filter (smtpd_proxy_filter). I use Amavis to generate and verify DKIM signatures, and policyd-spf-python to preform SPF checks. This works fine. But now I would like to add DMARC verification. Since DMARC needs the DKIM result from Amavis, my plan was to use the opendmarc milter in the after-Amavis smtpd instance. But this does not seem to work. Opendmarc logs "ignoring connection from localhost" and seems to do nothing. The after-Amavis smtpd listens at port 10028; opendmarc listens at port 10030. I have placed configuration information and tcpdump examples at https://www.dybdal.dk/opendmarc-problem/ I have verified with tcpdump that Amavis does provide an XFORWARD command to the after-Amavis smtpd. I have verified with tcpdump that the after-Amavis smtpd does connect to opendmarc and that they have a (very short) dialog. I don't know the milter protocol. The short dialog between the after-Amavis smtpd and opendmarc contains "127.0.0.1" a few times, but not the XFORWARD address, but I do not know if that is suspicious. I would very much appreciate it if somebody can tell me what is going on - and what opendmarc means with that error message. Since then, I've had a look at the milter protocol. And yes, one of the 127.0.0.1 addresses transmitted to the milter is the client IP address. But I do not understand why a DMARC check should even consider the client IP address - I would have thought that it should be concerned only with the "From:" and "Authentication-Results" headers. Also, I've found an old thread, in which it seems that the poster has succeeded in doing exactly what I'm trying - I can't see why it should be different from my setup: On 2019-02-25 19:43, Patrick Proniewski wrote: Then, I'm currently trying another approach. In my current setup, I've an amavisd sandwich: outer-smtp->amavisd->inner-smtp. I can't put opendmarc or any milter on the outer-smtp, so I've put opendmarc on the inner-smtp. It's working OK so far, but I'll need extensive testing to check all possible case. An alternative solution might be to use the milter variant of amsvis: policyd-spf, amavis-milter (doing DKIM), openDMARC milter. Would that work? (I hesitate to do major changes, since this is a production system.) Any help would be greatly appreciated. Hi Jesper, Looks like opendmarc is seeing the injected amavis mail as localhost, which I assume it is... by default opendmarc will ignore that. For what it is worth, this is my config for INBOUND email: - pypolicyd-spf called as a check_policy_service in smtpd_recipient_restrictions runs SPF checks, inserting an Authentication-Results header with SPF evaluation - smtpd_milter_maps calls opendkim and opendmarc (in that order) - I have smtpd_milter_maps set so the milters do not run on internal addresses: # Skip milters if mail is from internal addresses or localhost smtpd_milter_maps = cidr:/etc/postfix/smtpd_milter_map - opendmarc.conf is also configured to ignore IgnoreAuthenticatedClients; and IgnoreHosts contains my local network (although I think this last is duplication given the smtpd_milter_maps setting) - All SMTP inbound mail other than from localhost or local network therefore gets SPF, DKIM and DMARC evaluated - Postfix then calls amavis as a content_filter - Amavis evaluates, calls spamassassin (which applies rules on SPF, DKIM, DMARC), etc., and then passes back to postfix. - postfix has no content_filter or milters on the re-injected mail, so it comes back in for delivery Like you I use amavis to DKIM sign outbound email, not opendkim. I just prefer the way it handles it. I know it's a different setup to yours, but may provide an alternate route. Simon. -- Simon Wilson M: 0400 12 11 16
Re: Milters and policy
ranted. So now we come to DMARC. The DMARC RFC7489 says at 3.1 about SPF: "while [SPF] can authenticate either the domain that appears in the RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/ HELO domain, or both" ...acknowledging that a valid SPF pass can be based on HELO. It then says (4.1) that DMARC *must only use SPF MAIL FROM* authentication: "DMARC uses the result of SPF authentication of the MAIL FROM identity" pypolicyd-spf is giving OpenDMARC the necessary information to check whether this is achievable. Look at my example log entries as noted above with the prepend headers: spf=pass (mailfrom) spf=pass (helo) OpenDMARC has the information needed to make an informed decision on whether the SPF pass which has been made earlier can actually be used in alignment with the DMARC RFC (i.e. based on MAIL FROM) or should be ignored (i.e. based on HELO). If OpenDMARC stops parsing at "spf=pass" how is that an issue with anything other than OpenDMARC? The DMARC RFC *explicitly* says that DMARC must only use an SPF authentication of MAIL FROM - It does not say that DMARC should trust an spf=pass. Your comment: "we *could* add a check on an earlier SPF header that checks *ONLY* the mail-from identity in a received-spf header" strikes me as being the sensible fix. In fact, if OpenDMARC is *NOT* checking against only an SPF MAILFROM pass, perhaps you can enlighten me on how it is compliant with RFC7489 4.1? In turn, that could lead users to point at an SPF=pass in a previous A/R or received-spf header, and complain that we’re still rejecting. It could also lead OpenDMARC to add its own SPF A/R header with a different result than a previous one, which could greater complicate things down the chain. Which header does a downstream filter (say, Spamd) believe? Again - spf=pass is not the issue. Rejecting based on an SPF policy such as -all is carefully cautioned when used with DMARC (RFC7489 10.1). Since SPF is broken by pretty much every mailing list, and mailing lists are not SPF aware (but some ARE dmarc aware), using py-policyd to reject is probably not a great idea anyway, since as far as I know py-policyd doesn’t know how to check if a _dmarc record also exists. Not true. I currently reject SPF on fail, am on dozens of mailing lists without issue (I should say without *SPF* issues... ignoring issues like the OpenDMARC mailing list's use of deprecated TLS protocols). I usually get spf=none from those. I currently have only 1 dumb domain in my SPF skip-check whitelist (I've contacted them, no change). On my small server this results in (after extensive postscreen activity dropping about 90% of connection attempts) typically 2 or 3 SPF rejects a day (out of 300 to 500 emails. Of those, maybe 1 every three or four weeks is a false positive. Yes I could accept and pass further down the line for evaluation and e.g. DMARC tagging - I choose not to. Your interpretation of RFC7489 10.1 is also flawed (again IMO)... "Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this." That places the onus on domain owners, not receivers. It acknowledges that some receivers do SPF before DMARC and that may result in rejection before DMARC - it then cautions Operators to be aware of that risk. It is entirely valid under the SPF RFC for a receiver to reject messages based on an SPF Fail (RFC7208 G.2)... and I choose to do so before I get to DMARC. Our advice to the administrators is to carefully evaluate the behavior of this software — be aware that this is a failure mode, and act accordingly. I don’t use py-policyd, so I don’t know what else it can be used to do (for example, if it’s a general purpose wrapper like Amavis is). I don’t feel that we should be writing documentation or suggesting specific configuration knobs for software we didn’t put out. The CVE response is visible in the SECURITY folder in our github on the “develop” branch. This specific callout will probably also be in the RELEASE NOTES, which we’re still writing. Fundamentally I agree with Scott Kitterman here (https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816/comments/3): "If you look at https://tools.ietf.org/html/rfc7208#section-4.1 you can see that both HELO and Mail From are treated as first class inputs to check_host(). From a specification perspective, the result needs to consider what identity it relates to, which is why I think ***a DMARC processor that assumes any reported SPF result relates to the Mail From of the message is buggy***. Scott K" (***emphasis added***) Simon -- Simon Wilson M: 0400 12 11 16
Re: Milters and policy
- Message from Dan Mahoney - Date: Thu, 1 Apr 2021 16:19:05 -0700 From: Dan Mahoney Subject: Re: Milters and policy To: si...@simonandkate.net Cc: postfix-users@postfix.org On Mar 31, 2021, at 18:23, Simon Wilson wrote: ...if multiple milters are called are they run in order specified? smtpd_milters = inet:127.0.0.1:8891,inet:127.0.0.1:8893 yes I.e. in the example above if OpenDMARC is to see and trust an already-run OpenDKIM Authentication-Results header is the order of specifying the milters important? yes opendkim need to run before opendmarc, and if you have openarc place that before opendkim, it can be messy if opendmarc checks openarc results, remeber it also need to trust AR headers to be considered good info but i do not use milters self, only do all i need with fuglu Thanks again Benny. I have policyd-spf set to insert an AR header, and OpenDMARC set to trust the Authserv-Id added in Authentication-Results headers by policyd-spf and OpenDKIM. All working nicely and good to understand the sequence. Please read CVE-2019-20790, and tell me you’ve found a way to tell PyPolicyd not to trust the SMTP HELO to generate a passing AR header. -Dan In the interests of open disclosure of your interests, I assume d...@prime.gushi.org = https://github.com/thegushi = OpenDMARC developer? This is possibly off-topic for the Postfix list... maybe not. Re the risk from the CVE to my setup... I run policyd-spf as a postfix check_policy with reject on fail (on both HELO and MAILFROM), and assuming a mail gets past that (99% do), I then use that Pass along with OpenDKIM and OpenDMARC to contribute to Spamassassin scoring. My DMARC Spamassassin rules do not apply a -ve on a pass, only a +ve on a fail. The impact of a false pass from DMARC (particularly as our Webmail system - Horde - does not show any added trust for a dmarc pass) would be failure to apply a negative Spamassassin score from a the missed DMARC fail. With my mail setup and users the impact of that is probably manageable... but agreed it is not ideal. What concerns me as much as anything is that each of the apps' devs in question (pypolicyd-spf and opendmarc) are each pointing at each other :-/ https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816/comments/4: "my belief that the issue here is a DMARC processor failing to do alignment validation correctly" https://github.com/trusteddomainproject/OpenDMARC/issues/49#issuecomment-802242666 "Honestly, this CVE seems more to belong to py-policyd than OpenDMARC." What would be nice would be if the two of you worked together on coming up with a fix... Anyways... I see two possible workarounds (not fixes). 1. Setting pypolicyd to HELO_Reject = No_Check. RFC7208 indicates that MAILFROM and HELO are both equally valid for an SPF result, *BUT* the vast majority of my SPF checks trigger pass or fail on MAILFROM (I've had 3 spf HELO passes in 10 days on HELO, thousands on MAILFROM). Testing pypolicyd-spf with HELO_reject = No_Check results in spf=none for those. Removing the HELO check means that OpenDMARC can assume any spf result it is given is based on MAILFROM. 2. Tell OpenDMARC to *NOT* trust any existing spf result and do its own. I.e. SPFIgnoreResults true. This obviously doubles SPF processing time, and relegates pypolicyd-spf to purely an inbound policy reject check. If one is not using pypolicyd to reject then this would be pointless, and it could be removed from the stack. Thoughts? Simon. -- Simon Wilson M: 0400 12 11 16 - End message from Dan Mahoney - -- Simon Wilson M: 0400 12 11 16
Re: Milters and policy
...if multiple milters are called are they run in order specified? smtpd_milters = inet:127.0.0.1:8891,inet:127.0.0.1:8893 yes I.e. in the example above if OpenDMARC is to see and trust an already-run OpenDKIM Authentication-Results header is the order of specifying the milters important? yes opendkim need to run before opendmarc, and if you have openarc place that before opendkim, it can be messy if opendmarc checks openarc results, remeber it also need to trust AR headers to be considered good info but i do not use milters self, only do all i need with fuglu Thanks again Benny. I have policyd-spf set to insert an AR header, and OpenDMARC set to trust the Authserv-Id added in Authentication-Results headers by policyd-spf and OpenDKIM. All working nicely and good to understand the sequence. Simon. -- Simon Wilson M: 0400 12 11 16
Re: Milters and policy
Quick question please: Which does Postfix run first - a milter specified in smtpd_milters or a check_policy_service in smtpd_recipient_restrictions? milters is run after check policy service, to keep performance at top Thank you sir... I just found this too which helped: https://groups.google.com/g/mailing.postfix.users/c/3vGc-RMYV94/m/W3xYtyiovQcJ "...The Milter comes after smtpd/cleanup. Wietse" So in my config above, the SPF policy is run before OpenDKIM milter is called. Simon. ...if multiple milters are called are they run in order specified? smtpd_milters = inet:127.0.0.1:8891,inet:127.0.0.1:8893 I.e. in the example above if OpenDMARC is to see and trust an already-run OpenDKIM Authentication-Results header is the order of specifying the milters important? Simon -- Simon Wilson M: 0400 12 11 16
Re: Milters and policy
- Message from Benny Pedersen - Date: Thu, 01 Apr 2021 01:50:15 +0200 From: Benny Pedersen Subject: Re: Milters and policy To: postfix-users@postfix.org On 2021-04-01 01:43, Simon Wilson wrote: Quick question please: Which does Postfix run first - a milter specified in smtpd_milters or a check_policy_service in smtpd_recipient_restrictions? milters is run after check policy service, to keep performance at top Thank you sir... I just found this too which helped: https://groups.google.com/g/mailing.postfix.users/c/3vGc-RMYV94/m/W3xYtyiovQcJ "...The Milter comes after smtpd/cleanup. Wietse" So in my config above, the SPF policy is run before OpenDKIM milter is called. Simon. -- Simon Wilson M: 0400 12 11 16
Milters and policy
Quick question please: Which does Postfix run first - a milter specified in smtpd_milters or a check_policy_service in smtpd_recipient_restrictions? I.e.: #OpenDKIM smtpd_milters = inet:127.0.0.1:8891 ... smtpd_recipient_restrictions = ... # python-policyd-spf check_policy_service unix:private/policyd-spf permit Thanks. -- Simon Wilson M: 0400 12 11 16
Re: Setting up virtual alias domains and maps - failing to deliver
- Message from Simon Wilson - Date: Wed, 24 Mar 2021 09:57:37 +1000 From: Simon Wilson Reply-To: si...@simonandkate.net Subject: Re: Setting up virtual alias domains and maps - failing to deliver To: postfix-users@postfix.org - Message from Noel Jones - Date: Tue, 23 Mar 2021 12:46:29 -0500 From: Noel Jones Reply-To: njo...@megan.vbhcs.org Subject: Re: Setting up virtual alias domains and maps - failing to deliver To: postfix-users@postfix.org On 3/23/2021 6:31 AM, Simon Wilson wrote: Changes: mydestination - removed, left as default Don't do that. Set it to something specific maybe "localhost.local" virtual_alias_domains = simonandkate.lan, simonandkate.net, etc... virtual_alias_maps = hash:/etc/postfix/virtual (and postmapped) Removed all virtual alias domain entries from aliases and run newaliases The domain alias appears valid: [root@emp87 postfix]# postmap -q ka...@simonandkate.net hash:/etc/postfix/virtual katie virtual aliases should always use a fully qualified email address, such as katie@localhost.local -- Noel Jones Combining postconf -d/-n, naming is: mydestination = $myhostname, localhost.$mydomain, localhost (i.e. default) myhostname = mail.simonandkate.net (specified in main.cf) mydomain = simonandkate.lan (i.e. default) myorigin = $myhostname (i.e default) ...that pans out to: mydestination = mail.simonandkate.net, localhost.simonandkate.lan, localhost myhostname = mail.simonandkate.net mydomain = simonandkate.lan myorigin = mail.simonandkate.net On your second point, 'virtual' is written like this: #simonandkate.net si...@simonandkate.net simon ...which I will correct, note questions later. I think the combination of naming and 'not-FQ aliases' is contributing to the following in pflogsumm reporting (extract for clarity): Recipients by message count --- 519 si...@simonandkate.net 40 si...@mail.simonandkate.net 98 howie...@howiesue.net 2 howie...@mail.simonandkate.net Mail is getting delivered but with address variation to the final destination. Note also the example at the bottom of this email, where d...@domwilson.net is getting changed to d...@mail.simonandkate.net Questions: 1. in virtual, do alias addresses always map out to $mydestination-resolvable addresses? I.e. does it need to be si...@simonandkate.net --> simon@something-in-$mydestination? 2. Is there a way to keep the address as the original recipient (as it was when the domains were under mydestination) for things like pflogsumm reporting? 3. Are there better options for my mydestination, myhostname, mydomain, myorigin which will assist? Thanks so much for the help Noel, Viktor, Matus. Simon Example: Mar 24 09:29:49 emp87 postfix/lmtp[413570]: BDED91819ED: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=5.4, delays=1.2/0.01/0/4.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as BF46F1819EE) Mar 24 09:29:50 emp87 postfix/lmtp[413577]: BF46F1819EE: to=, relay=mail.simonandkate.net[/run/cyrus/socket/lmtp], delay=0.28, delays=0.01/0/0.01/0.26, dsn=2.1.5, status=sent (250 2.1.5 Ok SESSIONID=) - End message from Simon Wilson - It all makes sense now after (re-)reading all about address rewriting, aliases, myorigin, etc. Thanks Noel, Viktor and Matus for your patience. I now understand the reason having myorigin set to a virtual alias listed domain like simonandkate.net broke delivery. It did so *because my aliases were not FQ*. I.e. for the alias "si...@simonandkate.net simon", Postfix appended myorigin (append_at_myorigin (default: yes)), so it became si...@simonandkate.net and went nowhere. I now have it fully functioning, with virtual alias domains, etc., and I understand WHY it works... mydestination is now set to the default ($myhostname, localhost.$mydomain, localhost) PLUS a new one, mail.local: mydestination = $myhostname, localhost.$mydomain, localhost, mail.local virtual_alias_domains contains all the domain names to check for aliases virtual_alias_domains = simonandkate.lan, simonandkate.net, etc virtual_alias_maps is defined for containing all of the aliases: virtual_alias_maps = hash:/etc/postfix/virtual Aliases in /etc/postfix/virtual are now all in the form: si...@simonandkate.net simon@mail.local myhostname is per my externally visible resolvable MX and expected HELO: myhostname = mail.simonandkate.net mydomain is the default myhostname minus first component, so is effectively: mydomain = simonandkate.net myorigin is left at default ($myhostname) which resolves to be: myorigin = mail.simonandkate.net
Re: Setting up virtual alias domains and maps - failing to deliver
- Message from Noel Jones - Date: Tue, 23 Mar 2021 12:46:29 -0500 From: Noel Jones Reply-To: njo...@megan.vbhcs.org Subject: Re: Setting up virtual alias domains and maps - failing to deliver To: postfix-users@postfix.org On 3/23/2021 6:31 AM, Simon Wilson wrote: Changes: mydestination - removed, left as default Don't do that. Set it to something specific maybe "localhost.local" virtual_alias_domains = simonandkate.lan, simonandkate.net, etc... virtual_alias_maps = hash:/etc/postfix/virtual (and postmapped) Removed all virtual alias domain entries from aliases and run newaliases The domain alias appears valid: [root@emp87 postfix]# postmap -q ka...@simonandkate.net hash:/etc/postfix/virtual katie virtual aliases should always use a fully qualified email address, such as katie@localhost.local -- Noel Jones Combining postconf -d/-n, naming is: mydestination = $myhostname, localhost.$mydomain, localhost (i.e. default) myhostname = mail.simonandkate.net (specified in main.cf) mydomain = simonandkate.lan (i.e. default) myorigin = $myhostname (i.e default) ...that pans out to: mydestination = mail.simonandkate.net, localhost.simonandkate.lan, localhost myhostname = mail.simonandkate.net mydomain = simonandkate.lan myorigin = mail.simonandkate.net On your second point, 'virtual' is written like this: #simonandkate.net si...@simonandkate.net simon ...which I will correct, note questions later. I think the combination of naming and 'not-FQ aliases' is contributing to the following in pflogsumm reporting (extract for clarity): Recipients by message count --- 519 si...@simonandkate.net 40 si...@mail.simonandkate.net 98 howie...@howiesue.net 2 howie...@mail.simonandkate.net Mail is getting delivered but with address variation to the final destination. Note also the example at the bottom of this email, where d...@domwilson.net is getting changed to d...@mail.simonandkate.net Questions: 1. in virtual, do alias addresses always map out to $mydestination-resolvable addresses? I.e. does it need to be si...@simonandkate.net --> simon@something-in-$mydestination? 2. Is there a way to keep the address as the original recipient (as it was when the domains were under mydestination) for things like pflogsumm reporting? 3. Are there better options for my mydestination, myhostname, mydomain, myorigin which will assist? Thanks so much for the help Noel, Viktor, Matus. Simon Example: Mar 24 09:29:49 emp87 postfix/lmtp[413570]: BDED91819ED: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=5.4, delays=1.2/0.01/0/4.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as BF46F1819EE) Mar 24 09:29:50 emp87 postfix/lmtp[413577]: BF46F1819EE: to=, relay=mail.simonandkate.net[/run/cyrus/socket/lmtp], delay=0.28, delays=0.01/0/0.01/0.26, dsn=2.1.5, status=sent (250 2.1.5 Ok SESSIONID=) -- Simon Wilson M: 0400 12 11 16
Re: Setting up virtual alias domains and maps - failing to deliver
- Message from Simon Wilson - Date: Tue, 23 Mar 2021 21:31:29 +1000 From: Simon Wilson Reply-To: si...@simonandkate.net Subject: Re: Setting up virtual alias domains and maps - failing to deliver To: postfix-users@postfix.org - Message from Simon Wilson - Date: Tue, 23 Mar 2021 17:45:56 +1000 From: Simon Wilson Reply-To: si...@simonandkate.net Subject: Setting up virtual alias domains and maps - failing to deliver To: postfix-users@postfix.org Following recommendation from Viktor, trying to set up virtual alias domains. Previous arrangement works fine: domains in mydestination, local transport uses lmtp to cyrus. Here is an example of that arrangement - sent off to Amavis, then off to lmtp for successful delivery: Mar 23 14:25:35 emp87 postfix/lmtp[327725]: E85581819E5: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=6.9, delays=2.3/0/0/4.6, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 752C71819E6) Mar 23 14:25:35 emp87 postfix/lmtp[327851]: 752C71819E6: to=, relay=mail.simonandkate.net[/run/cyrus/socket/lmtp], delay=0.23, delays=0.01/0/0/0.22, dsn=2.1.5, status=sent (250 2.1.5 Ok SESSIONID=) Changes: mydestination - removed, left as default virtual_alias_domains = simonandkate.lan, simonandkate.net, etc... virtual_alias_maps = hash:/etc/postfix/virtual (and postmapped) Removed all virtual alias domain entries from aliases and run newaliases The domain alias appears valid: [root@emp87 postfix]# postmap -q ka...@simonandkate.net hash:/etc/postfix/virtual katie Save changes, postfix reload Mar 23 14:46:48 emp87 postfix/lmtp[329453]: ED7531819E6: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=11, delays=2.4/0/0/8.6, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 371701819EA) Mar 23 14:46:48 emp87 postfix/error[329457]: 371701819EA: to=, relay=none, delay=0.02, delays=0.01/0/0/0.01, dsn=5.1.1, status=bounced (User unknown in virtual alias table) So it initially accepts the email, sends to amavis, gets it back, and then fails to deliver, bouncing with 'relay=none' and 'User unknown in virtual alias table'. How do I get that second step to deliver to lmtp?? I'm obviously doing something fundamentally wrong with the setup, but I can't pick it... so I have reverted back to using domains in mydestination for now... Simon I've scaled back, taking on board Noel's suggestion of just using virtual_alias_maps for the exceptions I need to rewrite, but *not* moving any of the hosted domains from mydestination to virtual_alias_domains. That achieves what I need and works as expected. I am still interested to know how to achieve the full virtual_alias_domains setup if anyone can help on my problems noted above. Thanks Simon I worked it out. It was myorigin being one of the aliases - from postconf -n below: myorigin = simonandkate.net Removed that and it all started to work. Simon [root@emp87 virtual-alias]# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases, hash:/etc/postfix/report_aliases bounce_queue_lifetime = 3d bounce_template_file = /etc/postfix/bounce.cf broken_sasl_auth_clients = yes command_directory = /usr/sbin compatibility_level = 0 content_filter = amavisfeed:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 delay_warning_time = 2h disable_vrfy_command = yes html_directory = no inet_protocols = ipv4 local_destination_concurrency_limit = 5 local_destination_recipient_limit = 300 mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_transport = lmtp:unix:/run/cyrus/socket/lmtp mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man masquerade_domains = !system.simonandkate.net, simonandkate.net, simonandkate.lan maximal_queue_lifetime = 3d message_size_limit = 26214400 milter_default_action = accept mua_client_restrictions = mua_helo_restrictions = mua_sender_restrictions = myhostname = mail.simonandkate.net mynetworks = 127.0.0.0/8, 192.168.1.0/24, 103.16.129.171 myorigin = simonandkate.net newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = $smtpd_milters policyd-spf_time_limit = 3600 postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr postscreen_blacklist_action = drop postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.mailspike.net*2 b.barracudacentral.org*2 bl.spameatingmonkey.net bl.spamcop.net dnsbl.sorbs.net hostkarma.junkemailfilter.com=127.0.0.2 hostkarma.junkemailfilter.com=127.0.0.4 hostkarma.junkemailfilter.com=127.0.1.2 psbl.surriel.com swl.spamhaus.org*-4 list.dnswl.org=127.0.[2..15].0*-2 list.dnswl.org=127.
Re: Sequence of checks for virtual alias
- Message from Matus UHLAR - fantomas - Date: Tue, 23 Mar 2021 12:15:03 +0100 From: Matus UHLAR - fantomas Subject: Re: Sequence of checks for virtual alias To: postfix-users@postfix.org On 23.03.21 14:24, Simon Wilson wrote: I have some user email addresses (in domains that are specified as virtual_alias_domain) listed in /etc/postfix/recipient_access and configured to return 550 Mailbox no longer in use. Do I still need to list them in virtual_alias_maps, or is check_recipient_access processed first? you can keep it in reject_unlisted_recipient. - End message from Matus UHLAR - fantomas - Thanks, that was a useful pointer... :) Further reading tells me that if reject_unlisted_recipient is not specified in my smtpd_recipient_restrictions it is processed after the restrictions listed. So: an email to one of my users rejected with 550 by check_recipient_access happens before reaching reject_unlisted_recipient. I believe I do *NOT* need to have the user listed in virtual_alias_maps as a valid user, as the inbound email will never reach the reject_unlisted_recipient check - correct? Simon. -- Simon Wilson M: 0400 12 11 16
Re: Setting up virtual alias domains and maps - failing to deliver
- Message from Simon Wilson - Date: Tue, 23 Mar 2021 17:45:56 +1000 From: Simon Wilson Reply-To: si...@simonandkate.net Subject: Setting up virtual alias domains and maps - failing to deliver To: postfix-users@postfix.org Following recommendation from Viktor, trying to set up virtual alias domains. Previous arrangement works fine: domains in mydestination, local transport uses lmtp to cyrus. Here is an example of that arrangement - sent off to Amavis, then off to lmtp for successful delivery: Mar 23 14:25:35 emp87 postfix/lmtp[327725]: E85581819E5: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=6.9, delays=2.3/0/0/4.6, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 752C71819E6) Mar 23 14:25:35 emp87 postfix/lmtp[327851]: 752C71819E6: to=, relay=mail.simonandkate.net[/run/cyrus/socket/lmtp], delay=0.23, delays=0.01/0/0/0.22, dsn=2.1.5, status=sent (250 2.1.5 Ok SESSIONID=) Changes: mydestination - removed, left as default virtual_alias_domains = simonandkate.lan, simonandkate.net, etc... virtual_alias_maps = hash:/etc/postfix/virtual (and postmapped) Removed all virtual alias domain entries from aliases and run newaliases The domain alias appears valid: [root@emp87 postfix]# postmap -q ka...@simonandkate.net hash:/etc/postfix/virtual katie Save changes, postfix reload Mar 23 14:46:48 emp87 postfix/lmtp[329453]: ED7531819E6: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=11, delays=2.4/0/0/8.6, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 371701819EA) Mar 23 14:46:48 emp87 postfix/error[329457]: 371701819EA: to=, relay=none, delay=0.02, delays=0.01/0/0/0.01, dsn=5.1.1, status=bounced (User unknown in virtual alias table) So it initially accepts the email, sends to amavis, gets it back, and then fails to deliver, bouncing with 'relay=none' and 'User unknown in virtual alias table'. How do I get that second step to deliver to lmtp?? I'm obviously doing something fundamentally wrong with the setup, but I can't pick it... so I have reverted back to using domains in mydestination for now... Simon I've scaled back, taking on board Noel's suggestion of just using virtual_alias_maps for the exceptions I need to rewrite, but *not* moving any of the hosted domains from mydestination to virtual_alias_domains. That achieves what I need and works as expected. I am still interested to know how to achieve the full virtual_alias_domains setup if anyone can help on my problems noted above. Thanks Simon [root@emp87 virtual-alias]# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases, hash:/etc/postfix/report_aliases bounce_queue_lifetime = 3d bounce_template_file = /etc/postfix/bounce.cf broken_sasl_auth_clients = yes command_directory = /usr/sbin compatibility_level = 0 content_filter = amavisfeed:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 delay_warning_time = 2h disable_vrfy_command = yes html_directory = no inet_protocols = ipv4 local_destination_concurrency_limit = 5 local_destination_recipient_limit = 300 mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_transport = lmtp:unix:/run/cyrus/socket/lmtp mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man masquerade_domains = !system.simonandkate.net, simonandkate.net, simonandkate.lan maximal_queue_lifetime = 3d message_size_limit = 26214400 milter_default_action = accept mua_client_restrictions = mua_helo_restrictions = mua_sender_restrictions = myhostname = mail.simonandkate.net mynetworks = 127.0.0.0/8, 192.168.1.0/24, 103.16.129.171 myorigin = simonandkate.net newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = $smtpd_milters policyd-spf_time_limit = 3600 postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr postscreen_blacklist_action = drop postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.mailspike.net*2 b.barracudacentral.org*2 bl.spameatingmonkey.net bl.spamcop.net dnsbl.sorbs.net hostkarma.junkemailfilter.com=127.0.0.2 hostkarma.junkemailfilter.com=127.0.0.4 hostkarma.junkemailfilter.com=127.0.1.2 psbl.surriel.com swl.spamhaus.org*-4 list.dnswl.org=127.0.[2..15].0*-2 list.dnswl.org=127.0.[2..15].1*-3 list.dnswl.org=127.0.[2..15].[2..3]*-4 wl.mailspike.net=127.0.0.[17;18]*-1 wl.mailspike.net=127.0.0.[19;20]*-2 hostkarma.junkemailfilter.com=127.0.0.1*-1 postscreen_dnsbl_threshold = 3 postscreen_greet_action = enforce queue_directory = /var/spool/postfix recipient_delimiter = + sender_canonical_maps = hash:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail.postfix setgid_group = post
Setting up virtual alias domains and maps - failing to deliver
Following recommendation from Viktor, trying to set up virtual alias domains. Previous arrangement works fine: domains in mydestination, local transport uses lmtp to cyrus. Here is an example of that arrangement - sent off to Amavis, then off to lmtp for successful delivery: Mar 23 14:25:35 emp87 postfix/lmtp[327725]: E85581819E5: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=6.9, delays=2.3/0/0/4.6, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 752C71819E6) Mar 23 14:25:35 emp87 postfix/lmtp[327851]: 752C71819E6: to=, relay=mail.simonandkate.net[/run/cyrus/socket/lmtp], delay=0.23, delays=0.01/0/0/0.22, dsn=2.1.5, status=sent (250 2.1.5 Ok SESSIONID=) Changes: mydestination - removed, left as default virtual_alias_domains = simonandkate.lan, simonandkate.net, etc... virtual_alias_maps = hash:/etc/postfix/virtual (and postmapped) Removed all virtual alias domain entries from aliases and run newaliases The domain alias appears valid: [root@emp87 postfix]# postmap -q ka...@simonandkate.net hash:/etc/postfix/virtual katie Save changes, postfix reload Mar 23 14:46:48 emp87 postfix/lmtp[329453]: ED7531819E6: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=11, delays=2.4/0/0/8.6, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 371701819EA) Mar 23 14:46:48 emp87 postfix/error[329457]: 371701819EA: to=, relay=none, delay=0.02, delays=0.01/0/0/0.01, dsn=5.1.1, status=bounced (User unknown in virtual alias table) So it initially accepts the email, sends to amavis, gets it back, and then fails to deliver, bouncing with 'relay=none' and 'User unknown in virtual alias table'. How do I get that second step to deliver to lmtp?? I'm obviously doing something fundamentally wrong with the setup, but I can't pick it... so I have reverted back to using domains in mydestination for now... Simon [root@emp87 virtual-alias]# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases, hash:/etc/postfix/report_aliases bounce_queue_lifetime = 3d bounce_template_file = /etc/postfix/bounce.cf broken_sasl_auth_clients = yes command_directory = /usr/sbin compatibility_level = 0 content_filter = amavisfeed:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 delay_warning_time = 2h disable_vrfy_command = yes html_directory = no inet_protocols = ipv4 local_destination_concurrency_limit = 5 local_destination_recipient_limit = 300 mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_transport = lmtp:unix:/run/cyrus/socket/lmtp mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man masquerade_domains = !system.simonandkate.net, simonandkate.net, simonandkate.lan maximal_queue_lifetime = 3d message_size_limit = 26214400 milter_default_action = accept mua_client_restrictions = mua_helo_restrictions = mua_sender_restrictions = myhostname = mail.simonandkate.net mynetworks = 127.0.0.0/8, 192.168.1.0/24, 103.16.129.171 myorigin = simonandkate.net newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = $smtpd_milters policyd-spf_time_limit = 3600 postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr postscreen_blacklist_action = drop postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.mailspike.net*2 b.barracudacentral.org*2 bl.spameatingmonkey.net bl.spamcop.net dnsbl.sorbs.net hostkarma.junkemailfilter.com=127.0.0.2 hostkarma.junkemailfilter.com=127.0.0.4 hostkarma.junkemailfilter.com=127.0.1.2 psbl.surriel.com swl.spamhaus.org*-4 list.dnswl.org=127.0.[2..15].0*-2 list.dnswl.org=127.0.[2..15].1*-3 list.dnswl.org=127.0.[2..15].[2..3]*-4 wl.mailspike.net=127.0.0.[17;18]*-1 wl.mailspike.net=127.0.0.[19;20]*-2 hostkarma.junkemailfilter.com=127.0.0.1*-1 postscreen_dnsbl_threshold = 3 postscreen_greet_action = enforce queue_directory = /var/spool/postfix recipient_delimiter = + sender_canonical_maps = hash:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_client_restrictions = smtpd_data_restrictions = reject_unauth_pipelining permit smtpd_discard_ehlo_keywords = silent-discard, dsn smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_milters = inet:127.0.0.1:8893 smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/client_checks, permit_mynetworks, check_recipient_access hash:/etc/postfix/recipient_access, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_do
Sequence of checks for virtual alias
I have some user email addresses (in domains that are specified as virtual_alias_domain) listed in /etc/postfix/recipient_access and configured to return 550 Mailbox no longer in use. Do I still need to list them in virtual_alias_maps, or is check_recipient_access processed first? Simon smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/client_checks, permit_mynetworks, check_recipient_access hash:/etc/postfix/recipient_access, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org, check_policy_service unix:private/policyd-spf permit -- Simon Wilson M: 0400 12 11 16
Re: Rewrite user xxx in a specific local domain
- Message from Simon Wilson - Date: Tue, 23 Mar 2021 11:23:58 +1000 From: Simon Wilson Reply-To: si...@simonandkate.net Subject: Re: Rewrite user xxx in a specific local domain To: postfix-users@postfix.org - Message from Viktor Dukhovni - Date: Mon, 22 Mar 2021 20:25:01 -0400 From: Viktor Dukhovni Reply-To: postfix-users@postfix.org Subject: Re: Rewrite user xxx in a specific local domain To: postfix-users@postfix.org On Tue, Mar 23, 2021 at 10:16:31AM +1000, Simon Wilson wrote: I run multiple local domains, and for the first time need to have the same username in two of them go to different local accounts. I.e. my son has a local (LDAP) account "dom". Mail sent to dom@his-personal-domain reaches that mailbox fine. He now has a business domain, and I have setup a LDAP account dom.w, so dom.w@his-business-domain works fine. What I want to be able to do is rewrite dom@his-business-domain when it is received so it delivers to dom.w@his-business-domain. From what I read at http://www.postfix.org/aliases.5.html I don't think I can do this with aliases directly, as the "name" component of the alias line is a local address with no domain part. What I need to have happen (written in alias-style format) is this: dom@his-personal-domain: dom # this works fine already dom.w@his-business-domain: dom.w # this works fine already dom@his-business-domain: dom.w # this is the bit I want to add How do I achieve this with rewriting or aliasing, i.e. without having to move to virtual domains? You don't have to move to "virtual domains". The virtual(5) aliases table applies to all recipient addresses, regardless of "address class". In fact you should avoid local aliases(5) for address to address rewriting, and do all such rewriting in virtual(5) instead, using the aliases(5) file only for "|command", "/some/file" or ":include:" aliases. That said, I recommend making *all* you real domains be virtual alias domains, and using only "localhost.localdomain" or similar as the only domain in mydestination, with all addresses intended for local delivery rewritten into that domain as appropriate. In some cases I go further and add access(5) rules that block direct remote addressing of that domain, so that all inbound mail has to come through one of the virtual alias domains. So you can certainly migrate to virtual alias domains, which is a better model. - End message from Viktor Dukhovni - Thanks Viktor and Noel. Reading http://www.postfix.org/VIRTUAL_README.html, what I currently have is "As simple as can be: shared domains, UNIX system accounts": /etc/postfix/main.cf: mydestination = $myhostname, localhost.$mydomain ... simonandkate.net,... etc ...with any required aliases in /etc/aliases, e.g.: root: si...@simonandkate.net si: si...@simonandkate.net etc. Noel's response is the 'quickest way to achieve what I want': - insert "dom@business-domain dom.w@business-domain" into /etc/postfix/virtual - postmap /etc/postfix/virtual & postfix reload - I assume this works because of: [root@emp87 postfix]# postconf -n | grep virtual_transport [root@emp87 postfix]# postconf -d | grep virtual_transport ... virtual_transport = virtual - This keeps me on "As simple as can be: shared domains, UNIX system accounts", but uses the virtual transport to resolve my requirement for this one address only. I read Viktor's response as a step further, taking me to "Postfix virtual ALIAS example: separate domains, UNIX system accounts" (http://www.postfix.org/VIRTUAL_README.html): - mydestination = $myhostname, localhost.$mydomain # no hosted domains in here - virtual_alias_domains = simonandkate.net, ... # all hosted domains here - virtual_alias_maps = hash:/etc/postfix/virtual - have all hosted email addresses mapped to locals in /etc/postfix/virtual: si...@simonandkate.net simon s...@simonandkate.net simon dom@personal-domain dom dom@business-domain dom.w etc. Questions on 'virtual': 1. leave local aliases in /etc/aliases? e.g. postmaster: root; virusalert: root; root: si...@simonandkate.net, etc.? 2. looks like virtual multiple recipients works per aliases, e.g. "voicem...@simonandkate.net si...@simonandkate.net, us...@simonandkate.net"? 3. http://www.postfix.org/virtual.5.html says that each virtual alias domain needs a line with no addresses: /etc/postfix/virtual: virtual-alias.domain anything (right-hand content does not matter) <- this line - postmaster@virtual-alias.domain postmaster user1@virtual-alias.domain address1 user2@virtual-alias.domain address2, address3 The virtual-alias.domain anything entry is required for a virtual alias
Re: Rewrite user xxx in a specific local domain
- Message from Viktor Dukhovni - Date: Mon, 22 Mar 2021 20:25:01 -0400 From: Viktor Dukhovni Reply-To: postfix-users@postfix.org Subject: Re: Rewrite user xxx in a specific local domain To: postfix-users@postfix.org On Tue, Mar 23, 2021 at 10:16:31AM +1000, Simon Wilson wrote: I run multiple local domains, and for the first time need to have the same username in two of them go to different local accounts. I.e. my son has a local (LDAP) account "dom". Mail sent to dom@his-personal-domain reaches that mailbox fine. He now has a business domain, and I have setup a LDAP account dom.w, so dom.w@his-business-domain works fine. What I want to be able to do is rewrite dom@his-business-domain when it is received so it delivers to dom.w@his-business-domain. From what I read at http://www.postfix.org/aliases.5.html I don't think I can do this with aliases directly, as the "name" component of the alias line is a local address with no domain part. What I need to have happen (written in alias-style format) is this: dom@his-personal-domain:dom # this works fine already dom.w@his-business-domain: dom.w # this works fine already dom@his-business-domain:dom.w # this is the bit I want to add How do I achieve this with rewriting or aliasing, i.e. without having to move to virtual domains? You don't have to move to "virtual domains". The virtual(5) aliases table applies to all recipient addresses, regardless of "address class". In fact you should avoid local aliases(5) for address to address rewriting, and do all such rewriting in virtual(5) instead, using the aliases(5) file only for "|command", "/some/file" or ":include:" aliases. That said, I recommend making *all* you real domains be virtual alias domains, and using only "localhost.localdomain" or similar as the only domain in mydestination, with all addresses intended for local delivery rewritten into that domain as appropriate. In some cases I go further and add access(5) rules that block direct remote addressing of that domain, so that all inbound mail has to come through one of the virtual alias domains. So you can certainly migrate to virtual alias domains, which is a better model. - End message from Viktor Dukhovni - Thanks Viktor and Noel. Reading http://www.postfix.org/VIRTUAL_README.html, what I currently have is "As simple as can be: shared domains, UNIX system accounts": /etc/postfix/main.cf: mydestination = $myhostname, localhost.$mydomain ... simonandkate.net,... etc ...with any required aliases in /etc/aliases, e.g.: root: si...@simonandkate.net si: si...@simonandkate.net etc. Noel's response is the 'quickest way to achieve what I want': - insert "dom@business-domain dom.w@business-domain" into /etc/postfix/virtual - postmap /etc/postfix/virtual & postfix reload - I assume this works because of: [root@emp87 postfix]# postconf -n | grep virtual_transport [root@emp87 postfix]# postconf -d | grep virtual_transport ... virtual_transport = virtual - This keeps me on "As simple as can be: shared domains, UNIX system accounts", but uses the virtual transport to resolve my requirement for this one address only. I read Viktor's response as a step further, taking me to "Postfix virtual ALIAS example: separate domains, UNIX system accounts" (http://www.postfix.org/VIRTUAL_README.html): - mydestination = $myhostname, localhost.$mydomain # no hosted domains in here - virtual_alias_domains = simonandkate.net, ... # all hosted domains here - virtual_alias_maps= hash:/etc/postfix/virtual - have all hosted email addresses mapped to locals in /etc/postfix/virtual: si...@simonandkate.net simon s...@simonandkate.net simon dom@personal-domain dom dom@business-domain dom.w etc. Questions on 'virtual': 1. leave local aliases in /etc/aliases? e.g. postmaster: root; virusalert: root; root: si...@simonandkate.net, etc.? 2. looks like virtual multiple recipients works per aliases, e.g. "voicem...@simonandkate.net si...@simonandkate.net, us...@simonandkate.net"? 3. http://www.postfix.org/virtual.5.html says that each virtual alias domain needs a line with no addresses: /etc/postfix/virtual: virtual-alias.domainanything (right-hand content does not matter) <- this line - postmaster@virtual-alias.domain postmaster user1@virtual-alias.domain address1 user2@virtual-alias.domain address2, address3 The virtual-alias.domain anything entry is required for a virtual alias domain. Without this entry, mail is rejected with "relay access denied", or bounces with "mail loops back to myself". ...yet this requirement for "virtual-alias.domain
Rewrite user xxx in a specific local domain
I run multiple local domains, and for the first time need to have the same username in two of them go to different local accounts. I.e. my son has a local (LDAP) account "dom". Mail sent to dom@his-personal-domain reaches that mailbox fine. He now has a business domain, and I have setup a LDAP account dom.w, so dom.w@his-business-domain works fine. What I want to be able to do is rewrite dom@his-business-domain when it is received so it delivers to dom.w@his-business-domain. From what I read at http://www.postfix.org/aliases.5.html I don't think I can do this with aliases directly, as the "name" component of the alias line is a local address with no domain part. What I need to have happen (written in alias-style format) is this: dom@his-personal-domain:dom # this works fine already dom.w@his-business-domain: dom.w # this works fine already dom@his-business-domain:dom.w # this is the bit I want to add How do I achieve this with rewriting or aliasing, i.e. without having to move to virtual domains? Simon -- Simon Wilson M: 0400 12 11 16
Re: upgrade 2.10 - 3.3 config compatibility
- Message from Viktor Dukhovni - Date: Mon, 22 Mar 2021 00:13:00 -0400 From: Viktor Dukhovni Reply-To: postfix-users@postfix.org Subject: Re: upgrade 2.10 - 3.3 config compatibility To: postfix-users@postfix.org On Mon, Mar 22, 2021 at 12:32:18PM +1000, Simon Wilson wrote: I have temporarily set it at 0 after reading http://www.postfix.org/COMPATIBILITY_README.html to ensure that I pick up in logging if/when backwards-compatibility is triggered by the legacy settings as follows (from http://www.postfix.org/COMPATIBILITY_README.html): Logged with compatibility_level < 1: **Using backwards-compatible default setting append_dot_mydomain=yes** Using backwards-compatible default setting chroot=y This will only be logged if you have not explicitly set a value for "append_dot_mydomain". Logged with compatibility_level < 2: Using backwards-compatible default setting "smtpd_relay_restrictions = (empty)" Using backwards-compatible default setting mynetworks_style=subnet **Using backwards-compatible default setting relay_domains=$mydestination** Using backwards-compatible default setting smtputf8_enable=no Ditto. My advice is generally to set "relay_domains" empty, or at least to not include "relay_domains" in "parent_domain_matches_subdomains". And of course set mynetworks explicitly, which makes "mynetworks_style" irrelevant, but best to set that to "host". //Main.cf: # comment out, compat to 0, and monitor # append_dot_mydomain = yes # relay_domains = $mydestination compatibility_level = 0 //postconf -n: [root@emp87 log]# postconf -n | grep comp compatibility_level = 0 [root@emp87 log]# postconf -n | grep append_dot_mydomain [root@emp87 log]# postconf -n | grep relay_domains [root@emp87 log]# postconf -n | grep my_networks [root@emp87 log]# postconf -n | grep "mynetworks =" mynetworks = 127.0.0.0/8, 192.168.1.0/24, 103.16.129.171 For the smtpd_relay_restrictions, set: # Typically, there's no SASL on port 25, and for submission, # you'd should have an explicit override in master.cf # smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination but given that prior to 3.6 the order of relay vs. recipient restrictions is not as expected, also do the same at the top of smtpd_recipient_restrictions for now. smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination ... RBLs, ... for inbound mail ... [root@emp87 log]# postconf -n | grep "smtpd_relay" smtpd_relay_restrictions = [root@emp87 log]# postconf -n | grep "smtpd_recip" smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/client_checks, permit_mynetworks, check_recipient_access hash:/etc/postfix/recipient_access, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org, check_policy_service unix:private/policyd-spf permit Submission port is only accessible on internal network from webmail host, but has: # submission port 587 - TLS and SASL submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions=$mua_client_restrictions -o smtpd_helo_restrictions=$mua_helo_restrictions -o smtpd_sender_restrictions=$mua_sender_restrictions -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject_sender_login_mismatch,reject -o cleanup_service_name=auth-cleanup -o content_filter=amavisfeed:[127.0.0.1]:10026 Complete postconf -n is at the bottom of this email. With the items I need to watch for (emphasis added ** **) that means I need it to be less than 1. Once I am confident of the outcome I'll set to 2. When you upgrade to Postfix 3.6, and set the compatibility level to 3.6, you can simplify the recipient restrictions to just the anti-abuse rules (privided the relay restrictions are all set), Noted, thank you. - End message from Viktor Dukhovni - [root@emp87 log]# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases, hash:/etc/postfix/report_aliases bounce_queue_lifetime = 3d bounce_template_file = /etc/postfix/bounce.cf broken_sasl_auth_clients = yes canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin compatibility_level = 0 content_filter = amavisfeed:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PA
Re: Double-bounce to ISP's server
- Message from Phil Biggs - Date: Mon, 22 Mar 2021 14:34:44 +1100 From: Phil Biggs Subject: Re: Double-bounce to ISP's server To: postfix-users@postfix.org Monday, March 22, 2021, 1:49:53 PM, Simon Wilson wrote: Your IP address resolves back to aussiebb: You need Aussie BB to setup your reverse DNS. I am with Aussie BB too: Thanks, Simon. Now I see it! I'm using Namecheap's name servers for my domain, with dynamic DNS updates managed by pfSense. (IP hasn't changed since I joined ABB though.) Everything outbound is smart-hosted through mail.aussiebroadband so no need for the rDNS. Regarding: relay_domains = pjb.cc relayhost = mail.aussiebroadband.com.au My transport file has: pjb.cc smtp:[192.168.11.3] Thanks again, Phil - End message from Phil Biggs - Others far more well-versed in postfix will advise on the config. On ABB... I pay the $5 a month for a static IP, and I have outbound port 25 open (ask them nicely) and rDNS set. Means I run self-contained for postfix - inbound and outbound. Simon -- Simon Wilson M: 0400 12 11 16
Re: Double-bounce to ISP's server
- Message from Simon Wilson - Date: Mon, 22 Mar 2021 12:49:53 +1000 From: Simon Wilson Reply-To: si...@simonandkate.net Subject: Re: Double-bounce to ISP's server To: postfix-users@postfix.org - Message from Phil Biggs - Date: Mon, 22 Mar 2021 13:35:12 +1100 From: Phil Biggs Subject: Double-bounce to ISP's server To: postfix-users@postfix.org Hello all, I'm running the postfix-sasl-3.5.8,1 pkg on FreeBSD 12.2-RELEASE-p4 GENERIC Yesterday I plugged my public IP into the mxtoolbox diags page and my logs recorded this: Mar 21 14:50:35 postfix/postscreen[3804]: CONNECT from [18.205.72.90]:43471 to [192.168.11.2]:25 Mar 21 14:50:41 postfix/postscreen[3804]: PASS NEW [18.205.72.90]:43471 Mar 21 14:50:43 postfix/smtpd[3806]: connect from keeper-us-east-1c.mxtoolbox.com[18.205.72.90] Mar 21 14:50:45 postfix/cleanup[3810]: 05625DF30B: message-id=<20210321035045.05625df...@postfix.pjb.cc> Mar 21 14:50:45 postfix/qmgr[735]: 05625DF30B: from=, size=233, nrcpt=1 (queue active) Mar 21 14:50:45 postfix/smtp[3811]: Trusted TLS connection established to mail.aussiebroadband.com.au[121.200.0.25]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 Mar 21 14:50:46 postfix/smtp[3811]: 05625DF30B: to=, relay=mail.aussiebroadband.com.au[121.200.0.25]:25, delay=1.1, delays=0.01/0.02/0.99/0.03, dsn=2.1.5, status=deliverable (250 2.1.5 Ok) Mar 21 14:50:46 postfix/qmgr[735]: 05625DF30B: removed Mar 21 14:50:48 postfix/smtpd[3806]: NOQUEUE: reject: RCPT from keeper-us-east-1c.mxtoolbox.com[18.205.72.90]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= Mar 21 14:50:48 postfix/smtpd[3806]: disconnect from keeper-us-east-1c.mxtoolbox.com[18.205.72.90] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4 The relay was rejected but I've never seen an attempted relay generate a probe to my ISP's mail server before. Just curious as to how/why this probe would happen. Something wrong in my configuration? Many thanks, Phil Your IP address resolves back to aussiebb: [root@emp87 ~]# dig pjb.cc mx ; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> pjb.cc mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20478 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d0513ee68cc2ce4ef2bc0f8760580554a7ad92184239a6ba (good) ;; QUESTION SECTION: ;pjb.cc.IN MX ;; ANSWER SECTION: pjb.cc. 1091IN MX 10 mail.pjb.cc. [root@emp87 ~]# nslookup mail.pjb.cc Server: 192.168.1.145 Address:192.168.1.145#53 Non-authoritative answer: Name: mail.pjb.cc Address: 180.150.6.110 [root@emp87 ~]# nslookup 180.150.6.110 110.6.150.180.IN-ADDR.ARPA name = 180-150-6-110.b49606.syd.nbn.aussiebb.net You need Aussie BB to setup your reverse DNS. I am with Aussie BB too: [root@emp87 ~]# dig simonandkate.net mx ; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> simonandkate.net mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42204 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 3, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: bc9bdebc279b88fc955229e6605805a086b8818a7f8a1be0 (good) ;; QUESTION SECTION: ;simonandkate.net. IN MX ;; ANSWER SECTION: simonandkate.net. 5333IN MX 10 mail.simonandkate.net. [root@emp87 ~]# nslookup mail.simonandkate.net 1.1.1.1 Server: 1.1.1.1 Address:1.1.1.1#53 Non-authoritative answer: Name: mail.simonandkate.net Address: 119.18.34.29 [root@emp87 ~]# nslookup 119.18.34.29 29.34.18.119.IN-ADDR.ARPA name = mail.simonandkate.net. Simon - End message from Simon Wilson - Phil, Your config has: relay_domains = pjb.cc relayhost = mail.aussiebroadband.com.au From the postfix doco: - $relay_domains: domains that match $relay_domains are delivered with the $relay_transport mail delivery transport. ...and... - $relay_transport: The default mail delivery transport and next-hop destination for remote delivery to domains listed with $relay_domains. In order of decreasing precedence, the nexthop destination is taken from $relay_transport, $sender_dependent_relayhost_maps, $relayhost, or from the recipient domain. You are sending email for pjb.cc on to Aussie's mail host (which is accepting it). What are you aiming to do with email for pjb.cc? -- Simon Wilson M: 0400 12 11 16
Re: Double-bounce to ISP's server
- Message from Phil Biggs - Date: Mon, 22 Mar 2021 13:35:12 +1100 From: Phil Biggs Subject: Double-bounce to ISP's server To: postfix-users@postfix.org Hello all, I'm running the postfix-sasl-3.5.8,1 pkg on FreeBSD 12.2-RELEASE-p4 GENERIC Yesterday I plugged my public IP into the mxtoolbox diags page and my logs recorded this: Mar 21 14:50:35 postfix/postscreen[3804]: CONNECT from [18.205.72.90]:43471 to [192.168.11.2]:25 Mar 21 14:50:41 postfix/postscreen[3804]: PASS NEW [18.205.72.90]:43471 Mar 21 14:50:43 postfix/smtpd[3806]: connect from keeper-us-east-1c.mxtoolbox.com[18.205.72.90] Mar 21 14:50:45 postfix/cleanup[3810]: 05625DF30B: message-id=<20210321035045.05625df...@postfix.pjb.cc> Mar 21 14:50:45 postfix/qmgr[735]: 05625DF30B: from=, size=233, nrcpt=1 (queue active) Mar 21 14:50:45 postfix/smtp[3811]: Trusted TLS connection established to mail.aussiebroadband.com.au[121.200.0.25]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 Mar 21 14:50:46 postfix/smtp[3811]: 05625DF30B: to=, relay=mail.aussiebroadband.com.au[121.200.0.25]:25, delay=1.1, delays=0.01/0.02/0.99/0.03, dsn=2.1.5, status=deliverable (250 2.1.5 Ok) Mar 21 14:50:46 postfix/qmgr[735]: 05625DF30B: removed Mar 21 14:50:48 postfix/smtpd[3806]: NOQUEUE: reject: RCPT from keeper-us-east-1c.mxtoolbox.com[18.205.72.90]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= Mar 21 14:50:48 postfix/smtpd[3806]: disconnect from keeper-us-east-1c.mxtoolbox.com[18.205.72.90] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4 The relay was rejected but I've never seen an attempted relay generate a probe to my ISP's mail server before. Just curious as to how/why this probe would happen. Something wrong in my configuration? Many thanks, Phil Your IP address resolves back to aussiebb: [root@emp87 ~]# dig pjb.cc mx ; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> pjb.cc mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20478 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d0513ee68cc2ce4ef2bc0f8760580554a7ad92184239a6ba (good) ;; QUESTION SECTION: ;pjb.cc.IN MX ;; ANSWER SECTION: pjb.cc. 1091IN MX 10 mail.pjb.cc. [root@emp87 ~]# nslookup mail.pjb.cc Server: 192.168.1.145 Address:192.168.1.145#53 Non-authoritative answer: Name: mail.pjb.cc Address: 180.150.6.110 [root@emp87 ~]# nslookup 180.150.6.110 110.6.150.180.IN-ADDR.ARPA name = 180-150-6-110.b49606.syd.nbn.aussiebb.net You need Aussie BB to setup your reverse DNS. I am with Aussie BB too: [root@emp87 ~]# dig simonandkate.net mx ; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> simonandkate.net mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42204 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 3, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: bc9bdebc279b88fc955229e6605805a086b8818a7f8a1be0 (good) ;; QUESTION SECTION: ;simonandkate.net. IN MX ;; ANSWER SECTION: simonandkate.net. 5333IN MX 10 mail.simonandkate.net. [root@emp87 ~]# nslookup mail.simonandkate.net 1.1.1.1 Server: 1.1.1.1 Address:1.1.1.1#53 Non-authoritative answer: Name: mail.simonandkate.net Address: 119.18.34.29 [root@emp87 ~]# nslookup 119.18.34.29 29.34.18.119.IN-ADDR.ARPA name = mail.simonandkate.net. Simon -- Simon Wilson M: 0400 12 11 16
Re: upgrade 2.10 - 3.3 config compatibility
- Message from Viktor Dukhovni - Date: Sun, 21 Mar 2021 21:15:36 -0400 From: Viktor Dukhovni Reply-To: postfix-users@postfix.org Subject: Re: upgrade 2.10 - 3.3 config compatibility To: postfix-users@postfix.org On Mon, Mar 22, 2021 at 10:17:16AM +1000, Simon Wilson wrote: I've removed mynetworks_style based on improved knowledge as noted above; commented out append_dot_mydomain and relay_domains, have set compatibility_level to 0, and will monitor for messages. The right compatibility level to set after you're comfortable with your main.cf file is the one found in the stock main.cf file for the Postfix version in question. With Postfix 3.5 that's "2". Thanks Viktor, yes that is the plan from my reading and understanding. Noting I'm on 3.3, although 2 is also in 3.3 stock main.cf. I have temporarily set it at 0 after reading http://www.postfix.org/COMPATIBILITY_README.html to ensure that I pick up in logging if/when backwards-compatibility is triggered by the legacy settings as follows (from http://www.postfix.org/COMPATIBILITY_README.html): Logged with compatibility_level < 1: **Using backwards-compatible default setting append_dot_mydomain=yes** Using backwards-compatible default setting chroot=y Logged with compatibility_level < 2: Using backwards-compatible default setting "smtpd_relay_restrictions = (empty)" Using backwards-compatible default setting mynetworks_style=subnet **Using backwards-compatible default setting relay_domains=$mydestination** Using backwards-compatible default setting smtputf8_enable=no With the items I need to watch for (emphasis added ** **) that means I need it to be less than 1. Once I am confident of the outcome I'll set to 2. Simon. -- Simon Wilson M: 0400 12 11 16
Re: upgrade 2.10 - 3.3 config compatibility
- Message from Matus UHLAR - fantomas - Date: Sun, 21 Mar 2021 15:26:12 +0100 From: Matus UHLAR - fantomas Subject: Re: upgrade 2.10 - 3.3 config compatibility To: postfix-users@postfix.org I have a well established 2.10 Postfix instance on 2.10 (CentOS7) which is to be migrated to a new machine running Postfix 3.3 (on RHEL8). I've been reading http://www.postfix.org/COMPATIBILITY_README.html, and from what I can see the backward compatibility issues I may run into are (with existing config from 2.10) - append_dot_mydomain (not explicitly set on 2.10, i.e. implicitly "yes") - chroot (explicitly set to n on 2.10 in master.cf) - smtpd_relay_restrictions (explicitly set to empty on 2.10) - mynetworks_style (not explicitly set on 2.10, i.e. implicitly "subnet") - relay_domains (not explicitly set on 2.10, i.e. implicitly "$mydestination") To re-use the existing configuration I'm thinking I need to: 1. explicitly set append_dot_mydomain to yes 2. explicitly set mynetworks_style to subnet (2.10 config = "mynetworks = 127.0.0.0/8, 192.168.1.0/24") 3. explicitly set relay_domains=$mydestination If I do those should I explicitly set compatibility_level, or would it not be needed because I have addressed the compatibility issues? And are there any other 'gotchas' to be aware of with this upgrade? On 21.03.21 21:57, Simon Wilson wrote: Ok, I migrated the config from the 2.10 server, and added new specific configuration items for: append_dot_mydomain = yes localhost is in mydestination, so the first message noted at http://www.postfix.org/COMPATIBILITY_README.html won't happen... mydomain is not explicitly set, so postconf -d tells me it is 'simonandkate.lan', as expected. Local servers using this server as SMTP do send using emails without FQDN - hence I set append_dot_mydomain = yes. Is that incorrect? The test I suppose would be to unset it, put compatibility_level to less than 1 and monitor? mynetworks_style= subnet relay_domains = $mydestination I recommend avoiding setting any, unless you really need them. it's better to explicitly configyre "mynetworks" to your local subnets. mynetworks is explicitly set already: [root@emp87 ~]# postconf -n | grep "mynetworks =" mynetworks = 127.0.0.0/8, 192.168.1.0/24, 103.16.129.171 ...re-reading the doco http://www.postfix.org/postconf.5.html#mynetworks, I do *not* need to set mynetworks_style... thank you, corrected. and using only relay_domains makes sense if you are relay for anyone. The server is set to reject_unath_destination: smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/client_checks, permit_mynetworks, check_recipient_access hash:/etc/postfix/recipient_access, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org, check_policy_service unix:private/policyd-spf permit If relay_domains is empty, will it still accept to act as a local network relay (with restricted access) to domains listed in mydestination from mynetworks - I assume yes, from 'permit_mynetworks'? In which case, I can leave relay_domains blank? With those set, all services in master.cf explicitly chroot=n, and compatibility_level set to 99 don't do this. You never know what changes in the future and will require your intervention. I've removed mynetworks_style based on improved knowledge as noted above; commented out append_dot_mydomain and relay_domains, have set compatibility_level to 0, and will monitor for messages. Thanks Simon -- Simon Wilson M: 0400 12 11 16
Re: upgrade 2.10 - 3.3 config compatibility
- Message from Simon Wilson - Date: Fri, 19 Mar 2021 13:40:11 +1000 From: Simon Wilson Reply-To: si...@simonandkate.net Subject: upgrade 2.10 - 3.3 config compatibility To: postfix-users@postfix.org I have a well established 2.10 Postfix instance on 2.10 (CentOS7) which is to be migrated to a new machine running Postfix 3.3 (on RHEL8). I've been reading http://www.postfix.org/COMPATIBILITY_README.html, and from what I can see the backward compatibility issues I may run into are (with existing config from 2.10) - append_dot_mydomain (not explicitly set on 2.10, i.e. implicitly "yes") - chroot (explicitly set to n on 2.10 in master.cf) - smtpd_relay_restrictions (explicitly set to empty on 2.10) - mynetworks_style (not explicitly set on 2.10, i.e. implicitly "subnet") - relay_domains (not explicitly set on 2.10, i.e. implicitly "$mydestination") To re-use the existing configuration I'm thinking I need to: 1. explicitly set append_dot_mydomain to yes 2. explicitly set mynetworks_style to subnet (2.10 config = "mynetworks = 127.0.0.0/8, 192.168.1.0/24") 3. explicitly set relay_domains=$mydestination If I do those should I explicitly set compatibility_level, or would it not be needed because I have addressed the compatibility issues? And are there any other 'gotchas' to be aware of with this upgrade? Thank you kindly. Simon End message from Simon Wilson - Ok, I migrated the config from the 2.10 server, and added new specific configuration items for: append_dot_mydomain = yes mynetworks_style= subnet relay_domains = $mydestination With those set, all services in master.cf explicitly chroot=n, and compatibility_level set to 99, I migrated onto Postfix 3.3. I had a few minor hiccups with other bits (like a typo trying to run the spf policy) but the Postfix part of the migration has swung straight over and not missed a beat. Thanks Simon. -- Simon Wilson M: 0400 12 11 16
Re: _time_limit
- Message from Simon Wilson - Date: Sat, 20 Mar 2021 19:19:49 +1000 From: Simon Wilson Reply-To: si...@simonandkate.net Subject: _time_limit To: postfix-users@postfix.org According to Postfix SMTP Access Policy Delegation[1] "_time_limit" takes the format of "transport_time_limit ($command_time_limit): The maximal amount of time the policy daemon is allowed to run before it is terminated. The transport is the service name of the master.cf entry for the policy daemon service." Replicating the format on that page, my setup is: 1 /etc/postfix/master.cf: 2 policyd-spf unix - n n - 0 spawn 3 user=nobody argv=/usr/bin/policyd-spf 4 5 /etc/postfix/main.cf: 6 smtpd_recipient_restrictions = 7 ... 8 reject_unauth_destination 9 ... 10 check_policy_service unix:private/policyd-spf 11 ... 12 policyd-spf_time_limit = 3600 It looks to me like I am naming it all correctly, but I get: postconf: warning: /etc/postfix/main.cf: unused parameter: policyd-spf_time_limit=3600 This is on Postfix 3.3 on RHEL8 What am I doing wrong here, or is this just because the name is a transportname_parameter construct? Simon Links: -- [1] http://www.postfix.org/SMTPD_POLICY_README.html ----- End message from Simon Wilson - I had an errant space. Apologies for the un-needed message to the list... Simon -- Simon Wilson M: 0400 12 11 16
_time_limit
According to Postfix SMTP Access Policy Delegation[1] "_time_limit" takes the format of "transport_time_limit ($command_time_limit): The maximal amount of time the policy daemon is allowed to run before it is terminated. The transport is the service name of the master.cf entry for the policy daemon service." Replicating the format on that page, my setup is: 1 /etc/postfix/master.cf: 2 policyd-spf unix - n n - 0 spawn 3 user=nobody argv=/usr/bin/policyd-spf 4 5 /etc/postfix/main.cf: 6 smtpd_recipient_restrictions = 7 ... 8 reject_unauth_destination 9 ... 10 check_policy_service unix:private/policyd-spf 11 ... 12 policyd-spf_time_limit = 3600 It looks to me like I am naming it all correctly, but I get: postconf: warning: /etc/postfix/main.cf: unused parameter: policyd-spf_time_limit=3600 This is on Postfix 3.3 on RHEL8 What am I doing wrong here, or is this just because the name is a transportname_parameter construct? Simon Links: -- [1] http://www.postfix.org/SMTPD_POLICY_README.html -- Simon Wilson M: 0400 12 11 16
upgrade 2.10 - 3.3 config compatibility
I have a well established 2.10 Postfix instance on 2.10 (CentOS7) which is to be migrated to a new machine running Postfix 3.3 (on RHEL8). I've been reading http://www.postfix.org/COMPATIBILITY_README.html, and from what I can see the backward compatibility issues I may run into are (with existing config from 2.10) - append_dot_mydomain (not explicitly set on 2.10, i.e. implicitly "yes") - chroot (explicitly set to n on 2.10 in master.cf) - smtpd_relay_restrictions (explicitly set to empty on 2.10) - mynetworks_style (not explicitly set on 2.10, i.e. implicitly "subnet") - relay_domains (not explicitly set on 2.10, i.e. implicitly "$mydestination") To re-use the existing configuration I'm thinking I need to: 1. explicitly set append_dot_mydomain to yes 2. explicitly set mynetworks_style to subnet (2.10 config = "mynetworks = 127.0.0.0/8, 192.168.1.0/24") 3. explicitly set relay_domains=$mydestination If I do those should I explicitly set compatibility_level, or would it not be needed because I have addressed the compatibility issues? And are there any other 'gotchas' to be aware of with this upgrade? Thank you kindly. Simon -- Simon Wilson M: 0400 12 11 16
Re: check_sender_access not working on local senders
Yep, working perfectly, thanks! From: Bill Cole To: Postfix users Sent: 09.02.2020 2:12 AM Subject: Re: check_sender_access not working on local senders On 8 Feb 2020, at 17:25, simonh wrote: > Hello, > > I am trying to automate anti-spam flood on our Plesk servers, and my > goal is > to be able to REJECT mails from abused mailboxes or from non-captcha'd > web > forms. > > On the mailboxes, the directive check_sender_access works as expected, > no > problem here. > > Whenever I try to REJECT mails from root@localhost (sendmail -t > , > for example), or from a web form that uses a local UNIX account, it > does not > work. Just goes straight out. > > Anybody knows how to do the trick? Run 'man 5 postconf' and look for the section on the 'authorized_submit_users' directive. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Postfix HELO checks
On Wed, 15 Jan 2020 at 18:00, Dominic Raferd wrote: > > > On Wed, 15 Jan 2020 at 16:50, Simon B wrote: >> >> On Wed, 15 Jan 2020 at 17:43, Jaroslaw Rafa wrote: >> > >> > Dnia 15.01.2020 o godz. 17:26:48 Simon B pisze: >> > > >> > > Amavis listens on 10024, and postfix listens on 10025 >> > > >> > > That means mail comes in on 587, it goes to amavis on 10024 and comes >> > > back on 10025 before going out. >> > [...] >> > > and mail is flowing. I am not happy since the solution to the >> > > original problem has been to make smtpd_helo_restrictions=permit and >> > > even though it's internal we operate a zero-trust policy, and "permit" >> > > is not that. >> > >> > Does Amavis actually connect to 127.0.0.1 when injecting mail back to >> > Postfix? If yes, then maybe you don't have 127.0.0.1 in $mynetworks >> > >> > It can also be that Amavis doesn't connect to 127.0.0.1, but to some other >> > IP on your server - then you need to put that IP in $mynetworks too, or >> > reconfigure Amavis so that it connects to 127.0.0.1 >> >> I don't know where else it could connect... In master.cf it is defined >> >> 119 #The amavis reciever >> 120 127.0.0.1:10025 inet n - - - - smtpd >> >> > If it works with "permit", it should also work with "permit_mynetworks", >> > provided that the value of $mynetworks includes the actual IP Amavis is >> > connecting to. >> >> it should, but it isn't - hence the reason I have asked here for help. >> >> # postconf -n | grep -n mynetworks >> 36:mynetworks = 127.0.0.0/8, [::1]/128 >> 37:mynetworks_style = host > > > Try removing 'mynetworks' from definitions since it overwrites > 'mynetworks_style=host' which should already restrict the definition of > mynetworks to the local machine (and might do so in a more correct way?) > Try adding 'reject' after 'permit_mynetworks' at the end of one of the > restriction lists (for smtpd-from-amavis) e.g. smtpd_client_restrictions - > this gives you the full protection Thanks. That works and meets our objectives. Appreciate the fantastic support. Simon
Re: make smtpd listen on IPv6 as well
On Wed, 15 Jan 2020 at 18:03, Wietse Venema wrote: > > Simon B: > > Hi > > > > Currently the smtpd for receiving mails from amavis is set up like: > > > > 119 #The amavis reciever > > 120 127.0.0.1:10025 inet n - - - - smtpd > > > > Consequently it listens only IPv4 > > > > ~# netstat -tulpn | grep 10025 > > tcp0 0 127.0.0.1:10025 0.0.0.0:* > > LISTEN 4849/master > > > > Amavis is listening on both IPv4 and IPv6 > > > > # netstat -tulpn | grep 10024 > > tcp0 0 127.0.0.1:10024 0.0.0.0:* > > LISTEN 4135/amavisd-new (m > > tcp6 0 0 ::1:10024 :::* > > LISTEN 4135/amavisd-new (m > > > > Do I need to duplicate the entry in master.cf or is there some more > > elegant way to do it? > > Specify 'localhost' instead of an IP address, and add 'localhost' entries > to /etc/hosts to avoid problems at boot time. Thanks Wietse. I went with this option. > Alternatively specify no host, just 10025, in master.cf, and specify > inet_interfaces=loopback in main.cf. This option closes the submission port on the external interface. (for anyone else reading the archives, postconf.5 says the accepted value is: inet_interfaces = loopback-only (Postfix version 2.2 and later)) Regards Simon
Re: Postfix HELO checks
On Wed, 15 Jan 2020 at 17:43, Jaroslaw Rafa wrote: > > Dnia 15.01.2020 o godz. 17:26:48 Simon B pisze: > > > > Amavis listens on 10024, and postfix listens on 10025 > > > > That means mail comes in on 587, it goes to amavis on 10024 and comes > > back on 10025 before going out. > [...] > > and mail is flowing. I am not happy since the solution to the > > original problem has been to make smtpd_helo_restrictions=permit and > > even though it's internal we operate a zero-trust policy, and "permit" > > is not that. > > Does Amavis actually connect to 127.0.0.1 when injecting mail back to > Postfix? If yes, then maybe you don't have 127.0.0.1 in $mynetworks > > It can also be that Amavis doesn't connect to 127.0.0.1, but to some other > IP on your server - then you need to put that IP in $mynetworks too, or > reconfigure Amavis so that it connects to 127.0.0.1 I don't know where else it could connect... In master.cf it is defined 119 #The amavis reciever 120 127.0.0.1:10025 inet n - - - - smtpd > If it works with "permit", it should also work with "permit_mynetworks", > provided that the value of $mynetworks includes the actual IP Amavis is > connecting to. it should, but it isn't - hence the reason I have asked here for help. # postconf -n | grep -n mynetworks 36:mynetworks = 127.0.0.0/8, [::1]/128 37:mynetworks_style = host Regards Simon
make smtpd listen on IPv6 as well
Hi Currently the smtpd for receiving mails from amavis is set up like: 119 #The amavis reciever 120 127.0.0.1:10025 inet n - - - - smtpd Consequently it listens only IPv4 ~# netstat -tulpn | grep 10025 tcp0 0 127.0.0.1:10025 0.0.0.0:* LISTEN 4849/master Amavis is listening on both IPv4 and IPv6 # netstat -tulpn | grep 10024 tcp0 0 127.0.0.1:10024 0.0.0.0:* LISTEN 4135/amavisd-new (m tcp6 0 0 ::1:10024 :::* LISTEN 4135/amavisd-new (m Do I need to duplicate the entry in master.cf or is there some more elegant way to do it? Currently inet is defined in main.cf as # postconf -n | grep -n inet 25:inet_interfaces = all Thanks. Simon
Re: Postfix HELO checks
On Wed, 15 Jan 2020 at 15:57, Dominic Raferd wrote: > > > > On Wed, 15 Jan 2020 at 13:36, Simon B wrote: >> >> On Wed, 15 Jan 2020 at 13:40, Matus UHLAR - fantomas >> wrote: >> > >> > >> On Mon, Jan 13, 2020 at 06:25:27PM +0100, Simon B wrote: >> > >> > > > >> >Since upgrading to 2.11 yesterday (yes, I am on a path to >> > >> > > > >> >move up >> > >> > > > >> >through debian versions), all mail coming in on >> > >> > > > >> >postfix/submission/smtpd is being rejected by the domain >> > >> > > > >> >check in that >> > >> > > > >> >file, even though the user is sasl authenticated. >> > >> > >On Mon, 13 Jan 2020 at 18:44, Viktor Dukhovni >> > > wrote: >> > >> Note, Postfix 2.11 (actually 2.10 IIRC) adds "smtpd_relay_restrictions", >> > >> which you don't override in the submission service definition: >> > >> > On 15.01.20 13:19, Simon B wrote: >> > >Cause and effect in one simple sentence - thanks Viktor! >> > >> > if you use debian, the default smtpd_relay_restrictions should contain: >> > >> > smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated >> > defer_unauth_destination >> >> That results in this >> Jan 15 13:32:53 mail postfix/smtpd[743]: NOQUEUE: reject: RCPT from >> localhost[127.0.0.1]: 451 4.3.5 Server configuration error; >> > >Despite the fact that I changed those receiver settings in master.cf to: >> > > >> > >118 #The amavis reciever >> > >119 127.0.0.1:10025 inet n - - - - smtpd >> > >120 -o content_filter= >> > >121 -o local_recipient_maps= >> > >122 -o relay_recipient_maps= >> > >123 -o smtpd_restriction_classes= >> > >124 -o >> > >smtpd_client_restrictions=permit_mynetworks,reject_plaintext_session >> > >125 -o smtpd_helo_restrictions=permit_mynetworks >> > >126 -o smtpd_sender_restrictions= >> > >127 -o smtpd_recipient_restrictions=permit_mynetworks,reject >> > >128 -o mynetworks=127.0.0.0/8 >> > >129 -o strict_rfc821_envelopes=yes >> > >130 -o >> > >receive_override_options=no_unknown_recipient_checks,no_header_body_checks >> > >131 -o smtp_bind_address=127.0.0.1 >> > > >> > >At the moment nothing is going through amavis in either direction, so >> > >that's a problem... >> > >> > are you sure amavis sends mail through port 10025? >> >> Hi Matus, >> >> Yes, very sure. >> >> if I turn on -v logging for that hop, I am concerned about these lines >> in the log. >> >> Jan 15 13:09:01 mail postfix/smtpd[466]: < localhost[127.0.0.1]: EHLO >> amavisd.localhost >> Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: localhost: no >> match >> Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: 127.0.0.1: no >> match >> and >> Jan 15 13:09:01 mail postfix/smtpd[466]: generic_checks: >> name=permit_mynetworks >> Jan 15 13:09:01 mail postfix/smtpd[466]: permit_mynetworks: localhost >> 127.0.0.1 >> Jan 15 13:09:01 mail postfix/smtpd[466]: match_hostname: localhost ~? >> 127.0.0.0/8 >> Jan 15 13:09:01 mail postfix/smtpd[466]: match_hostaddr: 127.0.0.1 ~? >> 127.0.0.0/8 >> Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: >> permit_mynetworks: no match >> culminating in >> Jan 15 13:09:01 mail postfix/smtpd[466]: NOQUEUE: reject: RCPT from >> localhost[127.0.0.1]: 554 5.7.1 : Helo command >> rejected: Host not found; from= >> to= proto=ESMTP helo= >> >> >> permit_mynetworks should be permitting that, not offering no match. > > > Is amavis running on the local machine? The smtpd process listening for > amavis seems unable to match amavis's ip either to local host or to 127.0.0.1. > > As as workaround you could change the 'permit_mynetworks' setting on this > smtpd process to 'permit'. If you have firewalled port 10025 it should be > reasonably safe I think? Hi Dominic, So, there was an error in my previous response to Matus - but not a fatal one. Amavis listens on 10024, and postfix listens on 10025 That means mail comes in on 587, it goes to amavis on 10024 and comes back on 10025 before going out. I currently have #The amavis reciever 127.0.0.1:10025 inet n
Re: Postfix HELO checks
On Wed, 15 Jan 2020 at 13:40, Matus UHLAR - fantomas wrote: > > >> On Mon, Jan 13, 2020 at 06:25:27PM +0100, Simon B wrote: > >> > > > >> >Since upgrading to 2.11 yesterday (yes, I am on a path to move up > >> > > > >> >through debian versions), all mail coming in on > >> > > > >> >postfix/submission/smtpd is being rejected by the domain check > >> > > > >> >in that > >> > > > >> >file, even though the user is sasl authenticated. > > >On Mon, 13 Jan 2020 at 18:44, Viktor Dukhovni > > wrote: > >> Note, Postfix 2.11 (actually 2.10 IIRC) adds "smtpd_relay_restrictions", > >> which you don't override in the submission service definition: > > On 15.01.20 13:19, Simon B wrote: > >Cause and effect in one simple sentence - thanks Viktor! > > if you use debian, the default smtpd_relay_restrictions should contain: > > smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated > defer_unauth_destination That results in this Jan 15 13:32:53 mail postfix/smtpd[743]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 451 4.3.5 Server configuration error; > which is the default value. It's added in postfix postinst script. > > ...unless you have overridden it, in such case it contains what you put > there. > > >Now looks like this... > > > > 10 submission inet n - n - - smtpd > > 11 -o syslog_name=postfix/submission > > >Which seems to have solved the problem - or at least just kicked it > >down the road. Now there's a slightly different format of the error > >when receiving mail from the amavis filter... > > > >Jan 15 11:39:31 mail postfix/smtpd[31588]: connect from localhost[127.0.0.1] > >Jan 15 11:39:31 mail postfix/smtpd[31588]: NOQUEUE: reject: RCPT from > >localhost[127.0.0.1]: 554 5.7.1 : Helo command > >rejected: Host not found; from= to=< > >simo...@example.com> proto=ESMTP helo= > > note that this says "postfix/smtpd" and thus it's not related to master.cf > definition of submission above, then would say "postfix/submission/smtpd" Correct. The submission problem is now solved. The problem is now receiving mail back from amavis. > >Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) smtp resp to RCPT > >(pip) (): 554 5.7.1 : Helo > >command rejected: Host not found > > >Despite the fact that I changed those receiver settings in master.cf to: > > > >118 #The amavis reciever > >119 127.0.0.1:10025 inet n - - - - smtpd > >120 -o content_filter= > >121 -o local_recipient_maps= > >122 -o relay_recipient_maps= > >123 -o smtpd_restriction_classes= > >124 -o smtpd_client_restrictions=permit_mynetworks,reject_plaintext_session > >125 -o smtpd_helo_restrictions=permit_mynetworks > >126 -o smtpd_sender_restrictions= > >127 -o smtpd_recipient_restrictions=permit_mynetworks,reject > >128 -o mynetworks=127.0.0.0/8 > >129 -o strict_rfc821_envelopes=yes > >130 -o > >receive_override_options=no_unknown_recipient_checks,no_header_body_checks > >131 -o smtp_bind_address=127.0.0.1 > > > >At the moment nothing is going through amavis in either direction, so > >that's a problem... > > are you sure amavis sends mail through port 10025? Hi Matus, Yes, very sure. if I turn on -v logging for that hop, I am concerned about these lines in the log. Jan 15 13:09:01 mail postfix/smtpd[466]: < localhost[127.0.0.1]: EHLO amavisd.localhost Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: localhost: no match Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: 127.0.0.1: no match and Jan 15 13:09:01 mail postfix/smtpd[466]: generic_checks: name=permit_mynetworks Jan 15 13:09:01 mail postfix/smtpd[466]: permit_mynetworks: localhost 127.0.0.1 Jan 15 13:09:01 mail postfix/smtpd[466]: match_hostname: localhost ~? 127.0.0.0/8 Jan 15 13:09:01 mail postfix/smtpd[466]: match_hostaddr: 127.0.0.1 ~? 127.0.0.0/8 Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: permit_mynetworks: no match culminating in Jan 15 13:09:01 mail postfix/smtpd[466]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 554 5.7.1 : Helo command rejected: Host not found; from= to= proto=ESMTP helo= permit_mynetworks should be permitting that, not offering no match.
Re: Postfix HELO checks
On Mon, 13 Jan 2020 at 18:44, Viktor Dukhovni
wrote:
>
> On Mon, Jan 13, 2020 at 06:25:27PM +0100, Simon B wrote:
>
> > > > >> >Since upgrading to 2.11 yesterday (yes, I am on a path to move up
> > > > >> >through debian versions), all mail coming in on
> > > > >> >postfix/submission/smtpd is being rejected by the domain check in
> > > > >> >that
> > > > >> >file, even though the user is sasl authenticated.
>
> Note, Postfix 2.11 (actually 2.10 IIRC) adds "smtpd_relay_restrictions",
> which you don't override in the submission service definition:
Cause and effect in one simple sentence - thanks Viktor!
> > submission inet n - n - - smtpd
> >-o syslog_name=postfix/submission
> >-o smtpd_delay_reject=yes
> > # -o receive_override_options=no_address_mappings
> >-o always_add_missing_headers=yes
> >-o content_filter=dksign:[127.0.0.1]:10028
> >-o smtpd_enforce_tls=yes
> >-o smtpd_sasl_auth_enable=yes
> >-o smtpd_tls_security_level=encrypt
> >-o smtpd_tls_auth_only=yes
> >-o
> > smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
>
> But you also don't override, "smtpd_helo_restrictions", ...
Thanks for the additional hint.
> The boilerplate commented submission service in recent upstream Postfix
> master.cf files reads:
>
> #submission inet n - n - - smtpd
> # -o syslog_name=postfix/submission
> # -o smtpd_tls_security_level=encrypt
> # -o smtpd_sasl_auth_enable=yes
> # -o smtpd_tls_auth_only=yes
> # -o smtpd_reject_unlisted_recipient=no
> # -o smtpd_client_restrictions=$mua_client_restrictions
> # -o smtpd_helo_restrictions=$mua_helo_restrictions
> # -o smtpd_sender_restrictions=$mua_sender_restrictions
> # -o smtpd_recipient_restrictions=
> # -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
> # -o milter_macro_daemon_name=ORIGINATING
>
> Yours should look substantially similar (sans comments):
Now looks like this...
10 submission inet n - n - - smtpd
11 -o syslog_name=postfix/submission
12 -o smtpd_tls_security_level=encrypt
13 -o smtpd_sasl_auth_enable=yes
14 -o smtpd_tls_auth_only=yes
15-o smtpd_enforce_tls=yes
16-o smtpd_delay_reject=yes
17-o always_add_missing_headers=yes
18-o content_filter=dksign:[127.0.0.1]:10028
19 -o smtpd_reject_unlisted_recipient=no
20-o
smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
21 -o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_plaintext_session,reject
22 -o smtpd_helo_restrictions=permit_mynetworks,reject_invalid_helo_hostname
23 -o smtpd_sender_restrictions=reject_non_fqdn_sender
24 -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
25 -o milter_macro_daemon_name=ORIGINATING
Which seems to have solved the problem - or at least just kicked it
down the road. Now there's a slightly different format of the error
when receiving mail from the amavis filter...
Jan 15 11:39:31 mail postfix/smtpd[31588]: connect from localhost[127.0.0.1]
Jan 15 11:39:31 mail postfix/smtpd[31588]: NOQUEUE: reject: RCPT from
localhost[127.0.0.1]: 554 5.7.1 : Helo command
rejected: Host not found; from= to=<
simo...@example.com> proto=ESMTP helo=
Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) smtp resp to RCPT
(pip) (): 554 5.7.1 : Helo
command rejected: Host not found
Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) Negative SMTP resp.
to DATA: 554 5.5.1 Error: no valid recipients
Jan 15 11:39:31 mail postfix/smtpd[31588]: disconnect from localhost[127.0.0.1]
Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) (!)kTBsiMtC7PPJ FWD
from -> , BODY=7BIT 554 5.7.1
from MTA(smtp:[127.0.0.1]:10025): 554 5.7.1 :
Helo command rejected: Host not found
Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) Blocked MTA-BLOCKED
{RejectedInbound}, [127.0.0.1] [217.110.53.130] ->
, Message-ID:
<20200115113913.horde.vu0wmb4khzfc85v7hddg...@webmail.example.net>,
mail_id: kTBsiMtC7PPJ, Hits: -5.2, size: 1093, 5595 ms
Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) TIMING-SA total
5466 ms - parse: 1.86 (0.0%), extract_message_metadata: 3.8 (0.1%),
get_uri_detail_list: 0.31 (0.0%), tests_pri_-1000: 4.5 (0.1%),
tests_pri_-950: 1.14 (0.0%), tests_pri_-900: 0.91 (0.0%),
tests_pri_-400: 77 (1.4%), check_bayes: 76 (1.4%), b_tie_ro: 1.69
(0.0%), b_tokenize: 3.1 (0.1%), b_tok_get_all: 3.9 (0.1%),
b_comp_prob: 1.50 (0.0%), b_tok_touch_all: 63 (1.2%), b_finish: 0.65
(0.0%), tests_pri_0: 5223 (95.6%), check_spf:
Re: Postfix HELO checks
On Fri, 10 Jan 2020 at 18:22, Simon B wrote: > > On Fri, 10 Jan 2020 at 15:53, Matus UHLAR - fantomas > wrote: > > > > >> On 10.01.20 12:42, Simon B wrote: > > >> >For as long as I can I remember, I have blocked connections purporting > > >> >to be my own domain/IP address using a postmapped file called > > >> >helo_checks. > > >> > > > >> >This is checked AFTER permit_sasl_authenticated. > > >> > > > >> >smtpd_recipient_restrictions = > > >> >reject_non_fqdn_sender, > > >> >reject_non_fqdn_recipient, > > >> >permit_sasl_authenticated, > > >> >reject_sender_login_mismatch, > > >> >rejected_authenticated_sender_login_mismatch, > > >> >check_helo_access hash:/etc/postfix/helo_checks, > > >> >. > > >> >. > > >> >. > > >> >permit_mynetworks, > > >> >reject_unauth_destination, > > >> >a bunch more RBLs, > > >> >permit > > >> > > > >> >Since upgrading to 2.11 yesterday (yes, I am on a path to move up > > >> >through debian versions), all mail coming in on > > >> >postfix/submission/smtpd is being rejected by the domain check in that > > >> >file, even though the user is sasl authenticated. > > >> > > > >> >Can someone help me figure out why? > > >> > > > >> >I can probably remove/comment the offending line and rely on other > > >> >rejection parameters, but it still rejects a significant of spam > > >> >attempts, so I'd prefer to keep it. > > > > >On Fri, 10 Jan 2020 at 13:39, Matus UHLAR - fantomas > > >wrote: > > >> logs? > > > > On 10.01.20 14:50, Simon B wrote: > > >Quite difficult to get logs off the production environment onto my > > >office client, hence the redacted smtpd_recipient_restrictions > > > > > >Jan 10 13:42:22 mail postfix/smtpd[18730] : NOQUEUE: rejectRCPT from > > >localhost [127.0.0.1]: 550 5.7.1. : Helo command > > >rejected: Your server is misconfigured as you are not a member of this > > >domain; from= to= proto=ESMTP > > >helo= > > > > ok, this looks like recipient rejection, because of helo checks. > > Are you sure those clients did authenticate successfully? > > Very :) I can see the authentication attempt succeed, > > > >> don't you have check_helo_access at different place in any chance? > > > > > >Good shout. it is also in smtpd_relay_restrictions, but that is > > >functionally a one-to-one copy of smtpd_recipient_restrictions > > > > >> I'm not sure what smtpd_relay_restrictions debian adds to main.cf by > > >> default. > > > > > >nothing in my main.cf is default by debian. It's been painstakingly > > >constructed over hears with contributions from this list. > > > > I guess that upgrade script configured smtpd_recipient_restrictions to > > smtpd_relay_restrictions. > > That's a good guess, because I don't actually remember doing that... > But it makes sense to have it the same... > > > Since it's postfix/submission/smtpd, isn't there anything strange in > > master.cf ? > > Nothing I can see. I'll pick this up Monday and post that. Hi Matus, List root@mail:/etc/postfix# ls master.cf -rw-r--r-- 1 root root 6.4K 2016-01-13 10:43:01 master.cf smtp inet n - - - - smtpd -v submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_delay_reject=yes # -o receive_override_options=no_address_mappings -o always_add_missing_headers=yes -o content_filter=dksign:[127.0.0.1]:10028 -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=encrypt -o smtpd_tls_auth_only=yes -o smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject No changes since years, and nothing funky I can see.. I have added -v to the smtpd and will try to debug it like that... Cheers. Simon
Re: Postfix HELO checks
On Fri, 10 Jan 2020 at 15:53, Matus UHLAR - fantomas wrote: > > >> On 10.01.20 12:42, Simon B wrote: > >> >For as long as I can I remember, I have blocked connections purporting > >> >to be my own domain/IP address using a postmapped file called > >> >helo_checks. > >> > > >> >This is checked AFTER permit_sasl_authenticated. > >> > > >> >smtpd_recipient_restrictions = > >> >reject_non_fqdn_sender, > >> >reject_non_fqdn_recipient, > >> >permit_sasl_authenticated, > >> >reject_sender_login_mismatch, > >> >rejected_authenticated_sender_login_mismatch, > >> >check_helo_access hash:/etc/postfix/helo_checks, > >> >. > >> >. > >> >. > >> >permit_mynetworks, > >> >reject_unauth_destination, > >> >a bunch more RBLs, > >> >permit > >> > > >> >Since upgrading to 2.11 yesterday (yes, I am on a path to move up > >> >through debian versions), all mail coming in on > >> >postfix/submission/smtpd is being rejected by the domain check in that > >> >file, even though the user is sasl authenticated. > >> > > >> >Can someone help me figure out why? > >> > > >> >I can probably remove/comment the offending line and rely on other > >> >rejection parameters, but it still rejects a significant of spam > >> >attempts, so I'd prefer to keep it. > > >On Fri, 10 Jan 2020 at 13:39, Matus UHLAR - fantomas > >wrote: > >> logs? > > On 10.01.20 14:50, Simon B wrote: > >Quite difficult to get logs off the production environment onto my > >office client, hence the redacted smtpd_recipient_restrictions > > > >Jan 10 13:42:22 mail postfix/smtpd[18730] : NOQUEUE: rejectRCPT from > >localhost [127.0.0.1]: 550 5.7.1. : Helo command > >rejected: Your server is misconfigured as you are not a member of this > >domain; from= to= proto=ESMTP > >helo= > > ok, this looks like recipient rejection, because of helo checks. > Are you sure those clients did authenticate successfully? Very :) I can see the authentication attempt succeed, > >> don't you have check_helo_access at different place in any chance? > > > >Good shout. it is also in smtpd_relay_restrictions, but that is > >functionally a one-to-one copy of smtpd_recipient_restrictions > > >> I'm not sure what smtpd_relay_restrictions debian adds to main.cf by > >> default. > > > >nothing in my main.cf is default by debian. It's been painstakingly > >constructed over hears with contributions from this list. > > I guess that upgrade script configured smtpd_recipient_restrictions to > smtpd_relay_restrictions. That's a good guess, because I don't actually remember doing that... But it makes sense to have it the same... > Since it's postfix/submission/smtpd, isn't there anything strange in > master.cf ? Nothing I can see. I'll pick this up Monday and post that. Thanks. Simon
Re: Postfix HELO checks
On Fri, 10 Jan 2020 at 13:39, Matus UHLAR - fantomas wrote: > > On 10.01.20 12:42, Simon B wrote: > >For as long as I can I remember, I have blocked connections purporting > >to be my own domain/IP address using a postmapped file called > >helo_checks. > > > >This is checked AFTER permit_sasl_authenticated. > > > >smtpd_recipient_restrictions = > >reject_non_fqdn_sender, > >reject_non_fqdn_recipient, > >permit_sasl_authenticated, > >reject_sender_login_mismatch, > >rejected_authenticated_sender_login_mismatch, > >check_helo_access hash:/etc/postfix/helo_checks, > >. > >. > >. > >permit_mynetworks, > >reject_unauth_destination, > >a bunch more RBLs, > >permit > > > >Since upgrading to 2.11 yesterday (yes, I am on a path to move up > >through debian versions), all mail coming in on > >postfix/submission/smtpd is being rejected by the domain check in that > >file, even though the user is sasl authenticated. > > > >Can someone help me figure out why? > > > >I can probably remove/comment the offending line and rely on other > >rejection parameters, but it still rejects a significant of spam > >attempts, so I'd prefer to keep it. > > logs? Quite difficult to get logs off the production environment onto my office client, hence the redacted smtpd_recipient_restrictions Jan 10 13:42:22 mail postfix/smtpd[18730] : NOQUEUE: rejectRCPT from localhost [127.0.0.1]: 550 5.7.1. : Helo command rejected: Your server is misconfigured as you are not a member of this domain; from= to= proto=ESMTP helo= > don't you have check_helo_access at different place in any chance? Good shout. it is also in smtpd_relay_restrictions, but that is functionally a one-to-one copy of smtpd_recipient_restrictions > I'm not sure what smtpd_relay_restrictions debian adds to main.cf by > default. nothing in my main.cf is default by debian. It's been painstakingly constructed over hears with contributions from this list. Thanks Simon
Postfix HELO checks
Hallo, For as long as I can I remember, I have blocked connections purporting to be my own domain/IP address using a postmapped file called helo_checks. This is checked AFTER permit_sasl_authenticated. smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, permit_sasl_authenticated, reject_sender_login_mismatch, rejected_authenticated_sender_login_mismatch, check_helo_access hash:/etc/postfix/helo_checks, . . . permit_mynetworks, reject_unauth_destination, a bunch more RBLs, permit Since upgrading to 2.11 yesterday (yes, I am on a path to move up through debian versions), all mail coming in on postfix/submission/smtpd is being rejected by the domain check in that file, even though the user is sasl authenticated. Can someone help me figure out why? I can probably remove/comment the offending line and rely on other rejection parameters, but it still rejects a significant of spam attempts, so I'd prefer to keep it. Many thanks. Simon
Re: Relaying to 2 SMTP servers
Thanks for your reply. Sorry, I wanted to say using Postfix. I look for different open source solutions to achieve this. Regards Simon On 17/04/2019 16:33, Phil Stracchino wrote: On 4/17/19 10:03 AM, sel...@linagora.com wrote: Hi, I would like to know if it is possible to deliver a mail to 2 SMTP servers using OpenSMTPD. Perhaps that's a question you should ask on the OpenSMTPD mailing list.
Re: $queue_directory/private permissions
On 2019-03-25 1:32 a.m., Viktor Dukhovni wrote: >> On Mar 24, 2019, at 8:17 PM, Simon Deziel wrote: >> >> I was not clear because my issue is indeed with those accesses before >> privs get dropped. I noticed that tlsproxy accesses tlsmgr's socket >> while still running as root so it depends on its CAP_DAC_READ_SEARCH >> capability. My workaround to not need that cap was to change the perms >> to be like: >> >> $ ls -ld /var/spool/postfix/private/ >> drwx--x--- 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/ >> >> And with that group search bit on, the tlsproxy process no longer >> depends on the CAP_DAC_READ_SEARCH cap to get to tlsmgr's socket. >> >> In other words, this group search bit allows to _not_ depend on the >> CAP_DAC_READ_SEARCH which sounded like an improvement to me. That's what >> I wanted to validate with the mailing list. > > Sorry, that breaks the Postfix internal access control model in unsupported > ways. Root needs to be able to read the directory with its standard > permissions. OK, thank you. Regards, Simon
Re: $queue_directory/private permissions
On 2019-03-24 5:46 p.m., Wietse Venema wrote: > Simon Deziel: >> I can think of 2 ways to workaround this. One is to tell Apparmor to >> grant the tlsproxy process the needed capability and the other is to >> have the $queue_directory/private directory perms set to 0710 with the >> same owner/group. > > Sorry, changes to Postfix permissions are not supported. > > You are welcome to configure AppArmor etc. so that they will not > break legitimate operation of Postfix, but such configuration is > considered platform-specific, and outside the scope of Postfix. Apparmor is what highlighted the reliance on capabilities that seemed avoidable with a group search bit on the private dir so I wanted to hear the opinion of experts. I'm well aware that adding Apparmor or diverging from the default perms means I'm on my own, sorry if that was off-topic for postfix-users@. Regards, Simon
Re: $queue_directory/private permissions
On 2019-03-24 6:02 p.m., Viktor Dukhovni wrote: >> On Mar 24, 2019, at 4:33 PM, Simon Deziel wrote: >> >> I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I >> noticed the tlsproxy process is apparently trying to connect to tlsmgr's >> Unix socket while still running as root. > > The premise is false. On all the systems I've used, the "private" directory > belongs to the "$mail_owner" user: > > $ ls -ld /var/spool/postfix/private/ > drwx-- 2 postfix wheel 24 Mar 3 02:49 /var/spool/postfix/private/ Sorry, I should have included that as it look the same here: $ ls -ld /var/spool/postfix/private/ drwx-- 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/ > and connections to peer services (e.g. to tlsmgr(8)) often happen after privs > are dropped. Agreed, but I'm not concerned about the after. > Some requests may happen before that, but the directory must be > generally readable by $mail_owner. I was not clear because my issue is indeed with those accesses before privs get dropped. I noticed that tlsproxy accesses tlsmgr's socket while still running as root so it depends on its CAP_DAC_READ_SEARCH capability. My workaround to not need that cap was to change the perms to be like: $ ls -ld /var/spool/postfix/private/ drwx--x--- 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/ And with that group search bit on, the tlsproxy process no longer depends on the CAP_DAC_READ_SEARCH cap to get to tlsmgr's socket. In other words, this group search bit allows to _not_ depend on the CAP_DAC_READ_SEARCH which sounded like an improvement to me. That's what I wanted to validate with the mailing list. Thanks, Simon
$queue_directory/private permissions
Hello, I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I noticed the tlsproxy process is apparently trying to connect to tlsmgr's Unix socket while still running as root. Since tlsmgr's socket is stored under $queue_directory/private that has perms set to 0700 and owned by postfix:root, the tlsproxy process needs to override the DAC checks using the CAP_DAC_READ_SEARCH capability. I can think of 2 ways to workaround this. One is to tell Apparmor to grant the tlsproxy process the needed capability and the other is to have the $queue_directory/private directory perms set to 0710 with the same owner/group. Tuning the private directory perms removes the need for the capability so that's my current workaround [*] but I'm looking for feedback on the possible ramifications of this diversion from the default perms. Regards, Simon *: I created postfix-files.d/private-group-search.files with "$queue_directory/private:d:$mail_owner:-:710:uc" P.S: while testing further, I also noticed that smtpd processes need the same cap to access proxymap's Unix socket also under queue_directory/private.
Re: Finding why outbound mail is delayed
On Mon, Nov 13, 2017 at 10:57 AM, Rich Shepard <rshep...@appl-ecosys.com> wrote: > On Mon, 13 Nov 2017, Simon Matthews wrote: > >> I would hazard a guess that your outbound email packets are being dropped >> somewhere. Try using telnet on your mail server to connect to port 25 of >> the remote mail server (mail.appl-ecosys.com.) and see what happens. > > > Simon, > > I can telnet to port 25 of this desktop server/workstation. That's not what I asked. > >> You may have to have a list of domains that you continue to relay >> through your ISP's mail server. You would do this with a transport >> map. > > > I don't relay outbound mail any longer. Frontier Communications opens Port > 25 by default on business accounts, and some messages are delivered. Just because your ISP isn't blocking outgoing port 25 doesn't mean that the recipient mail server is accepting connections from your mail server. I have a virtual machine that is hosted in a datacenter and I find that some remote mail servers will not talk to it. Simon
Re: Finding why outbound mail is delayed
On Mon, Nov 13, 2017 at 10:02 AM, Rich Shepard <rshep...@appl-ecosys.com> wrote: > Running postfix-3.2.4 here on Slackware-14.2. I am a professional services > sole practitioner, not a professional system or network admin. > > After several years having outbound mail forwarded through my ISP's mail > server I changed ISPs and now have a static IP address. The other recent > change > here is replacing the old Netgear FVS318 router with a Ubiquiti EdgeRouter-X > fast enough to take advantage of the 15/5Mbps speeds of my fiber connection. > > Since the end of last week I find many messages delayed 1-2 days; several > hundred are listed in logwatch's daily report. These delayed messages > include may body_check rejections. However, since Friday pflogsumm is also > delayed rather than delivered. There are now 2 messages in the mail queue: > > # mailq > -Queue ID- --Size-- Arrival Time -Sender/Recipient--- > 5E148991FE 182118 Mon Nov 13 03:10:26 root > rshep...@appl-ecosys.com > > EF1E2991FD 815 Mon Nov 13 06:59:09 rshep...@appl-ecosys.com > (connect to A.A.AAA[DDD.DDD.D.DD]:25: Connection timed out) > mail-list-n...@mail.list.org > > The output of postdconf -Mf is attached. So is the output of the DDD log > generated after I modified master.cf by appending '-D' to the smtp line. > > I need to learn how to locate the source of this problem and how to fix > it. If more information is needed let me know and I'll provide it. > I would hazard a guess that your outbound email packets are being dropped somewhere. Try using telnet on your mail server to connect to port 25 of the remote mail server (mail.appl-ecosys.com.) and see what happens. Also, check your mail log file. You may have to have a list of domains that you continue to relay through your ISP's mail server. You would do this with a transport map. Simon
Re: SASL auth only on port 25
On Apr 27, 2017, at 12:45 PM, Simon Wilson <si...@simonandkate.net> wrote: smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/client_checks, permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/sender_access, That check looks risky here. You're making access decisions based on an easily spoofable sender address, prior to blocking relaying with "reject_unauth_destination". That table had better not have any OK entries, but in any case find some way to put this below reject_unauth_destination. Got it - because someone could potentially say "Hey I've got MAIL FROM x@wherever" and if that email address is in that sender_access file, they could then use my server as a relay, because the 'reject_unauth_destination' check has not been evaluated. Thank you for the comment, I will rectify that. Simon. check_recipient_access hash:/etc/postfix/recipient_access.outside, reject_unauth_destination, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org, check_policy_service unix:private/policy-spf permit -- Viktor. -- Simon Wilson I rectified the order as Viktor suggested back in April, and all now working to plan, including a client IP filter in the check_client_access file for local servers to skip amavisd. So I now have: smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/client_checks, permit_mynetworks, check_recipient_access hash:/etc/postfix/recipient_access.outside, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org, check_policy_service unix:private/policy-spf permit I have a follow-up question on smtpd_relay_restrictions. At the moment I have: smtpd_relay_restrictions = smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/client_checks, (etc.) This is an install that has migrated from a Postfix install that was pre-2.10, so for compatibility with what I had before it's all still in smtpd_recipient_restrictions with an explicitly empty smtpd_relay_restrictions. To move forward, what checks should I move into the relay restrictions? Simon -- Simon Wilson M: 0400 12 11 16
Internal IP range bypass filters
I have a bunch of servers that send internal network only emails and reports, e.g. logwatch data, etc. All servers are configured to use a simple local postfix instance that delivers mail to my primary postfix server, specified thus: relayhost = [192.168.1.235] That works fine, email hits that server on port 25 and is accepted because the addresses are in mynetworks of postfix listening on 192.168.1.235:25. But at the moment it is then processed through -> amavisd lmtp / spamassassin -> Postfix on port 10025 -> delivered. And sometimes they get spam trapped (particularly the ones from logwatch on postfix with spamassassin info in them). I'd like the server to not run these internal only emails through amavisd-new, but to just send them to the internal destination. What's the best way? I have a (currently empty) client_checks test that I could run "192.168.1 FILTER [127.0.0.1]:10025" in, but if I try that at the moment I get: warning: connect to transport private/smtp[127.0.0.1]: No such file or directory warning: connect to transport private/retry: Connection refused which I think is because my postfix on port 10025 is only configured to listen to localhost (127.0.0.1:10025 inet; smtpd_client_restrictions=permit_mynetworks,reject; and mynetworks=127.0.0.0/8)... which makes sense, that service is pretty much straight in. So that got me thinking, is that the best way anyway? I thought about submitting them to port 587 and disabling scanning on MYNETS in amavisd - but then if one of my users gets compromised outgoing email is not being spam scanned, so that's not my preference. What recommendations for running internal source / internal destination only emails through with minimal overhead - straight through postfix to delivery? Ideally I want something along the lines of IF((source IP = 192.168.1.0/24) AND (destination = (root,si...@simonandkate.net,whatever_other_internal)) THEN: send through aliases and to delivery transport. Simon. -- Simon Wilson M: 0400 12 11 16
Re: Optimising new system and postscreen questions
Viktor Dukhovni: > On May 1, 2017, at 8:17 AM, Simon Wilson <si...@simonandkate.net> wrote: > > ostscreen is using (threshold 3): > >zen.spamhaus.org*3 >bl.mailspike.net*2 >b.barracudacentral.org*2 >bl.spameatingmonkey.net >bl.spamcop.net >dnsbl.sorbs.net >hostkarma.junkemailfilter.com=127.0.0.2 >hostkarma.junkemailfilter.com=127.0.0.4 >hostkarma.junkemailfilter.com=127.0.1.2 >psbl.surriel.com >swl.spamhaus.org*-4 >list.dnswl.org=127.0.[2..15].0*-2 >list.dnswl.org=127.0.[2..15].1*-3 >list.dnswl.org=127.0.[2..15].[2..3]*-4 >wl.mailspike.net=127.0.0.[17;18]*-1 >wl.mailspike.net=127.0.0.[19;20]*-2 >hostkarma.junkemailfilter.com=127.0.0.1*-1 You'll likely find that after zen.spamhaus.org and bl.barracudacentral + bl.spamcop.net you don't need any other RBLs, as they contribute almost nothing to the effectiveness of the filter. Throw in a single whitelist, and you're done. I think that the current list of RBLs is too large. Start with a short list, grow with care one at a time if needed, and only if effectiveness increases non-trivially without too many FPs. As for a system that's too slow overall, have you checked whether your syslog service might be a bottleneck? Make sure that log writes are not synchronous. With syslog-ng use "unix-dgram" NOT "unix-stream". I've no experience with systemd's logging, check for troubles there if applicable. Disable synchronous writes, and with system-xxx-d, turn off rate limiting, at least for mail-related events (so that it won't impose ratelimits before passing events to rsyslogd). Wietse Thanks gents. Synchronous writes are already disabled for maillog on the CentOS 7 server, I hadn't changed it so it must be default. Rate limits - I'm not getting rate limit messages about dropped log entries for either journal or rsyslog. The server seems quick for most things, and is lightly loaded 99% of the time. Heaps of RAM and CPU capacity. I'll tweak the BLs in postscreen per Viktor's comments and see how it goes. I've got a separate email in to the Spamassassin list about slow lookups there, and I think it's just the combination of a few things that can be tweaked or better understood (including my misunderstanding about the postscreen 6 seconds) that makes the server seem slow. Can anyone comment on the value / no value of having zen.spamhaus as an RBL in smtpd in addition to it being used by postscreen? Simon. -- Simon Wilson M: 0400 12 11 16
Re: Optimising new system and postscreen questions
Simon Wilson: On my new Postfix 2.10 system incoming mail is slow to process (about 15 seconds end to end), and I think it is mainly because DNS queries are slowing things down. The server runs local caching DNS BIND, so it's as quick as I can get it on the slow Internet connection we are on. At the moment it seems like every step along the inbound email process is doing separate DNSBL lookups, and I'm wondering if this can be streamlined. Postscreen runs first and takes pretty much 6 seconds every time: That is incorrect. The 6 seconds is only for clients that haven't passed the pregreet test in the past 24 hours (the time is controlled with the postscreen_greet_ttl parameter). Wietse THanks Wietse - yes I noticed that after I sent the first email to list, and corrected myself with a follow-up. I have to say that it is *very* cool seeing postscreen do its stuff... I've been using postfix for many years with postgrey, so this is a new direction for me. Still interested to see if anyone can comment on my other questions though: 1. Would postscreen lose much effectiveness by taking some of the lookups out? - I think I can answer that one myself now that I know how fast postscreen is actually running, but if anyone can see any obvious problems with my combination of BLs please let me know (listed again at the end). I can't use the whitelist threshold (only on 2.10). 2. Is the reject_rbl_client zen.spamhaus.org doing anything when postscreen has already done a zen.spamhaus lookup? This one I am keen to hear thoughts on. I'll keep an eye on logs and see if anything that gets through postscreen's zen lookup gets kicked by this one. 3. Any other ways to speed it up, or should I accept the trade-off between speed and accuracy of result? Postscreen is using (threshold 3): zen.spamhaus.org*3 bl.mailspike.net*2 b.barracudacentral.org*2 bl.spameatingmonkey.net bl.spamcop.net dnsbl.sorbs.net hostkarma.junkemailfilter.com=127.0.0.2 hostkarma.junkemailfilter.com=127.0.0.4 hostkarma.junkemailfilter.com=127.0.1.2 psbl.surriel.com swl.spamhaus.org*-4 list.dnswl.org=127.0.[2..15].0*-2 list.dnswl.org=127.0.[2..15].1*-3 list.dnswl.org=127.0.[2..15].[2..3]*-4 wl.mailspike.net=127.0.0.[17;18]*-1 wl.mailspike.net=127.0.0.[19;20]*-2 hostkarma.junkemailfilter.com=127.0.0.1*-1 -- Simon Wilson M: 0400 12 11 16
Re: Optimising new system and postscreen questions
- Message from Marco Pizzoli <marco.pizz...@gmail.com> - Date: Mon, 1 May 2017 11:18:30 +0200 From: Marco Pizzoli <marco.pizz...@gmail.com> Subject: Re: Optimising new system and postscreen questions To: si...@simonandkate.net Cc: Postfix users <postfix-users@postfix.org> Hello Simon, The server runs local caching DNS BIND, so it's as quick as I can get it on the slow Internet connection we are on. I don't qualify mysef expert enough to answer the rest of your points, but for the DNS part I suggest you think about replacing BIND with Unbound, as the DNS resolver. It has a property called min_ttl that permits you to impose a minimum amount of TTL to the entries reported. DNSBL have always real low TTL values, on purpose. If you are fne with relaxing this real-timeness, well by setting a value of i.e. 60/90 seconds it will permit you to reduce the network dependency. Worth a try. Marco Thanks Marco, I'll investigate that. :) Simon -- Simon Wilson M: 0400 12 11 16
Re: Optimising new system and postscreen questions
- Message from Simon Wilson <si...@simonandkate.net> - Date: Mon, 01 May 2017 18:43:41 +1000 From: Simon Wilson <si...@simonandkate.net> Reply-To: si...@simonandkate.net Subject: Optimising new system and postscreen questions To: Postfix users <postfix-users@postfix.org> On my new Postfix 2.10 system incoming mail is slow to process (about 15 seconds end to end), and I think it is mainly because DNS queries are slowing things down. The server runs local caching DNS BIND, so it's as quick as I can get it on the slow Internet connection we are on. At the moment it seems like every step along the inbound email process is doing separate DNSBL lookups, and I'm wondering if this can be streamlined. Postscreen runs first and takes pretty much 6 seconds every time: May 1 18:19:20 emp07 postfix/postscreen[28420]: CONNECT from [64.20.227.131]:57512 to [192.168.1.235]:25 May 1 18:19:26 emp07 postfix/postscreen[28420]: PASS NEW [64.20.227.131]:57512 Postscreen is using (threshold 3): zen.spamhaus.org*3 bl.mailspike.net*2 b.barracudacentral.org*2 bl.spameatingmonkey.net bl.spamcop.net dnsbl.sorbs.net hostkarma.junkemailfilter.com=127.0.0.2 hostkarma.junkemailfilter.com=127.0.0.4 hostkarma.junkemailfilter.com=127.0.1.2 psbl.surriel.com swl.spamhaus.org*-4 list.dnswl.org=127.0.[2..15].0*-2 list.dnswl.org=127.0.[2..15].1*-3 list.dnswl.org=127.0.[2..15].[2..3]*-4 wl.mailspike.net=127.0.0.[17;18]*-1 wl.mailspike.net=127.0.0.[19;20]*-2 hostkarma.junkemailfilter.com=127.0.0.1*-1 (Yes I've checked them all, including 'registering' where necessary for some of those). Some of them register response in the logs - are the rest timing out? May 1 18:38:30 emp07 postfix/postscreen[29413]: CONNECT from [64.20.227.134]:60378 to [192.168.1.235]:25 May 1 18:38:30 emp07 postfix/dnsblog[29423]: addr 64.20.227.134 listed by domain hostkarma.junkemailfilter.com as 127.0.0.1 May 1 18:38:30 emp07 postfix/dnsblog[29423]: addr 64.20.227.134 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1 May 1 18:38:30 emp07 postfix/dnsblog[29418]: addr 64.20.227.134 listed by domain list.dnswl.org as 127.0.3.1 May 1 18:38:31 emp07 postfix/dnsblog[29421]: addr 64.20.227.134 listed by domain dnsbl.sorbs.net as 127.0.0.7 May 1 18:38:36 emp07 postfix/postscreen[29413]: PASS NEW [64.20.227.134]:60378 Then Postfix smtpd takes 3 to 4 seconds to get to 'cleanup' stage, including an SPF-policy lookup and a reject_rbl_client zen.spamhaus.org line. Then amavisd-new runs, and spamassassin does more BL lookups, including on URIs in the email (3 or 4 seconds there too). End result is 15 seconds or so end to end before it gets delivered. Most of the time this is fine, the server is low volume. However it got me thinking about all the separate DNS lookups... 1. Would postscreen lose much effectiveness by taking some of the lookups out? 2. Is the reject_rbl_client zen.spamhaus.org doing anything when postscreen has already done a zen.spamhaus lookup? 3. Any other ways to speed it up, or should I accept the trade-off between speed and accuracy of result? 4. Is it worth running postscreen in more detailed (verbose?) mode to see what it is doing? Simon. I just realised postscreen_greet_wait (default: normal: 6s, overload: 2s) will be the postscreen 6 seconds, as I have not over-ridden the default. So that answers question 4... it's done the lookups, printed the results it got, and is now doing the postscren_greet_wait. Simon -- Simon Wilson M: 0400 12 11 16
