Re: tracking through logs
[Subject: added] On Mon, Jun 04, 2018 at 03:34:33PM -0500, Greg Strange wrote: > I am trying to track a single email throughout the entire postfix > process. The idea is that when a customer calls us and says that a > certain email never reached them, we can quickly trace the email > through the logs and see that it died due to RBL, virus threshold, > etc. > > Ideally, I'd like to be able to get or set a unique message ID and > then be able to match that ID in the logfiles to see what the > outcome of a specific email was. Is there a way to trace a single > email through everything postfix does to it? Well, you want this: enable_long_queue_ids = yes ... but that won't help in one of the cases you mentioned, that of DNSBL blocking. Also, the customer won't know the queue ID, but it will be found in headers, unless of course it was blocked prior to DATA, in which case there's no queue ID. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Question about disabling SSLv2 and SSLv3 and Opportunistic TLS
On Sat, May 26, 2018 at 01:11:00PM -0400, Viktor Dukhovni wrote: > > On May 26, 2018, at 12:59 PM, /dev/rob0 <r...@gmx.co.uk> wrote: > > > >> Man postconf: > >> -d Print main.cf default parameter settings instead of > >> actual settings. Specify -df to fold long lines > >> for human readability (Postfix 2.9 and later). > > > > Perhaps this could be reworded to be less confusing? Since "-d" > > doesn't look at main.cf, s/main.cf/"Postfix internal"/? > > This attempts to distinguish between "main.cf" parameters and > "master.cf" service definitions. It might be slightly clearer > as: > > Print the compiled-in default main.cf parameter settings ... > > but we're assuming that the confused users have looked at the > postconf(1) manpage. And most of the time that's probably not > the case... I guessed that at least in this case, the OP had looked there, otherwise how did he "know" to use "-d"? -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: advice on postscreen setup / exception / dnsbls
On Sat, May 26, 2018 at 01:22:01PM +1000, Voytek wrote: > I've recently updated Postfix from 2.1, and, enabled postscreen, > all's working well, though, just picked up a false positive: > > several users inbound mail blocked with dnsbl.spfbl.net > > I have like: > > # grep spfbl.net main.cf > postscreen_dnsbl_sites = zen.spamhaus.org*5, psbl.surriel.com*2, > bl.spamcop.net*2, dnsbl.spfbl.net*2, > > as this is a gov.au server, should I whitelist health.gov.au ? or > sge.net ? how/where ? > > what's the best way to prevent emails from health.gov.au/sge.net > being blocked? Bubba: "Doc, it hurts when I do this." Doc: "So don't do that." The obvious solution, if dnsbl.spfbl.net is blocking real mail, is to stop using that list, or possibly to lower its score below your [unstated] threshold score. Postscreen is unable to do whitelisting by hostname. In fact the reverse DNS is not looked up at all, so only the IP address is known in postscreen. Another choice is DNS whitelisting: 145.65.91.152.list.dnswl.org. 10800 IN TXT "sge.net https://dnswl.org/s/?s=36576; 145.65.91.152.list.dnswl.org. 10800 IN A 127.0.9.2 For more information I would refer you to my page on postscreen; please see the link below, in the .sig . > # grep health.gov.au /var/log/maillog | grep block > May 21 08:49:16 geko postfix/postscreen[23877]: NOQUEUE: reject: > RCPT from [152.91.65.145]:57512: 550 5.7.1 Service unavailable; > client [152.91.65.145] blocked using dnsbl.spfbl.net; > from=<vijawathy.mcpher...@health.gov.au>, to=<br...@tld.com.au>, > proto=ESMTP, helo= While the helo/ehlo is logged, that's not usable either, because once postscreen decides to talk to a client, that client is already blocked. If you're not going to take the advice above, your only other option would be to whitelist the IP address[es]. Oh, also, you could talk to the DNSBL operator about theit listing criteria, and/or to the sending site about getting delisted. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Question about disabling SSLv2 and SSLv3 and Opportunistic TLS
On Sat, May 26, 2018 at 06:51:33AM -0600, @lbutlr wrote: > On 26 May 2018, at 06:30, Sean Son > <linuxmailinglistsem...@gmail.com> wrote: > > postconf -d | egrep '^[^ ]*mtpd?_tls.*_protocols' . but it still > > shows me the old settings > > > The output of postconf -d will never change. > > Man postconf: >-d Print main.cf default parameter settings instead of > actual settings. Specify -df to fold long lines > for human readability (Postfix 2.9 and later). Perhaps this could be reworded to be less confusing? Since "-d" doesn't look at main.cf, s/main.cf/"Postfix internal"/? Just a thought. This particular misunderstanding is pretty common. Of course "instead of actual settings" should be a clue. It might help if the OP tells us what he was thinking when reading that passage about "-d". Reading too fast? -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Log Messages
On Wed, May 23, 2018 at 08:39:08AM -0700, Doug Hardie wrote: > I am running a mail server that has a few local recipients and a > bunch of forwarded recipients for one domain. All is working > properly. However, there are some log messages that I find > confusing. The server receives many messages delivery attempts > where the user is not included in the virtual_alias_maps. All but > one of them receive log messages like > > Recipient address rejected: unverified address This was rejected by the reject_unverified_recipient smtpd restriction, after an attempt to verify the address failed. > That makes sense. However, one of them receives > > Recipient address rejected: User unknown in virtual alias table This was rejected by the reject_unauth_destination smtpd restriction, probably in smtpd_relay_restrictions, and means that the domain was found in virtual_alias_domains, but the address did not resolve via v_a_maps to an address NOT in v_a_domains. > I don't see what is different for this particular user. Is it a "user" or just a non-existent address? If the former, you have a problem. If the latter, it's fine. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Specify good mail sender
On Wed, May 16, 2018 at 06:48:55PM +0200, for...@mehl-family.fr wrote: > I can't specifie the good mail sender with postfix. What you describe most likely is not a Postfix problem. > I explain: > > I have a server mail cluster with 2 nodes (but only one works, the > second is going to be made). > > Node names is "node1" and "node2", cluster name is "node". On > node1, the server name is "node1" and the mail server name (for > postfix) is "node". The servers are on a personnal domain > (my_domain.fr). > > On all of my servers (mail servers and others), the postfix > configuration is: > > . > > mydomain = my_domain.fr > > myhostname = server_name.$mydomain Neither of which is directly relevant. See: http://www.postfix.org/BASIC_CONFIGURATION_README.html http://www.postfix.org/postconf.5.html#myorigin > (with "node" for relay to others servers and mail server > configuration for "node1") > > When I send a mail from a local server (linux) with a linux user, > I receive the mail with "from user@server.my_domain.fr" [1]. So, > that's OK. > > But when I send a mail from the mail server with a linux user, How did you send the mail? Typically the MUA would set a sender address. Is the sender set in the MUA? We might have been able to tell, if you had shown us LOGS. > I receive the mail with "from user@node1" [1] instead of "from > user@node1.my_domain.fr" [1]. Your link was not a real link. > I don't understand where is the bad configuration. Right, and we could possibly tell you, as above. But most likely your OS has preconfigured your mail(1) command to set a sender domain name. > Links: > -- > [1] > https://mehlsrvmail:40030/?_task=mail_caps=pdf%3D0%2Cflash%3D1%2Ctiff%3D0%2Cwebp%3D0_uid=59_mbox=Sent_framed=1_action=preview#NOP -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: postfix 3.3.0 and vda quota patch
On Wed, May 16, 2018 at 02:30:52PM +0200, Roberto Sebastiano wrote: > it seems that "postfix vda" patch that brings quota support for > virtual maildirs is not updated / not mantained anymore. There > is no patch for 3.3.0 > http://vda.sourceforge.net/ Note that your patch never was supported on this list. > I used that patch to create a custom mailserver on ubuntu 10.04 > and 14.04, but 18.04 uses postfix 3.3.0 and i'm stuck. > > Is there any way to achieve the same result (maildirsize quota > and overquota replay) without the vda patch at this point ? The recommended way is via a policy service which checks with the imapd, and causes a rejection for overquota recipients. Dovecot actually includes such a policy server. Refer to the Dovecot wiki for use and setup instructions. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: aquamail helo option
On Sun, Apr 22, 2018 at 07:24:42PM -0400, David Mehler wrote: > Is anyone using Android's Aquamail to send mail through postfix? > If so, how do you have it configured? > > My postfix is rejecting mail from Aquamail because it's helo is: > > <[192.168.1.1]> basically it's internal ip. What restriction do you have that is blocking this? Include "postconf -nf ; postconf -Mf" and the entire non-verbose logs showing the rejection. Perhaps you have a check_helo_access lookup; you should also show us what is in that lookup. While you can, and I do, block such HELOs on port 25, you must not apply such a restriction to submitting clients. A HELO like that is perfectly valid per RFC. So perhaps the actual problem is that you're submitting on port 25, and your fix is to require users to submit on submission[s], ports 587 or 465, and don't accept submitted mail on 25. Your reply as detailed above will show this. > I do not want to remove my restrictions can I get around this with > a map? That would be a bad idea, and anyway, a question we couldn't answer without knowing how you blocked it. The various Postfix HELO restrictions, such as: + reject_invalid_helo_hostname + reject_non_fqdn_helo_hostname + reject_unknown_helo_hostname will NOT block that HELO string. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Read Only account
On Fri, Apr 20, 2018 at 03:53:17PM -0400, Kevin A. McGrail wrote: > On 4/20/2018 3:40 PM, @lbutlr wrote: > > How would I configure a user so that they could only read mail > > and not send any mail (even to local users). > > > Different auth for POP or IMAP vs SMTP? Or in the SASL backend, have this user's credentials not be valid for SMTP, or in Postfix a check_sasl_access lookup to reject this user's mail. Lots of ways. These will also necessitate that you require your users to AUTH; no permit_mynetworks nor similar IP-based relay allowances. If perchance this is a shell user, don't forget to exclude him/her from your authorized_submit_users, to prevent sendmail submission. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Outbound address rewriting
On Thu, Apr 19, 2018 at 09:47:27PM +, Kevin Miller wrote: > Quick question: In the docs I don't see a reference to a line in > main.cf. Will postfix pick up on the existence of the table > automatically once I hash it, or do I need to add something along > the lines of: > virtual_alias_maps = hash:/etc/virtual > in main.cf? For backward compatibility, the default value for virtual_alias_maps is "$virtual_maps". If that's not set (and in 2018 it certainly should NOT be set) the default is empty. You seem to have missed postconf.5.html#virtual_alias_maps somehow. You do indeed need to set something for virtual_alias_maps if you intend to use the feature. You might also be interested in the command line postconf(1) tool: "postconf virtual_alias_maps" will show what you have set for virtual_alias_maps. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: user unknown in virtual mailbox table
On Wed, Apr 18, 2018 at 04:15:19PM +0200, Alfredo De Luca wrote: > We have 2 domain managed by postfix. > > When I send an email to an not existing user in the first donain I > got back an email user unknown... "User unknown in virtual mailbox table" means the domain was found in virtual_mailbox_domains, but the user@domain was NOT found in virtual_mailbox_maps. > ..while if I send it to the second domain I don't > receive anything. > > Any issue/clue on this? See your logs, and see Angelo's post if you need help with it. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Not receiving messages from mail servers
On Tue, Apr 17, 2018 at 06:38:00AM -0600, @lbutlr wrote: > I finally managed to isolate this. I have no been receiving mails > from some mail servers and there's very little being logged. I > obviously set some configuration that mucked things up. Here is > the entire mail.log from the first minute after midnight: > > Apr 17 00:00:09 mail postfix/postscreen[67061]: CONNECT from > [94.237.32.243]:46598 to [65.121.55.42]:25 > Apr 17 00:00:09 mail postfix/dnsblog[74920]: addr 94.237.32.243 listed by > domain hostkarma.junkemailfilter.com as 127.0.0.1 > Apr 17 00:00:09 mail postfix/dnsblog[74920]: addr 94.237.32.243 listed by > domain hostkarma.junkemailfilter.com as 127.0.1.1 > Apr 17 00:00:09 mail postfix/dnsblog[74865]: addr 94.237.32.243 listed by > domain score.senderscore.com as 127.0.4.97 > Apr 17 00:00:09 mail postfix/dnsblog[74950]: addr 94.237.32.243 listed by > domain list.dnswl.org as 127.0.9.2 > Apr 17 00:00:10 mail postfix/postscreen[67061]: PASS OLD [94.237.32.243]:46598 > Apr 17 00:00:11 mail postfix/smtpd[84666]: connect from > wursti.dovecot.fi[94.237.32.243] It gets through postscreen, to smtpd ... > Apr 17 00:00:39 mail postfix/smtpd[84666]: disconnect from > wursti.dovecot.fi[94.237.32.243] ehlo=1 mail=0/1 rcpt=0/1 data=0/1 > rset=0/1 quit=1 commands=2/6 > > As you can see, 94.237.32.243 connected and then after 30 seconds > disconnected. It says it sent an ehlo, but it is not logged. [it looks logged, to me] Unfortunately the SMTP protocol provides no means for a client to tell a server why it's unable to complete a transaction. Noting that this is probably from the Dovecot users' mailing list, I will put forth a WAG: perhaps you are requiring TLS? That host is among a small number of hosts in my logs which hit a "warn_if_reject reject_plaintext_session" restriction. If you require TLS you can't receive mail from hosts which do not STARTTLS. If you can ask Timo or dovecot.fi people directly, they should be able to help you. > This is one of the lists effected, so please include a Cc to me. Sorry, can't; I am a SPF violator. One Of These Days, I might fix that. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: problem with sending emails from second IP'
On Tue, Apr 17, 2018 at 01:39:45PM +0200, Poliman - Serwis wrote:
> Now all works fine. I have to add smtp_bind_address in main.cf,
> because any modification of original smtp_bind_address from
> master.cf did not work at all (thus in logs which I put you can
> see combinations like this one from port and comma). Based on
> documentation I thought I should modify smtp_bind_address from
> master.cf but no.
You didn't show us how you did it ("postconf -Mf"), so we can't say
what was wrong about it. My guess is that you did something wrong.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: problem with sending emails from second IP'
On Mon, Apr 16, 2018 at 07:23:34AM +0200, Poliman - Serwis wrote: > Yea, that's right. Unbeliveable that there is no comma. :D Now > I have smtp_bind_address in main.cf and master.cf. :) After being here awhile you'll get that Postfix is all about the Principle of Least Astonishment. Names of postconf(5) settings suggest what will be accepted there. In the case of an "*_address" setting, you would expect to see an address. For an "_address6" setting, that would take an ipv6 address. Note also that it's in singular form, "address", as opposed to plural, "addresses". Commas, as described in the leading part of the postconf(5) manual, the part on general syntax, are a form of whitespace. Also, commas are not part of normal ipv4 nor ipv6 address syntax. Therefore it should be quite believable that a comma would have no place in smtp_bind_address. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Relay mail from virtual domains and issue when the sender and recipient is on same server
0.0.1:10023, permit > smtpd_relay_restrictions = permit_sasl_authenticated, defer_unauth_destination You should force all submission through submission/submissions services, or as mentioned above, through a separate MSA. You don't want to accept submission on port 25. smtpd_relay_restrictions = reject_unauth_destination > smtpd_sasl_auth_enable = yes This, also, is not appropriate for port 25. > smtpd_sasl_authenticated_header = yes > smtpd_sasl_local_domain = $myhostname > smtpd_sasl_path = /var/run/dovecot/auth-client You could have your auth socket on TCP, and thus your remote MSA could use it to authenticate your users. (You would of course want to protect access to this socket via firewall or more. Perhaps a VPN connection between the two hosts, and only listen on the VPN address.) > smtpd_sasl_type = dovecot > smtpd_sender_restrictions = reject_unlisted_sender, permit_sasl_authenticated, > reject_non_fqdn_sender, check_sender_access > hash:/usr/local/etc/postfix/sender_access, reject_unknown_sender_domain, > permit > smtpd_tls_CAfile = /usr/local/share/certs/ca-root-nss.crt > smtpd_tls_ask_ccert = yes why? > smtpd_tls_cert_file = /etc/ssl/certs/mail.pem > smtpd_tls_key_file = /etc/ssl/private/mail.pem > smtpd_tls_loglevel = 1 > smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3 > smtpd_tls_protocols = !SSLv2,!SSLv3 > smtpd_tls_received_header = yes > smtpd_tls_security_level = may > smtpd_tls_session_cache_database = > btree:$data_directory/smtpd_tls_session_cache > tls_random_source = dev:/dev/urandom > transport_maps = hash:/usr/local/etc/postfix/recipient_transport > unknown_local_recipient_reject_code = 550 > virtual_alias_maps = hash:/usr/local/etc/postfix/virtual > virtual_gid_maps = hash:/usr/local/etc/postfix/virtual_uids > virtual_mailbox_base = /home/mail > virtual_mailbox_domains = hash:/usr/local/etc/postfix/domains > virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox > virtual_minimum_uid = 100 > virtual_transport = lmtp:unix:private/dovecot-lmtp > virtual_uid_maps = hash:/usr/local/etc/postfix/virtual_uids > % postconf -nf [ once was fine, thanks ] -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: problem confirming delivery of a deferred message in PostFix logs
On Wed, Mar 28, 2018 at 02:16:47PM +, l carr wrote: > Our other question is there a way to link the error message in > the logs to the original message that was deferred. The queue ID is always logged after it has been assigned. Also set enable_long_queue_ids = yes in any supported Postfix version, to ensure that queue IDs are unique. > (Even if it requires turning on additional logging.) No, don't do that. > As it is logged currently, there doesn't appear to be a unique > value that we could key on that is provided in both the error log > entry and the message log entry. So we can only 'assume' the > > Mar 27 16:20:54 redactedServer postfix/cleanup[24237]: warning: > > ldap:/etc/postfix/ldap-aliases.cf lookup error for "redacted@domain" > > Mar 27 16:20:54 redactedServer postfix/cleanup[24237]: warning: 745EC6AC49: > > virtual_alias_maps map lookup problem for redacted@domain -- deferring > > delivery The first line isn't really specific to queue ID 745EC6AC49, but the following line mentions it. You could grep 745EC6AC49, but the best choice is usually to use a pager like less, and search using its search function. If/when 745EC6AC49 is finally delivered or permanently bounced for some reason such as maximal_queue_lifetime, the queue ID will be mentioned in logs describing the final disposition. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Which user lookup wins?
On Mon, Mar 26, 2018 at 05:21:22PM +0200, Matus UHLAR - fantomas wrote: > > > >> On 14.03.18 20:14, Wietse Venema wrote: > > > >> >The Postfix SMTP server always looks in virtual_alias_maps. > > > > > > >Matus UHLAR - fantomas: > > > >> Always? isn't that a contradiction to the referenced > > > >> document that indicated only domains in > > > >> virtual_alias_domains are searched for virtual aliases? > > > > > > On 15.03.18 09:20, Wietse Venema wrote: > > > >Please cite the text that says 'only domains in > > > >virtual_alias_domains are searched for virtual aliases'. > > > Matus UHLAR - fantomas: > > > virtual_alias_domains and virtual_alias_maps are described in > > > "The virtual alias domain class." section. > > > > > > * Domain names are listed in virtual_alias_domains. The default > > > value is $virtual_alias_maps for Postfix 1.1 compatibility. > > > > > > * Valid recipient addresses are listed with the > > > virtual_alias_maps parameter. The Postfix SMTP server rejects > > > invalid recipients with "User unknown in virtual alias table". > > > The default value is $virtual_maps for Postfix 1.1 > > > compatibility. > > On 15.03.18 20:18, Wietse Venema wrote: > > That text does not exclude other virtual_alias_maps lookups. Furthermore, the behavior of virtual_alias_maps is documented completely, here: http://www.postfix.org/postconf.5.html#virtual_alias_maps > > > That lead me to think that virtual_alias_maps does not apply > > > to other classes. > > All Blacksmiths have dark skin. > > All Negroes have dark skin. > > All blacksmiths are negroes. > > there are 5 classes described on > http://www.postfix.org/ADDRESS_CLASS_README.html > > The local domain class. The virtual alias domain class. The > virtual mailbox domain class. The relay domain class. The default > domain class. > > each of those sections describes different configuration variables > used in those classes. > > virtual_alias_maps is only described in virtual alias domain class. But the ADDRESS_CLASS_README is not intended to completely document what virtual_alias_maps does. The postconf(5) manual does that. It is nicely hyperlinked from ADDRESS_CLASS_README.html, BTW. > if it applies in other classes (as you said above, always), it > should be probably described outsideof those sections. OTOH, perhaps your assumption about the ADDRESS_CLASS_README's function was wrong. > Or should I expect all of maps described in those sections > (local_recipient_maps, virtual_alias_maps, virtual_mailbox_maps, > relay_recipient_maps) to apply in all cases? The postconf(5) manual documents each of those, as well, each also being nicely hyperlinked from ADDRESS_CLASS_README.html. virtual_alias_maps apply to ALL addresses in ALL classes. Other class address maps do not. The virtual alias class is different in another way, too. There's not a transport setting for that class. The reason is that a virtual_alias_domains address must ultimately resolve via v_a_maps to a valid address in some other class, and that class defines the transport which will be used. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: New debian server: install postfix from src or package?
On Sun, Mar 25, 2018 at 01:48:05PM +, Tom Browder wrote:
> I'm in the process of setting up a new server and want postfix.
>
> My question is: should I install from source or use the debian
> packages?
>
> I have installed fro source before, but I would like to ease my
> maintenance burden as much as I can, but without sacrificing
> security.
A Debian list could better tell you the benefits of staying within
the Debian packaging system, but I'll talk a bit about living with
Postfix from source code.
It's not bad at all. In fact I have upgrades basically scripted; the
only thing I have to feed to it is the new version number.
I keep a "BUILD" file in the source which is copied from the previous
version's source directory ("postconf -h mail_version" tells the
script where to find it) which has my "make makefiles" command. The
"make upgrade" procedure is sure and painless. I have been doing
this for many years, never had a problem.
A really nice benefit sometimes is that you can get the awesome new
features without the wait. There have been numerous times I have
seen a new feature discussed here on the mailing list, and I get to
play with it right away. (Yes, I use development snapshots.)
By leaving the Debian packages you might also have issues with the
Debian init scripts, but those can be worked around.
You also get a vanilla Postfix without Debianisms. Something to be
said for that, as the Debian chroot is probably the largest single
source of problems for new users on this mailing list and in IRC.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Yahoo blocking emails from Postfix
On Sat, Mar 24, 2018 at 03:37:39PM -0600, @lbutlr wrote: > On 24 Mar 2018, at 14:32, ahsan2011 <ahsan2...@gmail.com> wrote: > > Basically i have the problems for all yahoo hosted mx records > > Doesn't everyone? Not that I have noticed, not for many years. I suppose IP reputation has a lot to do with it, and also that any site sending marketing mail should sign up for feedback loops with large receivers such as Yahoo. There are more unknown variables here that inhibit useful comment. One thing I'd like to point out, however, is that the emails aren't "from Postfix", and that the blocking has little or nothing to do with the choice of MTA. Yes, some of the workarounds for poor or nonexistent IP reputation include various transport(5) hacks, but ultimately to address the problem, the answer lies outside of Postfix. I'd recommend: - strict list hygiene - sign up at dnswl.org - if money depends on deliveries, spend some on a good ESP -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: postfix 2.6.6 / always_add_missing_headers behavior question
On Wed, Mar 21, 2018 at 07:06:33PM +, Aaron Bennett wrote: > I'm confused by the docs at > http://www.postfix.org/postconf.5.html#always_add_missing_headers, > to wit: > "Always add (Resent-) From:, To:, Date: or > Message-ID: headers when not present. Postfix 2.6 > and later add these headers only when clients match > the local_header_rewrite_clients parameter setting. > Earlier Postfix versions always add these headers; > this may break DKIM signatures that cover > non-existent headers." > With 2.6.6, will it "always" add those headers if they are missing, > or only if they are missing AND the clients match the > local_header_rewrite_clients parameter? 2.6.6, though many years past EOL, is indeed later than 2.6, so WHEN [the listed headers are] NOT PRESENT they are added ONLY WHEN CLIENTS MATCH THE local_header_rewrite_clients PARAMETER SETTING. That's the default setting of "no" for always_add_missing_headers. The Postfix 2.5 and prior behavior was to ALWAYS add these headers if missing, regardless of the client address. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Configure many users accounts.
On Wed, Mar 21, 2018 at 05:10:00PM -0300, Rodrigo Cunha wrote: > In my enviroment i write a script, this need sending mails from > 3 accounts operad...@gmail.com, operad...@gmail.com and > operad...@gmail.com; in my posftix file config i have configure > only operad...@gmail.com and all mail output from > operad...@gmail.com, setting default. This part does not make sense. You don't host gmail.com, so why did you configure it in your Postfix settings? Where is this mail supposed to go? > How i send mails accross mutt (script comand) and configure this > 3 relays accounts. There are support venues for mutt, not here. Likewise, for your script questions, this is not an appropriate place. This seems to be a "how do I use email?" question. The mutt client has for many years supported sending via SMTP. Yes, Postfix can be configured as a null client (see the STANDARD_CONFIGURATION_README) and for sender-dependent relaying (see the SOHO_README), but don't need Postfix at all, and in fact, you would probably be better off just using mutt's native sending capability. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Greylisting?
On Mon, Mar 12, 2018 at 09:59:27AM +, Allen Coates wrote: > Late last year I tried the Postscreen "deep protocol tests" as a > primitive form of greylisting; It was a high-maintenance exercise > for minimal benefit and I have since stopped using it. > > Google and the like, use a different mail server for each connect > attempt. You need an actively maintained whitelist to bypass the > grey-list process. Postfix 2.11+ (which is to say, all supported versions of Postfix at this time) supports DNS whitelists via postscreen_dnsbl_whitelist_threshold, and this is a very good and low-maintenance solution to that problem. Large senders such as Google are all listed at dnswl.org. What few smaller senders you encounter typically retry from the same IP address. We get the potential benefit of greylisting without much pain. > Also, (in my case) I was plagued by Ukrainian spamming mail > servers; they just retried and got through. Of course. The only potential benefit of greylisting a real MTA is that DNSBLs might have listed a spamming one by the time it retries delivery. > The experiment DID stop a few zombies, but not many. Every little bit helps, in such a hostile protocol as SMTP. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Backup mx relay got rejected due to SPF
On Fri, Nov 17, 2017 at 02:56:17PM -0800, Gao wrote: > Is there anything I can configure it to whitelist my backup mx IP? Again, as Noel said twice upthread, it makes more sense to do the whitelisting in Postfix rather than in the policy server. Just a simple check_client_access lookup, an example of which was given already. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Postfix now in Slackware-current
Slackware Linux has switched to the Postfix MTA as its default MTA as of an update to the development version today. https://mirrors.slackware.com/slackware/slackware64-current/ChangeLog.txt "Default MTA" in Slackware terms means "the only MTA". Sendmail 8.15.2 has been moved out of the main distro into "extra" packages, and a new libmilter package has been created therefrom, for Postfix milter support. Postfix has been available in the Slackbuilds.org user build script repository for many years, but there were a few issues with that package for me. I believe I have addressed those issues to my satisfaction. If anyone is interested, the new build script can be found here: https://mirrors.slackware.com/slackware/slackware64-current/source/n/postfix/postfix.SlackBuild On my own Slackware-based servers for years, what I have done was start with a patched Slackbuilds.org build script (to remove the Slackware-isms of gzipped man pages and the hard-coded version strings in configuration paths), and then for future upgrades, I "make upgrade" from source. The gzipped man pages are there, but the version-named directories are referred to with symlinks. "make upgrade" from source won't be happy with the man pages, but otherwise might work (I admit, I have not yet tried it.) In any case I believe that the Slackware upgradepkg(8) process will be safe, as it will invoke "postfix upgrade-configuration" in the "doinst.sh" script. Please let me know if you have any feedback. While I am not the actual package maintainer (in Slackware there is only one over all packages), I can and will bring any issues to his attention. Offlist email per .signature below is fine, but for likely faster response, see the URL below. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Mail Routing Question
On Thu, Nov 16, 2017 at 10:43:16PM +, Kevin Miller wrote: > You can point the A record for aaa.com to one IP and the MX record > for it to another. Yes, but not as per your example. > I.e. > aaa IN A 192.168.1.1 > IN MX 10 192.168.1.2 The RDATA for MX is "integer hostname". In your example the "192.168.1.2" would be read as a hostname, and noting the lack of trailing dot, the zone file's current $ORIGIN value would be appended. > In the example above, a web page to http://aaa.com would go to > 192.168.1.1, whereas an SMTP server would connect to 192.168.1.2. In this example mail would most likely not be deliverable. The MX record in DNS would point to a name which probably does not exist. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: postmap db
On Thu, Nov 16, 2017 at 10:20:09PM +0100, richard lucassen wrote: > When e.g. I have an access file with: > > domain.tld reject > baduser@ reject > > Postfix will reject "u...@domain.tld" and > "baduser@anydomain.anytld". > > When I want to test these db's using "postmap -q", postmap only > tests the "real" entries in the database. Is there a *simple CLI* > way to test the db like Postfix does? I mean a simpler tool than > "swaks" that I use now to test the db's. You did not mention how your access file was being used. Apparently it's being used for email address lookups, so perhaps check_sender_access or check_recipient_access. Any supercharged postmap tool would have to know this also. That's probably why postmap -q is so literal, because that way it does not have to know configuration details. Note also that parent_domain_matches_subdomains settings affect this as well. It would not be trivial to build a diagnostic tool which handles check_mumble_access lookups exactly as Postfix does. No, I am not aware of such a tool. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Helo rejected
On Fri, Nov 10, 2017 at 04:08:02PM +0100, Matus UHLAR - fantomas wrote:
> > > >On 10 November 2017 at 14:08, Enrico Morelli
> > > ><more...@cerm.unifi.it> wrote:
> > > >> my user don't receive mail from a real sender cause our
> > > >> mail server reject the Helo command:
> > > >>
> > > >> NOQUEUE: reject: RCPT from
> > > >> rrcs-70-60-37-220.central.biz.rr.com[70.60.37.220]: 450
> > > >> 4.7.1 : Helo command rejected:
> > > >> Host not found; from=<x...@xxx.xxx.xx> to=<x...@xxx.xxx.xx>
> > > >> proto=ESMTP helo=
> > > >> Nov 8 17:55:46 genio postfix/smtpd[3667]: disconnect from
> > > >> rrcs-70-60-37-220.central.biz.rr.com[70.60.37.220] ehlo=1
> > > >> mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5
> > > >>
> > > >> Is there a way to receive these mails?
>
> > On Fri, 10 Nov 2017 15:42:16 +0100
> > Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
> > > you can whitelist particular IP by using "check_client_access"
> > > and you most probably want to have such directive in main.cf.
>
> On 10.11.17 15:45, Enrico Morelli wrote:
> > I have a check_sender_access, can I use that?
>
> depends on where you have the reject_unknown_helo_hostname.
Well, mainly no. A check_sender_access looks up the SENDER address
("MAIL FROM <sender@address>"), and that is generally a bad idea,
both for whitelisting and blacklisting. Do not do that unless there
would be no other option.
> client access is evaluated before sender access, so if you have the
No. ANY access(5) lookup takes place exactly when you specify that
restriction. You cannot say this categorically. It is quite
possible to mix restrictions such that "earlier" SMTP parts are
checked after RCPT TO, or even after DATA.
> reject_unknown_helo_hostname in smtpd_client_restrictions, you
> must either use check_client_access or move the
> reject_unknown_helo_hostname (and possibly other checks) to
> check_sender_access.
Much is confused in this sentence.
You can do check_mumble_access in pretty much any of the smtpd
restrictions stages.
The OP needs to do a CLIENT access lookup, but that lookup must
precede the reject_unknown_helo_hostname restriction in whichever
restriction stage it is being used.
Many users find it easier to put all restrictions in a single stage,
so everything can be seen in a linear way. For more details and
exceptions,
http:://www.postfix.org/SMTPD_ACCESS_README.html
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Propper way to deliver email messages to gmail
On Sun, Nov 05, 2017 at 07:29:16PM +0100, Pau Peris wrote: > could someone tell, in his opinion, which would be the right way > to deliver remote messages to gmail? Looking at this [1] URL looks > like the only way available is through port 25. See also RFC 5321. All mail exchange among unconnected sites exclusively takes place on port 25. > If i wanted my Postfix to communicate through 465 or 587 it would > need a user/pass but it looks weird to me. I mean, should an MTA > really need an account for each other MTA where to deliver email > messages? Of course not. Don't know if i'm missing something here. You're missing the above bit about mail exchange being exclusively done on port 25. Submission (587) or the deprecated, non-standard smtps (465) are for AUTHENTICATED USERS to submit mail. They are never to be used for server-to-server mail exchange. > This question comes because in my domains table, from the MySQL > database managed by Postfix, there's a domain which used to be > virtual but right now it is not so i changed the transport to > smtp:[aspmx.l.google.com]:25 If you are no longer hosting the domain, you probably need to remove it from your domains table. And likewise, remove it from your transport table. BTW if for some reason you did want to deliver "@example.com" to Google, simply use the MX lookup in your transport entry: example.com smtp:google.com > [1] https://support.google.com/a/answer/176600?hl=en -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: unable to send email to hotmail.com domain
On Mon, Oct 30, 2017 at 06:29:52AM +0100, Poliman - Serwis wrote: > Hmm, you know... Contact in any case with the Microsoft was pain in > ass many times. Second thing better do some "backup way" if > contacting with ms support do nothing like almost all time. Now I > am really surprised, because they answer (wow!), they answer in > short time (WOW!) and it was positive answer which resolved some > problem (INSANE WOW!). That's all. In my earlier post I put the > link to form, which can help in similar problems to mine. IKR? Where is that Microsoft we all love to hate? :) Companies evolve over time, and right now Microsoft's postmaster seems to be distancing itself from their former reputation. I talked to someone else fairly recently who got a reply but NOT resolution of the issue. But in that case I think that person had some spammy practices and/or suspicious mail content. So this "new" Microsoft won't just roll over for you; they are going to examine things and make the best decision they can do for their users. Glad it worked out for you. > 2017-10-27 18:01 GMT+02:00 /dev/rob0 <r...@gmx.co.uk>: > > > On Thu, Oct 26, 2017 at 12:33:03PM +0200, Poliman - Serwis wrote: > > > I know that MS has own black list but why they block me. > > > > There is exactly one place which can answer that question, and it's > > *NOT* the postfix-users mailing list! > > > > If Microsoft is blocking you, ASK MICROSOFT for help. > > > > Recently (June) I helped someone with the same problem. Microsoft > > postmaster was contacted, a human replied, and the IP address was > > removed from their blacklist. > > > > Seriously ... why did no one else suggest this? Even if, as one > > might imagine, they didn't care enough to reply (as is the case at > > Google and other large receivers), Microsoft really is the only > > reasonable one to ask about this. > > > > #include -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Question about logging mismatched DNS in submission server
On Sun, Oct 29, 2017 at 07:28:24AM +, MRob wrote: > Lately it looks like some zombie bot farm is connecting to > submission (and looks to do nothing except connect), causing many > of these in the logs: > > Oct 28 06:15:35 mail postfix/smtpd[12941]: warning: hostname > x.y.z does not resolve to address 11.22.33.44: Name or service > not known BTW there is absolutely no need to mung such logs. Who are you trying to protect? Also, if this is in fact on submission, why is there no " -o syslog_name=postfix/submission" override to help distinguish submission from smtp? > For submission service where clients often connect from dynamic IP > address ranges, maybe seeing these is not important - just noise, > so I am curious about why postfix is logging this. Does this mean > client is somehow attempting to send before (without) doing any > AUTH? I tested by hand and MAIL FROM result is "530 5.7.0 Must > issue a STARTTLS command first". I found that I neglected to > override smtpd_sender_restrictions in the submission service, but > it shouldn't matter if the client cant AUTH, right? > > Or is it default postfix behavior and I can ignore these logs? TL;DR yes, ignore these. Postfix smtpd(8) by default looks up the PTR for every connecting client address, and then tries to validate that PTR with an A/ lookup of the hostname value. Your example failed in validation; "x.y.z./IN/A" (or ) lookup had an error. You can disable these reverse DNS lookups, and specifically only for submission, but that's probably not desirable, because then every Received: header in submission would show "unknown[ip.add.re.ss]". The reason for logging is that Postfix logs every error condition. The same smtpd code which listens on submission is also listening on port 25, and there, wonky lookup results are likely to indicate a problem of some kind. Best bet is to just leave the defaults in place and perhaps do filtering when reading logs, to avoid the entries you do not care/need to see. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: unable to send email to hotmail.com domain
On Thu, Oct 26, 2017 at 12:33:03PM +0200, Poliman - Serwis wrote: > I know that MS has own black list but why they block me. There is exactly one place which can answer that question, and it's *NOT* the postfix-users mailing list! If Microsoft is blocking you, ASK MICROSOFT for help. Recently (June) I helped someone with the same problem. Microsoft postmaster was contacted, a human replied, and the IP address was removed from their blacklist. Seriously ... why did no one else suggest this? Even if, as one might imagine, they didn't care enough to reply (as is the case at Google and other large receivers), Microsoft really is the only reasonable one to ask about this. #include -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Block IP rcpt-to or block MX
On Fri, Oct 20, 2017 at 03:06:32PM +0100, Dominic Raferd wrote: > On 20 October 2017 at 14:50, Emanuel > <emanuel.gonza...@donweb.com> wrote: > > > Quota: *Obvs you need to hash the transport file and then reload > > postfix. This transport file can easily be extended to cover > > similar cases.* > > > > how to make this? > > postmap /etc/postfix/transport > postfix reload The reload is not necessary after the postmap command. A reload speeds things up for configuration changes or for changes in in- memory map types. For hash: maps, no. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: disable receiving for particular email
On Fri, Oct 20, 2017 at 03:29:02PM +0200, Poliman - Serwis wrote: > Do you have maybe other better options? I am open for all nice > suggestions. :) I already said what I think is best, so no. But maybe we don't fully know why you're wanting the "no reply" address? > 2017-10-20 14:43 GMT+02:00 /dev/rob0 <r...@gmx.co.uk>: > > > On Fri, Oct 20, 2017 at 11:12:17AM +0200, > >Matus UHLAR - fantomas wrote: > > > I recommend using real, existent address and check its content > > > once upon a time. You don't want to get blocked (see points 2. > > > and 4.) > > > > Absolutely. This is better than the DISCARD suggestion. I find > > that people who ask for "do not reply" addresses usually don't > > understand what they are asking for, nor what they will get when > > they have it. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: disable receiving for particular email
On Fri, Oct 20, 2017 at 11:12:17AM +0200, Matus UHLAR - fantomas wrote: > On 20.10.17 08:00, Poliman - Serwis wrote: > > Hi all. I would like to create "do not reply" email account. The > > simpliest way is create an email account and disable receiving. As was suggested upthread, the simplest way is NOT to create the account. > > Which option in Postfix permit disable receiving for particular > > email? > > you can disable receiving mail for such account using > check_recipient_access Some references of interest: http://www.postfix.org/SMTPD_ACCESS_README.html http://www.postfix.org/postconf.5.html#check_recipient_access http://www.postfix.org/access.5.html > note that: > 1. anyone doing address verification will block the address > 2. systems that block senders who mail nonexistent addresses will block you >you won't find out you mail nonexistent addresses after mail leaves your >server, since you reject bounces to that addresses > 3. anyone getting angry for sending mail from nonexistent address will >block the address manually > 4. anyone getting angry for sending mail from nonexistent address may block >you manually. > > I recommend using real, existent address and check its content once > upon a time. You don't want to get blocked (see points 2. and 4.) Absolutely. This is better than the DISCARD suggestion. I find that people who ask for "do not reply" addresses usually don't understand what they are asking for, nor what they will get when they have it. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Virtual Domains/ Users
On Wed, Oct 18, 2017 at 10:42:34AM -0700, cac...@quantum-equities.com wrote: > My mail server will receive mail for 3 domains with 6 users, and > the MUA will be on another machine on The Internets. That is very small. The simplest choice is to add the second and third domains to mydestination. The drawback of this is that all domains share one namespace; u...@example.com is the sane as u...@example.net is the same as u...@example.org. > I'm seeing conflicting info on setting this up. The simplest > recipe is here: > https://blog.tinned-software.net/setup-postfix-for-multiple-domains/ I won't review third-party blog posts, but strongly recommend against using them for anything more than ideas. Most bloggers are not qualified to write Postfix documentation. > ... but nothing is mentioned about virtual_users nor any changes What is "virtual_users"? $ man 5 postconf | grep virtual_users || \ echo 'Your term does not exist in the postconf(5) manual.' Your term does not exist in the postconf(5) manual. $ /usr/sbin/postconf virtual_users /usr/sbin/postconf: warning: virtual_users: unknown parameter > to main.cf . So I'm not sure I trust it. > > Then there's this from Postfix: > http://www.postfix.org/VIRTUAL_README.html#virtual_mailbox The VIRTUAL_README has two simple examples. See also the #virtual_alias example. > A different (and it seems more primitive) paradigm than the > former. Again virtual_users is not mentioned. And now you know why. > Seems to me that the first approach is closer to the truth, but > it's clearly not complete. Can anyone advise? That is to imply that the Postfix documentation is untrue. Son, them's fightin' words around these parts. ;) Stick with the documentation. Also look at the BASIC_CONFIGURATION_README, and then further through the VIRTUAL_README. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: posttls-finger / DANE failure
On Tue, Oct 17, 2017 at 08:28:02PM +1030, Mal wrote: > On 17/10/2017 7:14 PM, Viktor Dukhovni wrote: > > > So it seems that the machine in question has the authoritative > > server for the zone as its recursive server. Such mixing of > > authoritative and recursive workloads is discouraged these days, > > and critically, it breaks DANE in Postfix for any authoritative > > zones, because authoritative servers are not validating > > resolvers, and don't set the AD bit in authoritative replies. > > Bingo. That information certainly explains the behavior observed. > > Does this therefore require DNSSEC-validation to be set to "no" > (for the authoritative NS): >dnssec-enable yes; >dnssec-validation no; >dnssec-lookaside auto; Um, validation is exclusively done on NON-authoritative lookup results. I'm not sure what you are thinking. In order: 1. dnssec-enable no; would prevent your BIND server from serving required records from a signed zone. It would prevent ANYONE from being able to validate your signed zone. This is surely not what you're seeking? 2. dnssec-validation no; again, this has no effect when you're serving authoritative data from a master or slave zone. 3. dnssec-lookaside has been removed! Disable it now, on any nameservers you control. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Question regarding Postfix virtual domains and SPF
On Mon, Oct 16, 2017 at 10:05:07PM -0400, J Doe wrote: > I have two questions regarding using SPF when I am using Postfix > with virtual domain hosting. > > I currently have an SPF record in my DNS: > > example.comTXT“v=spf1 ip4:1.2.3.4/32 ip6:1:2:3::4/128 ?all” .^no dot? ^ .. non-ASCII quote characters ... ^ Yes, probably just copy/paste errors, but attention to detail is important. > I virtually host a domain (in this example case, example.com), > that is set to forward mail to recipients on Gmail. Usually "virtual" means "using the Postfix virtual(8) delivery agent," but clearly in this case you means something else, like a relay domain or virtual alias domain. I don't get why, if you're wanting to read the mail via gmail, you don't just pay Google to host the domain? That would be MUCH simpler. > As an example case, if I send an e-mail from a Hotmail account to > an address on my server it then forwards that mail to the user’s > GMail e-mail address. Another example to consider is when spam gets through your lines of defense, and you forward that spam on to gmail. El Goog thinks you're the spam source, and they might block you! (I'm leaving the SPF/DKIM/DMARC questions for others, but holding to the point that forwarding spam *will* cause big problems.) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Syntax question for smtp mandatory TLS encryption
On Wed, Oct 11, 2017 at 05:36:07PM -0400, J Doe wrote: > I have a syntax question regarding configuring mandatory TLS > encryption for the smtp process as listed on: > www.postfix.org/TLS_README.html#client_tls > > In the second example on the page, square brackets are used when > specifying the policy for specific destinations in the tls_policy > file: > > /etc/postfix/tls_policy > [example.net]:587 encrypt protocols=TLSv1 ciphers=high > > Are the square brackets only required when the port to use is > specified (ie: in previous example when destination was example.net > with no port specified, I notice that the square brackets are left > out) or is this syntax specifying something else ? The [] enclose a hostname which is to be looked up as a type A or record. Without the [] first a lookup of type MX is done, and where found, prioritized lookups of further hostnames (A or ) would be done. This is not specific to TLS, it is common to transport(5) and many similar Postfix features. The reason being, MX records exist to control mail routing. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: OT lightweight IMAP client
On Fri, Sep 08, 2017 at 06:29:40PM -0600, @lbutlr wrote: > Figured someone on the list would have an opinion on a very > lightweight feature-poor IMAP client. It doesn't need to do > much else but access a single IMAP account and be able to > forward emails as attachments. Search would be good, but not > required. Searching for queueIDs in the Received header > would be fantastic. > > Primary considerations are fast and as light on memory use > as possible and usable from a Mac (command-line is fine). I > know mutt can do IMAP but I don't think it can forward > messages as attachments though I am probably wrong. Correct, you are incorrect. :) Forwarding as MIME attachment is default behavior when forwarding mail in mutt. I don't know about searching Received: headers, but I suspect in mutt, most things are possible. They do have a user community providing help. > Windows 10 might be useful, but not required. putty + mutt -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Postscreen exceptions and blacklisting
On Fri, Sep 08, 2017 at 03:03:49PM +0300, Nikolaos Milas wrote: > On 8/9/2017 2:42 μμ, Wietse Venema wrote: > > Just as with smtpd access maps, permit/reject are a final > > decision, and dunno means 'let something else make the decision'. > > Please let my ask for a clarification here. The problem is that > the rejection seems to have happened by postscreen itself. > > I would expect that by using dunno for a client in > postscript_exceptions (as follows): > >postscreen_access_list = > permit_mynetworks, > cidr:/etc/postfix/postscreen_exceptions.cidr > > all the following postscreen directives would by bypassed for > this client: > >postscreen_dnsbl_threshold = 2 >postscreen_dnsbl_sites = > b.barracudacentral.org*2, > zen.spamhaus.org*2, > psbl.surriel.com*2 >postscreen_dnsbl_action = enforce >postscreen_greet_action = enforce >postscreen_blacklist_action = enforce > > Isn't this true? No, and I thought that was already answered. > In particular, why the postscreen_access_list did not affect the > postscreen_dnsbl_action, which I would expect to be bypassed? Your DUNNO result only terminated the postscreen_access_list test. > Can you please explain? Which postscreen actions are affected by > postscreen_access_list? A permit/OK result causes all postscreen tests to be bypassed. > Sorry if my question is dumb. It's really the wrong question. The fundamental problem is that you're trusting unsafe DNSBL services for outright rejection. This typically is the case for those who need whitelisting. >postscreen_dnsbl_threshold = 2 Default there is 1, and the way you are scoring things, you didn't need this. >postscreen_dnsbl_sites = > b.barracudacentral.org*2, A very good list, but fully automated from Barracuda devices' input; I have tried using it for rejection and had some complaints about blocking real mail. > zen.spamhaus.org*2, This is the only one I'd trust fully. > psbl.surriel.com*2 Also mostly automated, with a removal tool provided to end users, whether spammers or not. I'd replace your config with: >postscreen_dnsbl_threshold = 2 >postscreen_dnsbl_sites = > b.barracudacentral.org, > zen.spamhaus.org*2, > psbl.surriel.com >postscreen_dnsbl_action = enforce This changes BRBL and PSBL to the default score of 1. More spam would get through postscreen this way, but it's unlikely that you would need to do much whitelisting. Note, I would not stop there; I'd go the rest of the way to my postscreen sample config as can be found at the site in .sig. Upgrade to at least Postfix 2.11 if you're not there yet. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Can send but not receive
On Mon, Aug 28, 2017 at 01:35:12PM +, Tom Browder wrote: > On Mon, Aug 28, 2017 at 08:22 Ralph Seichter > <m16+post...@monksofcool.net> wrote: ... > > > Please study http://www.postfix.org/DEBUG_README.html for starters. > > I had studied it and have done up through verbose messages with - v > but saw nothing. However, I forgot about the peer setting which is > probably why the logs are quiet. You absolutely DO NOT need verbose logging. Turn that off. Logs are quiet because nothing is able to connect to you. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Can send but not receive
On Mon, Aug 28, 2017 at 08:06:39AM -0500, Tom Browder wrote: > My remote postfix installation can send but not receive, and I'm > sure I have a bad setting somewhere. When sending to the remote > server, from my personal gmail account I finally get a response > from gmail as shown in the attached file. snip > There was a temporary problem delivering your message to > tbro...@novco1968tbs.com. Gmail will retry for 46 more hours. > You'll be notified if the delivery fails permanently. Assuming this address (the @domain part) is correct and not munged, there's enough information here to figure out what's wrong. rob0@harrier:~$ dig novco1968tbs.com. mx +short 10 mail.novco1968tbs.com. rob0@harrier:~$ telnet $(dig +short mail.novco1968tbs.com) 25 Trying 142.54.186.6... telnet: connect to address 142.54.186.6: No route to host Looks like a firewall problem, most likely. You have to have your port 25 open if you wish to receive mail exchange from other sites. > I can put my main.cf, master.cf in a github gist if there is any > interest. My mail logs are not interesting at all, at least to me, > but I am happy to put one or more of them on github, too. As has been explained by other posters, no, that is not how this mailing list works. In any case, this does not appear to be a Postfix issue, yet. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: verifying per site TLS policy -- maps override?
On Tue, Aug 22, 2017 at 09:21:33AM -0700, yodel...@yepmail.net wrote: > The reason that I'm asking is that I'd like to set my inbound > policy =may by default, but for specific servers (that I may > be working or warring with) sending email to me I want to > force policy =encrypt. > > For infrequent one offs like that, even if I could specify a > few sending hosts, by hostname &/or even IP, to force inbound > TLS =encrypt policy it'd be useful. See reject_plaintext_session, and in the case as you described, check_client_access: http://www.postfix.org/postconf.5.html#reject_plaintext_session http://www.postfix.org/postconf.5.html#check_client_access http://www.postfix.org/access.5.html -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: exempting user or domain from one RBL check ?
On Mon, Aug 07, 2017 at 06:52:05PM +0200, Matus UHLAR - fantomas wrote: > On 07.08.17 23:19, Voytek wrote: > > Aug 6 22:12:48 emu postfix/smtpd[24963]: NOQUEUE: reject: RCPT > > from sydney.sge.net[152.91.65.147]: 554 5.7.1 Service > > unavailable; Client host [152.91.65.147] blocked using > > b.barracudacentral.org; Client host blocked using Barracuda > > Reputation, see > > http://www.barracudanetworks.com/reputation/?r=1=152.91.65.147; > > from=<> to=<k...@dom.com.au> proto=ESMTP helo= > > I think me and Dominic Rafedr have already explained all that's > needed: > > 1. your setup is good, just use the /etc/postfix/sender_checks 1. The sender in the log line above is null sender, a bounce. It's probably a very bad idea to whitelist the null sender address universally. 2. Whitelisting by commonly-forged sender addresses is generally wrong. Spammers are likely to use sender addresses you have seen. 3. Whitelisting IP addresses or client hostnames is safe and reasonable, except that the hostname whitelist depends on successful DNS lookups. > 2. put OK instead of DUNNO there - that will stop checking in > blacklists. A safer lookup result is "permit_auth_destination". -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: exempting user or domain from one RBL check ?
On Mon, Aug 07, 2017 at 03:38:59PM +0200, Benny Pedersen wrote: > Voytek skrev den 2017-08-07 15:19: > > > thanks for other comments, I'll read in detail tomorrow > > > > (1) > > Aug 6 22:12:48 emu postfix/smtpd[24963]: NOQUEUE: reject: RCPT > > from sydney.sge.net[152.91.65.147]: 554 5.7.1 Service > > unavailable; Client host [152.91.65.147] blocked using > > b.barracudacentral.org; Client host blocked using Barracuda > > Reputation, see > > http://www.barracudanetworks.com/reputation/?r=1=152.91.65.147; > > from=<> to=<k...@dom.com.au> proto=ESMTP helo= > > https://www.dnswl.org/s/?s=36576 > > i noticed you did not use dns based whitelist at all, not that you > need to, but sometimes ips being fp listed aswell DNS whitelisting and postscreen, as Benny suggested, are good bits of advice, but they of course were not available that many years ago. Postfix 2.1 saw its final update over 12 years ago. That's a very long time in terms of software. You simply cannot expect to continue using Postfix 2.1 in this decade. The best (albeit partial) solution is to upgrade. That said, check_client_access did exist Way Back Then. Precede your DNSBL lookups with this check_client_access lookup: sydney.sge.net permit_auth_destination I don't think the cidr: maptype was implemented back then, but a cidr_table(5) is a good way to do check_client_access without (as per my example) relying on reverse DNS lookups. Much better tools have existed for a very long time! -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: exempting user or domain from one RBL check ?
On Mon, Aug 07, 2017 at 01:17:54PM +1000, Voytek wrote: > I have a user's inbound mail blocked by barracudacentral, is > there a way to exempt this particular user/domain from this > particular RBL check ? > > or what else can or should I do ? Share the looging of this rejection and be more specific. The problem is with one specific client, or more? > this is the only known issue with barracuda I have and, > otherwise it seems quite effective, I think ? Yes, but like Spamcop, it's an automated list, so it lists some legitimate outbound servers at times. Large senders often do content filtering on outbound streams, directing questionable content to a certain subgroup of their outbound farms. Members of those subgroups tend to be listed by Spamcop and BRBL. I use BRBL in postscreen with 2 points and a threshold of 3. But I had the same problem [I think] you had: intermittent rejections of good mail. So I don't use it with reject_rbl_client now. > smtpd_recipient_restrictions = > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unlisted_recipient, > check_policy_service inet:127.0.0.1:, > permit_mynetworks, > check_sasl_access hash:/etc/postfix/sasl_access > permit_sasl_authenticated, You should separate submission from your inbound stream. If you must accept user-submitted mail on port 25, use a different IP address. > reject_unauth_destination, > check_recipient_access hash:/etc/postfix/recipient_no_checks, > check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, > check_helo_access hash:/etc/postfix/helo_checks, > check_sender_access hash:/etc/postfix/sender_checks, > check_client_access hash:/etc/postfix/client_checks, > check_client_access pcre:/etc/postfix/client_checks.pcre, > reject_rbl_client zen.spamhaus.org, > reject_rbl_client b.barracudacentral.org, > reject_rhsbl_client dbl.spamhaus.org, > reject_rhsbl_sender dbl.spamhaus.org, > reject_rbl_client psbl.surriel.com, > reject_rbl_client ix.dnsbl.manitu.net, > reject_rbl_client bl.spamcop.net, I don't know manitu firsthand, so I wouldn't use that restriction. I *do* know PSBL and Spamcop firsthand, and I definitely wouldn't recommend those restrictions. > reject_rbl_client cbl.abuseat.org, Wasted lookup, as this is included in Zen. > reject_rhsbl_sender dsn.rfc-ignorant.org, Ralf discontinued the RFCI lists some years back. > check_policy_service inet:127.0.0.1:10031 > > > pflogsumm /var/log/maillog.1 | grep block > blocked using b.barracudacentral.org (total: 482) > blocked using bl.spamcop.net (total: 40) > blocked using dbl.spamhaus.org (total: 133) > blocked using ix.dnsbl.manitu.net (total: 37) > blocked using psbl.surriel.com (total: 14) > blocked using zen.spamhaus.org (total: 3438) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: hostname in aliases.db
On Sat, Aug 05, 2017 at 07:58:19PM +0300, Marat Khalili wrote: > > See also postalias(1), but I'm still not sure that this is a > > real problem. Does something in the container not work > > properly with host-generated aliases.db? > > That's what I'd like to know to, is this hostname mention even > being used? I doubt it is, but I am too lazy / busy to test. :) You could also consult your Berkeley DB documentation. I do know that Postfix simply queries it for the localpart in a localpart@domain, where domain is in $mydestination. Metadata in aliases.db is not queried. > Testing one particular container is not sufficient since I might > run into problems with some other container later, after I end > scripting it. > > > > The better way would probably be to simplify your mail > > infrastructure, using null clients where appropriate. > > > > I have nothing against containerizing Postfix nor running it > > in virtual machines, but unless your organization is very huge > > you do not need more than 1-2 MX hosts and perhaps a per-site > > MSA (which often can coexist on the submission port with MX > > instances.) > > Completely agree. It is mostly a problem of having a hammer and > seeing everything as a nail: I'm also not happy about having many > full-blown postfix instances, but it works and learning something > requires an effort. Hehe, okay. :) > Is msmtp the recommended tool for doing this or just one of the > many out there? There are several, and I am unable specifically to recommend one against the others, because I'm like you. I have this hammer, and when I need to do something involving sending mail, I just use Postfix. ;) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: hostname in aliases.db
On Sat, Aug 05, 2017 at 07:11:08PM +0300, Marat Khalili wrote: > I'm cloning an LXC container which optionally can contain postfix > installation. After cloning the filesystem there's a number of > places I need to change the hostname in. > > I used grep to search for these places and unexpectedly found > mentioning of hostname in /etc/aliases.db, even though /etc/aliases > does not include it. Is this an actual problem? Also, I wonder why you'd need multiple containers with Postfix installs? Did you consider possibly using a null client like msmtp, if all these containers need to do is send mail through a relayhost? > Thus I wonder if I need to re-generate /etc/aliases.db and how can > I do it without actually starting container? You might indeed want to generate your aliases.db for each container, and chroot(1) might be a means to do that. > I can run `newaliases -oAhash:/container/rootfs/etc/aliases` from > host, but then there's a name of the host system in aliases.db, > not container's. See also postalias(1), but I'm still not sure that this is a real problem. Does something in the container not work properly with host-generated aliases.db? > I can also re-generate it from within a container after starting > it and then reload postfix, but it is kludgy. Is there some better > way? The better way would probably be to simplify your mail infrastructure, using null clients where appropriate. I have nothing against containerizing Postfix nor running it in virtual machines, but unless your organization is very huge you do not need more than 1-2 MX hosts and perhaps a per-site MSA (which often can coexist on the submission port with MX instances.) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: no sasl listener on 587 clients can't send mail
On Sun, Jul 30, 2017 at 02:17:15PM -0700, fugeeohu wrote: > hlo whatever > 250-mail.whatever.com > 250-PIPELINING > 250-SIZE 134217728 > 250-VRFY > 250-ETRN > 250-STARTTLS And found in your OP: >> smtpd_tls_auth_only=yes See http://www.postfix.org/postconf.5.html#smtpd_tls_auth_only and "man s_client". > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250 DSN -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: accept+discard vs. reject
On Tue, Jul 25, 2017 at 09:02:17PM -0400, Kevin A. McGrail wrote: > On 7/25/2017 8:48 PM, /dev/rob0 wrote: > >I am curious, what kind of logic do you have to determine that a > >spamming client might be a backscatterer? Are you talking about a > >custom policy service, or a milter? > > For the record, I can agree to disagree as I respect and understand > your position. I just choose to do it differently and think others > should as well. > > But yes, I use a milter. I am a fanboy of MIMEDefang. > > For example, in his case, I have a REDIS backend and would store > message IDs if I give a 5xx. Then if I see the same message id > retried, you could do the 2xx+silent discard. Ah, okay. It seems we are looking at this from totally different angles. My rejections are pre-DATA, so there is no Message-ID to record. I would still be curious to know (back to what the OP was asking) if this strategy of accept+discard is actually making the zombies go away ... I wouldn't think so. But this is probably not all that relevant to Postfix, at this point. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
accept+discard vs. reject (was: Re: What's a better error code ...)
On Tue, Jul 25, 2017 at 07:49:32PM -0400, Kevin A. McGrail wrote: > On 7/25/2017 7:42 PM, /dev/rob0 wrote: >> On Tue, Jul 25, 2017 at 07:07:18PM -0400, Kevin A. McGrail wrote: >>> Unfortunately, you might need logic to accept and silently >>> discard. We do this, for example, with viruses to avoid blowback. > >Oh, I disagree. The best thing to do is to reject anything you're > >unwilling/unable to deliver. You're not causing any bounces; if a > >connecting client does generate a bounce for your rejection that > >is THEIR problem; or in the case of a human sender, that is the > >way to avoid mail loss. > > We can debate RFC's all day I am not talking about RFCs; I am talking about responsible mail handling. > but the reality is that we are dealing > with people not following the RFCs like spambots. A direct-to-MX zombie, the likes of which comprise the vast majority of our postscreen connections, is not going to cause anyone any blowback. The only harm in reject vs. accept/discard is for your Internet connection provider, because they can't bill you for exceeding your bandwidth allowance. :) Real MTAs relaying for a zombie most certainly should be rejected; perhaps it's the only way the admin can find out about, and fix, the problem. > They will just retry and if you do any type of queue and check, > then you can cause backscatter, etc. I certainly was not talking about accept-then-bounce, nor was the OP, unless I misunderstood the post. The previous $Subject would tend to indicate it was about rejection, not bounces. > My advice remains the same if you have mail you are giving a 5xx > that is retrying. Giving it a 5xx is the correct answer. Okay, we are good up to that point. > If that doesn't work, you will find you need to 2xx it and > silently discard. Fortunately that advice, with which I disagree, is difficult to implement in Postfix. It's in fact not possible, without a policy service external to Postfix. > As mentioned, we do this for viruses in particularly to rid the > world of them. Thanks, but I don't think it is working. :) > I'm sure it breaks an RFC in letter but not in spirit as it's my > job to avoid viruses getting through and sometimes they are looking > for blowback messages to carry the payload. I am curious, what kind of logic do you have to determine that a spamming client might be a backscatterer? Are you talking about a custom policy service, or a milter? -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: What's a better error code than 554 to get a sending server to stop retrying?
> On 7/25/2017 5:51 PM, robg...@nospammail.net wrote: > >Depending on where I read about it that "554 5.7.1" error code > >means "failed transaction". 554 is described in RFC 5321, yes, as "failed transaction". 5.7.1 is an Extended Mail System Status Code, described in RFC 3463: https://tools.ietf.org/html/rfc3463#section-3.8 It means "message refused" for policy or security reasons. Since spam zombies usually cannot heed a server's response, it does not matter what error code you give them. A normal MTA will consider "5xx 5.x.x" a permanent error, and will not retry. Exception: see soft_bounce: http://www.postfix.org/postconf.5.html#soft_bounce On Tue, Jul 25, 2017 at 07:07:18PM -0400, Kevin A. McGrail wrote: > Unfortunately, you might need logic to accept and silently discard. > We do this, for example, with viruses to avoid blowback. Oh, I disagree. The best thing to do is to reject anything you're unwilling/unable to deliver. You're not causing any bounces; if a connecting client does generate a bounce for your rejection that is THEIR problem; or in the case of a human sender, that is the way to avoid mail loss. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Which header check & reject method to use?
On Mon, Jul 24, 2017 at 02:27:16PM -0700, robg...@nospammail.net wrote: > I'm getting Postfix setup to deal with "bad headers". > > Looks like there's a bunch of ways to do it. > > Three I'm looking at are > > 1) Postfix's built in headers check > 2) A milter that'll check for & reject headers > 3) Amavisd's built in header handling It all depends on things we don't know: 1) What's the actual end goal of this? 2) What's easier for you? Since you mention amavisd and milter (and also your email domain, haha) I suppose your interest is in spam control/abatement. If so, start with postscreen, first: http://www.postfix.org/POSTSCREEN_README.html http://rob0.nodns4.us/postscreen.html > I can actually get all three to work pretty much the way I want. > > Is there any reason to use one over the other if they're all > doing it PreQueue? > > Is it more efficient to use a separate milter than to use > Postfix's built in stuff? You're unlikely to come up with anything on your own which is a better email content filter than SpamAssassin. But there too, content filtering is less safe and accurate than pre-DATA checks. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Sender dependent relay: Reject unknown senders
On Fri, Jul 21, 2017 at 10:36:47PM +0200, Michael Büker wrote: > sorry to bump myself here, but can anyone say if what I'd like is > even possible with postfix? Of course. > Should this be a feature request to the devs, maybe? If so that would be done here also. > On 18.07.2017 13:02, Michael Büker wrote: > >Here's two alternate ideas of how I would like postfix to behave > >instead: > > > >1. Postfix should reject all mail that doesn't have a "From: " > >identity associated with a relayhost in > >sender_dependent_relayhost_maps. You'd want a check_sender_access restriction lookup against the sender address list. A nice way to keep such a list in one file would be a sqlite database. For the restriction it would simply return "OK": [ main.cf ] [ ... ] sender_dependent_relayhost_maps = sqlite:/path/to/sender/relay-query smtpd_sender_restrictions = check_sender_access sqlite:/path/to/sender/access-query, reject The sender_dependent_relayhost_maps query would use the same sqlite backend and same basic query, but the access query would have a "result_format = OK". (You can use any lookup table type you want, I am merely making a suggestion in the interest of having all the data in one place.) > >2. Postfix should *only* relay through one of the hosts in > >sender_dependent_relayhost_maps (or deliver locally), and *never* > >try to deliver directly to some external domain's MX. That one could be done with "default_transport = error:not allowed" and replacing sender_dependent_relayhost_maps with sender_dependent_default_transport_maps. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Setting up multiple transport mappings for fallback relay mailserver
On Thu, Jul 20, 2017 at 04:30:38PM +, Pedro David Marco wrote: > > Wietse > >http://www.postfix.org/postconf.5.html#smtp_fallback_relay > > > is there any chance to suggest a future feature to have this done > via the transport file? The transport_maps lookup is not necessarily a "file", FWIW. It could be any supported maptype. Anyway, the requested functionality already exists through the creative use of MX records. The lack of "[]" brackets around a hostname tells Postfix to look up MX records for the name. For example: [ transport mapping ] example.org smtp:relays.example.net [ DNS records ] relays.example.net. MX 1 1.relays.example.net. relays.example.net. MX 2 2.relays.example.net. 1.relays.example.net. A 192.0.2.25 2.relays.example.net. A 192.0.2.26 The DNS names used do not have to be globally available; they could be in a private zone only queried by the Postfix server. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: SASL auth only on port 25
On Wed, Jul 19, 2017 at 05:44:56PM +1000, Simon Wilson wrote: > >>>On Apr 27, 2017, at 12:45 PM, Simon Wilson > >>><si...@simonandkate.net> wrote: > 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, These two cause no harm, but they are unlikely to be used. > 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? For main.cf I recommend "reject_unauth_destination" only. Then explicitly override that for submission in master.cf, as such: mua_relay_restrictions = permit_sasl_authenticated, reject (Add other permit_* as you need, before reject.) Then as per the example master.cf you would have under submission: -o smtpd_relay_restrictions=$mua_relay_restrictions -o syslog_name=postfix/submission ... This way you will not accept anything for relay on port 25, and you'll require all users to authenticate on submission. If you have users submitting on port 25 you will have to tell them to change. You'll especially want to do this so you can have postscreen controlling access for mail exchange; postscreeen does not play nicely with MUAs, and end users' IP addresses are commonly found in Spamhaus Zen via PBL and/or XBL. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: postscreen fail2ban filter
On Mon, Jul 17, 2017 at 01:33:24PM -0400, Wietse Venema wrote: > I don't think there is much to gain from parsing postscreen logging > to produce fail2ban rules. postscreen is designed to handle a lot > of abuse with near-zero resources. Granted, not much benefit within Postfix. But consider: these botnets are also attacking other services: http, ssh, DNS, and more. I think it's a reasonable goal to want to block botnets in the firewall. [ Linux-specific ] We do it with ssh attacks here using the "recent" iptables module. (On my TODO is a plan to port those rules to the --match set and --jump SET modules and ipset(8).) These attacks, when exceeding established maximum new connection rates, cause the attacker to be entirely blocked in the firewall. That obviously won't work for SMTP, where [FSVO] legitmate sites might have a bunch of new connections in short periods. For ssh, we're using the assumption that these connections are humans who are seeking shell access, although indeed a poorly-written script could easily go beyond the limits. So the move to ipset would allow broader participation in attack deflection; fail2ban could help populate the firewall blocking with input from httpd, named, and others (including Postfix.) Another advantage of firewall blocking is at the human level: decrease of noise in the logs, to potentially save time for the admin. I haven't had many systems which were vulnerable to the brute-force ssh attacks, but I don't need to see that spam in the system logs. To be clear, I don't have an answer for the OP; I am just tossing out a couple of coins in support of the goal. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: postscreen dnsbl AND smtpd_recipient_restrictions rbl?
On Sat, Jul 15, 2017 at 10:30:25AM -0700, techlist06 wrote: > I'm converting to use postscreen. I have a question about dnsbl's > in postscreen vs smtpd_recipient_restrictions > > Following threads here and a git by Steve Jenkins I was going to > start with this for postscreen: > > postscreen_dnsbl_sites = > zen.spamhaus.org*3 This looks similar to my own config, from which I think Steve adapted his. I presume therefore that you're using a threshold of 3? > bl.mailspike.net*2 > b.barracudacentral.org*2 > bl.spameatingmonkey.net > bl.spamcop.net > dnsbl.sorbs.net > psbl.surriel.com > swl.spamhaus.org*-4 SWL is no longer active; the zone has been emptied. > 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 > > I had my smtpd_recipient_restrictions RBLs as: > ... > reject_rbl_client zen.spamhaus.org=127.0.0.[2..255], > reject_rhsbl_client dbl.spamhaus.org=127.0.1.[2..99], > reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99], > reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99], > reject_rbl_client bl.spamcop.net > reject_rbl_client psbl.surriel.com I would not use those two to reject outright. If you wanted to do that, why not just increase their postscreen scoring to 3? > reject_rbl_client cbl.abuseat.org, While there can be occasional slight lag between XBL (part of Zen) and CBL, that's not significant. You already have this query, in effect, through the Zen lookup. > I've seen in other threads configs that left some but not all rbl's > in their smtpd_recipient_restrictions. If I'm going to reject no > matter what at smtpd_recipient_restrictions, it seems I should give > that rbl a high score in postscreen checks and not do the second > check in smtpd_recipient_restrictions? I understood that the > second lookup is "free" since it's cached, but is there any > advantage/disadvantage to having both? Advantages: - Second chance in case of slow DNS response to dnsblog(8) - Second chance in case a Zen-listed host was on one of your DNS whitelist queries (these should be rare, and I think the popular DNSWL services check Zen against their own lists.) Disadvantage: - The tiny time and CPU expenditure of the second, cached lookup > Any advise appreciated. It really can't hurt to leave it enabled, if it's a DNSBL you considered worthy to use to block outright. I would, however, advise you to remove the PSBL and spamcop smtpd restrictions. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Postfix 3.2.0 - Sending to all MX records
On Thu, Jul 13, 2017 at 02:02:09PM +0100, Dominic Raferd wrote: > On 13 July 2017 at 13:56, Daniel Caulfield > <daniel.caulfi...@giacom.com> wrote: > > > How would we go about getting you a copy of the 'postfix/smtpd' > > logs? where would they be or how do we switch that on? > > They will be in the same place, you can extract them thus: > > grep "/smtpd" /var/log/maillog This was not good advice, because there are likely relevant bits being logged by other Postfix daemon processes. Also, it likely results in a large amount of irrelevant results. I wrote a quick little document about how to condense relevant logs from the sometimes overwhelming amount of information in Postfix logs. It's posted here, and comments and suggestions are solicited and appreciated: http://rob0.nodns4.us/postfix-logging (Just a plain-text file for now, no HTML yet.) I think Noel said he was going to start on something like this, and perhaps he has but I missed it. Noel, if this is useful to you in that effort please feel free to adapt and/or incorporate it. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Postfix 3.2.0 - Sending to all MX records
On Wed, Jul 12, 2017 at 07:08:34AM -0700, Tom Hudson wrote: > Firstly, apologies if I haven't included all of the relevant > information in this initial post. Please let me know if I have > missed anything. Full "postconf -nf ; postconf -Mf" and complete non-verbose logging of a single email which demonstrates your issue. > I am currently running Postfix 3.2.0 and have a problem relating to > MX records and defered messages. What I have identified is, if a > domain our server is trying to send to has an MX record which > returns no response, the message is defered. Every time postfix > attempts to redeliver this message, it uses the same lowest > priority MX record. > > I have found examples in our mail queue which are deferred with the > reason "unknown mail transport error". When I attempt to telnet to You have changed a transport(5)-related setting to something which isn't a valid transport in your master.cf. > the MX records for their domain, their lowest value MX is not > contactable but the others are. > > We can see no traffic attempting to go from postfix to the other MX > records, only the lowest value every time. > > I understand that it should be standard practice for Postfix to > first attempt the lowest value and then attempt to use all other MX > records before deferring the message. > > Can anyone advise why this isn't working for me? I'll include any > postconf settings which I think are relevant below and please tell > me if you need any more information; > > ignore_mx_lookup_error = no > smtp_defer_if_no_mx_address_found = no > smtp_mx_address_limit = 20 > smtp_mx_session_limit = 5 > smtp_skip_5xx_greeting = yes > smtp_skip_quit_response = yes See above. This is not useful. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: postscreen with postgrey - can they cause a double reject?
On Fri, Jul 07, 2017 at 05:18:49PM -0500, techlist06 wrote: > - postscreen with postgrey - can they cause a double reject? Reject, no; deferral, of course yes. > I searched for answers regarding using both postscreen and > greylisting. I saw some differing opinions. But I did not > see this point covered. My opinion is that postscreen is a much better greylisting-like implementation. I do not recommend other greylisting now (and this opinion dates back many years.) > Assuming a clients first connection to me to deliver and > Assuming that postscreen is configured for deep protocol tests, > and the connection passes all tests. > > I understand postscreen will temporary whitelist the IP but the > client must reconnect in order to deliver. Yes, but see: http://www.postfix.org/postconf.5.html#postscreen_dnsbl_whitelist_threshold Most legitimate senders are listed in the DNSWL.org whitelist. Clients in that list (without offsetting DNSBL listings, which have been very rare) bypass postscreen's delaying behavior. > On that second connection, postscreen hands off to postfix > due to the temporary whitelist. Postscreen IS Postfix; it hands off to smtpd(8). > If I have greylisting configured, as I have done it in the > past in main.cf: > > smtpd_recipient_restrictions > ... > check_policy_service unix:postgrey/socket > permit > > Won't this second connection get temp rejected by my normal > greylisting a second time? The regular greylisting won't know > about the postscreen's recent pass. So won't the client would > have to connect for a 3rd time to deliver? > > That would seem to me to be an argument against using both, or Correct. > at least using both with postscreen's deep protocol tests > enabled. > > I'd be grateful to be straightened out if I have it wrong. Just stick with postscreen's deep protocol tests. Greylisting won't block anything that got through postscreen's delay. All pain, no gain, with greylisting behind postscreen. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Require TLS on internet-facing servers?
On Fri, Jul 07, 2017 at 10:40:47AM -0700, robg...@nospammail.net wrote: > I am starting to setup a Postfix server for our office. > > I'm looking at TLS policy. > > Reading old posts on the Postfix mailing lists there's lots of > comments that REQUIRING tls should never be done on an public > internet-facing server. > > But those comments are from 5-7 yrs ago. > > Is that still the case? > > On a friend's server we just checked 3 months of logs. IIUC > there's been no non-TLS connections at all in that time: I use a warn_if_reject reject_plaintext_session restriction at end-of-DATA, so I have some numbers which might not be relevant to anyone else, but there are two main classes of plaintext mail arriving at my site: 1. Legitimate (solicited & confirmed) marketing mail 2. Free software project mailing lists (not this one) Your numbers (and classes) would vary if you tinker with TLS settings such that you won't accept "weak" ciphers. (Is a weak cipher weaker than plaintext?) My cipher settings are all Postfix defaults. > Second, if there are actually no non-encrypted connections, is > it time finally to simply require it? I won't. It's not like TLS in SMTP is going to make a huge difference for privacy. I suppose big mail services like gmail are scanning mail content for their own use, and quite likely are allowing national governments to do the same. TLS addresses a single, relatively minor security concern, of protection of data in transit. Yes, that is a good thing, but remember: you're also trusting the administrators of the other endpoint. If you really want to be a privacy advocate, start using GnuPG for end-to-end email encryption. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Returning an Error Response
On Thu, Jul 06, 2017 at 11:45:01AM -0700, Doug Hardie wrote: > When using virtual domains, (That part is not relevant.) > is there a way to return a temp fail message for a specific > user in a domain? I am not finding anything about that in the > documentation. http://www.postfix.org/SMTPD_ACCESS_README.html http://www.postfix.org/access.5.html http://www.postfix.org/postconf.5.html#check_recipient_access main.cf : ... smtpd_recipient_restrictions = ... check_recipient_access hash:/path/to/rcpt-tempfail ... ... /path/to/rcpt-tempfail : u...@example.com450 4.2.1 This mailbox is unavailable Don't forget: "postmap /path/to/rcpt-tempfail" -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: something like smtp-limiter plugin for ISPConfig
On Thu, Jul 06, 2017 at 03:01:22PM +0200, Poliman - Serwis wrote: > I am looking for some plugin which is similar to smtp-limiter > which is for DirectAdmin. It would be nice if there would be any. What does that plugin do? What is the actual problem you're trying to solve? BTW, this is not the place for ISPConfig support. If you're using Postfix through some kind of management frontend, you need to use support offerings of that company or their user community. > If not, is there any similar plugin which can be manage by the > linux console? I'm going to guess that the real problem might be spam sent by authenticated users' malware. You can mitigate that with content filtering on submission mail, specifically with URIBL lookups, because practically all of this malware will be spewing references to URIBL-listed web sites. Also, a policy service such as postfwd[1] or cbpolicyd[2] can be deployed to limit users' sending. Generally this kind of malware exceeds a human user's ability to send mail. [1] http://postfwd.org/ratelimits.html [2] https://wiki.policyd.org/quotas -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: is there a RFC which suggests that the helo name should be DNS resolvable
On Wed, Jul 05, 2017 at 03:11:57PM -0400, Miles Fidelman wrote: > The language in RFC 5231 does not explicitly say that the HELO name > should be resolvable, but strongly implies it. No, it does. Note that "domain" is given as the argument to EHLO, and see how "domain" is defined in 2.3.5. See also the discussion of EHLO in 2.3.5: " o The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4." That's a MUST. Either resolve to an address or use an address literal. If we're RFC-lawyering, however, note that it does not explicitly require that the EHLO name resolves to the connecting client's address, just to "an address". And continuing, any site MAY have policies which are not set out specifically in RFC 5321 or other standards. So this whole discussion probably is pointless. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: is there a RFC which suggests that the helo name should be DNS resolvable
On Wed, Jul 05, 2017 at 06:57:17PM +0200, Stefan Sticht wrote: > is there a RFC or similar which suggests/requires that the helo > name should be DNS resolvable? I think you are looking for RFC 5321: https://tools.ietf.org/html/rfc5321#section-2.3.5 See also section 4.1.4 as linked from there, and also 4.1.1.1 which explicitly lays out the EHLO/HELO syntax. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Service currently unavailable
mtp inet n - n - 1 postscreen > -o smtpd_proxy_filter=localhost:10025 > -o smtpd_client_connection_count_limit=10 > -o smtpd_proxy_options=speed_adjust > > # fuglu include > 127.0.0.1:10026 inet n - n -- smtpd > -o smtpd_authorized_xforward_hosts=127.0.0.0/8 > -o smtpd_client_restrictions= > -o smtpd_helo_restrictions= > -o smtpd_sender_restrictions= > -o smtpd_recipient_restrictions=permit_mynetworks,reject > -o smtpd_data_restrictions= > -o mynetworks=127.0.0.0/8 > -o receive_override_options=no_unknown_recipient_checks > > smtpd pass - - n - - smtpd > -o smtpd_proxy_filter=localhost:10025 > -o smtpd_sasl_auth_enable=no > > dnsblog unix - - n - 0 dnsblog > tlsproxy unix - - n - 0 tlsproxy > > submission inet n - n - - smtpd > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes > -o smtpd_sasl_type=dovecot > -o smtpd_sasl_path=private/auth > -o > smtpd_recipient_restrictions=reject_unknown_recipient_domain,reject_non_fqdn_recipient,permit_sasl_authenticated,reject > -o smtpd_tls_dh1024_param_file=/etc/postfix/dh/dh2048.pem > > pickupunix n - n 60 1 pickup > cleanup unix n - n - 0 cleanup > qmgr unix n - n 300 1 qmgr > #qmgr unix n - n 300 1 oqmgr > tlsmgrunix - - n 1000? 1 tlsmgr > rewrite unix - - n - - trivial-rewrite > bounceunix - - n - 0 bounce > defer unix - - n - 0 bounce > trace unix - - n - 0 bounce > verifyunix - - n - 1 verify > flush unix n - n 1000? 0 flush > proxymap unix - - n - - proxymap > proxywrite unix - - n - 1 proxymap > smtp unix - - n - - smtp > relay unix - - n - - smtp > # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 > showq unix n - n - - showq > error unix - - n - - error > retry unix - - n - - error > discard unix - - n - - discard > local unix - n n - - local > virtual unix - n n - - virtual > lmtp unix - - n - - lmtp > anvil unix - - n - 1 anvil > scacheunix - - n - 1 scache -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: postfwd
On Sat, Jul 01, 2017 at 10:45:50AM -0600, @lbutlr wrote: > After installing the latest postfix I thought I’d look into postfwd. > > 1) is this the right place to ask about this package? Probably not. They have their own mailing list IIRC. > 2) Is this package generally recommended or not? I know no reason to steer you away from it, but the one I have used is "cluebringer" or cbpolicyd, formerly "policyd". > 3) It appears to me postfwd does largely what post screen would > already do. Is that correct or am I missing something? Well, I suppose it could do something like DNSBL scoring if you configured it to do that, but it can also do things postscreen cannot, such as, complex policy decisions based on various elements. Most importantly for many sites, it can do rate limiting for your authenticated users, to stop them if they have malware spewing spam. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA
On Wed, Apr 20, 2016 at 01:19:29PM -0500, I wrote: > On Wed, Apr 20, 2016 at 03:53:24PM +, Viktor Dukhovni wrote: [ LE certificate expired, DANE notification received ] > My temporary fix was to remove the TLSA records, sorry. I cannot > risk losing mail as my poor brain tries to digest all this. :) 14 months later I got back to this. :) > I'm going to consider my options here before I replace the TLSA > records. I am thinking I only want my LE cert on submission (so > that MUAs will be able to verify it) and to replace my port 25 cert > with one from my own private CA. And this is what I have done, initially on domain nodns4.us, but several other zones are signed and will be using TLSA records. Thanks again for all your work on DANE and Postfix. Thanks also to P@rick and the sys4.de gang for the validation site. Question: I noticed my domain in a drop-down list there. Is the validation site maintaining a list of DANE-enabled and former DANE zones? IOW, should I drop a note to Victor when adding more zones, or is the validation site taking care of that? -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: gmail servers on blacklists?
On Fri, Mar 17, 2017 at 05:12:07PM -0400, David Mehler wrote: > I'm starting to see blocks on my messages to my mail server. For some > reason postscreen is not letting any gmail servers send mail, it's > blocking them. > > Has anyone got an idea or have you seen this? Typically you would SHOW LOGS of the blocking when asking for help, but in your case it's pretty obvious. > Here's my postscreen setup: > > # postscreen(8) settings > ### Before-220 tests > postscreen_greet_action = enforce > postscreen_blacklist_action = enforce > postscreen_dnsbl_action = enforce > postscreen_access_list = permit_mynetworks > cidr:/usr/local/etc/postfix/postscreen_access.cidr > postscreen_dnsbl_reply_map = > pcre:/usr/local/etc/postfix/postscreen_dnsbl_reply_map.pcre > postscreen_dnsbl_sites = zen.spamhaus.org*3 > b.barracudacentral.org*2 > bl.spameatingmonkey.net*2 > dnsbl.ahbl.org*2 Closed as of 2015-01-01 when it began flagging EVERYTHING by means of a DNS wildcard. Read: http://www.ahbl.org/ (click through to the main page) and http://rob0.nodns4.us/postscreen.html In the latter start with the BIG FAT WARNING and then take special note of what it says about AHBL in the "Last Changes" section. >bl.spamcop.net > dnsbl.sorbs.net > psbl.surriel.com > bl.mailspike.net > swl.spamhaus.org*-4 > list.dnswl.org=127.[0..255].[0..255].0*-2 > list.dnswl.org=127.[0..255].[0..255].1*-3 > list.dnswl.org=127.[0..255].[0..255].[2..255]*-4 These are as I published them but they are wrong. Better: 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 This corresponds to DNSWL.org's own usage instructions. > postscreen_dnsbl_threshold = 2 > postscreen_dnsbl_whitelist_threshold = -2 Looks familiar except you changed these two threshold values. Just stick with what I have: postscreen_dnsbl_threshold = 3 postscreen_dnsbl_whitelist_threshold = -1 Your lower postscreen_dnsbl_threshold value caused every single AHBL listing (which, in case you didn't understand, now includes the entirety of the Internet) to be a rejection unless offset by a whitelist entry. Your higher whitelist threshold makes it more difficult to avoid the after-220 tests ... > ### End of before-220 tests > ### After-220 tests > ### WARNING -- See "Tests after the 220 SMTP server greeting" in the > ### Postscreen Howto and *UNDERSTAND* it *BEFORE* you enable the > ### following tests! > #postscreen_bare_newline_action = drop > #postscreen_bare_newline_enable = yes > #postscreen_non_smtp_command_action = drop > #postscreen_non_smtp_command_enable = yes > #postscreen_pipelining_enable = yes > #postscreen_pipelining_action = drop > ### ADDENDUM: Any one of the foregoing three *_enable settings may cause > ### significant and annoying mail delays. ... which in your case doesn't matter because you didn't enable them. > Any assistance appreciated. Lose AHBL. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Bypass restrictions for postmaster/abuse
On Thu, Mar 09, 2017 at 04:12:32PM -0800, MRob wrote: > On 2017-03-09 14:35, /dev/rob0 wrote: > >On Thu, Mar 09, 2017 at 12:44:04PM -0800, MRob wrote: > >>Are there any admins with opinions where in the order is best > >>for postmaster/abuse whitelisting? > > > >My opinion is "don't do it." I use smtpd_reject_footer to > >point to my web page for frustrated human senders. If they're > >not smart enough to read the fine error message they got, > >they're going to struggle with fixing the problem, also. > > > >One thing my page suggests is that they can contact me through > >any typical freemail services, such as gmail, Yahoo, and GMX. > >Which is true: my postscreen and smtpd restrictions do not > >block them. > > OK, that's a great idea. Thank you for the tip. Is this quite > common? I can't speak to what is common, nor do I think anyone truly can. But I can tell you my story. I tried that, once, bypassing restrictions for my postmaster@ and abuse@ addresses. Of all the addresses I have, my postmaster@ addresses are the most heavily spammed. My site is small but it cannot be exclusive, because it's a free software project with worldwide users and contributors. I've only seen a handful of actual, legitimate messages to postmaster. (And then a few non-spam that should not have been sent to postmaster, also.) Sure, you can do what you want, and in theory it sounds prudent to exempt postmaster & abuse from spam controls, but in practice, it turns out only to be a way to get yourself a lot more spam. I don't have enough rejections to be able to gauge what others are doing at their sites. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Bypass restrictions for postmaster/abuse
On Thu, Mar 09, 2017 at 12:44:04PM -0800, MRob wrote: > Are there any admins with opinions where in the order is best > for postmaster/abuse whitelisting? My opinion is "don't do it." I use smtpd_reject_footer to point to my web page for frustrated human senders. If they're not smart enough to read the fine error message they got, they're going to struggle with fixing the problem, also. One thing my page suggests is that they can contact me through any typical freemail services, such as gmail, Yahoo, and GMX. Which is true: my postscreen and smtpd restrictions do not block them. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: unused parameter: virtual_mailbox_limit_maps
On Thu, Mar 09, 2017 at 11:04:02AM -0500, Robert Moskowitz wrote: > I found one article: > > https://www.howtoforge.com/community/threads/postfix-warning-undefined-parameter-virtual_mailbox_limit_maps.71474/ > > that says it is not required anymore. It never was a part of Postfix. This was from a third-party patch which never was accepted into Postfix, yet managed to gain a significant following somehow. Rule of thumb, if it's not found in the postconf(5) manual, it's not a valid Postfix setting. (That doesn't take into account user- defined variables and the possibility of transport-specific settings which are documented as default_* settings, but otherwise is pretty close to accurate.) Don't trust random bloggers without also consulting the Postfix documentation. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Postfix, Hotmail never arrive
On Sat, Mar 04, 2017 at 05:18:53PM -0500, Viktor Dukhovni wrote: > > On Mar 4, 2017, at 4:50 PM, Maurizio Caloro <mauri...@caloro.ch> > > wrote: > > > > If i send any mail go @hotmail this will never arrive, but > > Postfix Log are here in other thing. snip > > Hotmail took responsibility for delivery of the message. If it > never showed up in the user's mailbox, perhaps Hotmail considers > your IP address sufficiently "spammy" to discard your mail. > > Create a Hotmail account for yourself, and send the mail there, see > if it arrives. There's not much Postfix can do to get Hotmail to > not discard your mail. On the idea from someone in IRC, and working in conjuction with a colleague who was a Hotmail user, I confirmed that Hotmail was discarding my mail if it had only one Received: header. Sounds crazy, and really, it is. Adding a forged Received: header, just as many spammers do, landed me in his Inbox. Go figure. This was a whole decade ago, so no telling what might have changed in the meantime. Oh, and I was also able to reply to his originated mail. Their content filter looked for In-Reply-To: and/or References: also. > Some people advocate publishing SPF records and using DKIM > signatures. Though my mail gets delivered without either, > perhaps these would help your mail not get junked. I think it's still mostly about IP reputation, which changes very slowly, especially at big receivers like Microsoft. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: removing SASL Authentication
On Sat, Mar 04, 2017 at 09:27:43PM +, Igor Golubkov wrote: > Just use smtpd_relay_restrictions = permit_mynetworks, reject This *might* be acceptable for the OP, but note that it is applied to all mail, and therefore nothing outside of mynetworks would ever be accepted. This is DEFINITELY wrong for a server acting as a MX, hosting mail for an Internet domain name. > But changing this setting will not remove all those bots trying to > authenticate on your server. > > сб, 4 марта 2017 г., 23:57 Jon LaBadie <jlaba...@acm.org>: > > > When I first set up my home mail server I mashed several "postfix > > recipies" to get my working system. Not knowing why, this line > > made it into main.cf. > > > > smtpd_relay_restrictions = \ The leading whitespace is what tells Postfix you are intending to continue a logical line on the following actual line. > > permit_mynetworks, permit_sasl_authenticated This won't work either, because a restriction such as "reject" or "reject_unauth_destination" is required to prevent open relay. > > I have no need to relay mail from anywhere except my own > > network and I don't authenticate for that. Still, requiring AUTH is a good idea. > > I do get 500-1000 daily attempts to relay but because I never > > set up an SASL Authentication Server, none can ever > > authenticate. So it looks like you ARE a MX host, since you are getting these connections from the outside. Best practice is: main.cf : ... smtpd_relay_restrictions = reject_unauth_destination mua_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination This closes off relaying on port 25. Then uncomment "submission" service in master.cf, and have a line like this under it: -o smtpd_relay_restrictions=$mua_relay_restrictions The benefit is that you completely separate your MX stream from users' submitted mail. This is advantageous for spam control and filtering. And then of course your users would have to submit mail on port 587. If you're not going to allow roaming users to submit, you could simply block port 587 in the firewall. > > I'd like to get rid of the "permit_sasl_authenticated" setting, > > perhaps rejecting relay attempts earlier. But I'm hesitant that > > I may be creating a relay server due to other settings. > > > > Another current setting that may be pertinent is > > > > smtpd_sender_restrictions = permit_mynetworks \ > > reject_non_fqdn_sender reject_unknown_sender_domain > > > > Suggestions or advice on getting rid of the SASL settings, > > still allowing relay from my private network, yet not an open > > relay? I suggest: http://www.postfix.org/SMTPD_ACCESS_README.html -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: DNSBL, Spamhaus and postscreen filters
On Wed, Mar 01, 2017 at 05:49:35PM -0600, /dev/rob0 wrote in
haste, and now at leisure, corrects:
> I'm more familiar with BIND, and this will do it:
>
> # mv /etc/named.conf /etc/named.conf.distrib
# touch /etc/named.conf
> # echo "nameserver 127.0.0.1" > /etc/resolv.conf
> # named
A named.conf file is required, but being all empty means only the
default settings are used. By default named will do recursion for
the same host and for physically-attached networks.
You could tighten that up somewhat by telling it only to listen on
the loopback interface,
# echo "options { listen-on { 127.0.0.1; }; };" > /etc/named.conf
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: DNSBL, Spamhaus and postscreen filters
On Wed, Mar 01, 2017 at 10:00:28PM +, Robert Sharp wrote: > I was prompted from reading a recent post to check whether my > postscreen set up was picking up Spamhaus responses. Quick grep > through my logs confirmed that it was not. Seems I am in a bit > of Bind (sorry for the pun). If I use Google's DNS I dont get a > response from zen.spamhaus.org. Hi Robert, Yes, this is a known issue. Spamhaus blocks Google Public DNS and many ISP resolvers as well. > If I use my ISP's DNS I will but my ISP also hijacks NXDOMAIN > responses as I was reminded last night when postscreen blocked > everything. I am now looking at setting up my own unbound > server, but I wondered if there was a quicker solution. What's not quick? It should probably do what you need with minimal (if any) fuss. I'm more familiar with BIND, and this will do it: # mv /etc/named.conf /etc/named.conf.distrib # echo "nameserver 127.0.0.1" > /etc/resolv.conf # named Configure your OS (DHCP client if relevant) to leave resolv.conf alone, and set it up to start the BIND service at boot. I don't know the details of unbound, but I expect it is similarly trivial to set up. It really is the right solution, for a mail server, to have its own resolver. > Can I use the filter option to ignore those hijacked responses? > For example: > > postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[0..127]*3 You need clean name service for a mail server, period. And what happens when your ISP resolver gets blocked by Spamhaus? That said, your idea sort of works, until it doesn't. :) > I would just give it a go but after blocking everything I am a > little cautious today. Yes, I could add soft bounces but... -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Generate passw with Postfixadmin to add mysql ?
On Mon, Feb 27, 2017 at 07:48:00AM +0100, Maurizio Caloro wrote: > My setup running with Postfix+Dovecot+Roundcube+Mysql > > Now I need to add the Password function to roundcube and are > available now with the Passwd plugin, but I need to know > > with what hash I need to do this? How will postfixadmin > generate the passwort to add mysql db. Postfixadmin is a mysql/pgsql frontend which is not a part of Postfix, not supported on this list. I think they have a web forum for user-to-user support. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Simple (attempted) AUTH logging?
On Sat, Feb 25, 2017 at 08:23:44AM +, Dominic Raferd wrote:
> On 25/02/2017 05:28, Noel Jones wrote:
> >On 2/24/2017 5:55 PM, James wrote:
> >>I was hoping there might be some setting that would cause log
> >>entries like:
> >>
> >>postfix/smtpd[12345]: NOQUEUE: AUTH rejected from
> >>client.example.com[0.1.2.3], sasl_method=PLAIN,
> >>sasl_username=spam_r_us
> >>
> >>As long as the sasl_username was obviously hopeless then I
> >>wouldn't worry... but if they started using something that
> >>I thought they shouldn't know about then I'd start getting
> >>worried.
A comment here: at any kind of scale it will not be easy (I am
tempted to say "not possible") to make such a determination of a
worrisome condition other than by manual reading of these logs.
> >I'm pretty sure the sasl_username part of the log (and probably
> >the method too) is supplied by the sasl library, which is never
> >called when sasl isn't offered.
> >
> >When sasl isn't offered but the client sends AUTH anyway, it
> >should be possible for postfix to log the (sanitized) AUTH
> >command the client sends, but it will be encoded. The
> >encoding as recorded in the log may be (I think likely)
> >broken by the log sanitizer.
On Sat, Feb 25, 2017 at 08:23:44AM +, Dominic Raferd wrote:
> If you use dovecot for SASL authentication with settings log_path =
> syslog, auth_verbose = yes, then you can see attempted logins and
> the reason for failure easily enough:
>
> # grep "dovecot: auth: " /var/log/mail.log
But we are talking here about a case in which AUTH is not offered.
Again, as Noel pointed out, smtpd is not going to pass that forbidden
AUTH command to Dovecot.
What the OP wants is perhaps most closely related to the
reject_unauth_pipelining restriction, but for a specific ESMTP
command. But pipelining is different, as although it is enabled also
by virtue of an EHLO keyword, it's not a specific command; it's the
method by which a client presents multiple commands at once.
So in this case I suspect the actual code path is in the area of
smtpd_{hard,soft}_error_limit. At this point does smtpd know
anything about AUTH, or is it just one of infinite possible protocol
errors? Would it be feasible to treat it specially?
I don't think the OP's request is entirely without merit. Anything
which gathers information on botnets is good. This looks like a
possible case for log parsing and fail2ban. But I bet we usually
already know we're looking at a zombie without this extra bit of
information, so I wouldn't consider it a high priority.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: dovecot cram-md5 setting break sending emails
On Thu, Feb 23, 2017 at 04:08:21PM +0100,
wilfried.es...@essignetz.de wrote:
> Your problem with cram-md5 is, that you have
>
> "default_pass_scheme = CRYPT"
>
> in /etc/dovecot/dovecot-sql.conf.
>
>
> As mentioned in this text from my last mail, you need to change
> the schema your passwords are stored in:
> >>> On http://wiki.dovecot.org/Authentication/PasswordSchemes
> >>> you'll find under "Non-plaintext authentication mechanisms":
> >>> "The problem with non-plaintext auth mechanisms is that the
> >>> password must be stored either in plaintext, or using a
> >>> mechanism-specific scheme that's incompatible with all other
> >>> non-plaintext mechanisms. In addition, the mechanism-specific
> >>> schemes often offer very little protection. This isn't a
> >>> limitation of Dovecot, it's a requirement for the algorithms
> >>> to even work.
The most common choice for mail is to require TLS for AUTH
(smtpd_tls_auth_only) and then only offer PLAIN mechanism. This
works well with encrypted password storage.
> >>> For example if you're going to use CRAM-MD5 authentication, the
> >>> password needs to be stored in either PLAIN or CRAM-MD5 scheme.
> >>> If you want to allow both CRAM-MD5 and DIGEST-MD5, the password
> >>> must be stored in plaintext. "
>
> You'll have to set an other default scheme in your
> /etc/dovecot/dovecot-sql.conf and recreate your passwords in the
> db. Read more in above mentioned URL.
Indeed, the Dovecot wiki has the answers to all the common Dovecot
questions, and the Dovecot list is the more appropriate place to ask
those questions.
On the Postfix side there really wasn't much going on; Dovecot was
failing to present a list of SASL mechanisms to smtpd -- both smtps
and port 25; apparently no submission service was configured.
Submission (port 587) should be configured in favor of the now-
deprecated smtps, and ideally, there would be no SASL AUTH offered on
port 25.
The advice to use verbose logging was wrong. Verbose logging in most
cases only serves to further confuse the issue.
> Or you can prefix every password with its scheme, but i don't
> remember details.
{PLAIN}thisIsMyPassword
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Know wich mail client connect in postix
> On Mon, Feb 20, 2017 at 02:48:15PM +, Luis Miguel Flores dos > Santos wrote: > > Hi, exist a way to know which mail client try or are connected in > > 587? Like Android Mail, Outlook, thunderbird? > > No, because to protocol doesn't care about "which client". The actual problem, whatever it is, might be better addressed from the angle of the IMAP server. MUAs generally do much more with the imapd than with postfix/submission; the latter is typically a short, single transaction. Perhaps there is no associated IMAP login, in which case there's a high probability that you're faced with malware. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Can anyone expain this difference between almost identical postfix installations
On Sat, Feb 18, 2017 at 05:43:03PM +, Chris Green wrote: > I am trying to diagnose why messages from on system fail to arrive > whereas identical messages from another similar system arrive > successfully. > > Both systems are single board computers running postfix 2.9.6 under > Debian. The main.cf on both systems is identical. Both systems are > connecting to the same SMTP server for relaying. > > On the system where the message is sent and received successfully I > see (in /var/log/mail.log):- > Feb 18 17:32:51 pi postfix/pickup[25898]: 2009B22C52: uid=1000 > from= > Feb 18 17:32:51 pi postfix/cleanup[25978]: 2009B22C52: > message-id=<20170218173251.2009b22...@pi.zbmc.eu> > Feb 18 17:32:51 pi postfix/qmgr[21159]: 2009B22C52: from=<ch...@zbmc.eu>, > size=294, nrcpt=1 (queue active) > Feb 18 17:32:52 pi postfix/smtp[25980]: 2009B22C52: to=<ch...@zbmc.eu>, > relay=mail3.gridhost.co.uk[95.142.156.18]:587, delay=0.97, > delays=0.15/0.11/0.36/0.35, 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 08DEC26AEC71) Here the relayhost seems to be using a content filter, and on the line above is reporting what it has heard through the filter. It also reports the queue ID on the other side of the filter, to wit: "08DEC26AEC71". > Feb 18 17:32:52 pi postfix/qmgr[21159]: 2009B22C52: removed > > > > On the system that appears to send OK but the message never > reaches its destination I see:- > > Feb 18 18:32:18 odin postfix/pickup[15648]: 05E963BC3: uid=1001 > from= > Feb 18 18:32:18 odin postfix/cleanup[15989]: 05E963BC3: > message-id=<20170218173218.05e963...@odin.zbmc.eu> > Feb 18 18:32:18 odin postfix/qmgr[14084]: 05E963BC3: > from=<ch...@zbmc.eu>, size=296, nrcpt=1 (queue active) > Feb 18 18:32:19 odin postfix/smtp[15991]: 05E963BC3: to=<ch...@zbmc.eu>, > relay=mail3.gridhost.co.uk[95.142.156.18]:587, delay=1.2, > delays=0.22/0.11/0.65/0.19, dsn=2.0.0, > status=sent (250 2.0.0 Ok: queued as EDA7EE0C39) Here we didn't get anything from the content filter. The answer of the question, "Why not?" is probably in the logs on the relayhost. > Feb 18 18:32:19 odin postfix/qmgr[14084]: 05E963BC3: removed > > > Does that 'queued as EDA7EE0C39' in the second case mean that the > message has been put on a queue rather than being sent? But why? > The messages are virtually identical, the destination address is > the same, etc. If you don't control the relayhost, talk to the admin there. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Multiple "from" fields
On Wed, Feb 15, 2017 at 10:15:14PM -0800, li...@lazygranch.com wrote: > Regarding multiple from fields, I found this on serverfault : > http://serverfault.com/questions/554520/smtp-allows-for-multiple-from-addresses-in-the-rfc-was-this-ever-useful-why-do > > I could almost see this being legitimate if from the same domain. > At least the SPF would be valid. > > But I think the argument is weak since the clients don't handle the > situation well. SMTP does not allow multiple MAIL FROM: addresses, and that's pretty much all that would be relevant for discussion in this mailing list. Postfix isn't going to focus on mail content issues, and its own built-in filtering feature (header_checks(5), body_checks(5)) is unable to deal effectively with this. Perhaps you would want to take up this question in a place for mail content filtering software? -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Postfix 20 years ago
On Sun, Feb 12, 2017 at 09:16:16PM +, Viktor Dukhovni wrote: > On Sun, Feb 12, 2017 at 01:06:42PM -0500, Wietse Venema wrote: > > > Last month it was 20 years ago that I started writing Postfix code. > > It is good to see thanks from users who've been with you all for > almost the entire time. By that standard, I came on board late, > when Bennett Todd introduced me to Postfix 1.0 in the spring of > 2001. Since that time, Postfix has for me been not only a pleasure > to use and contribute to, but also a standard of excellence. > > Thanks, much appreciated. I'd like to echo the thanks and add some to Victor and others. :) I've been here off-and-on for a long time, and I have learned much from this list. I don't remember exactly when I first posted here, but I bet it was 15 or more years ago. I was new to mail and Unix then; somewhere along the way I turned pro, but even now I continue to learn. This software and this mailing list are amazing resources. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Best way to run Postfix on a single server for multiple domains
On Mon, Feb 13, 2017 at 12:20:45PM +0530, Nitin N wrote: > Dear Rob (I hope that is your name), That works, but I also answer to "hey you" and various epithets (you can even google up a few from this very list. ;) ) > On Sat, Feb 11, 2017 at 8:53 PM, /dev/rob0 <r...@gmx.co.uk> wrote: > > On Sat, Feb 11, 2017 at 01:55:26PM +0530, Nitin N wrote: > > > Method 2] > > > > > > Use postmulti and create a separate instance for each domain. > > > In this case, I am not sure how complex it might get if I want > > > to create further instances for each domain to handle outgoing, > > > incoming and null-client scenarios. > > > > Why would you want to do this? If you're seeking Perfect > > Headers, why? Users mostly can't read nor understand headers. > > [Nitin:] > One reason why we would like to have Perfect Headers is that one > of the domains is a B2C platform where many users can register. We > want to reduce all possibilities (as much as we can) of our first > email to these users from getting marked as Spam. So, we believe > having a CA Trusted certificate might just add some more > credibility in this scenario. It probably won't help. Deliverability is a frequent concern for small sites, and there is no single clear answer (nor group of answers) that will guarantee Inbox access. Thank the spammers, sigh. The main steps are: 1. FCrDNS: your PTR value is $myhostname, which in turn resolves to your IP address. If you don't control the PTR you're sunk. 2. IP Reputation (more on that to follow) 3. Clean non-spammy practices (likewise) IP reputation depends mostly on clean, non-spammy practices, but it could also be linked to issues partly beyond your control, such as your hosting ISP's reputation for abuse. I say "partly" because you always have the option to move to better-regarded hosting. You can possibly improve your own reputation by signing up for DNSWL.org (and possibly other whitelisting services.) I use DNSWL myself with the postscreen_dnsbl_whitelist_threshold feature, and it is very useful. I doubt any major providers use DNSWL directly, but I bet they check their spam blocking against it. "Clean" means, of course, that you must not be the source of UBE, nor should you forward any UBE from your system to others. "Spammy practices" ... well, there are a lot of those, but they mostly boil down to attempts to evade blacklisting. If you're consistently sending from a single IP address (or netblock if you're big enough, but I don't think you'd be asking here if you were that big), with static forward and reverse DNS entries, you're not looking like a blacklist evader. Another spammy practice which might look tempting is to send "reminders" about registration emails. You should only send ONE single verification email, because before address verification you have no way to know that it was a valid address. > Honestly, I am not sure if we are being paranoid here since you > mention below that MTAs don't really verify if the certificate used > by another MTA is in fact Trusted or not. Right. And I said "probably won't help" above because it's possible that some providers might do occasional checks of certificates. But it certainly won't matter that "example.net" hosts handle mail from send...@example.com. > > > Method 3] > > > > > > Use FreeBSD jails for each domain and a common jail for all the > > > spam/virus protection services and use a proxy + NAT on the > > > main host. This could also help me use postmulti in each jail > > > in case I need to have multiple instances based on functions. > > > > > > So based on your experience/expertise, which method would you > > > recommend? > > Seems like not many have tried Method 3]. I think it might be a > good path to take from a scalability/security point of view, > although Jails do add some additional overhead from a maintenance > perspective. It seems like a lot of fuss for no actual benefit. You get the warm fuzzies when you examine your Received: headers, but that's not getting you out of spam folders. > > > Further, do you think I can stop using Postgrey as I also have > > > Postscreen enabled? > > > > With after-220 tests enabled, postscreen will easily block > > anything postgrey might have blocked. Also, greylisting, ISTM, > > is mostly defeated by spammers' current methods. It's typical > > for zombies to go through their lists more than once. > > Thanks, so that means it bye-bye Postgrey, thanks to Postscreen :) Yes, and I can recommend my own postscreen config, which you can find at: http://rob0.nodns4.us/postscreen.html Good luck. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Best way to run Postfix on a single server for multiple domains
On Sat, Feb 11, 2017 at 01:55:26PM +0530, Nitin N wrote: > Now, I have to migrate to a new server that is running FreeBSD 11. > I need to support 4 domains on this single server with each domain > having its own Trusted CA certified SSL digital certificate. > > I can think of three ways to accomplish this and I am looking for > some guidance based on your knowledge/experience with Postfix. > > Method 1] > > Use virtual domains on a single Postfix instance and override > master.cf to take care of the individual SSL certificate for each > domain using a separate IP in each case. Based on my research, I > believe this could get complicated with Postscreen and other > milters enabled. So I am not too keen on going this path. Correct > me if I am wrong... Postscreen (which, BTW, is *not* a milter) and submission do not play well together. If you must accept submission on port 25, do so with a distinct IP address which isn't published as MX for any of your domains, and only accept authenticated users there. If there's only one IP address and you cannot fix the problem of mail users submitting mail on port 25, you're probably going to have to disable postscreen. Certificates only matter on submission, and there only if your user base is large and beyond your control, such as at an ISP or university. Small-timers can just tell their users, "this is the TLS certificate we're using, accept it." > Method 2] > > Use postmulti and create a separate instance for each domain. In > this case, I am not sure how complex it might get if I want to > create further instances for each domain to handle outgoing, > incoming and null-client scenarios. Why would you want to do this? If you're seeking Perfect Headers, why? Users mostly can't read nor understand headers. > Method 3] > > Use FreeBSD jails for each domain and a common jail for all the > spam/virus protection services and use a proxy + NAT on the main > host. This could also help me use postmulti in each jail in case I > need to have multiple instances based on functions. > > So based on your experience/expertise, which method would you > recommend? Method 4: use a single IP address for mail, tell users what name it is (no reason why that name has to be "in their domain"), tell them what certificate they need to accept in their MUAs. Offer and accept AUTH only on port 587; accept mail exchange only on port 25. Your question and stated 3 methods indicate you don't understand much about the place of TLS in SMTP. Yes, a user sending mail through your server needs to check (and to trust) your certificate, but remote MTAs will usually not ask for it and do not care. > Further, do you think I can stop using Postgrey as I also have > Postscreen enabled? With after-220 tests enabled, postscreen will easily block anything postgrey might have blocked. Also, greylisting, ISTM, is mostly defeated by spammers' current methods. It's typical for zombies to go through their lists more than once. > I look forward to your responses. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: The "from" header looks like paypal but it is coming from somewhere else.
On Thu, Feb 09, 2017 at 06:16:36PM +0800, P.V.Anthony wrote: > Just got an scam email that looks like from paypal. > > It passed dkim and spf. > > dkim=pass (1024-bit key) header.d=service2.sdmone.email > header.i=sdmone@service2.sdmone.email header.b="adXLiw9w"; > dkim=pass (1024-bit key) header.d=mandrillapp.com > header.i=@mandrillapp.com header.b="JsfO1hqx" > > spf=pass (sender SPF authorized) smtp.mailfrom=mandrillapp.com > (client-ip=198.2.187.23; This appears to be from Mailchimp, so reporting it as abuse is likely to yield some satisfactory results. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Autoresponder?
On Thu, Jan 19, 2017 at 01:17:49PM +, Ralph Corderoy wrote: > > > Yes, that makes sense. I hadn't thought of vacation. > > > > Ah.. slight hiccough, the email is a sql account, not a shell > > account, so not .forward. > > No home directory for a .forward? How about /etc/aliases > instead? No, same problem: aliases(5) are only used by/for local(8) delivery and if local was in use for this account it would be solved. BTW a virtual user *should* have a home directory, but as there is no system account, .forward would not work. I can suggest to the OP to use a virtual alias pointing to a system user; then your .forward would work. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Configuration problems (postfix, dovecot, postgresql, thunderbird)
On Sat, Jan 14, 2017 at 12:34:26PM +0100, Mohamed Maalej wrote: > I installed Postfix and Dovecot on a Ubuntu 16.04 LTS machine. I > used PostgreSQL as a database. > > My configuration .txt file and the issues I found was hosted on > Guthub: > https://github.com/MedMaalej/Postfix-Dovecot-setup > > Please advise. Yes, don't do it this way. Post your information here. Also, the github post does not have any LOGS, and LOGS are always the first, most important step. See http://www.postfix.org/DEBUG_README.html#mail and share that information right here on the list. Based on the github post I can also suggest this: http://www.postfix.org/VIRTUAL_README.html -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Make postfix log to show how sender rewriting happens
> On Tue, Dec 20, 2016 at 7:35 PM, Viktor Dukhovni > <postfix-us...@dukhovni.org> wrote: > > > > > On Dec 20, 2016, at 12:53 AM, Burn Zero <burnze...@gmail.com> > > > wrote: > > > > > > As you can see the orig_to parameter shows the original id to > > > which the email was sent and the to= parameter explains the > > > rewritten email id. I can clearly see the email rewriting > > > happened. Similarly, I want to get the log entries for sender > > > rewrite. > > > > You can cause the envelope sender to be logged via the INFO > > action of access(5): > > > > main.cf: > > smtpd_end_of_data_restrictions = > > check_sender_access static:INFO > > On Fri, Dec 23, 2016 at 04:36:56PM +0530, Burn Zero wrote: > Thank you. But when I use > > smtpd_end_of_data_restrictions = > check_sender_access static:INFO > > I get, > > postfix/smtpd[13668]: warning: unknown smtpd restriction: "INFO > postfix/smtpd[13668]: 12E9F6420F: reject: END-OF-MESSAGE from > host[x.x.x.x]: 451 4.3.5 Server configuration error; > from=<root@host> to=<root@host> proto=SMTP The INFO action was added to access(5) in Postfix 3.0. Older versions have the functionally-identical "WARN" action. The presence of a manual page reference should be a hint for you to check that manual. Your own local "man 5 access" has no mention of the "INFO" action, but compare that to the online one, http://www.postfix.org/access.5.html BTW you might want to consider looking up this one in your own postconf(5) manual, and if you have it, set this: main.cf: enable_long_queue_ids = yes -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: request improved logging for postfix.
On Fri, Dec 16, 2016 at 09:56:26AM -0600, Noel Jones wrote: > No fixes are necessary, other than maybe I should write a tutorial > on reading logs. Oh, a LOG_README, an excellent idea! Later it can branch out into the various configuration knobs we might eventually see. Do you think you could start a draft sometime soon? I'd be happy to review and comment if you like. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: how to black hole unknown users on a server that acts as a mailing list
On Thu, Dec 08, 2016 at 02:58:24PM +, cmc wrote: > We have a server running Postfix, with mailing lists run by > Mailman, for a local domain. This server receives mail from an > upstream cloud-based server for all recipients not on the > cloud-based server (the idea being that any user not on the cloud > server is a mailing list). Ouch. Ugly and wrong. > The mail is relayed to the mailing list > server via another internal postfix server. Mail that is sent to > users that don't exists and are not mailing lists ends up on the > relay server, as it gets rejected with 'user unknown' by the > mailing list server when Postfix sees that it is not in the > local_recipient_maps. This ends up clogging up the relay server as > it tried to deliver (mostly spam) back to the originators. I think > the best solution may be to have the mailing list server to accept > mail received via SMTP that it doesn't have a local_recipient_map > for, and then forward it to /dev/null, but I'm not quite sure how > to do this. Or perhaps there is a way on the relay server to delete > mail it gets a 550 unknown response for. > > Any suggestions as to the best way to do this? Both the frontend (MX host) and the backend (Mailman host) need to have complete address lists for the domain (or domains) involved. Then transport_maps on each host should route the mail for the other host's addresses to that host. It's easy enough to replicate the Mailman aliases to the MX host, but replicating the MX host's address list to the internal Mailman host might be more of a problem. (Or it might not ... we don't know how you configured it.) Anyway, there it is, that's what you have to do. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Stopping compromised accounts
On Wed, Dec 07, 2016 at 10:01:54AM +0100, Julian Kippels wrote: > Am Tue, 6 Dec 2016 08:24:56 -0600 > schrieb /dev/rob0 <r...@gmx.co.uk>: > > > On Tue, Dec 06, 2016 at 08:59:56AM +0100, Julian Kippels wrote: > > > I use a policy deamon that registers every mail that is sent by > > > our servers. The metadata is stored in a SQL Database. Every two > > > minutes a cronjob is run which checks the metadata for which > > > sasl_sender has send how many mails. If a sasl_sender surpasses > > > a certain threshold the cronjob automatically blocks this user > > > in our LDAP so that he can't submit any more mails. > > > > First, I don't understand the need for the cron job. Just let the > > policy service keep track of the number of mails sent per SASL user > > and reject (or quarantine, via HOLD action, if that is better for > > your site) when the quota is reached. > > > > We use 4 MTAs that are load balanced. Without a central instance > keeping track of all mails it would be quite difficult to identify > a compromised account. Additionally we want to be able to view the > metadata afterwards. Hence we write it all to a postgres sql > database. So I'm still confused. Why can't the policy daemon write to and read from PostgreSQL also? > > Likewise, there is no need to have the interaction with LDAP. > > The policy daemon should be able to do this all natively. > > This is just to stay compatible to established procedures. We have > just switched to using postfix as our MTA software. Before this we > used to have Sun Java System Messaging Server. All we do in LDAP is > to scramble the userPassword-Hash, so that it is impossible for the > user to log in. This forces the user to use our to change their > password to a new, uncompromised one. Sure, but it's still better to reject a spam right away, as soon as you know the credentials are compromised. Seems like you have built in a delay. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Stopping compromised accounts
On Tue, Dec 06, 2016 at 08:59:56AM +0100, Julian Kippels wrote: > Am Mon, 5 Dec 2016 20:52:21 -0500 > schrieb Alex <mysqlstud...@gmail.com>: > > > I have a postfix-3.0.5 system with a few hundred users. They > > have access to submission, webmail, and dovecot to send and > > receive mail. > > > > On occasion, user's local desktop are compromised, and with it > > their account on this system. This leads to their local desktop > > using the submission service to send hundreds or thousands of > > spam emails through this compromised account. As another poster pointed out, sometimes the credentials have been shared with a botnet, and the spam can come from around the world. It's not only a matter of a desktop machine compromise. Sometimes mobile devices (phones, tablets) are involved. And sometimes the software holds secure but social engineering prevails! A user might be fooled into providing his/her email credentials in the wrong place. > > They're only stopped after the user receives a ton of bounce > > messages, or we happen to see it somehow while watching logs. > > > > What mechanisms are available to say, control the number of > > messages sent per day or otherwise be made aware of a pattern > > of messages being sent by an account that could be indicative > > of account compromise? There were numerous suggestions upthread which are of varying usefulness, depending on site-specific requirements, but Julian's answer here is the best overall for generic use, of what I have seen before starting this post. But it's not complete and can stand some improvement. :) > I use a policy deamon that registers every mail that is sent by > our servers. The metadata is stored in a SQL Database. Every two > minutes a cronjob is run which checks the metadata for which > sasl_sender has send how many mails. If a sasl_sender surpasses > a certain threshold the cronjob automatically blocks this user > in our LDAP so that he can't submit any more mails. First, I don't understand the need for the cron job. Just let the policy service keep track of the number of mails sent per SASL user and reject (or quarantine, via HOLD action, if that is better for your site) when the quota is reached. Likewise, there is no need to have the interaction with LDAP. The policy daemon should be able to do this all natively. What I have seen of these things suggests that the malware goes like a fire hose. They know they have a limited time before your site gets listed as a spam source, so they launch as much as they can as long as they can. A human sender is generally more like a squirt gun than like a fire hose. We can't spew unless we use software to do it for us. This generally is easy to detect with a policy service. If you look around you can probably find recipes for cbpolicyd and postfwd. Now, as for what Julian's reply was missing: first, maintain strict separation of user submission from MX (inbound, port 25) mail. Perhaps you already do this. The best practice recommendation is that SASL AUTH should only be offered on the submission service, by means of an " -o smtpd_sasl_auth_enable=yes" in master.cf. If you have legacy users you don't control, submitting on port 25, use a separate IP address for that. And the hostname given to your users to set up their MUAs must not be one of the published MX names. Next, use content filtering on submission. You can't use the same kind of tests that you use on MX mail, which is why the above separation is mentioned. But URIBL lookups are extremely effective against these. Another potential improvement to the policy daemon is as Sebastian suggested upthread: geoip lookups. If you're seeing connections originate from widely separate locations in the same time period, you're pretty certain that the account is compromised. I'm not an advocate of geoip in general, but it can be useful in this context. These are things anyone can safely use, whilst many of the other ideas might not be useful for some sites. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: What is the number means?
> On 12/02/2016 04:26 PM, Gao wrote: > > I'd like ask a dumb question: I see there are many things in > > Postfix which named as pipe(8), smtp(5), lmtp(8). So what is > > number 5 or 8 mean? Version number? > > On Fri, Dec 02, 2016 at 04:34:04PM -0500, Michael Munger wrote: > Linux man page numbers. Actually, no. See Wietse's post. Linux man page sections differ somewhat from the BSD standard used by Postfix. The most notable difference is that the Linux convention would put the superuser commands (such as postfix(1) and postsuper(1)) in section 8 of the manual along with the daemons. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: SV: SV: SV: block emails which pretend to originate from my domain
On Sat, Nov 19, 2016 at 01:33:34PM -0600, /dev/rob0 wrote: > A much simpler and better way to do this and to force the use of > submission for your clients is to change the default on port 25, > and to override relay restrictions in master.cf for submission, > port 587: > > main.cf : > > [ ... ] > mua_relay_restrictions = >check_sender_access , reject > smtpd_relay_restrictions = reject_unauth_destination > [ ... ] > > master.cf : > > [ ... ] > submission [ ... ] smtpd > -o smtpd_relay_restrictions=$mua_relay_restrictions > [ -o to unset any other restrictions in use, plus the ones > which are found in the sample master.cf submission entry ] > [ ... ] Sorry, I forgot to mention that the check_sender_access lookup should return "permit_sasl_authenticated" for any of your own domains or addresses. Without that "minor" detail things could be very bad. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: SV: SV: SV: block emails which pretend to originate from my domain
[ top-posting fixed ] > -Ursprungligt meddelande- > [mailto:owner-postfix-us...@postfix.org] För /dev/rob0 > > On Thu, Nov 17, 2016 at 05:31:43PM +0100, Sebastian Nielsen wrote: > > The advantage with using "permit_sasl_authenticated, reject" as > > check_sender_access in the global config, is that authenticated > > senders won't be able to send with a adress outside of your > > domain either, thus achieving both local spoof prevention for > > unauthenticated users, but also prevents foregin spoof from > > authenticated users. > > That's not true. > > "permit_sasl_authenticated" does exactly what it says, regardless > of sender address. If the client successfully authenticated, the > mail is accepted. On Sat, Nov 19, 2016 at 07:47:40PM +0100, Sebastian Nielsen wrote: > Im talking about this: > > smtpd_sender_restrictions = check_sender_access hash:/etc/file > > /etc/file (before postmap) > mydomain.com permit_sasl_authenticated, reject Please don't use a real domain as an example. We have example.com (and in many other TLDs besides com, guaranteed by RFC 6761 in net and org) for that. > The result is that if sender domain is mydomain.com, the policy > applied will be "permit_sasl_authenticated, reject". This will > result in any unauthenticated mail claiming to be from mydomain.com > to be rejected (, reject), even if the destination is authorized > since the policy stack will see a plain "reject" before > "reject_unauth_destination". This part is correct. > BUT, if the sender is NOT mydomain.com, the check_sender_access > will return nothing, thus there will be no > "permit_sasl_authenticated" on the policy stack, thus the mail will > be rejected with "Relay access denied" even for authenticated "Relay access denied" comes only in smtpd_relay_restrictions (or smtpd_recipient_restrictions in older versions.) Look again: your example is in smtpd_sender_restrictions and is therefore incorrect. > users, as the policy stack will end up on > "reject_unauth_destination" without seeing any > permit_sasl_authenticated. Your repeated reference to a "policy stack" suggests that you might wrongly believe there is a connection between the various smtpd_mumble_restrictions stages. There is not. Each stage must result in a permit action (or "DUNNO", which invokes the implied "permit" at the end of each one) or the mail is not accepted. More specifically, the result from any one "mumble" stage has no bearing on the result from any other stage. > (Note that this means that every instance of > "permit_sasl_authenticated" need to be replaced with > "check_sender_access hash:/etc/file") Okay, sort of. You didn't say this part before. It's true if you are replacing permit_sasl_authenticated in *relay* restrictions. BTW smtpd_relay_restrictions has a default setting which includes permit_sasl_authenticated, so that default would also have to be changed; your plan fails if smtpd_relay_restrictions are not specified in the main.cf file. A much simpler and better way to do this and to force the use of submission for your clients is to change the default on port 25, and to override relay restrictions in master.cf for submission, port 587: main.cf : [ ... ] mua_relay_restrictions = check_sender_access , reject smtpd_relay_restrictions = reject_unauth_destination [ ... ] master.cf : [ ... ] submission [ ... ] smtpd -o smtpd_relay_restrictions=$mua_relay_restrictions [ -o to unset any other restrictions in use, plus the ones which are found in the sample master.cf submission entry ] [ ... ] > You understand the idea now? I understood it before. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: SV: SV: block emails which pretend to originate from my domain
On Thu, Nov 17, 2016 at 05:31:43PM +0100, Sebastian Nielsen wrote: > The advantage with using "permit_sasl_authenticated, reject" as > check_sender_access in the global config, is that authenticated > senders won't be able to send with a adress outside of your domain > either, thus achieving both local spoof prevention for > unauthenticated users, but also prevents foregin spoof from > authenticated users. That's not true. "permit_sasl_authenticated" does exactly what it says, regardless of sender address. If the client successfully authenticated, the mail is accepted. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Postfix and IPV6
sendmail_path = /usr/sbin/sendmail.postfix > setgid_group = postdrop > smtp_tls_CAfile = /etc/postfix/cert/cacert.pem > smtp_tls_loglevel = 1 > smtp_tls_security_level = may > smtp_tls_session_cache_database = btree:/data/postfix/cache/tls_smtp_session > smtpd_client_connection_count_limit = 5 > smtpd_client_connection_rate_limit = 22 > smtpd_client_event_limit_exceptions = $mynetworks > smtpd_client_recipient_rate_limit = 100 > smtpd_client_restrictions = permit_sasl_authenticated, > hash:/etc/postfix/whitelist, hash:/etc/postfix/access Client restrictions of just a filename are going to use a check_client_access lookup. It's better to be specific about what you're trying to do. Also, "access" is a terrible name for an access(5) file. Its name should indicate how it is to be used. > smtpd_delay_reject = yes > smtpd_helo_required = yes > smtpd_helo_restrictions = permit_mynetworks, check_helo_access > hash:/etc/postfix/helo_checks, reject_invalid_hostname Like this, you specifically stated check_helo_access. That is better. That's deprecated syntax for the last one; it's now reject_invalid_helo_hostname. You might find it easier to keep all restrictions in one stage. You're all over the place with these. See here for the overview: http://www.postfix.org/SMTPD_ACCESS_README.html > smtpd_recipient_restrictions = permit_mynetworks, > permit_sasl_authenticated, reject_unauth_destination, > reject_rbl_client mail-abuse.org, MAPS RBL is a pay service, and I don't think that's the correct hostname for it. > reject_rbl_client sbl-xbl.spamhaus.org, Again, why not Zen? This looks like an ancient config, upgraded without keeping up-to-date on the services available. > reject_rbl_client blackholes.easynet.nl, Are you familiar with this one? I'm not (other than having seen it in many ancient configurations based on some blog post.) I would not use a DNSBL with which I am not familiar. > reject_rbl_client cbl.abuseat.org, This is included in Zen & sbl-xbl via XBL, so basically a wasted lookup. > reject_rhsbl_client mail-abuse.org, > reject_rhsbl_client sbl-xbl.spamhaus.org, > reject_rhsbl_client blackholes.easynet.nl, > reject_rhsbl_client cbl.abuseat.org Probably none of these (definitely not in the case of Spamhaus and CBL) are RHSBL services. And they never were. These were all wrong from the beginning. > check_recipient_access hash:/etc/postfix/check_recipients, That's good, because you're specific about what you're doing and you've given the file a descriptive name. However if you are using this for blocking, you should have put it before all those DNSBL queries. > check_recipient_access hash:/etc/postfix/access, This is bad for the filename, and for the fact that you're using the same file for a check_client_access lookup. Different things are looked up depending on the mumble in check_mumble_access. Please familiarize yourself with that (the above mentioned README can help.) > check_recipient_access ldap:/etc/postfix/ldap-spamfilter.cf, permit Likewise the LDAP lookup might have belonged above the DNSBLs. > smtpd_sasl_auth_enable = no > smtpd_sasl_local_domain = postfix The former is the default, does not need to be here; the latter makes no sense unless the former is "yes". > smtpd_sender_restrictions = permit_mynetworks, > permit_sasl_authenticated, You won't have SASL-authenticated clients if you've disabled SASL AUTH. > reject_unknown_sender_domain, hash:/etc/postfix/whitelist, Another implicit "mumble" which here in sender restrictions would be check_sender_access. And we used the same whitelist as a check_client_access lookup! That might not make sense. > check_sender_access hash:/etc/postfix/access, And wow, a third use of that same "access" file. > reject_rhsbl_sender dsn.rfc-ignorant.org The RFCI lists closed just over 4 years ago. You really should keep up-to-date on these services you are using. You're lucky that RFCI didn't put in a wildcard record, as some other retired DNSBL services have done. > smtpd_tls_CAfile = /etc/postfix/cert/cacert.pem > smtpd_tls_CApath = /etc/postfix/cert/CA > smtpd_tls_cert_file = /etc/postfix/cert/violina.mail.cert.pem > smtpd_tls_key_file = /etc/postfix/cert/violina.mail.key.pem > smtpd_tls_loglevel = 1 > smtpd_tls_security_level = may > smtpd_tls_session_cache_database = btree:/data/postfix/cache/tls_session > strict_rfc821_envelopes = no > transport_maps = hash:/etc/postfix/transport What is this doing? It's used to override DNS in specific cases. If you don't need to do that, don't set this. > unknown_local_recipient_reject_code = 550 > virtual_alias_maps = proxy:ldap:/etc/postfix/ldap-alias.cf > virtual_gid_maps = static:89 > virtual_mailbox_base = /data/postfix/maildrop/ > virtual_mailbox_domains = proxy:ldap:/etc/postfix/ldap-domain.cf > virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap-mailbox.cf > virtual_minimum_uid = 51 > virtual_transport = virtual > virtual_uid_maps = static:89 -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: smtp_bind_address affects outbound too?
On Tue, Nov 01, 2016 at 11:17:10AM -0400, D'Arcy Cain wrote: > I am not sure what I want. The smtp_bind_address has been in the > config for ages, possibly added by someone else. I don't mind if > Postfix listens on all interfaces and I can't even imagine a > scenario where I would want to limit outgoing interfaces. That's what you get with defaults for inet_interfaces and smtp_bind_address, so just take those out. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
