Sendmail Question

Sun May 16 12:49:30 UTC 2004

Am Sa, den 15.05.2004 schrieb Ow Mun Heng um 07:36:

> Mine's a laptop, I don't exactly have a FQDN or a resolvable domain. :)
> so how does it sends mail??

A FQDN and resolvable domain is not technically needed to being able to
send mail using Sendmail.

> >From what I see in the /var/log/maillog, I seem to see that sendmail is
> actually connecting straight to the domains' to relay the message
> instead of connecting to a (ISP) smtp server. 
> 
> I've not changed anything to my sendmail.mc file and smart_host is not
> defined.

Yes, if you did not define your ISP's SMTP server as your SMART_HOST
then Sendmail will first check whether there is an MX record for the
target domain and contact it directly if available. If no MX record
configured it will use an available A record.

What you see and described above is pretty normal. That is how sending
mail servers work, following RFCs.

> <snip from /var/log/maillog>
> May 14 18:05:56 Neuromancer sendmail[910]: i4F15nTS000906:
> to=<fedora-list at redhat.com>, delay=00:00:07, xdelay=00:00:07,
> mailer=esmtp, pri=30620, relay=mx3.redhat.com. [66.187.233.32],
> dsn=2.0.0, stat=Sent (i4F17DAX027620 Message accepted for delivery)
> </snip>

Sendmail speaks with the ESMTP mailer directly to the mx3.redhat.com MX
host.

> Is this correct behaviour? I thought that to send emails you need to
> either be authenticated (SMTP auth) or be on the same IPs as your ISP??

No, that would be pretty stupid. In case of needed authentification it
would mean that you would need authentification data for the receiving
mail host to be able to send him a mail. Doesn't it sound strange and
contra productive in your ears too, knowing how you treat mail
generally? The second case, that you have an IP from the IP pool of your
ISP, isn't it the common case? Or do you mean that you as MTA owner
would need to have/use the same IP as the ISP's SMTP server? Would be
curious too.

What's partly right in your opinion is the idea, that the receiving MTA
will check the sender host's domain name. That is more and more the
case, due to SPAM protection. It is commonly well known that in past
most of the spammers used hosts with domain names which did not resolve.
By default Sendmail rejects such mail. You would need to activate
FEATURE(`accept_unresolvable_domains') in the sendmail.mc to make
Sendmail accept incoming mail from such hosts. Now having that in mind
you easily see that home users seldom have resolvable domain names at
home. Therefor running an MTA at home an not using a defined smart host
will cause you trouble, because some if not most recipient mail hosts
will reject your mails. That is the reason why you better define your
ISP's SMTP host as smart host for your own MTA. Of course, you will then
- and in this meaning your above opinion makes much sense - have to
either authenticate against that ISP's mail host to be able to relay
through it or that ISP's host is configured that way, to accept mail
relay attempts from each host which has an IP from a specific well known
IP range.

But be aware: local mail accepting is not mail relaying! You mix both
cases. In case a mail has to be delivered to a mail host, means the
recipient has an account anywhere in the area to who's MX host you are
speaking, it would break everything if authentification would be
required or a specific IP would be needed. Sound abvious? (To be more
precise: I am not speaking about the case of challenge response systems,
but about SMTP following RFCs.)

Relaying in opposite means when you use an SMTP server to send mail
through it to a different MTA. A relay host would be i.e. your ISP's
smart host. It is not the target mail server itself but a "routing
station" through which the mail goes to it's final destination. Your own
Sendmail acts as a relay too, if you use a mail client to send mail to
outside recipients. Therefor your /etc/mail/access file contains at
least a line like "127   RELAY", to allow mail relayed coming from
localhost. If you use a mail client from a different host in your own
LAN, then you additional would need a line like "192.168  RELAY" to
allow hosts from 192.168.0.0/16 to be able to send mail using that
Sendmail as a " pass through".

> Or is this what's happening? Sendmail is actually querying DNS root
> servers and then upon getting the MX server, it connects straight to
> port 25 of that MX Server and sends it? If that's the case, what's
> stopping it from being a relay???

No, Sendmail does not query root DNS servers. Sendmail uses like other
applications those DNS servers your defined in /etc/resolv.conf. If all
name resolution would go first to the root servers you could forget
internet working properly or those root DNS servers would have to be
awful big beasts. DNS is a different topic, but worth to be understood.

And the other part of your question is wrong too. I explained it above.
Having read up to this point you should see yourself that it is wrong.
Again: if an MTA gets a mail for a recipient for which the MTA is
reliable - Sendmail knows the domains for which it acts as MTA from
/etc/mail/local-host-names) - that MTA is not a relay in that case. If
an MTA gets a mail for a recipient / domain which is not local, then
this MTA is a relay and it has to contact a further MTA to pass him the
mail. In that last case it is very important to have restricted the
possibilities to send the mail. You call an open relay such an MTA which
accepts mail by senders to non local recipients without need for
authentification nor having a specific well defined IP. Such hosts can
be easily misused by spammers. The net is regularly scanned for open
relays, both by spammers as by blacklisting services (RBL).

> /curious

Still curious?

Alexander

-- 
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 1 (Yarrow) on Athlon CPU kernel 2.4.22-1.2188.nptl
Sirendipity 14:09:07 up 3 days, 11:53, load average: 0.08, 0.09, 0.03 
                   [ Γνωθι σ'αυτον - gnothi seauton ]
             my life is a planetarium - and you are the stars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20040516/890f4e1c/attachment-0002.bin 