On Sun, 20 Mar 2005 10:21:36 UTC, (dmc) wrote:

In article ,
:::Jerry:::: wrote:

So do explain why mail can be returned to the sender up to a week
after the mail was sent to a invalid and non existent address......

If the email was sent to an invalid, non existent address and took a week
to bounce then the mail server is broken.

If (as others have said) it the domain is valid then the mail system will
attempt to deliver it to the mail machine(s) at that domain. If the
address is invalid then ideally the remote machine should not accept it
and should reject at SMTP time with a permenant error (5**) to cut down
on collaterol spam but several systems out there are broken and accept and
then bounce.

The point I was making, which Jerry seems not to be able to understand,
is that mail to a nonexistent *domain* (or subdomain is the case in
point) will not even be attempted, because the DNS lookup for the MX
record will fail. Now, if the mail server that's doing the sending takes
a week to say it couldn't do the DNS lookup, then , as you say, it's
broken - badly so.

Never mind...he'll get there one day....


--
Bob Eager
begin a new life...dump Windows!

"Bob Eager" wrote in message
...
snip

The point I was making, which Jerry seems not to be able to
understand,
is that mail to a nonexistent *domain* (or subdomain is the case in
point) will not even be attempted, because the DNS lookup for the MX
record will fail. Now, if the mail server that's doing the sending
takes
a week to say it couldn't do the DNS lookup, then , as you say, it's
broken - badly so.

Never mind...he'll get there one day....


Right, so the sending mail server will look up DNS of the sub-domain
and not just the 'parent' domain ? That is making sense now, why
couldn't you have said that in the first place ?!..

:::Jerry:::: wrote:

How will that effect those on the South Coast, were TX power is
limited due to the problem of co-channel interference with French
stations, surely any increase in TX power will only make that problem
worse, or will this co-channel interference problem stop with a full
digital service ?

In the favoured 'conversion' channel plan option for so-called 'digital
switch-over,' at least three of the DTT muxes will move on to channels
currently used for analogue. These channels already have international
clearance for high power transmissions. The post-switch-over DTT power
is likely to be -10 to -7dB relative to the current analogue power -
i.e. something like 10dB (x10) up on current DTT levels.

--
Andy

"Andy Wade" wrote in message
...
:::Jerry:::: wrote:

How will that effect those on the South Coast, were TX power is
limited due to the problem of co-channel interference with French
stations, surely any increase in TX power will only make that problem
worse, or will this co-channel interference problem stop with a full
digital service ?

In the favoured 'conversion' channel plan option for so-called 'digital
switch-over,' at least three of the DTT muxes will move on to channels
currently used for analogue. These channels already have international
clearance for high power transmissions.

True. But they also have and cause international interference during many
months of the year and the French will not take kindly to us splatting them
with digital TV interference as it will make their analogue service almost
unwatchable whereas nowadays one can get by.

"Mike" wrote in :

True. But they also have and cause international interference during
many months of the year and the French will not take kindly to us
splatting them with digital TV interference as it will make their
analogue service almost unwatchable whereas nowadays one can get by.

My heart bleeds.

I didn't realise there was an upside to this mess before, but it gives the
Frogs grief for making most telly unwatchable I'm all for it

mike

"Mike" wrote in message
...

snip

True. But they also have and cause international interference
during many
months of the year and the French will not take kindly to us
splatting them
with digital TV interference as it will make their analogue service
almost
unwatchable whereas nowadays one can get by.


Oh I see (or don't...), it's OK for the French to splat our TV but not
for us to it to them ?!...

:::Jerry:::: wrote:

Right, so the sending mail server will look up DNS of the sub-domain
and not just the 'parent' domain ? That is making sense now, why
couldn't you have said that in the first place ?!..

It doesn't work that way round, as it happens: the sending mail machine
(which need not be a "server" - some people run their personal desktop
system as a fully-capable mail-sending machine, though most just point
at a "smart" next-hop mailhost) asks, through the DNS, for the list of
MX servers for that particular, fully-qualified, machine - if the
request is for the MX handlers for a.tiny.subdomain.of.something.big.net
the response relates to a.tiny etc - the mail handling program isn't
expected to recurse up/down the domain hierarchy. The MX entries each
come with a "priority", lowest number being "best", i.e. most
appropriate; the sender tries to establish contact with an SMTP handler
on each entry on the list, in priority order, unless that priority is
"worse" than its own for that domain (this is how we avoid mail routing
loops).

While the DNS does support "wildcard" entries, so an MX server can be
listed as handling a whole chunk-o-domain, the response "looks as if"
it's specific to the particular domain (a.tiny.subdomain etc in the
example above), so the sending mailer doesn't need any special smarts to
handle a 'wildcard' MX entry - that's the DNS server's (well, servers'
;-) job.

