Subject: Re: BCP for handling DNS SERVFAIL results
From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "Arnt Gulbrandsen" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sun, 27 Nov 2005 17:35:30 -0500
List-Id: <ietf-smtp.imc.org>

Interesting,

Yes and no. No, I wasn't aware of this specific SendMail implementation
"kludge" to accommodate a flawed behavior. But yes, I guess it was done
because the author (greg?) realized the environment of various bozo types
(from admins, to buggy DNS servers) was prevalent.

We all (authors) have to do this like we don't like, thats the nature of the
game.

In this case, I wasn't aware of a history of DNS servers having some form or
another problem with SERVFAIL responses. So this was fixed now that I found
out the cause and solution.

I don't think it is 100% related to having a bad setup, although that is
what I initially thought was the case here.

db.usinterlink.com has a A record, no MX record.  the usinterlink.com
authoritive server was passing info to my DNS server, which it didn't handle
right.  I'm not a DNS admin so I can't tell you 100% if this domain is setup
wrong, other than the fact it has no MX record.

I can see an specific implementation option, not a recommendation for BCP,
called "BozoServerFailChecks"  which might work like this:

  1) Perform all query checks as normal, using SERVFAIL to move to next
     server list.

  2) Maybe after all retry attempts, try the A record atleast once to
     close the deal or follow the option setting:

      BozoServerFailChecks -1  ; final deal
      BozoServerFailChecks  2  ; Try A record after 2 retries
      BozoServerFailChecks  0  ; Off, DEFAULT

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "Arnt Gulbrandsen" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Sunday, November 27, 2005 3:30 AM
Subject: Re: BCP for handling DNS SERVFAIL results

On Sun, 27 Nov 2005 02:45:18 EST, Hector Santos said:

> But if you search the net, you will find discussions on this SMTP client
> consideration.   I can only suggest the historical reason is that there
were
> many DNS servers producing the erroneous SERVFAIL failures

I can only suggest that in an environment were a lot of bozos were unable to
properly set up their DNS, it's not at all surprising to find that other
bozos
were recommending totally bogus methods of working around the ineptitute of
the first set of bozos.

Or were you thinking of this from Sendmail:

        New ResolverOptions setting: WorkAroundBrokenAAAA.  When
                attempting to canonify a hostname, some broken nameservers
                will return SERVFAIL (a temporary failure) on T_AAAA (IPv6)
                lookups.  If you want to excuse this behavior, use this new
                flag.

Date: Sun, 27 Nov 2005 17:32:15 -0500
From: John C Klensin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
cc: [email-masked], Hector Santos <[email-masked]>, =?UTF-8?Q?Valdis_Kl=C4=93tnieks?= <[email-masked]>, [email-masked]
Subject: Re: BCP for handling DNS SERVFAIL results
Sender: [email-masked]

--On Sunday, 27 November, 2005 08:23 +0100 Arnt Gulbrandsen
<[email-masked]> wrote:

> 
> Valdis Klētnieks writes:
>> I think Arnt's meaning was "If you get a SERVFAIL trying to
>> get the  MX, then you *don't* know there's no MX, so dropping
>> back to an A is  improper. The message should be queued and
>> retried later".
> 
> Exactly.
> 
> I'd say that SERVFAIL is best covered by RFC 2821 section 6.1,
> which has this to say about error handling: «It [the MTA]
> must take this responsibility seriously.  It MUST NOT lose the
> message for frivolous reasons, such as because the host later
> crashes or because of a predictable resource shortage.»
> Although the DNS is not mentioned, the passage doesn't seem to
> condone speculatively falling back to A in case of an MX query
> timeout, SERVFAIL, or other uncertain response.
> 
> Arnt

That was the intent.  If it doesn't seem sufficient clear, text
would be welcome.

"There is no MX" means that one actually gets an authoritative
reply that says that there isn't one.  Only then does one look
for the associated A RR and assume it is equivalent to a
best-priority MX.

     john

   john

Date: Sun, 27 Nov 2005 07:01:05 -0800
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: BCP for handling DNS SERVFAIL results
Sender: [email-masked]

Hi Arnt,
At 23:23 26-11-2005, Arnt Gulbrandsen wrote:
>I'd say that SERVFAIL is best covered by RFC 
>2821 section 6.1, which has this to say about 
>error handling: «It [the MTA] must take this 
>responsibility seriously.  It MUST NOT lose the 
>message for frivolous reasons, such as because the host later crashes or

I didn't read your previously reply 
correctly.  The above sums up nicely the BCP for SERVFAIL.

Regards,
-sm 

To: Hector Santos <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: BCP for handling DNS SERVFAIL results 
From: [email-masked]
Date: Sun, 27 Nov 2005 03:30:23 -0500
Sender: [email-masked]

--==_Exmh_1133080223_2922P
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, 27 Nov 2005 02:45:18 EST, Hector Santos said:

> But if you search the net, you will find discussions on this SMTP clien=
t
> consideration.   I can only suggest the historical reason is that there=
 were
> many DNS servers producing the erroneous SERVFAIL failures

I can only suggest that in an environment were a lot of bozos were unable=
 to
properly set up their DNS, it's not at all surprising to find that other =
bozos
were recommending totally bogus methods of working around the ineptitute =
of
the first set of bozos.

Or were you thinking of this from Sendmail:

        New ResolverOptions setting: WorkAroundBrokenAAAA.  When
                attempting to canonify a hostname, some broken nameserver=
s
                will return SERVFAIL (a temporary failure) on T_AAAA (IPv=
6)
                lookups.  If you want to excuse this behavior, use this n=
ew
                flag.

--==_Exmh_1133080223_2922P
Content-Type: application/pgp-signature

--==_Exmh_1133080223_2922P--

From: "Hector Santos" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, =?utf-8?Q?Valdis_Kl=C4=93tnieks?= <[email-masked]>, <[email-masked]>
Subject: Re: BCP for handling DNS SERVFAIL results
Date: Sun, 27 Nov 2005 02:45:18 -0500
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Arnt Gulbrandsen" <[email-masked]>

>> Valdis Klētnieks writes:
>> I think Arnt's meaning was "If you get a SERVFAIL trying to get the
>> MX, then you *don't* know there's no MX, so dropping back to an A is
>> improper. The message should be queued and retried later".

> Exactly.
>
> I'd say that SERVFAIL is best covered by RFC 2821 section 6.1, which has
> this to say about error handling: «It [the MTA] must take this
> responsibility seriously.  It MUST NOT lose the message for frivolous
> reasons, such as because the host later crashes or because of a
> predictable resource shortage.» Although the DNS is not mentioned, the
> passage doesn't seem to condone speculatively falling back to A in case
> of an MX query timeout, SERVFAIL, or other uncertain response.

I think all agreed.

But if you search the net, you will find discussions on this SMTP client
consideration.   I can only suggest the historical reason is that there were
many DNS servers producing the erroneous SERVFAIL failures, and it would be
quite possible that exhausted attempts would finally kill/dump the message
when in fact, an A record lookup might have satisfied the transaction.

But you are right.  This wouldn't be a good idea.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Sun, 27 Nov 2005 08:23:37 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: BCP for handling DNS SERVFAIL results
Cc: [email-masked], Hector Santos <[email-masked]>, Valdis =?utf-8?q?Kl=C4=93tnieks?= <[email-masked]>, [email-masked]
Sender: [email-masked]

