MX and DNS records

[xtine]

Falko -

I restarted famd, ran postmap /etc/postfix/virtusertable, and restarted postfix. It seems I have the same problem that's described in this thread in regards to the virtusertable. Should I run the postmap command and restart postfix every so often? How often?
http://www.howtoforge.com/forums/arc...p/t-10321.html

In /etc/named.conf. Note: substitution names are used, in navy (b169.my.servername.com and anothervirtualhostname.com).

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
mail_owner = postfix
unknown_local_recipient_reject_code = 550
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = maildrop
html_directory = /usr/share/doc/packages/postfix/html
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/packages/postfix/samples
readme_directory = /usr/share/doc/packages/postfix/README_FILES
inet_protocols = all
biff = no
mail_spool_directory = /var/mail
canonical_maps = hash:/etc/postfix/canonical
virtual_alias_domains = hash:/etc/postfix/virtual
relocated_maps = hash:/etc/postfix/relocated
transport_maps = hash:/etc/postfix/transport
sender_canonical_maps = hash:/etc/postfix/sender_canonical
masquerade_exceptions = root
masquerade_classes = envelope_sender, header_sender, header_recipient
myhostname = b169.my.servername.com
program_directory = /usr/lib/postfix
inet_interfaces = all
masquerade_domains =
defer_transports =
mynetworks_style = subnet
disable_dns_lookups = no
relayhost =
mailbox_command =
mailbox_transport =
strict_8bitmime = no
disable_mime_output_conversion = no
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_client_restrictions =
smtpd_helo_required = no
smtpd_helo_restrictions =
strict_rfc821_envelopes = no
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,rejec
t_unauth_destination
smtp_sasl_auth_enable = no
smtpd_sasl_auth_enable = yes
smtpd_use_tls = yes
smtp_use_tls = yes
alias_maps = hash:/etc/aliases
mailbox_size_limit = 0
message_size_limit = 10240000
mydomain = anothervirtualhostname.com
mynetworks = 127.0.0.0/8
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_tls_auth_only = no
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
virtual_maps = hash:/etc/postfix/virtusertable
mydestination = /etc/postfix/local-host-names

Chipsafts -

first off, is it 'example.info' or 'example.com' ?

I had a typo. It's just a substitution.

there is no MX reported by the dig,
when is the last time you restarted the named ?

A couple of weeks ago when I set it up. I just restarted it and this is what's seen in /var/log/messages (substitutions in navy).

Jun 16 19:17:14 b169 named[31024]: shutting down: flushing changes
Jun 16 19:17:14 b169 named[31024]: stopping command channel on 127.0.0.1#953
Jun 16 19:17:14 b169 named[31024]: stopping command channel on ::1#953
Jun 16 19:17:14 b169 named[31024]: no longer listening on 127.0.0.1#53
Jun 16 19:17:14 b169 named[31024]: no longer listening on 11.111.11.111#53
Jun 16 19:17:14 b169 named[31024]: no longer listening on 192.168.1.2#53
Jun 16 19:17:14 b169 named[31024]: exiting
Jun 16 19:17:14 b169 named[27482]: starting BIND 9.3.2 -t /var/lib/named -u named
Jun 16 19:17:14 b169 named[27482]: found 1 CPU, using 1 worker thread
Jun 16 19:17:14 b169 named[27482]: loading configuration from '/etc/named.conf'
Jun 16 19:17:14 b169 named[27482]: listening on IPv4 interface lo, 127.0.0.1#53
Jun 16 19:17:14 b169 named[27482]: listening on IPv4 interface eth0, 11.111.11.111#53
Jun 16 19:17:14 b169 named[27482]: listening on IPv4 interface eth0:0, 192.168.1.2#53
Jun 16 19:17:14 b169 named[27482]: command channel listening on 127.0.0.1#953
Jun 16 19:17:14 b169 named[27482]: command channel listening on ::1#953
Jun 16 19:17:14 b169 named[27482]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42
Jun 16 19:17:14 b169 named[27482]: zone 11.111.11.in-addr.arpa/IN: loaded serial 2008060101
Jun 16 19:17:14 b169 named[27482]: zone example.com/IN: loaded serial 2008061501
Jun 16 19:17:14 b169 named[27482]: zone anothervirtualhostname.com/IN: loaded serial 2008060101
Jun 16 19:17:14 b169 named[27482]: running
Jun 16 19:17:14 b169 named[27482]: zone example.com/IN: sending notifies (serial 2008061501)

[falko]

Originally Posted by xtine

Should I run the postmap command and restart postfix every so often? How often?

I don't know why this happens (SUSE - sigh...), but you must do this whenever you see the warning.

Can you post your /etc/named.conf?

[xtine]

