In <[log in to unmask]> [log in to unmask] writes:
> (Kind listers/newsreaders: this is admittedly vendor-specific but I think
> the underlying issues are of general interest, so bear with me)
>
> Chris Bartram or associate can probably give you a definitive answer, but
> I'll give this a shot...
I did respond directly to the user, as well as to the [log in to unmask]
mailing list where we generally field freeware-netmail-specific questions.
Since the topic might be of some general interest (I help alot of people
configure their way through various firewalls, and there are several common
problems) I'll repeat some of the less specific details (then promptly shut
down my PC and head off for a week vacation at the beach! :-) ). Pardon
the long diatribe, but I hope it helps some people out there that are about
to set up a similar configuration (it's very popular these days).
> On Thu, 4 Jul 1996 18:44:15 -0700 you said:
> >I am attempting to use the freeware version of Netmail/3000, with a view to
> >'mail-enabling' some of our 3000-based systems, but I am running into problem
> ms
> >as described below - help would be much appreciated.
> >
> >We intend to use a 'trusted gateway', since our organisation already has
> >(internet) email up and running.
> >Netmail is submitting messages OK to our trusted gateway, but they are being
> >bounced back with errors such as the following:
> >
> > ----- Transcript of session follows -----
> >While talking to mailgate1.uea.ac.uk:
> >>>> RCPT To:<<@139.222.130.1:[log in to unmask]>><<< 550 Unknown domain
> >'139.222.130.1'
> >550 <<@139.222.130.1:[log in to unmask]>>... User unknown
As Jeff mentioned, this format of e-mail address (@hostname:address@host) is
called "source routing". In the older days it wasn't used alot - only by
mailers that couldn't do DNS or IP routing themselves. Nowadays it's getting
alot more use as you need it to get mail passed through most of the
commercial firewall packages floating around today.
What the format tells the mail system is to send the message first to the
system named between the first "@" and the ":". That system, *IFF* it
recognizes that name as itself (or an alias for itself) will strip the
"@hostname:" off the address, and proceed to attempt to deliver the message
on to the (hopefully) final destination. (Just to make things more
complicated, you can nest the "@hostname:" tags and force mail through
multiple hops, but we won't do into that...)
The *IFF* above the most common problem I've seen with people using this
configuration. Not understanding that "hostname" is different than a fully
qualified domain (i.e. "3k.com" is our domain name; technically an individual
host should have a name prepended to that name -- "picard.3k.com" is a
fully qualified hostname (though 'picard' is the hostname part and '3k.com'
is the domain part). What I've seen many people do, knowing that they want
their mail to come from [log in to unmask] for example, is configure their
hostname as '3k.com' (the domain name) instead of giving it a proper host
name. While this looks logical, the machine REALLY needs a host name; the
fact that you want mail to come and go with just '3k.com' on it is taken
care of elsewhere.
To cut to the chase, the "@name:" from the example cited must be (at least
our mailer requires it) a "name" not an IP address. Further, it had better
be the name of the firewall (PLEASE give the firewall a REAL name!). Since
most of the commercial firewall makers I've seen have either chosen to write
their own mailers, or customized someone elses (and sometimes seem to do
rather mediocre jobs of it) you've either got to get the hostname exact, or
try to do the equivalent of identifying alias names (Dw line in sendmail.cf
I believe) which overrides the system hostname for e-mail purposes. The error
encountered above is the receiving mailer saying "I don't know this hostname-
139.222.130.1". Source-routing format expects a hostname, not an IP address.
Further, since there doesn't appear to be an IP address listing for this
hostname (cause it's already an IP address!) the mailer gives up and returns
the message as undeliverable.
One final note on firewalls; since most will of the commercial firewalls are
setup to not allow any direct tcp/ip connections to pass through (they all
must go TO the firewall, which then relays them on), DNS on the INSIDE of
the firewall'd area (i.e. your 3000 if theres a firewall between you and the
"outside world") must either have DNS (/etc/resolv.conf a.k.a. RESLVCNF.NET.SY
S) disabled or you must run your own 'internal DNS' system. In NetMail's case
(and some other networking software I'm sure) if we can resolve an ip address
for a host, we assume we can connect to it. If you have access to full
Internet-DNS inside the firewall, then the mailer will be able to resolve
(lookup) IP addresses for any host on the Internet - and will then try to
deliver directly to that address... which won't succeed; either by getting
connection failures from the low-level tcp/ip, or timeouts if the firewall
accepts but drops outbound packets.
Hope that helps... I'm outta here!
Chris Bartram
______________________/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_
Chris Bartram Sales (US): 800 Net-Mail Fax:+1 703 451-3720
______ +1 703 569-9189 E-Mail: [log in to unmask]
/__ | \__________ Sales (Europe):+44(1480)414131 Fax:+44(1480)414134
/ / | / ________ Sales (Pacific Rim):+61 3 489 8216 (same for fax)
| /_ |< ______ Tech Support:+1 703 569-9189 Fax:+1 703 451-3720
\ __)| \ ___ E-mail: [log in to unmask] Personal(me): [log in to unmask]
\______/Associates, 6901 Old Keene Mill Rd Suite 205 Springfield VA 22150
_________________Inc._/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_
Gopher: gopher.3k.com Anon-FTP: ftp.3k.com WWW: http://www.3k.com/
|