As for why Bob couldn't have said that - well, clearly he *could* ;-)
but didn't because (I'm guessing here) you seemed keener on spreading
your as-yet-incomplete partial understanding of mail mechanics than on
listening. Since MX-based email routing is getting on for 20? years old
on t'infosuperhypewebnetwebway, and How It Works pieces litter the
ishwnww, you ran into a temporary patience shortage in the Eager area...

":::Jerry::::" wrote in message
...

"Mike" wrote in message
...

snip

True. But they also have and cause international interference
during many
months of the year and the French will not take kindly to us
splatting them
with digital TV interference as it will make their analogue service
almost
unwatchable whereas nowadays one can get by.


Oh I see (or don't...), it's OK for the French to splat our TV but not
for us to it to them ?!...

The French splat us with analogue which is bearable and we do the same to
them. But if it turns into a game of digital splatting nobody will see
anything.

On Sun, 20 Mar 2005 21:02:02 +0000, Stefek Zaba
wrote:

:::Jerry:::: wrote:

Right, so the sending mail server will look up DNS of the sub-domain
and not just the 'parent' domain ? That is making sense now, why
couldn't you have said that in the first place ?!..

It doesn't work that way round, as it happens: the sending mail machine
(which need not be a "server" - some people run their personal desktop
system as a fully-capable mail-sending machine, though most just point
at a "smart" next-hop mailhost) asks, through the DNS, for the list of
MX servers for that particular, fully-qualified, machine - if the
request is for the MX handlers for a.tiny.subdomain.of.something.big.net
the response relates to a.tiny etc - the mail handling program isn't
expected to recurse up/down the domain hierarchy. The MX entries each
come with a "priority", lowest number being "best", i.e. most
appropriate; the sender tries to establish contact with an SMTP handler
on each entry on the list, in priority order, unless that priority is
"worse" than its own for that domain (this is how we avoid mail routing
loops).

Well we try, anyway. However, it does require sobriety when writing
sendmail rules.......



While the DNS does support "wildcard" entries, so an MX server can be
listed as handling a whole chunk-o-domain, the response "looks as if"
it's specific to the particular domain (a.tiny.subdomain etc in the
example above), so the sending mailer doesn't need any special smarts to
handle a 'wildcard' MX entry - that's the DNS server's (well, servers'
;-) job.


I suspect that there are a number of additional places where various
forms of caching go on which make a confusion of some of this and
where the spammers certainly don't follow the rules.

For example, a week ago, I needed to do some network readdressing that
involved the public address of my mail server being changed. This
meant that the MX records in the public domain servers needed to be
changed to reflect that so that mail transaction connections would be
made to the new address.

This was duly done during a quiet period last weekend when there is
little legitimate incoming mail - obviously outgoing is not affected.

Normally I would expect the address change to have propagated through
the Internet and for DNS servers at mail sending hosts to have updated
to the new address. I left the old configuration in place for about
a day to allow incoming mail to the old address to be delivered, and
then switched address configurations for the new IP address to be
used.

I logged all SMTP connection attempts (passed and failed), and most
were to the new address or if attempted to the old address would
shortly be made again on the new one. All of the legitimate and
common sources from which I receive mail picked up the address change
very quickly and nobody complained of undelivered email.

However, a week later, I am still getting quite a number of connection
attempts to the old address. This is way past normal DNS server and
other network software timeouts as far as I know. I did some address
checking and almost all are from known spam server sources.
It seems that they cache IP addresses for a long time or deliberately
store them, which rather surprised me.....
Perhaps it's to save doing as many DNS lookups?








--

..andy

To email, substitute .nospam with .gl

