quote
"It also can cause less problems in the corporate world if some
brighter-than-normal person performs a telnet session and finds that
you're not only running their email, but a competitor's as well or other
similar situation. "
I liked this answer so much because I have a situation like this :)
Regards
Lucian
Jake Vickers wrote:
Eric Shubert wrote:
Jake Vickers wrote:
Eric Shubert wrote:
Interesting.
I don't buy that using an IP address is necessarily the best
practice though. Here are my thoughts on this.
It does not matter so much these days, but it used to be best
practice for multi-domain machines that accept mail. The reason
being that when a connection is coming in the recipient server has
no idea (initially) what domain the message is destined for, so it
should answer with an IP address since this IP address *should
always* be the answer when checking a domain's MX record versus the
domain name which may not be related to the recipient domain.
For diagnosing purposes when the sending admin checks the logs and
sees the IP address for the server he can then check the MX record
and verify the IP address.
These days it's a given that a mail server is accepting mail for
multiple domains and this does not matter as much, but I have seen
it used for a lot of "older" email shops.
Thanks for the explanation Jake. To be honest though, I don't really
follow your logic. This has nothing to do with MX records that I've
seen in the RFCs.
BL, I agree it doesn't matter much, at least until a server refuses
mail from you because of it. I still think that the best value here
is a hostname that has a type A record matching the IP address that
is used to connect to the host. If this is the case and a receiving
server has a problem with the name, then I think the problem lies
with the receiving server.
The MX record is a side item and really means nothing. I was throwing
that in there to show some diagnostic uses.
I deliver a message to you at mail.shubes.net. Your server response
that it's [192.168.0.1] since it does not know what domain the
incoming message is for. This can sometimes give you less problems
than mailers that expect to connect to mail.shubes.net when your
server responds that it's incoming.ejs.net or something. It also can
cause less problems in the corporate world if some
brighter-than-normal person performs a telnet session and finds that
you're not only running their email, but a competitor's as well or
other similar situation.
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and
installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
