[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Exim as a LAN mail server [possibly-OT]



On Mon, Jul 16, 2001 at 12:01:18PM +0100, Nikki Locke wrote:
> In article <[🔎] 20010714153744.B2234@animus.fel.iae.nl>, Carel Fellinger 
> wrote:
...
> > Only if the destination machine is on the net too in those few 
> moments
> > that you are. Imagion that you are to send mail to my mail server
> > directly, then it's quit likely that, though I'm on the net for
> > atleast 12 hours a day, you still miss me because my daytime differs
> > from yours, living on the other side of the world and all that.  Were
> > you to use your ISP's mail server, changes would go up remarkably,
> > just because that machine is on the net during your nighttime / my
> > daytime.  Best would be if we both used our ISP's servers, then the
> > mail would get delivered instantaniously, so less resources used.
> 
> I think this is misleading. 

What it the above is misleading? The less resources used bit? Maybe.
But the rest is just to the point.
 
> SMTP mailers, when sending mail "direct", first look up the 
> destination's MX record in the DNS. The MX record will normally (I mean 
> "always, unless the destination's configuration is screwed") point to 
> an SMTP server which is permanently (I mean "barring breakdowns") 
> connected to the net. 

Here is were you err:)  We were discussing a set up were our own
machine, connected to the internet during daytime, and even then
intermittendly, was advertised to others to use to deliver mail to us.
That's why we mentioned dynamic dns services like provided by dyndns.
And I explained that such a setup, though technical feasable, is
better avoided, as it's bound to cause delivery problems.
 
> If the destination machine does not have a permanent connection, the MX 
> address usually points to the SMTP server of an ISP. That server will 

Not in the case under discussion, though...

> then either store the mail in a POP/IMAP/whatever server, or forward 
> the mail via SMTP/UUCP/whatever to the ultimate destination when it 
> next connects.

...this *is* what I suggested as being better.
 
-- 
groetjes, carel



Reply to: