Hi Jan,
okay I think you are right, that 192.0.2.15. shouldn't be considered a
valid domain.
But your EBNF has been releaxed by RFC 1123, section 2.1:
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
Jan Ingvoldstad writes:
RFC 1035:
::= | " "
::= | "."
::= [ [ ] ]
::= |
::= | "-"
::= |
Indeed.
So any DNS reply that contains one of these fails to validate RFC 1035's
grammar, and is ill-formed.
When a reply is ill-formed, no assurances can be made that some pa
On Thu, Jun 28, 2012 at 6:24 PM, Matthias Wimmer wrote:
>
>
> Well technically I'd say that the (invalid) MX *is* pointing to a domain
> name, but that domain name does not exist.
>
> There is no way an IP address can be in an MX record. There can just be
> some (non-existent) domain, that *looks*
Hi Matus,
Matus UHLAR - fantomas schrieb am 2012-06-27 09:44:18:
> Pointing the MX to an IP address _IS_ his fault. MX points to a domain
> name and IP address is _not_ a domain name. RFC 1035, section 3.3.9.
Well technically I'd say that the (invalid) MX *is* pointing to a domain
name, but th
On Tue, Jun 26, 2012 at 11:16 PM, Lucio Crusca wrote:
> Alessandro Vesely wrote:
> > For example, Lucio's server could have matched the bad MX 20
> > of domain.com, unable to recognize its own IP address because it sits
> > behind a NAT, and unable to recognize its own name since the DNS hid
> >
On Tue 26/Jun/2012 23:16:04 +0200 Lucio Crusca wrote:
> Alessandro Vesely wrote:
>> For example, Lucio's server could have matched the bad MX 20
>> of domain.com, unable to recognize its own IP address because it sits
>> behind a NAT, and unable to recognize its own name since the DNS hid
>> it. I
>Alessandro Vesely wrote:
>> For example, Lucio's server could have matched the bad MX 20
>> of domain.com, unable to recognize its own IP address because it sits
>> behind a NAT, and unable to recognize its own name since the DNS hid
>> it. If it had used the good MX record by default, it would h
Alessandro Vesely wrote:
> For example, Lucio's server could have matched the bad MX 20
> of domain.com, unable to recognize its own IP address because it sits
> behind a NAT, and unable to recognize its own name since the DNS hid
> it. If it had used the good MX record by default, it would have
>
On Tue, Jun 26, 2012 at 3:58 PM, Alessandro Vesely wrote:
> On Tue 26/Jun/2012 13:14:34 +0200 Jan Ingvoldstad wrote:
> > On Tue, Jun 26, 2012 at 12:52 PM, Sam Varshavchik
> > mailto:mr...@courier-mta.com>> wrote:
> >
> > There are no prescribed means for handling bad DNS data. If DNS is
> >
On Tue 26/Jun/2012 13:14:34 +0200 Jan Ingvoldstad wrote:
> On Tue, Jun 26, 2012 at 12:52 PM, Sam Varshavchik
> mailto:mr...@courier-mta.com>> wrote:
>
> There are no prescribed means for handling bad DNS data. If DNS is
> wrong, one cannot have any expectation that it will work in any
>
On Tue, Jun 26, 2012 at 12:52 PM, Sam Varshavchik wrote:
>
> There are no prescribed means for handling bad DNS data. If DNS is wrong,
> one cannot have any expectation that it will work in any particular way,
> even if some parts of it are correct.
>
That's not quite correct, there are prescribe
Lucio Crusca writes:
Hello *,
courier-0.65 here (Debian). For a particular domain, courier refuses to
deliver messages because it violates RFC 1035. Correct, it actually does and
I
added it to esmtproutes for the time being. However the same domain has two
MX
records configured. One violat
Vasiliy Kotikov wrote:
> Hello!
>
> This morning I have got this reply from courier mail server 0.54.2
>
> ---
>
>UNDELIVERABLE MAIL
> Your message to the following recipients cannot be delive
On Friday 04 August 2006 15:21, Sam Varshavchik wrote:
> No. Either turn off incoming DNS checking completely, or reject all
> domains that do not have a valid incoming mail server defined in DNS.
Sam,
Thanks for your answer. It looks like I quoted you from 2004 in my previous
email. :P
Tom
-
Tom Brown writes:
Hi,
We had trouble sending to a particular domain because their MX records were
incorrect. So, I added a line to esmtproutes to get around the problem. Now,
we can send to this domain. However, we cannot receive email from the domain
because of the MX records. I am seeing t
On Friday 04 August 2006 15:04, Tom Brown wrote:
> We had trouble sending to a particular domain because their MX records were
> incorrect. So, I added a line to esmtproutes to get around the problem.
> Now, we can send to this domain. However, we cannot receive email from the
> domain because of t
--- Matt Savigear <[EMAIL PROTECTED]> wrote:
> Is there a workaround? The esmtproutes fix doesnt
> seem to help in this instance.
Fixed (well, worked around): Temporarily disabled
BOFHCHECKDNS in the esmtpd configuration file.
Matt.
Send instant messages to your online friends http://uk.messenge
> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Tuesday, May 04, 2004 12:47 AM
> Julian Mehnle <[EMAIL PROTECTED]> wrote:
> > That's exactly what I meant. *Mounting* the license plate
> > on the roof
> > is bad, but *looking* for the license plate on the roof isn't -- if
> > it'
Julian Mehnle <[EMAIL PROTECTED]> wrote:
> That's exactly what I meant. *Mounting* the license plate on the roof is
> bad, but *looking* for the license plate on the roof isn't -- if it's not
> significantly more effort.
If it looks like a license plate it must be a license plate, huh? What
happ
Precisely, or vice versa, but what people should be worrying about isn't
RFC compliance, but interoperability and better design.
Exactly...this is what the proposed RFC's and the IETF is attempting to
do. But these is no ESP, so there has to be a consortium to make
standards to ease interoperabi
Gerardo Gregory wrote:
> Dan,
>
> Read -> RFC 1796 first;
>
> Just cause it is mentioned as/or referenced to an RFC does not make it a
> standard.
Precisely, or vice versa, but what people should be worrying about isn't
RFC compliance, but interoperability and better design. Whether it means
RF
Kirk worte;
Is this the case if the MX entry is a 'real' entry, but doesn't resolve
to an IP address?
---
If you are saying that the MX record has a domain name that has no valid
A record associated then it is not a legitimate entry - it violates the RFC.
If you are saying that th
Dan,
Read -> RFC 1796 first;
Just cause it is mentioned as/or referenced to an RFC does not make it a
standard.
If it is a standard and you still have a better way to accomplish what
the standard is implying then RFC 2926
is for you.
The standards is what I am very critical about [I find it h
Anand wrote:
> On Tue, Jan 20, 2004 at 11:20:51PM -0600, Kirk A Wolff wrote:
>
> > First off: Courier-mta is the BEST!
> >
> > Question: Does courier iterate through all available MX records even if
> > the first few are broken and possibly violate RFC1035?
>
> No. All the MX records have to be
> First off: Courier-mta is the BEST!
> Question: Does courier iterate through all available MX records even
if
> the first few are broken and possibly violate RFC1035?
I agree with Gerardo Gregory and i also have had some issues regarding
this topic nevertheless i neede
Il 06:20, mercoledì 21 gennaio 2004, Kirk A Wolff ha scritto:
> First off: Courier-mta is the BEST!
> Question: Does courier iterate through all available MX records even if
> the first few are broken and possibly violate RFC1035?
I agree with Gerardo Gregory and i also have had some issues reg
Gerardo Gregory wrote:
> If he broke the mx entries on purpose then ask him where in the RFC it
> states that type of methadology, or what "best business" practice is he
> following here.
Too bad some RFCs don't always make sense. DSN is a good example. What
a waste of bandwidth and disk space.
Thank you Gerardo for your reply. I have some additional information
regarding WHY the MX RRs are broken. The mailserver admin does not intend
to keep these broken. I also have a comment about how RFC1035 is
implemented in Courier.
Regarding RFC1035 in Courier; I looked through the most recen
kirk wrote;
>It was explained to me that the other guy's ISP (otherguysisp.com) has
>the
>broken domain's entries purposely broken for the first few MX records
>(brokendomain.com). He says that his ISP wants to keep the first few >MX
>records broken, and that the problem is with MY mailserver.
On Tue, Jan 20, 2004 at 11:20:51PM -0600, Kirk A Wolff wrote:
> First off: Courier-mta is the BEST!
>
> Question: Does courier iterate through all available MX records even if
> the first few are broken and possibly violate RFC1035?
No. All the MX records have to be correct; even if one is wro
ay, November 25, 2003 6:26 PM
> To: Steve Hultquist
> Cc: [EMAIL PROTECTED]
> Subject: Re: [courier-users] RFC 1035 unpleasantness
>
> What kinda cracked out RFC specifies the format of a configuration file!!
> No wonder maintaining DNS is such a pain, the lame file format is actuall
What kinda cracked out RFC specifies the format of a configuration file!!
No wonder maintaining DNS is such a pain, the lame file format is actually
specified in the RFC!
Anyways MX records point to A records & are not IP addresses & as a 'special
case' in RFC 974 MX records can also be CNAMEs...
Bizarro - I thought it was the other way around.
Anyhoo after poking around my DNS records the MX record had a typo -
really need to stop trying to maintain them by hand.
Give it 3 days to percolate around the Internet & then I'll know...
thanks!
Mark
On Tue, Nov 25, 2003 at 05:47:43PM -0700,
On Sat, Jun 01, 2002 at 10:32:29AM -0500, Lindsay Haisley wrote:
> Thus spake Sam Varshavchik on Sat, Jun 01, 2002 at 09:20:42AM CDT
> > > $ dig -t mx pdrap.org
> > >
> > > ;; ANSWER SECTION:
> > > pdrap.org. 48666 IN MX 0 pdrap.org.
> > >
> > > What's the issue?
> >
>
Thus spake Sam Varshavchik on Sat, Jun 01, 2002 at 09:20:42AM CDT
> > $ dig -t mx pdrap.org
> >
> > ;; ANSWER SECTION:
> > pdrap.org. 48666 IN MX 0 pdrap.org.
> >
> > What's the issue?
>
> Their DNS was broken, but it looks like they updated their zone this morning
> in
On Sat, Jun 01, 2002 at 01:34:48AM -0500, Lindsay Haisley wrote:
> What's the meaning of this?
>
> > SMTP error from remote mailer after MAIL FROM:<[EMAIL PROTECTED]> SIZE=4421:
> > host bailey.fmp.com [192.207.27.55]: 517-MX records for pdrap.org
> > violate
> > +section 3.3.9 of RFC 1035.
36 matches
Mail list logo