This is what's in my /etc/named.conf (I just chopped off the comments). Note: substitution names are used, in navy (b169.my.servername.com and anothervirtualhostname.com)

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
mail_owner = postfix
unknown_local_recipient_reject_code = 550
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = maildrop
html_directory = /usr/share/doc/packages/postfix/html
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/packages/postfix/samples
readme_directory = /usr/share/doc/packages/postfix/README_FILES
inet_protocols = all
biff = no
mail_spool_directory = /var/mail
canonical_maps = hash:/etc/postfix/canonical
virtual_alias_domains = hash:/etc/postfix/virtual
relocated_maps = hash:/etc/postfix/relocated
transport_maps = hash:/etc/postfix/transport
sender_canonical_maps = hash:/etc/postfix/sender_canonical
masquerade_exceptions = root
masquerade_classes = envelope_sender, header_sender, header_recipient
myhostname = b169.my.servername.com
program_directory = /usr/lib/postfix
inet_interfaces = all
masquerade_domains =
defer_transports =
mynetworks_style = subnet
disable_dns_lookups = no
relayhost =
mailbox_command =
mailbox_transport =
strict_8bitmime = no
disable_mime_output_conversion = no
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_client_restrictions =
smtpd_helo_required = no
smtpd_helo_restrictions =
strict_rfc821_envelopes = no
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,rejec
t_unauth_destination
smtp_sasl_auth_enable = no
smtpd_sasl_auth_enable = yes
smtpd_use_tls = yes
smtp_use_tls = yes
alias_maps = hash:/etc/aliases
mailbox_size_limit = 0
message_size_limit = 10240000
mydomain = anothervirtualhostname.com
mynetworks = 127.0.0.0/8
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_tls_auth_only = no
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
virtual_maps = hash:/etc/postfix/virtusertable
mydestination = /etc/postfix/local-host-names

[xtine]

A friend came over to my house and looked at this for me. Turns out the culprit is this line in the pri.example.com file.

mail MX 10 example.com

He explained to me that since this is the first line for MX, DNS is using the MX records for the mail.example.com subdomain. Once I removed that line, pingability.com is able to see my MX record. Yay!

I'm still getting a delay in sending mail to Yahoo though. I've emailed their support team, but haven't received anything useful yet. This is what's seen on my mail.info log.

Jun 17 13:33:11 b169 postfix/smtp[11973]: EF92A5E829E: to=<mytestemail@yahoo.com>, relay=f.mx.mail.yahoo.com[209.191.88.247]:25, delay=4, delays=0.81/0.02/3.1/0, dsn=4.0.0, status=deferred (host f.mx.mail.yahoo.com[209.191.88.247] refused to talk to me: 421 Message from (11.111.11.111) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html)

The behavior is changing, it seems. Yesterday, there was no delay in delivering the mail, but it ended up in the Spam Folder still. Today, there's a delay in delivering the mail (around 30 minutes), but the mail arrived in my Inbox instead of the Spam Folder.

I wonder if the postfix virtusertable issue has something to do with ISPConfig.

[falko]

Originally Posted by xtine

This is what's in my /etc/named.conf (I just chopped off the comments). Note: substitution names are used, in navy (b169.my.servername.com and anothervirtualhostname.com)

This is your Postfix configuration. Is it possible that you saved it in your named.conf instead of in /etc/postfix/main.cf?

[xtine]

Hey Falko,

My bad. Below is the /etc/name.conf. I'm good with the MX record though now.

The only remaining problem I have is delay in getting email to Yahoo Mail at this point.

From Pingability.com, I got a "heads-up," do I need to do anything about this?

Heads-up: This mail server has no reverse DNS (PTR) record. Some email servers require a PTR record from any server that connects to them and reject any email from a mail server without a PTR record.

/etc/name.conf

options {
pid-file "/var/lib/named/var/run/named/named.pid";
directory "/var/lib/named";
auth-nxdomain no;
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
allow-recursion {127.0.0.1;217.160.224.4;};
};

//
// a caching only nameserver config
//
zone "." {
type hint;
file "root.hint";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.zone";
};

zone "11.111.11.in-addr.arpa" {
type master;
file "pri.11.111.11.in-addr.arpa";
};


zone "anothervirtualhostname.com" {
type master;
file "pri.anothervirtualhostname.com";
};
zone "example.com" {
type master;
file "pri.example.com";
};

//// MAKE MANUAL ENTRIES BELOW THIS LINE! ////

[falko]

The named.conf looks good. What's in pri.example.com?

You should ask your hosting company to set up a PTR record for you.

[xtine]

In my pri.example.com

$TTL 86400
@ IN SOA ns1.example.com. myemail.yahoo.com. (
2008061703 ; serial, todays date + todays serial #
28800 ; refresh, seconds
7200 ; retry, seconds
604800 ; expire, seconds
86400 ) ; minimum, seconds
;
NS ns1.example.com. ; Inet Address of name serv
er 1
NS slv1.1and1.com. ; Inet Address of name serv
er 2
;

MX 30 mail.example.com.

example.com. A 11.111.11.111
www A 11.111.11.111
qa A 11.111.11.111
ns1 A 11.111.11.111
mail A 11.111.11.111
bugzilla A 11.111.11.111
twiki A 11.111.11.111
wiki A 11.111.11.111
example.com. A 11.111.11.111

example.com. TXT "v=spf1 a mx ptr ~all"

;;;; MAKE MANUAL ENTRIES BELOW THIS LINE! ;;;;

This is what I do dig -x 11.111.11.111 (my IP), I get

; <<>> DiG 9.3.2 <<>> -x 11.111.11.111
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11262
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;111.11.111.11.in-addr.arpa. IN PTR

;; ANSWER SECTION:
111.11.111.11.in-addr.arpa. 0 IN PTR b169.servername.serverdomain.com.

;; Query time: 4 msec
;; SERVER: 11.111.22.2#53(11.111.22.2)
;; WHEN: Thu Jun 19 08:58:00 2008
;; MSG SIZE rcvd: 84

Is this sufficient as far as PTR is concerned or do I need more?

[falko]

Originally Posted by xtine

In my pri.example.com

Looks ok.

Originally Posted by xtine

This is what I do dig -x 11.111.11.111 (my IP), I get


Is this sufficient as far as PTR is concerned or do I need more?

Yes, that's sufficient.