Andy Hall wrote:

However, a week later, I am still getting quite a number of connection
attempts to the old address. This is way past normal DNS server and
other network software timeouts as far as I know. I did some address
checking and almost all are from known spam server sources.
It seems that they cache IP addresses for a long time or deliberately
store them, which rather surprised me.....
Perhaps it's to save doing as many DNS lookups?

Interesting - it's possible that the 'better' (more effective, *not*
morally superior) spammers now keep an IP address of a 'live last time
we tried' SMTP listener for each domain they spam - as it's possible
that some ISPs have started to block or tarpit large numbers of MX
queries from a single IP address in a short period of time from machines
other than their own outward-facing mailservers...

In message , Mike
writes

"Andy Wade" wrote in message
...
:::Jerry:::: wrote:

How will that effect those on the South Coast, were TX power is
limited due to the problem of co-channel interference with French
stations, surely any increase in TX power will only make that problem
worse, or will this co-channel interference problem stop with a full
digital service ?

In the favoured 'conversion' channel plan option for so-called 'digital
switch-over,' at least three of the DTT muxes will move on to channels
currently used for analogue. These channels already have international
clearance for high power transmissions.

True. But they also have and cause international interference during many
months of the year and the French will not take kindly to us splatting them
with digital TV interference as it will make their analogue service almost
unwatchable

That would be an improvement, then

--
geoff

On Sun, 20 Mar 2005 22:15:01 +0000, Stefek Zaba
wrote:

Andy Hall wrote:

However, a week later, I am still getting quite a number of connection
attempts to the old address. This is way past normal DNS server and
other network software timeouts as far as I know. I did some address
checking and almost all are from known spam server sources.
It seems that they cache IP addresses for a long time or deliberately
store them, which rather surprised me.....
Perhaps it's to save doing as many DNS lookups?

Interesting - it's possible that the 'better' (more effective, *not*
morally superior) spammers now keep an IP address of a 'live last time
we tried' SMTP listener for each domain they spam - as it's possible
that some ISPs have started to block or tarpit large numbers of MX
queries from a single IP address in a short period of time from machines
other than their own outward-facing mailservers...

I was wonderig that or possibly simply taking out a DNS query. If
it's to the other side of the world plus the server response, that
adds up to a lot of dead time of there are lots of relatively short
messages



--

..andy

To email, substitute .nospam with .gl

On Mon, 21 Mar 2005 01:02:31 +0000, Andy Hall
wrote:

I was wonderig that or possibly simply taking out a DNS query. If
it's to the other side of the world plus the server response, that
adds up to a lot of dead time of there are lots of relatively short
messages

That is not necessarily true. A DNS query can bounce between London
and New York or California in a shorter time than it might take for a
request to bounce from London to Manchester.

It depends on a lot of things. How fast is the wire between the
locations? How busy is the connection? Is the connection optimised?

One thing that doesn't enter into the equation is "how long is this
piece of string?".

You can bounce a signal off the moon in much less than 1 second.

Andrew

On Mon, 21 Mar 2005 04:55:04 UTC, Andrew McKay
wrote:

You can bounce a signal off the moon in much less than 1 second.

Yes, but only if you are near the moon (say, under 100,000 miles)!

--
Bob Eager
begin a new life...dump Windows!

Bob Eager wrote:

On Mon, 21 Mar 2005 04:55:04 UTC, Andrew McKay
wrote:

You can bounce a signal off the moon in much less than 1 second.

Yes, but only if you are near the moon (say, under 100,000 miles)!

From Earth it's about 2.5 seconds to the moon and back, as any
self-respecting radio amateur should know.

--
Andy

On Mon, 21 Mar 2005 11:54:58 UTC, Andy Wade
wrote:

Bob Eager wrote:

On Mon, 21 Mar 2005 04:55:04 UTC, Andrew McKay
wrote:

You can bounce a signal off the moon in much less than 1 second.

Yes, but only if you are near the moon (say, under 100,000 miles)!

From Earth it's about 2.5 seconds to the moon and back, as any
self-respecting radio amateur should know.

Exactly. Same answer, really.

--
Bob Eager
begin a new life...dump Windows!

Stefek Zaba wrote:

