Tsumi's questions

From some days I noticing a strange whois output under CentOS 6.9 with .com domains:

whois google.com
[Interrogando whois.verisign-grs.com]
[whois.verisign-grs.com]
   Domain Name: GOOGLE.COM
   Registry Domain ID: 2138514_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.markmonitor.com
   Registrar URL: http://www.markmonitor.com
   Updated Date: 2011-07-20T16:55:31Z
   Creation Date: 1997-09-15T04:00:00Z
   Registry Expiry Date: 2020-09-14T04:00:00Z
   Registrar: MarkMonitor Inc.
   Registrar IANA ID: 292
   Registrar Abuse Contact Email: [email protected]
   Registrar Abuse Contact Phone: +1.2083895740
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
   Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited
   Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
   Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited
   Name Server: NS1.GOOGLE.COM
   Name Server: NS2.GOOGLE.COM
   Name Server: NS3.GOOGLE.COM
   Name Server: NS4.GOOGLE.COM
   DNSSEC: unsigned
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2017-07-31T15:24:36Z <<<

For more information on Whois status codes, please visit https://icann.org/epp

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar.  Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability.  VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.

From CentOS 7 I can see, instead, the classic, full, whois output:

whois google.com
[Interrogando whois.verisign-grs.com]
[Redirezione verso whois.markmonitor.com]
[Interrogando whois.markmonitor.com]
[whois.markmonitor.com]
Domain Name: google.com
Registry Domain ID: 2138514_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.markmonitor.com
Registrar URL: http://www.markmonitor.com
Updated Date: 2015-06-12T10:38:52-0700
Creation Date: 1997-09-15T00:00:00-0700
Registrar Registration Expiration Date: 2020-09-13T21:00:00-0700
Registrar: MarkMonitor, Inc.
Registrar IANA ID: 292
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +1.2083895740
Domain Status: clientUpdateProhibited (https://www.icann.org/epp#clientUpdateProhibited)
Domain Status: clientTransferProhibited (https://www.icann.org/epp#clientTransferProhibited)
Domain Status: clientDeleteProhibited (https://www.icann.org/epp#clientDeleteProhibited)
Domain Status: serverUpdateProhibited (https://www.icann.org/epp#serverUpdateProhibited)
Domain Status: serverTransferProhibited (https://www.icann.org/epp#serverTransferProhibited)
Domain Status: serverDeleteProhibited (https://www.icann.org/epp#serverDeleteProhibited)
Registry Registrant ID: 
Registrant Name: Dns Admin
Registrant Organization: Google Inc.
Registrant Street: Please contact [email protected], 1600 Amphitheatre Parkway
Registrant City: Mountain View
Registrant State/Province: CA
Registrant Postal Code: 94043
Registrant Country: US
Registrant Phone: +1.6502530000
Registrant Phone Ext: 
Registrant Fax: +1.6506188571
Registrant Fax Ext: 
Registrant Email: [email protected]
Registry Admin ID: 
Admin Name: DNS Admin
Admin Organization: Google Inc.
Admin Street: 1600 Amphitheatre Parkway
Admin City: Mountain View
Admin State/Province: CA
Admin Postal Code: 94043
Admin Country: US
Admin Phone: +1.6506234000
Admin Phone Ext: 
Admin Fax: +1.6506188571
Admin Fax Ext: 
Admin Email: [email protected]
Registry Tech ID: 
Tech Name: DNS Admin
Tech Organization: Google Inc.
Tech Street: 2400 E. Bayshore Pkwy
Tech City: Mountain View
Tech State/Province: CA
Tech Postal Code: 94043
Tech Country: US
Tech Phone: +1.6503300100
Tech Phone Ext: 
Tech Fax: +1.6506181499
Tech Fax Ext: 
Tech Email: [email protected]
Name Server: ns1.google.com
Name Server: ns4.google.com
Name Server: ns2.google.com
Name Server: ns3.google.com
DNSSEC: unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>> Last update of WHOIS database: 2017-07-31T07:15:42-0700 <<<

The Data in MarkMonitor.com's WHOIS database is provided by MarkMonitor.com for
information purposes, and to assist persons in obtaining information about or
related to a domain name registration record.  MarkMonitor.com does not guarantee
its accuracy.  By submitting a WHOIS query, you agree that you will use this Data
only for lawful purposes and that, under no circumstances will you use this Data to:
 (1) allow, enable, or otherwise support the transmission of mass unsolicited,
     commercial advertising or solicitations via e-mail (spam); or
 (2) enable high volume, automated, electronic processes that apply to
     MarkMonitor.com (or its systems).
MarkMonitor.com reserves the right to modify these terms at any time.
By submitting this query, you agree to abide by this policy.

MarkMonitor is the Global Leader in Online Brand Protection.

MarkMonitor Domain Management(TM)
MarkMonitor Brand Protection(TM)
MarkMonitor AntiPiracy(TM)
MarkMonitor AntiFraud(TM)
Professional and Managed Services

Visit MarkMonitor at http://www.markmonitor.com
Contact us at +1.8007459229
In Europe, at +44.02032062220

For more information on Whois status codes, please visit
 https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en
--

The first (and only) usefull thing that i notice is that, on CentOS 6.9, the whois doesn't do the redirect to whois.markmonitor.com:

[Interrogando whois.verisign-grs.com]
[Redirezione verso whois.markmonitor.com]
[Interrogando whois.markmonitor.com]

Anyone know anything about that? This happened first time last week...

I'm trying to overwrite default rule for public_html directory:

/home/[^/]*/((www)|(web)|(public_html))(/.+)?   unconfined_u:object_r:httpd_user_content_t:s0

Assigning the httpd_user_rw_content_t context

I tried to add another rule for the same path with:

semanage fcontext -a -t httpd_user_rw_content_t "/home/[^/]*/((www)|(web)|(public_html))(/.+)?"

But restorecon -R /home/user/public_html still assign httpd_user_content_t context.

Is there a way to overwrite the default rule? (Edit file_contexts.homedirs doesn't looks a good idea...)

The context:

I currently have a main MX that run spamassassin trough a direct filter:

smtp      inet  n       -       n       -       -       smtpd -o content_filter=filter
filter    unix  -       n       n       -       -       pipe flags=R user=spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

I also have a backup MX that run his spam checks and forward to my main mailserver.

The issue:

When a forwarded mail arrive to the main MX spam checks are done again and previous X-Spam-Flag: are overwritten (asd expected).

BUT, on main MX, the Received: header point to the backup MX, that cause RBL checks are done on wrong IP, always success and spam mails (correctly detected by backup MX) are marked again as "not spam" (an this is bad).

The question:

Is there a way to skip content_filter and keep original X-Spam-Flag: for mails that came from a specific host (the backup MX)?

I try to explain better...

Actually I have a standalone mailserver (CentOS7+postfix+dovecot) that provide some mailboxes for my domains and I want to add a Backup MX.

As said in lot of doc (http://www.akadia.com/services/postfix_mx_backup.html) a backup MX usually keep mails in his queue and keep try to forward them to the main MX server until it came back online.

But, as I know, is not possible to easy access to these mails in order to read them when the main MX server is down (yes, I can go to /var/spool/mail/somewhere by SSH in case of emergency but this is far away of "mailbox" concept).

So my idea is to deliver a copy of all mails that arrive on the backup MX to a local mailbox too where I can read them with a dedicated webmail. The other copy still be in mail queue ready to be delivered to the main MX when possible (as standard backup MX configuration).

So the question is, how do it? master.cf support customs route for mails (I use a pipe here to forward mails to spamassassin without use amavis, for example) but I wasn't able to locate an how-to/manual/example to do something like that.

UPDATE:

I found a workaround that works fine for me, I'll add it here and leave the question open for answers or suggestions because I'm not sure that is the best possible solution...

I actually configured the backup MX with the same postfix/dovecot config of main MX (with local mailboxes, users etc) and add it as MX to DNS (lower priority that main MX).

Then I configured a rule that add a BCC to all incoming mails following this guide: http://www.linuxmail.info/backup-mail-postfix/

In main.cf I added:

recipient_bcc_maps = pcre:/etc/postfix/backup_bcc.pcre
transport_maps = hash:/etc/postfix/transport
smtp_generic_maps = pcre:/etc/postfix/generic.pcre

The backup_bcc.pcre contain a rule that add a bcc adding .backupmx to the recipient domain (making it an invalid local domain):

/^(.*)@example\.com$/ [email protected]

The transport map contain a rule to forward all mails for .backupmx to the main MX:

.backupmx smtp:[1.2.3.4]

And must be compiled in db format with:

postmap /etc/postfix/transport

And the generic.pcre contain a rule to remove .backupmx ext before forward it to the main MX:

/^(.*)@example\.com\.backupmx$/ [email protected]

So, if a mail is sent to my backup MX (due main MX down) the mail is delivered to the local mailbox and forwarded to the main MX (or, if unreachable, keep in queue until came back online).

I also added

-o receive_override_options=no_address_mappings

to my master.cf as suggested by Rob here https://serverfault.com/a/28484/348531 in order to avoid duplicate-BCC problem cause by content filter.