Valdis Klētnieks writes:
> I think Arnt's meaning was "If you get a SERVFAIL trying to get the 
> MX, then you *don't* know there's no MX, so dropping back to an A is 
> improper. The message should be queued and retried later".

Exactly.

I'd say that SERVFAIL is best covered by RFC 2821 section 6.1, which has 
this to say about error handling: «It [the MTA] must take this 
responsibility seriously.  It MUST NOT lose the message for frivolous 
reasons, such as because the host later crashes or because of a 
predictable resource shortage.» Although the DNS is not mentioned, the 
passage doesn't seem to condone speculatively falling back to A in case 
of an MX query timeout, SERVFAIL, or other uncertain response.

Arnt

From: "Hector Santos" <[email-masked]>
To: "Hector Santos" <[email-masked]>, <[email-masked]>
Cc: "IETF-SMTP" <[email-masked]>
Subject: Re: BCP for handling DNS SERVFAIL results
Date: Sat, 26 Nov 2005 23:10:34 -0500
Organization: Santronics Software, Inc.
Sender: [email-masked]

Ned,

I got the hotfix from Microsoft (a per request item, not part of the service
packs), apply it and the SERVFAIL issue is now resolved. :-)

I think what this all says that many of the legacy servers, including NT,
Windows 2000, and BIND had SERVFAIL related issues, and the idea or (bad)
consideration to view SERVFAIL as a NXDOMAIN in order to fallback to the A
record reflected the fact that this issue did exist in the past for many of
the DNS servers.

I don't agree with this SMTP outgoing DNS logic consideration, but I can
certainly see why it was discussed in some of the net research I did on the
matter.

Thanks for your comments.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "IETF-SMTP" <[email-masked]>
Sent: Saturday, November 26, 2005 3:08 AM
Subject: Re: BCP for handling DNS SERVFAIL results

>
> Well Ned! I did some detailed searching, and found this for Windows NT 4.0
> and 2000 DNS.EXE server.
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;295933
>
> Here its description (For Windows):
>
> ----
> SYMPTOMS
>
> The resolution of e-mail names and other names may not work if a Windows
> 2000-based or Windows NT 4.0-based Domain Name System (DNS) server
receives
> a non-authoritative response from a root hint or forwarder. The Windows
> 2000-based or Windows NT 4.0-based DNS server sends a "Server Failure"
> message to the client when it receives a Start of Authority (SOA) record
> from a non-authoritative resource.
>
> Some non-Microsoft DNS servers (for example, some BIND versions) cache
empty
> authoritative responses, which Windows 2000-based and Windows NT 4.0-based
> DNS servers consider to be referrals. When a Windows 2000-based or Windows
> NT 4.0-based DNS server receives such a response, the response is ignored
> and a "Server Failure" message is sent to the client instead of the SOA
> record.
> ----
>
> I am trying to get this update now which I thought SP6 already covered
this.
> Apparently not.  Hopefully, this will clear the server issue.
>
> BTW, I found SERVFAIL related issues too with BIND too.
>
> http://www.isc.org/pubs/tn/isc-tn-2002-2.html
> http://archives.neohapsis.com/archives/bind/2002/0007.html
>
> I downloaded the BIND source to learn about DNS server logic.
>
> --
> Hector Santos, Santronics Software, Inc.
> http://www.santronics.com
>
>
>
>
> ----- Original Message -----
> From: <[email-masked]>
> To: "Hector Santos" <[email-masked]>
> Cc: <[email-masked]>; "IETF-SMTP" <[email-masked]>
> Sent: Friday, November 25, 2005 11:39 PM
> Subject: Re: BCP for handling DNS SERVFAIL results
>
>
> >
> > > Thanks Ned. Excellent info and insight.
> >
> > > I do have a few follow-up questions related this:
> >
> > > >> 2) Use Multiple DNS server.
> > > >>
> > > >>    An IBM solution was to suggest to make sure you have
> > > >>    additional DNS servers to query.
> > > >
> > > > Well, sure. Having at least one secondary DNS server is pretty much
> > > essential,
> > > > and they need to be geographically separate. I note in passing that
> > > > interlink.com has two servers and they appear to be on separate
> networks.
> > > >
> > > > ns5.ecsecure.com. [208.56.100.1] [TTL=86400]
> > > > ns6.ecsecure.com. [216.147.1.227] [TTL=86400]
> >
> > > One of the confusing issues about this, and no doubt probably a
> > > misunderstanding on my part, is related to having multiple DNS servers
> vs
> > > Primary DNS recursion lookups.
> >
> > First a disclaimer: DNS operations are not exactly my primary area of
> expertise
> > either. Hopefully what I say here will be correct and if it isn't
> hopefully
> > someone else will chime in and correct me.
> >
> > With that said...
> >
> > Be very careful here with your terminology. In the DNS world a "primary"
> server
> > is one that provides authoritative information for one or more domains.
A
> > "secondary" is a slave that periodically transfers information from the
> > primary and makes it available for queries.
> >
> > The servers for a given domain are specified by NS records in the
"upper"
> > domain. So the way this works is that a resolver starts at the top of
the
> tree
> > and walks down using NS records at each level to find the servers below.
> If
> > there are multiple NS records I believe the approach is to pick one  at
> random
> > and if that doesn't work try another. This may also depend on the
resolver
> > implementation.
> >
> > Caching of course eliminates the need for many of these queries and
makes
> the
> > load at the upper levels manageable. There's also a bunch of tricky
stuff
> done
> > at the very top to make things sufficiently performant while allowing
> multiple
> > providers - I know very little about all this magic.
> >
> > > How do I best ask this because again, I am not a DNS admin or a server
> > > expert.
> >
> > Well, I guess I qualify as an admin since I handle a bunch of primary
and
> > secondary domains. But again, I'm no expert.
> >
> > > I guess the question is, can the same results be expected with:
> >
> > >   1) A server with multiple uplinks, versus
> >
> > I'm afraid this exceeds my level of expertise. I use bind but I don't
have
> a
> > multihomed environment so I don't know how it or any other server
> > implementation handles being multihomed.
> >
> > >   2) Multiple Server list
> >
> > Applications typically don't have a full resolver built in that's
capable
> of
> > walking the DNS tree. Rather, they have a so-called "stub" resolver that
> is
> > given a list of full resolvers to send queries to. The stub resolver
> builds a
> > query and sends it to one of the resolvers, gets back a result and
decodes
> it.
> >
> > > I guess your statement above about having geographically separate
> servers
> > > makes all this work better to increase the odds of getting result.
> >
> > Right. Of course geographic separation doesn't matter when the problem
is
> that
> > a server is down, but it can save you when a link is down.
> >
> > > But it was my impression that when you query a primary server, if the
> query
> > > is not available in the zone and not currently cached, that the server
> will
> > > query its uplinks. No?
> >
> > Your terminology is confusing here. I think by "primary server" you mean
> "full
> > resolver" and by "uplink" you mean "servers for uplevel domains". If so,
> then
> > yes, this is more or less how it works, but it works its way down from
the
> > lowest uplevel entry that the resolver has cached.
> >
> > > You see, for my company SMTP server, I have:
> >
> > >       208.247.131.10
> > >       198.6.1.2
> >
> > > 208.247.131.10 is where I have my ns.santronics.com primary DNS
server,
> >
> > OK, but that has nothing to do with whether or not you're using that
> machine as
> > your full resolver. For example, the primary server for mrochek.com is
> > mauve.mrochek.com, but DNS queries on that machine are actually
forwarded
> to a
> > completely different system for resolution. I believe it's considered
good
> > practice not to have your DNS primaries or secondaries performing
general
> DNS
> > resolution services.
> >
> > > and I have as forwarders the UUNET servers:
> >
> > >       198.6.1.2
> > >       198.6.1.3
> >
> > > I had the impression this provided the uplink queries when the primary
> did
> > > not have the information.
> >
> > Maybe. It would depend on how you have things configured. Forwarders are
> > basiclaly used to offload DNS processing from one machine to another.
> >
> > > I just happen to see this SERVFAIL fail when I was testing this
> customer's
> > > db.usinterlink.com MX record against 208.247.131.10 via Window's
> > > NSLOOKUP.EXE.
> >
> > > I was assisting him remotely from home and didn't see this SERVFAIL
> against
> > > the bellsouth.net server:
> >
> > >    NSLOOKUP -query=mx -debug db.usinterlink.com ns.santronics.com
> > >    NSLOOKUP -query=mx -debug db.usinterlink.com dns.msy.bellsouth.net
> >
> > > First one returns SERVFAIL, second one NOERROR.
> >
> > You might consider clearing the cache on your home server and see if
that
> > helps.
> >
> > > I was able to send him a test message because the SMTP server was
> finally
> > > able to get to the second unnet server, and thus fallback to a
> successful A
> > > record result.
> >
> > > But the situation got me wondering what was wrong or different between
> the
> > > two, and also what if I or other customers didn't have a second DNS
> server
> > > setup for SMTP, if its something to worry about.
> >
> > > >> 4) Ignore SERVFAIL?
> > > >
> > > >> Some just said that the SMTP client should be looking at SERVFAIL
as
> a
> > > >> NXDOMAIN, etc.
> > > >
> > > > Bad idea IMO. Configuration glitches happen, and when they do you
> > > > don't want to bounce mail to the domain unnecessarily. Most of the
> > > > time these problems get fixed and the mail goes on through with
> > > > only a small delay.
> >
> > > I agree.  I was wondering, and now realize that its probably wrong to
> jump
> > > the gun with this, if it would make sense to do a A record lookup for
a
> > > SERVFAIL.
> >
> > I've actually seen cases where MX record queries got a SERVFAIL but an A
> record
> > query got a successful result. (I've always believed this is due to the
> server
> > being down or misconfigured and having one record type cached but not
the
> > other, but I've never been able to track down the specific cause.) This
> stuff
> > gets very complex because DNS servers do tricky stuff like piggyback A
> record
> > information on MX queries, making problems hard to isolate.
> >
> > But this doesn't mean that you should do this: Nothing prevents someone
> from
> > having an MX for foo.example.com pointing to a completely separate
> > mail.example.org while having a SMTP server running on foo.example.com
> that
> > silently eats everything sent to it. And yes, such a setup would be
stupid
> and
> > dangerous, but people do stupid and dangerous things all the time.
> >
> > Ned
> >
> >
>
>
>

From: "Hector Santos" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>, "SM" <[email-masked]>
Subject: Re: BCP for handling DNS SERVFAIL results
Date: Sat, 26 Nov 2005 20:01:34 -0500
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "SM" <[email-masked]>

>> The problem is that I found while some other DNS servers
>> return NOERROR, my DNS server returned SERVFAIL to the MX query.
>
> SERVFAIL is returned if the DNS server cannot process the query.

Right. What I'm founding out is that it seems some versions of DNS servers
do have some packet handling issues, most likely due to record
configuration, is reflecting possibly an erroneous error SERVFAIL.

Currently looking to update the NT 4.0 server, based on this article:

http://support.microsoft.com/default.aspx?scid=kb;en-us;295933

We are planning to upgrade the machine this year, but I though we had all
and last of Service Pack 6.    We have an 2 year older DNS.EXE. It sounds
like it might be the reason we see it on this server.

BIND had some similar SERVFAIL issues that were corrected in 9.3.1.

See note about how empty authoritive responses were cached and this was
picked up by the MS DNS server resulting in SERVFAIL.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: SM <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked], Hector Santos <[email-masked]>
Subject: Re: BCP for handling DNS SERVFAIL results 
From: [email-masked]
Date: Sat, 26 Nov 2005 19:35:44 -0500
Sender: [email-masked]