[...] The MX entries each come with a "priority", lowest number being
"best", i.e. most appropriate; the sender tries to establish contact
with an SMTP handler on each entry on the list, in priority order,

OK so far...

unless that priority is "worse" than its own for that domain (this is
how we avoid mail routing loops).

.... could you explain that in a bit more depth Stefek - i.e. what do do
you mean by "its own [priority] for that domain?" Do you mean its own
cached MX record from a previous lookup, or something else? And how
does this avoid loops?

The detailed workings of DNS are still a bit of a mystery to me, but I'm
gradually trying to understand the beast...

--
Andy

In article ,
Andy Wade wrote:
The detailed workings of DNS are still a bit of a mystery to me, but I'm
gradually trying to understand the beast...

Same here. Does anyone know of a site that explains it in language I could
understand?

--
*Even a blind pig stumbles across an acorn now and again *

Dave Plowman London SW
To e-mail, change noise into sound.

On Mon, 21 Mar 2005 04:55:04 +0000, Andrew McKay
wrote:

On Mon, 21 Mar 2005 01:02:31 +0000, Andy Hall
wrote:

I was wonderig that or possibly simply taking out a DNS query. If
it's to the other side of the world plus the server response, that
adds up to a lot of dead time of there are lots of relatively short
messages

That is not necessarily true. A DNS query can bounce between London
and New York or California in a shorter time than it might take for a
request to bounce from London to Manchester.

Yes of course, but very often a query needs to go to further servers
to be resolved if the particular domain is not locally cached.
This can add up to quite a lot.


It depends on a lot of things. How fast is the wire between the
locations? How busy is the connection? Is the connection optimised?

One thing that doesn't enter into the equation is "how long is this
piece of string?".

You can bounce a signal off the moon in much less than 1 second.

Mmmm... I think that's the one-way trip.......


Andrew



--

..andy

To email, substitute .nospam with .gl

In article ,
Andy Hall wrote:

Well we try, anyway. However, it does require sobriety when writing
sendmail rules.......

Exim is the answer to sendmail rewriting rules. Switched to it 10 years
ago now and never looked back

It seems that they cache IP addresses for a long time or deliberately
store them, which rather surprised me.....
Perhaps it's to save doing as many DNS lookups?

I have seen windows boxes ignoring the TTL for seemingly random periods.
Don't know why - we never got to the bottom of it and just marked it up
as yet-another-broken-windows-feature.

Something else that I haven't seen mentioned is that MX records are great
but *most* email systems will actually try to deliver to the a record if
no MX can be found. I've come across many people who have no MX and have
been unaware that some systems are not delivering to them

Darren

On Mon, 21 Mar 2005 13:59:53 UTC, (dmc) wrote:

Something else that I haven't seen mentioned is that MX records are great
but *most* email systems will actually try to deliver to the a record if
no MX can be found. I've come across many people who have no MX and have
been unaware that some systems are not delivering to them

In fact, they *should* all try that...according to section 5 of
RFC2821....!

--
Bob Eager
begin a new life...dump Windows!

In article ,
Bob Eager wrote:
On Mon, 21 Mar 2005 13:59:53 UTC, (dmc) wrote:

Something else that I haven't seen mentioned is that MX records are great
but *most* email systems will actually try to deliver to the a record if
no MX can be found. I've come across many people who have no MX and have
been unaware that some systems are not delivering to them

In fact, they *should* all try that...according to section 5 of
RFC2821....!

Indeed. Still a fair few systems that don't though :-(

Darren

On Mon, 21 Mar 05 13:59:53 GMT, (dmc) wrote:

In article ,
Andy Hall wrote:

Well we try, anyway. However, it does require sobriety when writing
sendmail rules.......

Exim is the answer to sendmail rewriting rules. Switched to it 10 years
ago now and never looked back

That's wimpish. Although I have used Postfix.



It seems that they cache IP addresses for a long time or deliberately
store them, which rather surprised me.....
Perhaps it's to save doing as many DNS lookups?

I have seen windows boxes ignoring the TTL for seemingly random periods.
Don't know why - we never got to the bottom of it and just marked it up
as yet-another-broken-windows-feature.

Microsoft doesn't know how to do networking any more than it knows how
to do operating systems


