[SGVLUG] email: Can I send it out directly?

[Emerson, Tom]

> -----Original Message----- Of David Lawyer
> 
> I think my email is working OK now, but I'm just curious ...
> what about my outgoing email?  When I dialup to my ISP 
> ... Exim ... could just send out my outgoing email to the 
> Internet [intended recipient], bypassing the mail server at LAFN. 
> ... if I did, will it work?

10 years ago, yes.  Today, odds are that the receiving SMTP host will
refuse to listen to your "open relay".  (you and I both know it isn't
really an "open relay", but the rest of the e-mail admins out there
don't know this...)

> If I did this, my exim would first use DNS to find the mail 
> servers that I need to connect to and send packets to port 25 
> (ordinary email, not TLS) on various mail servers.  If they 
> accept my email, then I've succeeded.  But will this work OK? 

For the admins that are cluess or don't care, yes, this would work.
Here's a test you can try:   telnet <some.random.smtp.host> 25

If you get a prompt AND can "log in", you can interactively issue SMTP
commands and type in a message right-on-the-spot (sorry, no editing).
Most likely you WILL get a prompt, but the host will require some form
of authentication to allow you to "log in".  Even if you do get in, a
"properly" configured server will only let you send messages to the
domain it is responsible for (otherwise it would be an "open relay") --
in this sense, it is a half-open relay -- if you get to "mail.xyz.com",
you can only send messages to xyz.com recipients, but you can send a lot
of them... 

>  Will they accept mail from an IP number that is roving 
> (assigned to my isp)?  What if my email is not accepted and 
> returned to my temporary ip# just as I hang up my ppp 
> connection.  Then who gets the return packets?  Not me since 
> I'm offline.

As John mentioned, the STMP "protocol" includes some hand-shaking, so
you wouldn't be able to "hang up" before any "return packets" arrived
(if you did, your original message would likely be discarded even if it
could otherwise be sent)  try running ethereal (or pcap) during a
session where you send mail "normally" (I think pcap is the stand-alone
capture portion of ethereal -- does anyone know if there is a text-mode
only version of ethereal for reviewing the captured packets?)  You can
then see the interaction between processes to make this a little
clearer.

OTOH, you *might* be connected to a designated mail relay -- for
instance, you're sending a message to someone at xyz.com, but their
server is currently "down" -- your MTA [exim] would then query the DNS
server for "the closest server that isn't xyz.com", and might find a
server at pdq.org (i.e., the admins of the respective domains have
agreed to be a backup e-mail host for each other...)  The server at
pdq.org would happily accept your mail for someone at xyz.com, and then
IT would be responsible for getting it to xyz.  If xyz.com never comes
back up (for a week...) eventually the server at pdq.org will "give up"
on attempting to send your message and generate a "failed delivery"
notice sent to YOUR e-mail (not IP) address -- this will be picked up by
lafn and stored there until you connect.
 
> And then what about authentication?  I suppose that it's only 
> required for relaying email and not if the mail server 
> delivers mail locally to the To: address 

I think we have been saying that all along, but even for "locally
delivered" messages, authentication is still a good idea (more on that
in a moment)

> ... one reason for sending outgoing email 
> via your ISP's mail server is that you may not have a program 
> like sendmail installed that can use dns and send out email directly.

As the myriad of e-mail viruses will attest, "having a program like
sendmail" that can deliver using DNS to find the host is trivial ;)  In
reality, ALL of the e-mail clients "out there" could do this -- since
they at least "speak" SMTP to get to your ISP's SMTP host, they could
take the extra step and look up every receiving SMTP host and send
messages directly, but then it becomes a headache for your client if one
of the recipients' machines is down...

In other words, routing messages through your ISP serves several useful
purposes:

   1) your ISP's e-mail "host" is a well known host and can be validated
via reverse DNS -- your "dial up" connection can rarely be validated in
this manner.
   2) paranoid domain admins won't accept messages from non-validated
hosts
   3) your ISP will "store-and-forward" messages -- if your intended
recipient's machine isn't online when you try to send, (and they don't
have any "alternates" designated), your ISP effectively becomes a
"universal alternate MX"
   4) often an ISP will BLOCK outbound port-25 traffic (i.e., traffic on
port 25 that ISN'T targeted towards their own SMTP host) to stop viruses
from spreading and to stop "open relays" from being a spam portal...

When your ISP's SMTP host requires validation, it serves another couple
of useful purposes as well:

   1) it helps cut down forgery -- if I were to telnet to "localhost" on
port 25, I could write a message that appeared to come from you, but any
savvy admin would see through that in an instant.  If instead I were to
telnet to LAFN on port 25 and claim to be "you", and make more admins
"believe" it because the message would have indeed originated from the
LAFN server and not "localhost" ;)

   2) it cuts down the "open relay" spam problem -- in order to use the
LAFN host, I need to have a valid account there -- if I have an account
but send SPAM through their system, very shortly I suppose I wouldn't
have an account there...