It might be the case that it's useful for an MTA to have an option to
skip MX lookup for specific destinations because of DNS brokenness at
those destinations. But this seems to me to be outside of the scope of
the standard. Skipping MX lookup is not acceptable as a general
practice, nor is
From: Ned Freed [EMAIL PROTECTED]
You seem to be of the opinion that fallback behavior should be extended to
, and you seem to be the first one to express that opinion. (I myself have
no opinion on how to resolve this other than believing it has to be resolved -
the present ambigiuty is
It might be the case that it's useful for an MTA to have an option to
skip MX lookup for specific destinations because of DNS brokenness at
those destinations. But this seems to me to be outside of the scope of
the standard.
By the same token, discussions of gatewaying to non-Internet
Markku Savela wrote:
The goal should be to make IPv4 and IPv6 easily replaceable anywhere,
whithout any reduced functionality.
I don't see how requiring MX lookups for IPv6 mail relaying reduces
functionality. As far as I can tell, it increases functionality because
it provides (as a
At 19:32 25-03-2008, Bill Manning wrote:
er... what about zones w/ A rr's and no MX's?
when I pull the A rr's, you are telling me that SMTP
stops working? That is so broken.
SMTP will still work as the above case is covered by the implicit MX rule.
At 20:02
On Wed, Mar 26, 2008 at 12:10:38AM -0700, SM wrote:
At 19:32 25-03-2008, Bill Manning wrote:
er... what about zones w/ A rr's and no MX's?
when I pull the A rr's, you are telling me that SMTP
stops working? That is so broken.
SMTP will still work as the
SM wrote:
We could look at the question by asking whether the fallback MX
behavior should be an operational decision. But then we would be
treating IPv4 and IPv6 differently.
IPv4 and IPv6 really are different, in a number of ways that affect both
applications and operations. e.g.
At 19:32 25-03-2008, Bill Manning wrote:
er... what about zones w/ A rr's and no MX's?
when I pull the A rr's, you are telling me that SMTP
stops working? That is so broken.
SMTP will still work as the above case is covered by the implicit MX rule.
At
At 00:27 26-03-2008, Bill Manning wrote:
what this daft is trying to do is force the presumptive
existance of an MX in a zone into an explict rule that
forces the existance of an MX, else SMTP fails.
That's not what Section 5.1 (Locating the Target Host) of the draft
--On Wednesday, 26 March, 2008 00:27 -0700 Bill Manning
[EMAIL PROTECTED] wrote:
what this daft is trying to do is force the presumptive
existance of an MX in a zone into an explict rule that
forces the existance of an MX, else SMTP fails.
While several people have
At 00:57 26-03-2008, Mark Andrews wrote:
Which is not documented in any RFC despite being a good idea.
It is easy to turn MX 0 . into This domain doesn't support
email as . is not confusable with a hostname. There is no
reason to look up addresses records for
On Wed, 26 Mar 2008, Markku Savela wrote:
You seem to be of the opinion that fallback behavior should be extended to
, and you seem to be the first one to express that opinion. (I myself
have
no opinion on how to resolve this other than believing it has to be resolved
-
the present
Hi Simon,
the case I was thinking about was this one:
http://www.consortiuminfo.org/standardsblog/article.php?story=20070323094639
964
Stephan
On 3/25/08 3:33 PM, Simon Josefsson [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
[...]
If we learned that the anonymous posting actually
At 00:57 26-03-2008, Mark Andrews wrote:
Which is not documented in any RFC despite being a good idea.
It is easy to turn MX 0 . into This domain doesn't support
email as . is not confusable with a hostname. There is no
reason to look up addresses
Bill Manning wrote:
example.com. soa (
stuff
)
ns foo.
ns bar.
;
mailhost fe80::21a:92ff:fe99:2ab1
is what i am using today.
In that case adding an MX record pointing to mailhost
or not is perfectly irrelevant from an IPv4-only POV:
IPv4-only users cannot reach your
Frank Ellermann [EMAIL PROTECTED] writes:
Noel Chiappa wrote:
if our IP rules, which I haven't looked at recently, already
said that, my apologies, and don't kick me too hard! :-)
*KICK* ;-) Posted yesterday:
Hm, how does those rules meet any of the requirements Noel had?
/Simon
| The
[EMAIL PROTECTED] (Noel Chiappa) writes:
From: Hallam-Baker, Phillip [EMAIL PROTECTED]
If someone participates under a pseudonym with the objective of
inserting patented technology and anyone finds out they are in big
trouble. Much worse than any prior case.
We should
On 25 mrt 2008, at 16:10, Dan Wing wrote:
...
And yes, the issues I referred to are DoS and TCP spoofing.
These can only be protected against at the network level.
What are your thoughts on DTLS's DoS and spoofing protection?
Looks like this is mostly similar to IPsec except that the port
Frank Ellermann wrote:
Bill Manning wrote:
example.com. soa (
stuff
)
ns foo.
ns bar.
;
mailhost fe80::21a:92ff:fe99:2ab1
is what i am using today.
In that case adding an MX record pointing to mailhost
or not is perfectly irrelevant from an IPv4-only POV:
On Wed, Mar 26, 2008 at 01:15:23PM +0100, Frank Ellermann wrote:
Bill Manning wrote:
example.com. soa (
stuff
)
ns foo.
ns bar.
;
mailhost fe80::21a:92ff:fe99:2ab1
is what i am using today.
In that case adding an MX record pointing to mailhost
or not is
Thanks for clarifying, given the lack of details I jumped to
conclusions. Still, I don't see how anonymous contributions were
involved?
/Simon
Stephan Wenger [EMAIL PROTECTED] writes:
Hi Simon,
the case I was thinking about was this one:
On 25 mrt 2008, at 22:39, David Harrington wrote:
I think asking attendees during registration which sessions they
intend to attend and building a conflict matrix would be the simplest
approach. Of course, attendee conflicts matter less than ADs, chairs,
and presenter conflicts.
Actually we
Thanks a lot Michelle.
I have a question related. How long it take to register a port for an
application? Is there any monetary policy?
Thank you
Kapil
From: Michelle Cotton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 12:55 AM
To:
Hi Michelle,
I have few questions more:
1) Is port registration is platform dependent? We have our
services running on Windows, Linux and Mac OS (obviously different
binaries to server different OS's). Does registering one port for all
the service (For example: port 7001 for
Hi Michelle,
I have few questions more:
1) Is port registration is platform dependent? We have our
services running on Windows, Linux and Mac OS (obviously different
binaries to server different OS's). Does registering one port for all
the service (For example: port 7001 for
On Mar 25, 2008, at 4:57 PM, Michael Thomas wrote:
How do I know that you're not a dog?
or a puppet... A small fellow with a red nose, a yellow complexion,
and a miserable hairdo was at some point even appointed to the IAB !?!
--On Wednesday, 26 March, 2008 22:41 +1100 Mark Andrews
[EMAIL PROTECTED] wrote:
...
It would be needed until IPv6 takes over.
It will be needed even *after* IPv6 takes over. There will
be lots of queries for A records long after the majority
of hosts don't have A
On Wed, Mar 26, 2008 at 11:24:42AM +0100,
Bert [EMAIL PROTECTED] wrote
a message of 55 lines which said:
or a puppet... A small fellow with a red nose, a yellow complexion,
and a miserable hairdo was at some point even appointed to the IAB !?!
It's easy to prove this fellow does not
At Wed, 26 Mar 2008 13:25:20 +0100,
Iljitsch van Beijnum wrote:
On 25 mrt 2008, at 16:10, Dan Wing wrote:
...
And yes, the issues I referred to are DoS and TCP spoofing.
These can only be protected against at the network level.
What are your thoughts on DTLS's DoS and spoofing
Keith Moore wrote:
IPv4-only hosts can see the record even if they can't
directly send mail to that address. and there's no reason
(obvious or otherwise) why a MTA should reject mail from
a host just because that MTA can't directly route to it
What I wrote was at their border, that
On 26 mrt 2008, at 14:36, Eric Rescorla wrote:
- Modern cryptographic implementations are extremely fast. For
comparison the MacBook Air I'm typing this on will do order 10^6
HMAC-MD5s/second on 64-byte packets. So, to consume all my
resources would require order 10^8 bits per second,
On Mar 25, 2008, at 5:21 PM, Steve Silverman wrote:
The Blue Sheets only tell you where someone was rather than where they
wanted to be.
I'd also note that people may wind up on multiple Blue Sheets. I
know that I have started in one WG and signed the Blue Sheet there
and then wound up
--On Tuesday, March 25, 2008 21:30:54 -0600 Peter Saint-Andre
[EMAIL PROTECTED] wrote:
Russ Housley wrote:
During the Wednesday Plenary at IETF 71, I gave the IETF community a
heads up on two documents from the IPR WG that were nearing IETF
Last Call. Both of the documents have now
--On Wednesday, March 26, 2008 00:24:57 +0100 LB [EMAIL PROTECTED] wrote:
So it seems to me that the current debate, which I do not have much
time to spend and who is in a language that I do not master, has two
other goals.
- Discredit these Drafts in case they would allow the internet to
At Wed, 26 Mar 2008 15:01:21 +0100,
Iljitsch van Beijnum wrote:
On 26 mrt 2008, at 14:36, Eric Rescorla wrote:
- Modern cryptographic implementations are extremely fast. For
comparison the MacBook Air I'm typing this on will do order 10^6
HMAC-MD5s/second on 64-byte packets. So, to
Bill Manning wrote:
sounds like a great way to reduce the incoming spam to me.
Dunno, I normally want to know if a mail from me (really,
SPF PASS and all) did not make it, and for that purpose I
want the good bounces. If legit undeliverable mail ends
up in black holes a.k.a. spam filters it
At Wed, 26 Mar 2008 07:32:41 -0700,
Eric Rescorla wrote:
At Wed, 26 Mar 2008 15:01:21 +0100,
Iljitsch van Beijnum wrote:
On 26 mrt 2008, at 14:36, Eric Rescorla wrote:
- Modern cryptographic implementations are extremely fast. For
comparison the MacBook Air I'm typing this on
As the shepherd/pseudo-chair for 2821bis effort, our plan of action is
going to be as follows:
*) the implicit MX issue needs to be resolved.
*) there are a few other small items that need to be resolved that
will be detailed on the [EMAIL PROTECTED] list
We'll give the
Simon Josefsson wrote:
*KICK* ;-) Posted yesterday:
Hm, how does those rules meet any of the requirements Noel had?
Hardly, but now is a good time to discuss the proposed rules,
where they don't do what folks consider as required. I think
there are enough interesting details in the incoming
IPv4-only hosts can see the record even if they can't
directly send mail to that address. and there's no reason
(obvious or otherwise) why a MTA should reject mail from
a host just because that MTA can't directly route to it
Well, other than the practical fact that it's almost
On Wed, 19 Mar 2008, Jari Arkko wrote:
Just FYI, this draft is being AD sponsored as a report of a research effort
that certain people have done in the source address validation space. To
quote my ballot explanation:
This draft documents an experimental design implemented in
a research
--On Wednesday, 26 March, 2008 10:52 +0200 Pekka Savola
[EMAIL PROTECTED] wrote:
As a private person using the A record only way of
receiving mail, I find it useful.
It might be helpful in this context if you could elaborate a
bit why you find it useful?
The only reason I can think of
--On Wednesday, 26 March, 2008 14:25 +0100 Stephane Bortzmeyer
[EMAIL PROTECTED] wrote:
On Wed, Mar 26, 2008 at 11:24:42AM +0100,
Bert [EMAIL PROTECTED] wrote
a message of 55 lines which said:
or a puppet... A small fellow with a red nose, a yellow
complexion, and a miserable hairdo
On Wed, 26 Mar 2008, John C Klensin wrote:
At the time 974 and 1123 were written, the only sort of address record
in Class=IN was an A RR, and those documents used A RR terminology.
The change in 2821bis essentially substituted the phrase address
record (or address RR) for A record because
Frank Ellermann wrote:
Keith Moore wrote:
IPv4-only hosts can see the record even if they can't
directly send mail to that address. and there's no reason
(obvious or otherwise) why a MTA should reject mail from
a host just because that MTA can't directly route to it
What I
John Levine wrote:
Not to be cynical or anything, but regardless of what we decree, I
think it's vanishingly unlikely that many systems on the public
Internet* will accept mail from a domain with only an record.
I think it's vanishing unlikely that email will be useful at all, if
spam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Michael Thomas
Mike, could be a dog too
I'm not sure what you people have against canines - if a dog can email in
cohesive comments on a draft or working group topic, I say we should
1. The MIB compiles cleanly.
2. idnits detected three documents in the references that were already
published as RFCs:
== Outdated reference: draft-ietf-pim-mib-v2 has been published as RFC
5060
== Outdated reference: draft-ietf-pim-sm-bsr has been published as RFC
5059
== Outdated
Not to be cynical or anything, but regardless of what we decree, I
think it's vanishingly unlikely that many systems on the public
Internet* will accept mail from a domain with only an record.
I think it's vanishing unlikely that email will be useful at all, if spam
filter writers
John Levine wrote:
When upwards of 90% of all mail is
spam, keeping mail usable is at least as dependent on limiting the spam
that shows up in people's mailboxes as delivering the trickle of good
mail.
And to add to what John is saying, given that horrific statistic and
that mail is
On Wed, Mar 26, 2008 at 10:11 AM, IAB Chair [EMAIL PROTECTED] wrote:
What Makes For a Successful Protocol?
draft-iab-protocol-success-03
as an informational RFC.Before doing so the IAB wants to solicit from
the community any last comments on this document.
...
The document can
John Levine wrote:
Not to be cynical or anything, but regardless of what we decree, I
think it's vanishingly unlikely that many systems on the public
Internet* will accept mail from a domain with only an record.
I think it's vanishing unlikely that email will be useful at all, if
John Levine wrote:
Not to reignite the usual spam argument, but it is (unfortunately in
this case) not 1988 or even 1998 any more. When upwards of 90% of all
mail is spam, keeping mail usable is at least as dependent on limiting
the spam that shows up in people's mailboxes as delivering
This document is not the place to fight spam. If you want a BCP to deprecate
the fall-back, then write one. Until all the implementations remove
fall-back to A, the correct behavior is to also fall-back to . People
(particularly the apps dev support communities) are having a hard enough
Hi -
From: Harald Tveit Alvestrand [EMAIL PROTECTED]
To: LB [EMAIL PROTECTED]; ietf@ietf.org
Cc: [EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 6:29 AM
Subject: Re: Possible RFC 3683 PR-action.
...
c'mon neihter JFC nor LB has ever offered a draft,
JFTR
Harald Tveit Alvestrand wrote:
--On Tuesday, March 25, 2008 21:30:54 -0600 Peter Saint-Andre
[EMAIL PROTECTED] wrote:
Russ Housley wrote:
During the Wednesday Plenary at IETF 71, I gave the IETF community a
heads up on two documents from the IPR WG that were nearing IETF
Last Call.
Keith Moore wrote:
you're assuming lots of conditions there that don't apply
in the general case...
The cases involving MX queries are not unusual, a good part
of 2821bis explains how this works. MTAs know if they are
an inbound border MTA or not depending on the client.
e.g. single-hop
Tony Hain wrote:
This document is not the place to fight spam.
right.
Until all the implementations remove
fall-back to A, the correct behavior is to also fall-back to . People
(particularly the apps dev support communities) are having a hard enough
time getting their heads around
Frank Ellermann wrote:
Keith Moore wrote:
you're assuming lots of conditions there that don't apply
in the general case...
The cases involving MX queries are not unusual, a good part
of 2821bis explains how this works. MTAs know if they are
an inbound border MTA or not depending on
Dave Crocker wrote:
I keep trying to understand why the SMTP use of records should be any
different than its use of A records. Haven't heard a solid explanation,
nevermind seen consensus forming around it.
because conditions are different now than it was when RFC 974 was
written,
On 2008-03-27 09:14, Peter Saint-Andre wrote:
Harald Tveit Alvestrand wrote:
--On Tuesday, March 25, 2008 21:30:54 -0600 Peter Saint-Andre
[EMAIL PROTECTED] wrote:
snip
Finally, the outbound draft merely provides recommendations regarding
license text and other materials, final definition
I don't undestand the reasoning here.
My understanding is that we implicitly deprecated receivers relying on fallback
to A in 2821. Section 5 makes it clear that you look for MX first and that MX
takes priority.
It is thus not compliant to look at records today and I see no reason to
Keith Moore wrote:
snipped
because conditions are different now than it was when RFC 974 was
written, and the case that compelled fallback to A in RFC 974 does not
significantly exist for .
I agree with Keith here.
The published RFC 2821 states in section 5:
... The lookup first
It is pretty clear here that we are talking about a configuration that is
actually specfically prohibited by 2821.
If you are doing SMTP and claiming to be 2821 compliant you must lookup the MX
and you must not look at the A if there is no MX there. Any sender that is
breaking those rules is
Keith Moore wrote:
nobody is expected to pay any attention to SPF as a matter
of compliance with 2821. SPF is pretty much a joke.
Then let's move RFC 3834 and a bunch of draft standards to
historic because they rely on an envelope sender address
indicating the originator.
SPF PASS
Dave Crocker wrote:
I keep trying to understand why the SMTP use of records should be any
different than its use of A records. Haven't heard a solid explanation,
nevermind seen consensus forming around it.
It seems there are two ways of looking at this:
(1) records in the
Hi,
On Mar 26, 2008, at 3:35 PM, Jim Fenton wrote:
It seems there are two ways of looking at this:
(1) records in the IPv6 world should do exactly same things as A
records in the IPv4 world,
...
I don't really have a strong opinion on the whether or not s
should be used for email
Your arguments make no sense. Any service that has an MX creates absolutely
no cost, and the fallback to only makes one last attempt to deliver the
mail before giving up. Trying to force the recipient MTA to publish an MX to
avoid delivery failure on the sending MTA is useless, and in no way
Tony Hain wrote:
You should also stop trying to rewrite history by claiming
that something was 'not understood at the time'.
That got me to speed read a few RFCs, 805, 819, 882, 883, 973,
and in 974 I finally found what I wanted:
| It is possible that the list of MXs in the response to the
|
Brian == Brian E Carpenter [EMAIL PROTECTED] writes:
Brian Also note that appeal and recall procedures for the IAOC
Brian are defined in RFC 4071, and that clearly includes Trust
Brian actions, since the Trustees are by definition the IAOC
Brian members. So if the IETF doesn't
The IAB is ready to ask the RFC-Editor to publish:
What Makes For a Successful Protocol?
draft-iab-protocol-success-03
as an informational RFC.Before doing so the IAB wants to solicit from
the community any last comments on this document.
This document contains a number of case
71 matches
Mail list logo