Something else that I haven't seen mentioned is that MX records are great
but *most* email systems will actually try to deliver to the a record if
no MX can be found. I've come across many people who have no MX and have
been unaware that some systems are not delivering to them

Yuk..... things should follow the spec.

Darren


--

..andy

To email, substitute .nospam with .gl

On Mon, 21 Mar 2005 12:09:27 +0000, Andy Wade
wrote:

Stefek Zaba wrote:

[...] The MX entries each come with a "priority", lowest number being
"best", i.e. most appropriate; the sender tries to establish contact
with an SMTP handler on each entry on the list, in priority order,

OK so far...

unless that priority is "worse" than its own for that domain (this is
how we avoid mail routing loops).

... could you explain that in a bit more depth Stefek - i.e. what do do
you mean by "its own [priority] for that domain?" Do you mean its own
cached MX record from a previous lookup, or something else? And how
does this avoid loops?


I'm sure that Stefek will explain his point on this one.

I've run into several areas over the years where mail loops can be
created inadvertently through seemingly innocent DNS configurations.

One way is if you don't watch out for definitions of the MX records
and reference via a CNAME rather than an A record.

This is correct:

; Mail Exchangers
;
IN MX 10 primary.you.com.
IN MX 20 secondary.you.com.

;
; Canonical names
;
primary.you.com. IN A 192.168.0.1
secondary.you.com. IN A 192.168.2.3

This is not:

; Mail Exchangers
;
IN MX 10 primary.you.com.
IN MX 20 secondary.you.com.
;
; Canonical names
;
primary.you.com. IN A 192.168.0.1
secondary.you.com. IN CNAME relay.you.com.

;
; Aliases
;
relay.you.com. IN A 192.168.2.3


It's also important to be careful with mailer configurations,
especially if you are relaying mail from machine to machine. You can
create loops this way as well.

e.g.
http://www.bb-zone.com/SLGFG/chapter18.html



The detailed workings of DNS are still a bit of a mystery to me, but I'm
gradually trying to understand the beast...

One of the best known works on this is the O'Reilly book on DNS and
BIND which has been around for years.

http://www.oreilly.com/catalog/dns4/

I have one of the older editions and have just ordered the latest
which covers new versions, particularly 9.x

This is also a good starting point

http://www.isc.org/index.pl?/sw/bind/



--

..andy

To email, substitute .nospam with .gl

Steve Firth wrote:
Richard wrote:

Can anyone shed any light on how to choose a DVD recorder? Does it

matter if it will record in only one of the + - formats??? Should
he
simply buy Richer Sounds' latest best buy????

I would say avoid Goodmans and Philips recorders, they seem to be the
cause of more whinging than anything else. Best buy in the DVD
recorder
only stakes seemed to be the Mico being sold by Sainsburys for =A399.
The

Nah, recommend Philips, the DVDR610 @ around =A3180, the only downside
being it doesn't have a 1hr/disc recording mode but I generally record
for longer than that anyway so it's not an issue to me. I did read a
few whinging complaints about the Philips but still bought it anyway
and it's fine. You have to remember it's usually only the whingers who
post their views.

I tried two cheaper models and both had to go back as they were crap
(Liteon and Matsui). One obviously had serious firmware problems and
kept locking up, the other had interference on the picture whenever the
disc was spinning.

The discs are so cheap nowadays that you can afford to stock up on
DVDRW, keep what you want and re-use any you don't.

MBQ

Andy Wade wrote:

... could you explain that in a bit more depth Stefek - i.e. what do do
you mean by "its own [priority] for that domain?" Do you mean its own
cached MX record from a previous lookup, or something else? And how
does this avoid loops?

The detailed workings of DNS are still a bit of a mystery to me, but I'm
gradually trying to understand the beast...

Cricket Liu's O'Reilly book is a fine reference for the DNS - he starts
off gently and builds up to relatively fantsy-pantsy stuff, but uses one
extended, increasingly-complex example domain throughout, so the
learning slips down easily.