--==_Exmh_1133051744_2922P
Content-Type: text/plain; charset=us-ascii

On Sat, 26 Nov 2005 13:03:18 PST, SM said:
> 
> Hi Arnt,
> At 23:48 25-11-2005, Arnt Gulbrandsen wrote:
> >I agree with Ned: Don't fall back to A unless you know there's no MX.
> 
> According to the RFC, you should fall back to A if there is no 
> MX.  There is no reliable way to tell that there should be a MX and 
> we should not fall back.

I think Arnt's meaning was "If you get a SERVFAIL trying to get the MX,
then you *don't* know there's no MX, so dropping back to an A is improper.
The message should be queued and retried later".

--==_Exmh_1133051744_2922P
Content-Type: application/pgp-signature

--==_Exmh_1133051744_2922P--

Date: Sat, 26 Nov 2005 13:03:18 -0800
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: BCP for handling DNS SERVFAIL results
Cc: [email-masked], Hector Santos <[email-masked]>
Sender: [email-masked]

Hi Arnt,
At 23:48 25-11-2005, Arnt Gulbrandsen wrote:
>I agree with Ned: Don't fall back to A unless you know there's no MX.

According to the RFC, you should fall back to A if there is no 
MX.  There is no reliable way to tell that there should be a MX and 
we should not fall back.

Regards,
-sm 

Date: Sat, 26 Nov 2005 12:37:09 -0800
To: Hector Santos <[email-masked]>, IETF-SMTP <[email-masked]>
From: SM <[email-masked]>
Subject: Re: BCP for handling DNS SERVFAIL results
Sender: [email-masked]

Hi Hector,
At 11:18 25-11-2005, Hector Santos wrote:
>This week, I ran across a particular new customer setup with an email domain
>that he hadn't created a MX record yet.  He was using a sub domain,
>db.usinterlink.com.

The host resolves.  It's valid as there is an A record.

>Of course, the SMTP client should:
>
>     - Do a MX query
>     - if none result, do a A record query
>
>The problem is that I found while some other DNS servers return NOERROR, my
>DNS server returned SERVFAIL to the MX query.

SERVFAIL is returned if the DNS server cannot process the query.

>Here is what I found on the net as four different answers:
>
>1) SendMail Configuration/New Behavior
>
>http://www.brandonhutchinson.com/host_map__lookup_(domain)__deferred.html
>
>  However, if the A or MX record lookup for the domain returns a
>  "SERVFAIL," Sendmail will queue the message, believing it has
>  encountered a transient DNS problem. For example, if a domain has a
>  valid A record but returns a "SERVFAIL" when queried for an MX record
>  (instead of "NOERROR" with an empty answer section), Sendmail will
>  queue the message. You should contact the remote name server
>  administrator in order to fix these problems."

SERVFAIL is a treated as a temporary failure.  There may be a problem 
with the authoritative servers or the DNS server which is being 
queried.  Previously, sendmail did not enforce these DNS checks.

>2) Use Multiple DNS server.

