Re: Mail Routing Question

2017-11-16 Thread /dev/rob0
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

2017-11-16 Thread /dev/rob0
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

2017-11-16 Thread Peter
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

2017-11-16 Thread Doug Hardie

> 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

2017-11-16 Thread Alex
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

2017-11-16 Thread Benny Pedersen

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

2017-11-16 Thread Viktor Dukhovni


> 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.



RE: Mail Routing Question

2017-11-16 Thread Kevin Miller
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

2017-11-16 Thread Doug Hardie
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

2017-11-16 Thread richard lucassen
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

2017-11-16 Thread Wietse Venema
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.

2017-11-16 Thread P.V.Anthony

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