The particular thing about MX priority I was telegraphically summarising
goes as follows. To increase robustness of mail-handling, and to allow
for 'final' mail-delivery systems to be unreachable from The World At
Large, there can be - and usually are - multiple MX (Mail eXchange)
records in the DNS for a given destination. When a sending system wants
to have a little SMTP natter with An Appropriate mail-delivery target,
it asks the DNS for all MX records, and tries to establish the SMTP
dialogue with each of them in priority order - lower numbers signify
betterness. So, let's say we're trying to deliver mail to an address at
foo.bar.net, and the DNS delivers three MX records for foo.bar.net -
mailhub.bar.net at priority 10, mailhub.friendofbardotnet.org at
priority 20, and smtp.anothermate.net, also at priority 20. It tries to
talk SMTP to mailhub.bar.net, but finds that host's not listening for
whatever reason. It falls back to, say, mailhub.friendofbardotnet.org,
which is happy to store-n-forward the mail. The sending system considers
it's done all it needs to at this point (ass-U-ming it's got a Happy
response from m.f.o).

When m.f.o next gets round to processing its mail queue, it comes across
the message it accepted for foo.bar.net. It gets the same DNS responses
as the original sender - mailhub.bar.net at prio 10, itself at prio 20,
smtp.anothermate.net at 20. Since its own MX priority is 20, it won't
try pushing the mail to itself, nor to smtp.anothermate.net; the only
SMTP listener worth trying, with a 'better' priority than itself, is
mailhub.bar.net. So it'll keep trying that server, according to whatever
retry/backoff strategy it uses (preferably an exponential backoff, but
you never know what some numpty might code up), until it either succeeds
or times out after (typically) a few days.