That's not really a solution as you can still get SERVFAIL in some 
cases.  The best practice however is to have more than one 
authoritative DNS server for redundancy.  They should have diverse 
paths.  Each DNS is in a different geographical location.

>3) Lame Delegation
>
>I saw other comments pointing it to be mostly a DNS configuration issue,
>Lame Delegation?

That's a different issue.  You should only list DNS servers which are 
authoritative for the domain.

>4) Ignore SERVFAIL?
>
>Some just said that the SMTP client should be looking at SERVFAIL as a
>NXDOMAIN, etc.

No, see above.  You may lose mail if you rejected based on DNS failures.

>I have a second DNS server so the result was found at my secondary UUNET
>server.  But in general, I am trying to see why I got the SERVFAIL error in
>the first place and in general for customers who might just have 1 DNS
>server, how a SERVFAIL should be handled.  We are querying it. So it not a
>matter of lost mail.

Query the authoritative servers and see whether you get a 
SERVFAIL.  If you don't, flush the cache and query your DNS 
server.  BTW, truncated DNS replies can cause 
SERVFAIL.  Misconfigured firewalls can also affect DNS responses.

Regards,
-sm 

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "IETF-SMTP" <[email-masked]>
Subject: Re: BCP for handling DNS SERVFAIL results
Date: Sat, 26 Nov 2005 03:08:17 -0500
Organization: Santronics Software, Inc.
Sender: [email-masked]

Well Ned! I did some detailed searching, and found this for Windows NT 4.0
and 2000 DNS.EXE server.

http://support.microsoft.com/default.aspx?scid=kb;en-us;295933

Here its description (For Windows):

----
SYMPTOMS

The resolution of e-mail names and other names may not work if a Windows
2000-based or Windows NT 4.0-based Domain Name System (DNS) server receives
a non-authoritative response from a root hint or forwarder. The Windows
2000-based or Windows NT 4.0-based DNS server sends a "Server Failure"
message to the client when it receives a Start of Authority (SOA) record
from a non-authoritative resource.

Some non-Microsoft DNS servers (for example, some BIND versions) cache empty
authoritative responses, which Windows 2000-based and Windows NT 4.0-based
DNS servers consider to be referrals. When a Windows 2000-based or Windows
NT 4.0-based DNS server receives such a response, the response is ignored
and a "Server Failure" message is sent to the client instead of the SOA
record.
----

I am trying to get this update now which I thought SP6 already covered this.
Apparently not.  Hopefully, this will clear the server issue.

BTW, I found SERVFAIL related issues too with BIND too.

http://www.isc.org/pubs/tn/isc-tn-2002-2.html
http://archives.neohapsis.com/archives/bind/2002/0007.html

I downloaded the BIND source to learn about DNS server logic.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>; "IETF-SMTP" <[email-masked]>
Sent: Friday, November 25, 2005 11:39 PM
Subject: Re: BCP for handling DNS SERVFAIL results

>
> > Thanks Ned. Excellent info and insight.
>
> > I do have a few follow-up questions related this:
>
> > >> 2) Use Multiple DNS server.
> > >>
> > >>    An IBM solution was to suggest to make sure you have
> > >>    additional DNS servers to query.
> > >
> > > Well, sure. Having at least one secondary DNS server is pretty much
> > essential,
> > > and they need to be geographically separate. I note in passing that
> > > interlink.com has two servers and they appear to be on separate
networks.
> > >
> > > ns5.ecsecure.com. [208.56.100.1] [TTL=86400]
> > > ns6.ecsecure.com. [216.147.1.227] [TTL=86400]
>
> > One of the confusing issues about this, and no doubt probably a
> > misunderstanding on my part, is related to having multiple DNS servers
vs
> > Primary DNS recursion lookups.
>
> First a disclaimer: DNS operations are not exactly my primary area of
expertise
> either. Hopefully what I say here will be correct and if it isn't
hopefully
> someone else will chime in and correct me.
>
> With that said...
>
> Be very careful here with your terminology. In the DNS world a "primary"
server
> is one that provides authoritative information for one or more domains. A
> "secondary" is a slave that periodically transfers information from the
> primary and makes it available for queries.
>
> The servers for a given domain are specified by NS records in the "upper"
> domain. So the way this works is that a resolver starts at the top of the
tree
> and walks down using NS records at each level to find the servers below.
If
> there are multiple NS records I believe the approach is to pick one  at
random
> and if that doesn't work try another. This may also depend on the resolver
> implementation.
>
> Caching of course eliminates the need for many of these queries and makes
the
> load at the upper levels manageable. There's also a bunch of tricky stuff
done
> at the very top to make things sufficiently performant while allowing
multiple
> providers - I know very little about all this magic.
>
> > How do I best ask this because again, I am not a DNS admin or a server
> > expert.
>
> Well, I guess I qualify as an admin since I handle a bunch of primary and
> secondary domains. But again, I'm no expert.
>
> > I guess the question is, can the same results be expected with:
>
> >   1) A server with multiple uplinks, versus
>
> I'm afraid this exceeds my level of expertise. I use bind but I don't have
a
> multihomed environment so I don't know how it or any other server
> implementation handles being multihomed.
>
> >   2) Multiple Server list
>
> Applications typically don't have a full resolver built in that's capable
of
> walking the DNS tree. Rather, they have a so-called "stub" resolver that
is
> given a list of full resolvers to send queries to. The stub resolver
builds a
> query and sends it to one of the resolvers, gets back a result and decodes
it.
>
> > I guess your statement above about having geographically separate
servers
> > makes all this work better to increase the odds of getting result.
>
> Right. Of course geographic separation doesn't matter when the problem is
that
> a server is down, but it can save you when a link is down.
>
> > But it was my impression that when you query a primary server, if the
query
> > is not available in the zone and not currently cached, that the server
will
> > query its uplinks. No?
>
> Your terminology is confusing here. I think by "primary server" you mean
"full
> resolver" and by "uplink" you mean "servers for uplevel domains". If so,
then
> yes, this is more or less how it works, but it works its way down from the
> lowest uplevel entry that the resolver has cached.
>
> > You see, for my company SMTP server, I have:
>
> >       208.247.131.10
> >       198.6.1.2
>
> > 208.247.131.10 is where I have my ns.santronics.com primary DNS server,
>
> OK, but that has nothing to do with whether or not you're using that
machine as
> your full resolver. For example, the primary server for mrochek.com is
> mauve.mrochek.com, but DNS queries on that machine are actually forwarded
to a
> completely different system for resolution. I believe it's considered good
> practice not to have your DNS primaries or secondaries performing general
DNS
> resolution services.
>
> > and I have as forwarders the UUNET servers:
>
> >       198.6.1.2
> >       198.6.1.3
>
> > I had the impression this provided the uplink queries when the primary
did
> > not have the information.
>
> Maybe. It would depend on how you have things configured. Forwarders are
> basiclaly used to offload DNS processing from one machine to another.
>
> > I just happen to see this SERVFAIL fail when I was testing this
customer's
> > db.usinterlink.com MX record against 208.247.131.10 via Window's
> > NSLOOKUP.EXE.
>
> > I was assisting him remotely from home and didn't see this SERVFAIL
against
> > the bellsouth.net server:
>
> >    NSLOOKUP -query=mx -debug db.usinterlink.com ns.santronics.com
> >    NSLOOKUP -query=mx -debug db.usinterlink.com dns.msy.bellsouth.net
>
> > First one returns SERVFAIL, second one NOERROR.
>
> You might consider clearing the cache on your home server and see if that
> helps.
>
> > I was able to send him a test message because the SMTP server was
finally
> > able to get to the second unnet server, and thus fallback to a
successful A
> > record result.
>
> > But the situation got me wondering what was wrong or different between
the
> > two, and also what if I or other customers didn't have a second DNS
server
> > setup for SMTP, if its something to worry about.
>
> > >> 4) Ignore SERVFAIL?
> > >
> > >> Some just said that the SMTP client should be looking at SERVFAIL as
a
> > >> NXDOMAIN, etc.
> > >
> > > Bad idea IMO. Configuration glitches happen, and when they do you
> > > don't want to bounce mail to the domain unnecessarily. Most of the
> > > time these problems get fixed and the mail goes on through with
> > > only a small delay.
>
> > I agree.  I was wondering, and now realize that its probably wrong to
jump
> > the gun with this, if it would make sense to do a A record lookup for a
> > SERVFAIL.
>
> I've actually seen cases where MX record queries got a SERVFAIL but an A
record
> query got a successful result. (I've always believed this is due to the
server
> being down or misconfigured and having one record type cached but not the
> other, but I've never been able to track down the specific cause.) This
stuff
> gets very complex because DNS servers do tricky stuff like piggyback A
record
> information on MX queries, making problems hard to isolate.
>
> But this doesn't mean that you should do this: Nothing prevents someone
from
> having an MX for foo.example.com pointing to a completely separate
> mail.example.org while having a SMTP server running on foo.example.com
that
> silently eats everything sent to it. And yes, such a setup would be stupid
and
> dangerous, but people do stupid and dangerous things all the time.
>
> Ned
>
>

Date: Sat, 26 Nov 2005 08:48:13 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: BCP for handling DNS SERVFAIL results
Cc: [email-masked], Hector Santos <[email-masked]>
Sender: [email-masked]

[email-masked] writes:
> But this doesn't mean that you should do this: Nothing prevents 
> someone from having an MX for foo.example.com pointing to a 
> completely separate mail.example.org while having a SMTP server 
> running on foo.example.com that silently eats everything sent to it. 
> And yes, such a setup would be stupid and dangerous, but people do 
> stupid and dangerous things all the time.

I've seen this exact setup, in two varieties.

workstation15.example.com IN A 10.0.1.15
                           IN MX 0 smarthost.example.com.

Who knows what you might reach at 10.0.1.15?

The other variety has a proper IP addres for workstation15, and 
workstation15 runs a vendor-standard SMTP server, delivering to 
somewhere that noone ever reads.

I agree with Ned: Don't fall back to A unless you know there's no MX.

Arnt

From: [email-masked]
Cc: [email-masked], IETF-SMTP <[email-masked]>
To: Hector Santos <[email-masked]>
Date: Fri, 25 Nov 2005 20:39:16 -0800 (PST)
Subject: Re: BCP for handling DNS SERVFAIL results
Sender: [email-masked]

> Thanks Ned. Excellent info and insight.

> I do have a few follow-up questions related this:

> >> 2) Use Multiple DNS server.
> >>
> >>    An IBM solution was to suggest to make sure you have
> >>    additional DNS servers to query.
> >
> > Well, sure. Having at least one secondary DNS server is pretty much
> essential,
> > and they need to be geographically separate. I note in passing that
> > interlink.com has two servers and they appear to be on separate networks.
> >
> > ns5.ecsecure.com. [208.56.100.1] [TTL=86400]
> > ns6.ecsecure.com. [216.147.1.227] [TTL=86400]

