The lookup name does not matter on the IP address as long as there is
one. I would point the MX record to "cpe-24-221-41-162.az.sprintbbd.net"
not a CNAME record.
For Example:
ecloud.org NS ns1.hn.org
ecloud.org NS aux1.hn.org
www.ecloud.org CNAME ecloud.org
ecloud.org MX cpe-24-221-41-162.az.sprintbbd.net 10
ecloud.org A 24.221.41.162
Many mail servers will not accept mail unless it has a reverse lookup
record associated with it. Some mail servers will not send mail to servers
that are referenced by a CNAME (The reverse lookup must match the MX record
statement).
You have two other problems as I can see it. First is your TOS (that is if
your ports are not blocked) and second, mail blocking lists. There are
lists kept on blocks of IP addresses used by residential customers (
http://mail-abuse.org/dul/ ) that some mail servers in turn use to block mail.
Good Luck.
Gilbert
At 07:46 PM 1/29/2002 -0700, you wrote:
>On Tue, Jan 29, 2002 at 04:20:51PM -0700, Roderick Ford wrote:
> > I started looking into setting up an MX on my LAN, by reading info at
> > Sendmail.org. I have a fairly static IP address, i.e. not guaranteed to
> > NEVER change, but never does. It is VERY (34 char) long,
> > "cpe-24-221-41-162.az.sprintbbd.net", and
> >
> > (1) I'm wondering if mail sent here would have to be @this_long_address, or
> > if there is a way to alias it shorter.
>
>Yes. You need a registered domain. For example I own ecloud.org,
>and my DNS records look like this:
>
>ecloud.org NS ns1.hn.org
>ecloud.org NS aux1.hn.org
>www.ecloud.org CNAME ecloud.org
>ecloud.org MX ecloud.org 10
>ecloud.org A 68.3.203.249
>
>That's one way to do it... just map your domain to your "static" IP,
>and forget about cpe-blah-blah entirely. Or, you could maybe make
>your domain a CNAME for cpe-blah-blah, and also have an MX record
>which says that cpe-blah-blah can accept mail for your-domain.
>
>I'm using HammerNode (hn.org) for DNS service. Seems to be OK so
>far. Used to use GraniteCanyon but they had some problems.
>
>Now if only the SMTP port wasn't being blocked... (by Cox AFAIK)
>
> > (2) Will I be able to configure a mail server so that
> > (2a) fetchmail will forward retrieved mail to the mail server
>
>I haven't done that yet but why bother with fetchmail? If you pull off
>having your own domain, just have mail sent to you@your-domain.
>
>As I use fetchmail right now, I just run a separate copy for each
>user.
>
>But I saw in the fetchmail docs that it's possible to run it as a
>system daemon and have it grab mail from multiple POP accounts and
>deliver to specific users. For example
>
>user foo there is bar here
>
>or something like that, in the config file.
>
> > (2b) where it can be retrieved by the user on the LAN?
>
>Sure, of course. Mail for each user ends up in one big file
>/var/spool/mail/username. Simple mailers like elm or mutt simply
>read messages from this file, and modify this file to mark messages
>read, delete them, etc. Lockfiles are used to make sure that sendmail/exim
>and mutt/elm don't write to the same file at the same time. If your
>users want to use mailers on other machines, rather than logging in
>to your mail server and running mutt or some such, then you need a
>POP or IMAP server. Different ones work differently; but the simplest
>POP server simply leaves the mail in the same spool file, and delivers
>messages from it upon request. Other mail systems (Cyrus, maybe some
>others) have other ways of organizing the mail on disk.
>
> > (3) Can the mail server be on the DNS server as long as they have the same
> > name and don't slow each other down?
>
>Sure, neither is very resource-intensive.
>
> > (4) IF mail does have to go to webmaster@this_long_address, then it is over
> > 40 characters...
>
>Why is there a 40-character limit? I don't ever remember encountering
>anything like that, but don't know for sure.
>
> > (4a) too long?
> > (4b) Then mail will hit the router and be forwarded according to the
> > port/firewall setting to the mailserver box, right?
>
>I don't think routers can do mail delivery; I think sendmail is
>what pays attention to the DNS MX records. For example, suppose
>somebody@xyz.edu is trying to send you mail. The sendmail process
>running at xyz.edu sees that the highest-priority (lowest-numbered)
>MX record for your-domain points to mail.your-domain. So it will
>try to open an SMTP connection to mail.your-domain. If it fails
>to establish a connection, then it will have another look at the
>DNS records and see if there is a secondary MX (higher numbered).
>If it finds one, it will try to open an SMTP connection to that;
>and so on, until it either succeeds or runs out of servers to try.
>If it still can't deliver it then it simply has to leave the mail
>in a file on disk (taking up disk space at xyz.edu) until it gets
>around to trying again. By default, sendmail will keep trying for
>5 days and then ultimately give up and delete the message.
>
>SMTP sessions are conversations occurring on TCP connections; and
>the TCP connection is the level with which the routers are
>concerned, but AFAIK they usually don't much care what sort of
>data is being sent over those TCP connections that they are
>maintaining.
>
>--
> _______ Shawn T. Rutledge / KB7PWD ecloud@bigfoot.com
> (_ | |_) http://ecloud.org kb7pwd@kb7pwd.ampr.org
> __) | | \________________________________________________________________
>________________________________________________
>See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail doesn't
>post to the list quickly and you use Netscape to write mail.
>
>PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
>http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)