So, *provided* *a* *domain's* *MX* *priorities* *are* *consistently*
*set* *up*, mail only makes 'forward progress', i.e. towards the final
'best' handler, while listing multiple handlers at the same priority
allows simple load-balancing. Yes, there are ways of screwing it up -
Andy H showed one (where the 'fallback' server doesn't recognise itself
because it's been described by an alias rather than its canonical name),
transitional 'rationalisations' of priorities are another,
inconsistencies across a DNS 'split horizon' a third - but generally it
works fine, provided implementors bother to read, understand, and act on
*all* of the RFCs, and not just the bits they think are relevant to them...

Stefek

On Tue, 22 Mar 2005 18:01:06 +0000, Stefek Zaba
wrote:



So, *provided* *a* *domain's* *MX* *priorities* *are* *consistently*
*set* *up*, mail only makes 'forward progress', i.e. towards the final
'best' handler, while listing multiple handlers at the same priority
allows simple load-balancing. Yes, there are ways of screwing it up -
Andy H showed one (where the 'fallback' server doesn't recognise itself
because it's been described by an alias rather than its canonical name),
transitional 'rationalisations' of priorities are another,
inconsistencies across a DNS 'split horizon' a third - but generally it
works fine, provided implementors bother to read, understand, and act on
*all* of the RFCs, and not just the bits they think are relevant to them...

Stefek


I've just started to look at it, but I understand that BIND9 has
capabilities to help with implementing MX properly and also doing
split horizon if you want to have different things pointing in
different directions through different interfaces.



--

..andy

To email, substitute .nospam with .gl

On Tue, 22 Mar 2005 18:01:06 UTC, Stefek Zaba
wrote:

When m.f.o next gets round to processing its mail queue, it comes across
the message it accepted for foo.bar.net. It gets the same DNS responses
as the original sender - mailhub.bar.net at prio 10, itself at prio 20,
smtp.anothermate.net at 20. Since its own MX priority is 20, it won't
try pushing the mail to itself, nor to smtp.anothermate.net; the only
SMTP listener worth trying, with a 'better' priority than itself, is
mailhub.bar.net. So it'll keep trying that server, according to whatever
retry/backoff strategy it uses (preferably an exponential backoff, but
you never know what some numpty might code up), until it either succeeds
or times out after (typically) a few days.

Or (if it supports it), it receives an ETRN for that domain, it'll try
immediately. The secondary MX provided by my ISP (I run the highest
priority MX right here) does that, and it's handy for kicking it all off
again after my mail server has been down (e.g. after a recent power
cut).

An unrelated question, Stefek....

The writing style you used above (entertaining!) reminds me strongly of
the writings of a friend of mine, Mike Padlipsky (he of the Telnet
protocol, and a book which was a diatribe against OSI). Ever read any of
his stuff?

--
Bob Eager
begin a new life...dump Windows!

Bob Eager wrote:


The writing style you used above (entertaining!) reminds me strongly of
the writings of a friend of mine, Mike Padlipsky (he of the Telnet
protocol, and a book which was a diatribe against OSI). Ever read any of
his stuff?

No - or rather, not yet, since it sounds like I might have a treat in
store. The 'personalising' of machines to describe protocol steps isn't
exactly a Stefek invention, though I've been known to do it in a
particularly animated way when trying to keep a lecture room full of
students from falling asleep when hearing about IP basics or the innards
of TLS/SSL, SSH, IPSEC, and the like...

Hmm. I think I'm just about to buy Padlipsky's Collected Rants in
hardcopy - should be just the thing for those quiet moments!

Thanks for the pointer - Stefek

On Tue, 22 Mar 2005 22:14:33 UTC, Stefek Zaba
wrote:

Bob Eager wrote:


The writing style you used above (entertaining!) reminds me strongly of
the writings of a friend of mine, Mike Padlipsky (he of the Telnet
protocol, and a book which was a diatribe against OSI). Ever read any of
his stuff?

No - or rather, not yet, since it sounds like I might have a treat in
store. The 'personalising' of machines to describe protocol steps isn't
exactly a Stefek invention, though I've been known to do it in a
particularly animated way when trying to keep a lecture room full of
students from falling asleep when hearing about IP basics or the innards
of TLS/SSL, SSH, IPSEC, and the like...

What I do, too! And remember...

All People Should Talk Nicely Like Padlipsky

Hmm. I think I'm just about to buy Padlipsky's Collected Rants in
hardcopy - should be just the thing for those quiet moments!

Just make sure you're well up on the works and aliases of Voltaire,
inter alia....

Do let me know how you get on...

--
Bob Eager

Stefek Zaba wrote:

[...] So, let's say we're trying to deliver mail to an address at
foo.bar.net, and the DNS delivers three MX records for foo.bar.net -
mailhub.bar.net at priority 10, mailhub.friendofbardotnet.org at
priority 20, and smtp.anothermate.net, also at priority 20. It tries to
talk SMTP to mailhub.bar.net, but finds that host's not listening for
whatever reason. It falls back to, say, mailhub.friendofbardotnet.org,
which is happy to store-n-forward the mail. The sending system considers
it's done all it needs to at this point (ass-U-ming it's got a Happy
response from m.f.o).

When m.f.o next gets round to processing its mail queue, it comes across
the message it accepted for foo.bar.net. It gets the same DNS responses
as the original sender - mailhub.bar.net at prio 10, itself at prio 20,
smtp.anothermate.net at 20. Since its own MX priority is 20, it won't
try pushing the mail to itself, nor to smtp.anothermate.net; the only
SMTP listener worth trying, with a 'better' priority than itself, is
mailhub.bar.net. So it'll keep trying that server, according to whatever
retry/backoff strategy it uses (preferably an exponential backoff, but
you never know what some numpty might code up), until it either succeeds
or times out after (typically) a few days.

So, *provided* *a* *domain's* *MX* *priorities* *are* *consistently*
*set* *up*, mail only makes 'forward progress', i.e. towards the final
'best' handler, while listing multiple handlers at the same priority
allows simple load-balancing.

Stefek, thanks for all that. It answers my question about "its own
priority" - but prompts a few more, of the
probably-naive-and-obvious-to-you kind:

This 'forward progress' - what's the point? If lots of people are
trying to send mail to m.b.n (hosts as per your example) then all that's
achieved by having the other handlers at m.f.o and s.a.n is to
transfer small amounts of delayed mail from a large no. of places and
accumulate a large amount in one or two places. But users of m.b.n are
still not getting any mail, because it's down - unless m.f.o/s.a.n can
provide a POP facility. So why does that constitute progress? - is it
just that there'll be fewer hops left to the final destination.

Load balancing: you said that when the sending SMTP server failed to
talk to m.b.n it tried "say one of the others" - but what algorithm
decides which one to try, and how, when lots of other senders are doing
the same, is the said balancing achieved?

--
Andy