> One of the confusing issues about this, and no doubt probably a
> misunderstanding on my part, is related to having multiple DNS servers vs
> Primary DNS recursion lookups.

First a disclaimer: DNS operations are not exactly my primary area of expertise
either. Hopefully what I say here will be correct and if it isn't hopefully
someone else will chime in and correct me.

With that said...

Be very careful here with your terminology. In the DNS world a "primary" server
is one that provides authoritative information for one or more domains. A
"secondary" is a slave that periodically transfers information from the
primary and makes it available for queries.

The servers for a given domain are specified by NS records in the "upper"
domain. So the way this works is that a resolver starts at the top of the tree
and walks down using NS records at each level to find the servers below. If
there are multiple NS records I believe the approach is to pick one  at random
and if that doesn't work try another. This may also depend on the resolver
implementation.

Caching of course eliminates the need for many of these queries and makes the
load at the upper levels manageable. There's also a bunch of tricky stuff done
at the very top to make things sufficiently performant while allowing multiple
providers - I know very little about all this magic.

> How do I best ask this because again, I am not a DNS admin or a server
> expert.

Well, I guess I qualify as an admin since I handle a bunch of primary and
secondary domains. But again, I'm no expert.

> I guess the question is, can the same results be expected with:

>   1) A server with multiple uplinks, versus

I'm afraid this exceeds my level of expertise. I use bind but I don't have a
multihomed environment so I don't know how it or any other server
implementation handles being multihomed.

>   2) Multiple Server list

Applications typically don't have a full resolver built in that's capable of
walking the DNS tree. Rather, they have a so-called "stub" resolver that is
given a list of full resolvers to send queries to. The stub resolver builds a
query and sends it to one of the resolvers, gets back a result and decodes it.

> I guess your statement above about having geographically separate servers
> makes all this work better to increase the odds of getting result.

Right. Of course geographic separation doesn't matter when the problem is that
a server is down, but it can save you when a link is down.

> But it was my impression that when you query a primary server, if the query
> is not available in the zone and not currently cached, that the server will
> query its uplinks. No?

Your terminology is confusing here. I think by "primary server" you mean "full
resolver" and by "uplink" you mean "servers for uplevel domains". If so, then
yes, this is more or less how it works, but it works its way down from the
lowest uplevel entry that the resolver has cached.

> You see, for my company SMTP server, I have:

>       208.247.131.10
>       198.6.1.2

> 208.247.131.10 is where I have my ns.santronics.com primary DNS server,

OK, but that has nothing to do with whether or not you're using that machine as
your full resolver. For example, the primary server for mrochek.com is
mauve.mrochek.com, but DNS queries on that machine are actually forwarded to a
completely different system for resolution. I believe it's considered good
practice not to have your DNS primaries or secondaries performing general DNS
resolution services.

> and I have as forwarders the UUNET servers:

>       198.6.1.2
>       198.6.1.3

> I had the impression this provided the uplink queries when the primary did
> not have the information.

Maybe. It would depend on how you have things configured. Forwarders are
basiclaly used to offload DNS processing from one machine to another.

> I just happen to see this SERVFAIL fail when I was testing this customer's
> db.usinterlink.com MX record against 208.247.131.10 via Window's
> NSLOOKUP.EXE.

> I was assisting him remotely from home and didn't see this SERVFAIL against
> the bellsouth.net server:

>    NSLOOKUP -query=mx -debug db.usinterlink.com ns.santronics.com
>    NSLOOKUP -query=mx -debug db.usinterlink.com dns.msy.bellsouth.net

> First one returns SERVFAIL, second one NOERROR.

You might consider clearing the cache on your home server and see if that
helps.

> I was able to send him a test message because the SMTP server was finally
> able to get to the second unnet server, and thus fallback to a successful A
> record result.

