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: always_bcc on outgoing mail
On 17/11/17 13:48, Alex wrote: > submission inet n - n - - smtpd ... > -o receive_override_options=$submission_overrides ... > submission_overrides = no_unknown_recipient_checks, > no_address_mappings, no_header_body_checks The problem is no_address_mappings in submission_overrides is preventing always_bcc from working ^. Peter
Re: Mail Routing Question
> On 16 November 2017, at 14:45, Viktor Dukhovni> wrote: > > > >> On Nov 16, 2017, at 5:32 PM, Doug Hardie wrote: >> >> I have a domain, say: aaa.com for which I receive mail. Currently I have A >> records in DNS for aaa.com and mail.aaa.com as well as a MX record for >> aaa.com. All three of them point to the same IP address which is where >> postfix is running. There is a political issue with the A record for >> aaa.com and it "needs" to be changed to elsewhere. I somehow seem to recall >> that there are some MTAs that do not use the MX records, but only check the >> A records. > > Any MTA that fails to check MX records is badly broken, and can barely > deliver email to any domains that matter (all the big players have > MX hosts separate from their A/ records used primarily for HTTP). > >> Will changing the A record for aaa.com cause the loss of some incoming mail > > No. > > -- > Viktor. > Thanks to all. I have changed the A record.
always_bcc on outgoing mail
Hi, I have always_bcc set on my postfix-3.1.4 system on fedora25 and it's working fine for incoming email, but not outgoing. Outgoing mail is sent via submission. I see there are other systems within our domain which do not use submission and are properly bcc'd. submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING -o receive_override_options=$submission_overrides -o syslog_name=postfix/submission -o cleanup_service_name=auth-cleanup -o smtpd_relay_restrictions=$mua_relay_restrictions I've included my postconf below. This server only receives mail from our external relay (and a few other local systems). This configuration originated from the configuration of that external relay, so some of it like the postscreen stuff probably isn't necessary. Also, is always_bcc what some companies use to provide "always on" email service to their clients/users? In other words, is there a way to store a copy of the email on one system and allow users to somehow access that when their primary system is unavailable? Considering always_bcc stores to a single mbox, some kind of mailbox management would be necessary? alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases allow_mail_to_files = alias,forward always_bcc = bcc-user biff = no bounce_queue_lifetime = 2d command_directory = /usr/sbin compatibility_level = 2 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix default_process_limit = 100 delay_warning_time = 4h disable_mime_input_processing = no disable_vrfy_command = yes header_checks = pcre:/etc/postfix/header_checks.pcre html_directory = no inet_protocols = ipv4 mail_owner = postfix mailbox_command = /usr/bin/procmail mailbox_size_limit = 0 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man maximal_queue_lifetime = 2d message_size_limit = 5024 meta_directory = /etc/postfix milter_default_action = accept milter_protocol = 2 mydestination = $myhostname, localhost.$mydomain, example.com mydomain = example.com myhostname = orion.example.com mynetworks = 127.0.0.0/8, 192.168.1.0/24, 68.123.193.40/29 newaliases_path = /usr/bin/newaliases non_smtpd_milters = $smtpd_milters postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr postscreen_blacklist_action = enforce postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = mykey.zen.dq.spamhaus.net*2 b.barracudacentral.org*1 postscreen_dnsbl_threshold = 1 postscreen_greet_action = enforce queue_directory = /var/spool/postfix rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps} readme_directory = /usr/share/doc/postfix/README_FILES relay_domains = $mydestination, $transport_maps, example.com sample_directory = /usr/share/doc/postfix/samples sendmail_path = /usr/sbin/sendmail setgid_group = postdrop shlib_directory = no smtp_send_xforward_command = yes smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtpd_authorized_xforward_hosts = $mynetworks smtpd_client_restrictions = check_client_access cidr:/etc/postfix/sinokorea.cidr, check_client_access cidr:/etc/postfix/asian-ip5.txt smtpd_helo_required = yes smtpd_milters = inet:127.0.0.1:8891 smtpd_recipient_restrictions = reject_non_fqdn_recipient, check_client_access hash:/etc/postfix/client_checks_special, check_sender_access hash:/etc/postfix/sender_checks_special, reject_non_fqdn_sender, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_invalid_helo_hostname, reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net, reject_rhsbl_sender mykey.dbl.dq.spamhaus.net, reject_rhsbl_helo mykey.dbl.dq.spamhaus.net check_client_access hash:/etc/postfix/client_checks, check_sender_access hash:/etc/postfix/sender_checks, check_recipient_access pcre:/etc/postfix/relay_recips_access, permit smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_ask_ccert = yes smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/privkey.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_req_ccert = no smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache submission_overrides = no_unknown_recipient_checks, no_address_mappings, no_header_body_checks tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport virtual_alias_maps = hash:/etc/postfix/virtual
Re: Mail Routing Question
Doug Hardie skrev den 2017-11-16 23:32: Will changing the A record for aaa.com cause the loss of some incoming mail? no, if that changed ip accept delivery of that recipient domain back to what mx does ?, it only defines a seperate hostname to deliver mail to if mail and other servicefs on hostnamea is not same as service on hostnameb eq if you only have single ip, do not use mx setup people are misguided if that say mx is needed to recieve emails, i have seen fool bounces that i need mx to recieve bounces, where the bounced text was rejected mail from me since i did inded not have a mx, i dont need a complex world setup for a single ip
Re: Mail Routing Question
> On Nov 16, 2017, at 5:32 PM, Doug Hardiewrote: > > I have a domain, say: aaa.com for which I receive mail. Currently I have A > records in DNS for aaa.com and mail.aaa.com as well as a MX record for > aaa.com. All three of them point to the same IP address which is where > postfix is running. There is a political issue with the A record for aaa.com > and it "needs" to be changed to elsewhere. I somehow seem to recall that > there are some MTAs that do not use the MX records, but only check the A > records. Any MTA that fails to check MX records is badly broken, and can barely deliver email to any domains that matter (all the big players have MX hosts separate from their A/ records used primarily for HTTP). > Will changing the A record for aaa.com cause the loss of some incoming mail No. -- Viktor.
RE: Mail Routing Question
You can point the A record for aaa.com to one IP and the MX record for it to another. I.e. aaa IN A 192.168.1.1 IN MX 10 192.168.1.2 All the MX record does is tell the world what mail host to use for a given domain. So you may have a web server running on aaa.com but not your email server. When someone queries aaa.com the A record is normally returned, but if the type is set to MX then the MX record is returned instead. 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. Be sure that you update the PTR records for the hosts when you change them... ...Kevin -- Kevin Miller Network/email Administrator, CBJ MIS Dept. 155 South Seward Street Juneau, Alaska 99801 Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357 -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Doug Hardie Sent: Thursday, November 16, 2017 1:32 PM To: Postfix users Subject: Mail Routing Question I have a domain, say: aaa.com for which I receive mail. Currently I have A records in DNS for aaa.com and mail.aaa.com as well as a MX record for aaa.com. All three of them point to the same IP address which is where postfix is running. There is a political issue with the A record for aaa.com and it "needs" to be changed to elsewhere. I somehow seem to recall that there are some MTAs that do not use the MX records, but only check the A records. Will changing the A record for aaa.com cause the loss of some incoming mail? -- Doug
Mail Routing Question
I have a domain, say: aaa.com for which I receive mail. Currently I have A records in DNS for aaa.com and mail.aaa.com as well as a MX record for aaa.com. All three of them point to the same IP address which is where postfix is running. There is a political issue with the A record for aaa.com and it "needs" to be changed to elsewhere. I somehow seem to recall that there are some MTAs that do not use the MX records, but only check the A records. Will changing the A record for aaa.com cause the loss of some incoming mail? -- Doug
postmap db
Hello list, 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. R. -- richard lucassen http://contact.xaq.nl/
PATCH: check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error
flowhosts: > Nov 14 10:53:54 fallback postfix/smtpd[7187]: warning: restriction > check_recipient_a_access returns OK for vasilnhdgz0sdiminut...@netgooya.com > Nov 14 10:53:54 fallback postfix/smtpd[7187]: warning: this is not > allowed for security reasons > Nov 14 10:53:54 fallback postfix/smtpd[7187]: warning: use DUNNO instead > of OK if you want to make an exception > Nov 14 10:53:54 fallback postfix/smtpd[7187]: NOQUEUE: reject: RCPT from > unknown[192.168.xxx.xxx]:53698: 451 4.3.5 Server configuration error; This patch applies to Postfix 3.0 and later. Wietse --- ./src/smtpd/smtpd_check.c- 2017-05-31 16:29:46.0 -0500 +++ ./src/smtpd/smtpd_check.c 2017-11-16 09:32:46.898378490 -0600 @@ -4044,7 +4044,7 @@ static void forbid_whitelist(SMTPD_STATE *state, const char *name, int status, const char *target) { -if (status == SMTPD_CHECK_OK) { +if (state->discard == 0 && status == SMTPD_CHECK_OK) { msg_warn("restriction %s returns OK for %s", name, target); msg_warn("this is not allowed for security reasons"); msg_warn("use DUNNO instead of OK if you want to make an exception");
Re: Is it compulsory for an outgoing smtp server to have FQDN.
On 16/11/2017 01:20, @lbutlr wrote: It is not compulsory, but the *vast* majority of servers that are not configured this way are spammers. You will reject some "legitimate" mail, but it is a tiny fraction of the illegitimate mail. When I tested this, more than 98% of the warnings were from spammer sites and private-space domains (like .local). Thank you all for replying. The answer are useful. I will inform them about this. P.V.Anthony smime.p7s Description: S/MIME Cryptographic Signature