> But the situation got me wondering what was wrong or different between the
> two, and also what if I or other customers didn't have a second DNS server
> setup for SMTP, if its something to worry about.

> >> 4) Ignore SERVFAIL?
> >
> >> Some just said that the SMTP client should be looking at SERVFAIL as a
> >> NXDOMAIN, etc.
> >
> > Bad idea IMO. Configuration glitches happen, and when they do you
> > don't want to bounce mail to the domain unnecessarily. Most of the
> > time these problems get fixed and the mail goes on through with
> > only a small delay.

> I agree.  I was wondering, and now realize that its probably wrong to jump
> the gun with this, if it would make sense to do a A record lookup for a
> SERVFAIL.

I've actually seen cases where MX record queries got a SERVFAIL but an A record
query got a successful result. (I've always believed this is due to the server
being down or misconfigured and having one record type cached but not the
other, but I've never been able to track down the specific cause.) This stuff
gets very complex because DNS servers do tricky stuff like piggyback A record
information on MX queries, making problems hard to isolate.

But this doesn't mean that you should do this: Nothing prevents someone from
having an MX for foo.example.com pointing to a completely separate
mail.example.org while having a SMTP server running on foo.example.com that
silently eats everything sent to it. And yes, such a setup would be stupid and
dangerous, but people do stupid and dangerous things all the time.

				Ned

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "IETF-SMTP" <[email-masked]>
Subject: Re: BCP for handling DNS SERVFAIL results
Date: Fri, 25 Nov 2005 21:31:50 -0500
Organization: Santronics Software, Inc.
Sender: [email-masked]

Thanks Ned. Excellent info and insight.

I do have a few follow-up questions related this:

>> 2) Use Multiple DNS server.
>>
>>    An IBM solution was to suggest to make sure you have
>>    additional DNS servers to query.
>
> Well, sure. Having at least one secondary DNS server is pretty much
essential,
> and they need to be geographically separate. I note in passing that
> interlink.com has two servers and they appear to be on separate networks.
>
> ns5.ecsecure.com. [208.56.100.1] [TTL=86400]
> ns6.ecsecure.com. [216.147.1.227] [TTL=86400]

One of the confusing issues about this, and no doubt probably a
misunderstanding on my part, is related to having multiple DNS servers vs
Primary DNS recursion lookups.

How do I best ask this because again, I am not a DNS admin or a server
expert.

I guess the question is, can the same results be expected with:

  1) A server with multiple uplinks, versus
  2) Multiple Server list

I guess your statement above about having geographically separate servers
makes all this work better to increase the odds of getting result.

But it was my impression that when you query a primary server, if the query
is not available in the zone and not currently cached, that the server will
query its uplinks. No?

You see, for my company SMTP server, I have:

      208.247.131.10
      198.6.1.2

208.247.131.10 is where I have my ns.santronics.com primary DNS server, and
I have as forwarders the UUNET servers:

      198.6.1.2
      198.6.1.3

I had the impression this provided the uplink queries when the primary did
not have the information.

I just happen to see this SERVFAIL fail when I was testing this customer's
db.usinterlink.com MX record against 208.247.131.10 via Window's
NSLOOKUP.EXE.

I was assisting him remotely from home and didn't see this SERVFAIL against
the bellsouth.net server:

   NSLOOKUP -query=mx -debug db.usinterlink.com ns.santronics.com
   NSLOOKUP -query=mx -debug db.usinterlink.com dns.msy.bellsouth.net

First one returns SERVFAIL, second one NOERROR.

I was able to send him a test message because the SMTP server was finally
able to get to the second unnet server, and thus fallback to a successful A
record result.

But the situation got me wondering what was wrong or different between the
two, and also what if I or other customers didn't have a second DNS server
setup for SMTP, if its something to worry about.

>> 4) Ignore SERVFAIL?
>
>> Some just said that the SMTP client should be looking at SERVFAIL as a
>> NXDOMAIN, etc.
>
> Bad idea IMO. Configuration glitches happen, and when they do you
> don't want to bounce mail to the domain unnecessarily. Most of the
> time these problems get fixed and the mail goes on through with
> only a small delay.

I agree.  I was wondering, and now realize that its probably wrong to jump
the gun with this, if it would make sense to do a A record lookup for a
SERVFAIL.

As long as its configuration related and the message is being requeued, its
all good then.

Thanks Ned

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: [email-masked]
Cc: IETF-SMTP <[email-masked]>
To: Hector Santos <[email-masked]>
Date: Fri, 25 Nov 2005 15:11:41 -0800 (PST)
Subject: Re: BCP for handling DNS SERVFAIL results
Sender: [email-masked]

> I'm not an DNS server expert so I am not sure if this mostly a configuration
> issue, but my research reveals different information.

> Currently our SMTP outgoing mail client is designed to check each DNS server
> provided when doing a QUERY except for NXDOMAIN results.

I assume you mean you try the first server on your list, and if it has a
problem you move on to the second. Either a succesful return or a NXDOMAIN
response should result in no further queries.

This seems like a reasonable strategy to me.

> This week, I ran across a particular new customer setup with an email domain
> that he hadn't created a MX record yet.  He was using a sub domain,
> db.usinterlink.com.

FWIW, www.dnsreport.com says that the timeouts associated with the DNS entries
for this domain are too high. This sort of thing makes it difficult to add such
an MX record and get it recognized quickly.

> Of course, the SMTP client should:

>     - Do a MX query
>     - if none result, do a A record query

> The problem is that I found while some other DNS servers return NOERROR, my
> DNS server returned SERVFAIL to the MX query.

This sort of thing happens all the time. I'd guess it comes up in a customer
query for us about once every month or two on average, and has done so for well
over a decade. The usual cause is that some sort of infrastructural change has
occured - a server's IP address has changed, some glue record has changed,
whatever - and some server in your setup has managed to cache some bogus
information that prevents it from completing the query.

Another situation you sometimes see is that there is now a configuration
error but some other server managed to cache the information before the
error was made. So the effect it is works but your server doesn't.

My usual advice is to try clearing all the DNS caches you have access to.
In many cases this makes the problem go away.

Tracking this stuff down is very difficult, especially since these sorts of
problems tend to be transient and by the time you have all your debugging ducks
in a row the problem may have vanished. I also have to say I haven't found the
tools available for debugging these problems to be all that sharp.

> Here is what I found on the net as four different answers:

> 1) SendMail Configuration/New Behavior

> http://www.brandonhutchinson.com/host_map__lookup_(domain)__deferred.html

>  However, if the A or MX record lookup for the domain returns a
>  "SERVFAIL," Sendmail will queue the message, believing it has
>  encountered a transient DNS problem. For example, if a domain has a
>  valid A record but returns a "SERVFAIL" when queried for an MX record
>  (instead of "NOERROR" with an empty answer section), Sendmail will
>  queue the message. You should contact the remote name server
>  administrator in order to fix these problems."

IMO this is the correct thing to do.

> 2) Use Multiple DNS server.

> An IBM solution was to suggest to make sure you have additional DNS servers
> to query.

Well, sure. Having at least one secondary DNS server is pretty much essential,
and they need to be geographically separate. I note in passing that
interlink.com has two servers and they appear to be on separate networks.

ns5.ecsecure.com. [208.56.100.1] [TTL=86400]
ns6.ecsecure.com. [216.147.1.227] [TTL=86400]

But this really has nothing to do with how SERVFAIL is handled by an SMTP
client.

Sadly, one of most irrational actions taken in the fight against spam has been
to go after people hosting secondary DNS servers when there's a problem with
some machines associated with the domain. For example, I used to provide
secondary DNS service for a university. They got careless and ended up with a
number of zombies on their network and I got blacklisted as result, even though
all I did was provide secondary DNS service.

I don't know how widespread a practice this is or to what extent this has had a
chilling effect on people being willing to provide secondary DNS service, but
it certainly made me more reluctant to provide such services.

> 3) Lame Delegation

> I saw other comments pointing it to be mostly a DNS configuration issue,
> Lame Delegation?

One lame delegation out of several is another case that can cause these sorts
of mixed results. If your server happens to follow the working delegation path
you win, if not you lose. And which one you get may be more or less random. And
once things are cached...

But this again is a cause, not a solution.

> 4) Ignore SERVFAIL?

> Some just said that the SMTP client should be looking at SERVFAIL as a
> NXDOMAIN, etc.

Bad idea IMO. Configuration glitches happen, and when they do you don't want to
bounce mail to the domain unnecessarily. Most of the time these problems get
fixed and the mail goes on through with only a small delay.

				Ned

From: "Hector Santos" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>
Subject: BCP for handling DNS SERVFAIL results
Date: Fri, 25 Nov 2005 14:18:11 -0500
Organization: Santronics Software, Inc.
Sender: [email-masked]

I'm not an DNS server expert so I am not sure if this mostly a configuration
issue, but my research reveals different information.

Currently our SMTP outgoing mail client is designed to check each DNS server
provided when doing a QUERY except for NXDOMAIN results.

This week, I ran across a particular new customer setup with an email domain
that he hadn't created a MX record yet.  He was using a sub domain,
db.usinterlink.com.

Of course, the SMTP client should:

    - Do a MX query
    - if none result, do a A record query

The problem is that I found while some other DNS servers return NOERROR, my
DNS server returned SERVFAIL to the MX query.

Here is what I found on the net as four different answers:

1) SendMail Configuration/New Behavior

http://www.brandonhutchinson.com/host_map__lookup_(domain)__deferred.html

 However, if the A or MX record lookup for the domain returns a
 "SERVFAIL," Sendmail will queue the message, believing it has
 encountered a transient DNS problem. For example, if a domain has a
 valid A record but returns a "SERVFAIL" when queried for an MX record
 (instead of "NOERROR" with an empty answer section), Sendmail will
 queue the message. You should contact the remote name server
 administrator in order to fix these problems."

2) Use Multiple DNS server.

An IBM solution was to suggest to make sure you have additional DNS servers
to query.

3) Lame Delegation

I saw other comments pointing it to be mostly a DNS configuration issue,
Lame Delegation?

4) Ignore SERVFAIL?

Some just said that the SMTP client should be looking at SERVFAIL as a
NXDOMAIN, etc.

I have a second DNS server so the result was found at my secondary UUNET
server.  But in general, I am trying to see why I got the SERVFAIL error in
the first place and in general for customers who might just have 1 DNS
server, how a SERVFAIL should be handled.  We are querying it. So it not a
matter of lost mail.

I am trying to understand why if I use my home DSL bellsouth.net DNS server,
 the NOERROR is returned, but against my own DNS server, it returns
SERVFAIL.  I'm not clear if its a configuration issue or not.

Any input would be appreciated.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Query Regarding CRAM-MD5 Authentication
Date:  Wed, 16 Nov 2005 11:55:37 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 35
Sender: [email-masked]

Vijayan wrote:

> my server supports 3 types of authentications
> LOGIN, CRAM-MD5 and PLAIN.

The latter shouldn't work without STARTTLS.

> for LOGIN and CRAM-MD5 server sends some encrypted data.

Encoded.  Base-64.  Nothing special, for a nice example see
<http://www.technoids.org/saslmech.html>

"LOGIN" is no SASL mechanism, and "PLAIN" must not be used
outside of TLS, that leaves "CRAM-MD5" for ESMTPA in your
scenario.

> what to do with this encrypted data..??

For "CRAM-MD5" read the proposed standard (RfC 2195), it has
an example for IMAP.  If you're looking for some code I can
offer a REXX MD5 test suite (it also includes OTP and some
DIGEST-MD5 tests, but not the new I18N stringprep stuff):
<http://purl.net/xyzzy/src/md5.cmd>

> any other mechanisms available that which SMTP Servers can
> support??

Sure, problem is that clients (MUAs) won't support it.  For
ESMTPA "CRAM-MD5" is the only game in town.  If that's not
good enough for your purposes you need ESMTPSA (S = secure),
or in other words TLS + PLAIN.
                              Bye, Frank

http://tools.ietf.org/html/2195

From: "Vijayan" <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, <[email-masked]>, "Paul Smith" <[email-masked]>, "Tony Finch" <[email-masked]>
Cc: <[email-masked]>
Subject: Query Regarding CRAM-MD5 Authentication
Date: Wed, 16 Nov 2005 15:31:38 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0045_01C5EAC2.D5E1D7B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Ppl..!

I have one doubt in SMTP Authentication (Still....!!)

my server supports 3 types of authentications

LOGIN,  CRAM-MD5 and PLAIN.

for LOGIN and CRAM-MD5 server sends some encrypted data.

doubts:
what to do with this encrypted data..??

how to encrypt the user mailID and Password with this data..??

i have to encode this encrypted data with Mail_ID and password or only =
with Password.??

if only password required then how the server will identify which user =
is trying to send mail.?

what is the algorith to get the encrypted data for LOGIN and CRAM-MD5 =
mechanisms ??

any other mechanisms available that which SMTP Servers can support??

can any one pls send me tha algorithm to encrypt the data.

Pls answer this questions asap.

thanks in advance..

Regards,
Vijayan
------=_NextPart_000_0045_01C5EAC2.D5E1D7B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1515" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>Hello =
Ppl..!</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#ff0000 size=3D2><STRONG>I have =
one doubt in=20
SMTP Authentication (Still....!!)</STRONG></FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>my server =
supports 3 types of=20
authentications</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2><STRONG>LOGIN, =
&nbsp;CRAM-MD5=20
and PLAIN.</STRONG></FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>for =
<STRONG>LOGIN and=20
CRAM-MD5 </STRONG>server sends some encrypted data.</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#ff0000=20
size=3D2><U><STRONG>doubts:</STRONG></U></FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>what to do with =
this=20
encrypted data..??</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>how to encrypt =
the user=20
<STRONG>mailID</STRONG> and <STRONG>Password</STRONG> with this=20
data..??</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>i have to =
encode this=20
encrypted data with <STRONG>Mail</STRONG>_ID and =
<STRONG>password</STRONG> or=20
<STRONG><U>only with Password</U></STRONG>.??</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>if only =
password required=20
then how the server will identify which user is trying to send=20
mail.?</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>what is the =
algorith to get=20
the encrypted data for <STRONG>LOGIN and CRAM-MD5</STRONG> mechanisms=20
??</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>any other =
mechanisms=20
available that which SMTP Servers can support??</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>can any one pls =
send me tha=20
algorithm to encrypt the data.</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>Pls answer this =
questions=20
asap.</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>thanks in=20
advance..</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2><STRONG>Vijayan</STRONG></FONT></DIV></BODY></HTML>

------=_NextPart_000_0045_01C5EAC2.D5E1D7B0--

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
Subject: Re: Terminology: Administrative <Email-Admin>
Date: Mon, 14 Nov 2005 12:49:02 -0800
To: Tony Finch <[email-masked]>
Sender: [email-masked]

On Nov 14, 2005, at 12:26 PM, Tony Finch wrote:

> On Mon, 14 Nov 2005, Douglas Otis wrote:
>>
>> You wish to avoid the term domain.  There are terms used like System
>> Administrator (Sys-Admin), or Network Administrator (Net-Admin),  
>> or Database
>> Administrator (DBA).  Email Administrator (Email-Admin),
>
> Otherwise known as "postmaster".

Perhaps, but "postmaster" could also be limited to the disposition of  
complaints for a domain.  For example, the email-admin is contacted  
by the various postmasters for the different domains when an email  
system change is needed.

The term AU would be confusing when it is not understood to mean  
Administrative-Unit.  The same could be said of COG or EA.  The  
concept of an Administrative-Unit is also a departure from similar  
references that consider administration to represent a function  
rather than an area.  Terminology that extends email-admin to _area_  
could reference that "under" an email-admin.

Administrative-Unit could be replaced by that "under" a common "email- 
admin".  An Administrative-Unit border would be "under" a different  
"email-admin".  The terminology that could replace Administrative- 
Unit would be "under" common/different "email-admin."  This is not as  
concise, but could be understood without a dictionary of terms.

-Doug

Date: Mon, 14 Nov 2005 20:26:34 +0000
From: Tony Finch <[email-masked]>
To: Douglas Otis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Terminology: Administrative <Email-Admin>
Sender: [email-masked]

On Mon, 14 Nov 2005, Douglas Otis wrote:
>
> You wish to avoid the term domain.  There are terms used like System
> Administrator (Sys-Admin), or Network Administrator (Net-Admin), or Database
> Administrator (DBA).  Email Administrator (Email-Admin),

Otherwise known as "postmaster".

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Date: Mon, 14 Nov 2005 11:50:19 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Alex van den Bogaerdt <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Terminology: Administrative <?>
Sender: [email-masked]

> 
> So:  (A)dministrative, (B)order/(or: Boundary), (C)loud:  ABC

boundary cloud or border cloud?  i don't understand the semantics of such a 
term.

(also, "cloud" strikes me a problematic for serious terminology.  it's great 
for conversation but as part of a formal term?)

> this Email-Admin term can still be understood.  COG would seem to be as

I did not see a term being proposed.  Also, although the AE/AU terminology 
has not caught on, I was not aware that it confused folks.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
Subject: Re: Terminology: Administrative <Email-Admin>
Date: Mon, 14 Nov 2005 11:32:41 -0800
To: [email-masked]
Sender: [email-masked]

On Nov 14, 2005, at 10:49 AM, Dave Crocker wrote:

>
> Folks,
>
>> The current draft refers to a collectively-managed set of email  
>> components
>> as distinct from some other, independent collectively-managed set of
>> components -- as an Administrative Unit (AU).  Examples might be a  
>> personal
>> MTA, as one AU, an email hosting service as another, an integrated  
>> service
>> (AOL, Yahoo, MSN, etc) as another, and so on.
> ...
>> We need *some* term, so that such references as "boundary MTA" can be
>> meaningful -- what is it the boundary of?
>
>
> I am still searching for a term that folks will be willing to use.   
> The various ones I've suggested have not resonated with folks.
>
> Last week, I was told to see whether an acronym might do better.   
> Here is my first candidate, with an eager request for anything  
> better that folks like:
>
>      Common Operating Group (COG)
>
>      A COG is a collection of Internet Mail components
>      subject to a single set of administrative operations
>      policies.
>
> Comments?

You wish to avoid the term domain.  There are terms used like System  
Administrator (Sys-Admin), or Network Administrator (Net-Admin), or  
Database Administrator (DBA).  Email Administrator (Email-Admin),  
rather than Administrative-Unit (AU) would follow this vein.  An  
administrative boundary would occur where systems are under a  
different Email-Admin.  Systems would be under the same Email-Admin  
rather than within the same AU.  Without a dictionary of terms, this  
Email-Admin term can still be understood.  COG would seem to be as  
confusing as AU.

-Doug

Date: Mon, 14 Nov 2005 20:23:39 +0100
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Terminology: Administrative <?>
Sender: [email-masked]

On Mon, Nov 14, 2005 at 10:49:06AM -0800, Dave Crocker wrote:

> >The current draft refers to a collectively-managed set of email components
> >as distinct from some other, independent collectively-managed set of
> >components -- as an Administrative Unit (AU).  Examples might be a personal
> >MTA, as one AU, an email hosting service as another, an integrated service
> >(AOL, Yahoo, MSN, etc) as another, and so on.
> ...
> >
> >We need *some* term, so that such references as "boundary MTA" can be
> >meaningful -- what is it the boundary of?

> Last week, I was told to see whether an acronym might do better.  Here is 
> my first candidate, with an eager request for anything better that folks 
> like:

People like to visualize.  Often I see clouds to define borders.  You can't
look through clouds.  That's OK, as you hand the message over to the next
administrative unit you're not responsible anymore.  You do not know nor
care what is in the cloud, or behind it.  Easy analogy I'd say.

So:  (A)dministrative, (B)order/(or: Boundary), (C)loud:  ABC

Obviously the host serving as boundary MTA _is_ visible.  It is on
the edge of the cloud.

Inside the cloud you can see your own servers.

If someone sets up (an) MX record(s), they hide behind those servers.
Those become, by definition, points where Mail is eXchanged between
clouds.

Not all servers on the border need to be MXes.  There can be servers
on the edge looking outside, but not receive mail.  Those _can_ send.

If mail is forwarded, it comes out of that cloud and goes into the
next.  The next receiver cannot look through the cloud either, it
knows nothing about this message except that it comes from this cloud.

Alex

Date: Mon, 14 Nov 2005 10:49:06 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Terminology: Administrative <?>
Sender: [email-masked]

Folks,

> The current draft refers to a collectively-managed set of email components
> as distinct from some other, independent collectively-managed set of
> components -- as an Administrative Unit (AU).  Examples might be a personal
> MTA, as one AU, an email hosting service as another, an integrated service
> (AOL, Yahoo, MSN, etc) as another, and so on.
...
> 
> We need *some* term, so that such references as "boundary MTA" can be
> meaningful -- what is it the boundary of?

I am still searching for a term that folks will be willing to use.  The 
various ones I've suggested have not resonated with folks.

Last week, I was told to see whether an acronym might do better.  Here is my 
first candidate, with an eager request for anything better that folks like:

      Common Operating Group (COG)

      A COG is a collection of Internet Mail components
      subject to a single set of administrative operations
      policies.

Comments?

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

Date: Tue, 08 Nov 2005 13:24:54 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
CC: Markus Hofmann <[email-masked]>
Subject: Reminder: OPES meeting Tues night
Sender: [email-masked]

Of interest to SMTPers is the OPES WG meeting 6:50-7:50 pm in the OAK
room. In particular, two drafts of interest are:

 OPES SMTP Use Cases - draft-ietf-opes-smtp-use-cases-03

 SMTP adaptation with OPES - draft-ietf-opes-smtp-00

	Tony Hansen
	[email-masked]
	OPES co-chair