This thread is trying to redefine or redesign SMTP's use of TLS. It
should probably be happening on the [EMAIL PROTECTED] list
instead of the main IETF mailing list. That's where the implementers
are, and that's where the implementers of most of the foo-over-TLS
protocols are. They too should b
> > Not quite inherent -- if you verify against a SubjectAltName dNSName
> > you can decide the certificate is valid for many domains.
> >
> Yes, this is true in theory, but I want to know how you're going
> to get VeriSign to issue you a certificate with subjectAltNames
> corresponding to a bunch
[EMAIL PROTECTED] wrote:
On Wed, 12 Mar 2003 15:37:23 MST, Doug Royer <[EMAIL PROTECTED]> said:
If you are talking about TLS certs (not S/MIME certs) then the ISP can
issue them to the customer directly (be a CA for connections from their
customers over TLS connections). I have read that the c
m: Eric Rescorla [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 13 March 2003 10:18
> To: Matt Crawford
> Cc: Keith Moore; [EMAIL PROTECTED]
> Subject: Re: IAB policy on anti-spam mechanisms?
>
>
> "Matt Crawford" <[EMAIL PROTECTED]> writes:
>
> > &
On Wed, 12 Mar 2003 15:37:23 MST, Doug Royer <[EMAIL PROTECTED]> said:
> If you are talking about TLS certs (not S/MIME certs) then the ISP can
> issue them to the customer directly (be a CA for connections from their
> customers over TLS connections). I have read that the customer can be
> given
Yes, this is true in theory, but I want to know how you're going
to get VeriSign to issue you a certificate with subjectAltNames
corresponding to a bunch of unrelated domains. And remember
that ever time the ISP gets a new customer they have to get a new
cert from VeriSign with yet another subjec
"Matt Crawford" <[EMAIL PROTECTED]> writes:
> > > Not clear. SMTP can relay a single copy of a message to multiple
> > > recipients at multiple domains. Your suggestion would force a
> > > separate TLS session, or a separate SMTP session, for every distinct
> > > recipient domain.
> >
> > Yes,
> > Not clear. SMTP can relay a single copy of a message to multiple
> > recipients at multiple domains. Your suggestion would force a
> > separate TLS session, or a separate SMTP session, for every distinct
> > recipient domain.
>
> Yes, that's true, but that's inherent in the "one certificate"
> > There's no reason a protocol can't be spec'd to let the client convey
> > the name of the resource before the TLS handshake begins.
>
> no, there isn't. but it still wouldn't give the client a way to verify
> that the server is authoritative for that domain.
If it isn't, your trust in the C
Keith Moore <[EMAIL PROTECTED]> writes:
> > It's true that this is a backward compatibility problem
> > in that STARTTLS as currently defined doesn't actually contain
> > the domain name. As I indicated before, I consider this to
> > be a design error. There wouldn't have been a compatibility
> >
> It's true that this is a backward compatibility problem
> in that STARTTLS as currently defined doesn't actually contain
> the domain name. As I indicated before, I consider this to
> be a design error. There wouldn't have been a compatibility
> problem if the domain name had been included in ST
On Wed, 12 Mar 2003 09:09:09 -0600
"Matt Crawford" <[EMAIL PROTECTED]> wrote:
> > I see your point. But I suspect it illustrates a significant
> > limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume
> > that an IP address and port number are used by only one named
> > service.
On Tue, 11 Mar 2003 15:42:00 -0500
John Stracke <[EMAIL PROTECTED]> wrote:
> >Perhaps the notion of a well known port is a concept whose time has
> >passed. At least for connection oriented protocols, doing away with
> >well known ports might have some good properties for some basic
> >authentica
On Wed, 12 Mar 2003 07:56:06 EST, Keith Moore said:
> I think you mean "every domain"; DNS names don't need to correspond to hosts
> anymore (and often don't). I'm not sure why it's inherently impractical to d
o
> this, especially if it were possible to have a single cert that covered
> multiple
Keith Moore <[EMAIL PROTECTED]> writes:
> > > I see your point. But I suspect it illustrates a significant
> > > limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume
> > > that an IP address and port number are used by only one named service.
> > > It's been awhile since I looked
> I see your point. But I suspect it illustrates a significant
> limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume
> that an IP address and port number are used by only one named service.
> It's been awhile since I looked at the TLS protocol but I don't recall
> any way for
> > I see your point. But I suspect it illustrates a significant
> > limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume
> > that an IP address and port number are used by only one named service.
> > It's been awhile since I looked at the TLS protocol but I don't recall
> > any wa
Keith Moore <[EMAIL PROTECTED]> writes:
> yes. because mail.isp.com is the name of a server which might support
> thousands of MXed domains.
That's what I figured.
> > If so, this really isn't satisfactory, because it allows
> > anyone who can tamper with the DNS to intercept mail
> > destined fo
On Wednesday, March 12, 2003, at 12:27 AM, Eric Rescorla wrote:
Keith Moore <[EMAIL PROTECTED]> writes:
or at least, proper behavior isn't well-defined. IMHO, about the only
behavior that is reasonable (assuming a single cert, which IIRC is
what TLS assumes) is to have the peer server offer a ce
Keith Moore <[EMAIL PROTECTED]> writes:
> or at least, proper behavior isn't well-defined. IMHO, about the only
> behavior that is reasonable (assuming a single cert, which IIRC is
> what TLS assumes) is to have the peer server offer a cert for the
> domain name associated with the A record, not t
On Tuesday, March 11, 2003, at 02:21 PM, Eric Rescorla wrote:
[EMAIL PROTECTED] writes:
It did teach me the importance of protecting against the
man-in-the-middle attack. This is not often done, at least not by
default, in many STARTTLS implementations.
Indeed. The problem is that it's pretty har
John Kristoff wrote:
Perhaps the notion of a well known port is a concept whose time has
passed. At least for connection oriented protocols, doing away with
well known ports might have some good properties for some basic
authentication/cookie mechanism as well.
Well, there's SRV records; but t
From: Eric Rescorla <[EMAIL PROTECTED]>
Date: 11 Mar 2003 11:21:51 -0800
[EMAIL PROTECTED] writes:
> It did teach me the importance of protecting against the
> man-in-the-middle attack. This is not often done, at least not by
> default, in many STARTTLS implementations.
Indee
On Thu, 27 Feb 2003 10:15:34 -0600
"Spencer Dawkins" <[EMAIL PROTECTED]> wrote:
> It might be interesting for IAB to think about the estimated half-life
> of well-known port numbers in the Internet architecture, since we've
> been seeing
It might be interesting to find a way to make port numbers
[EMAIL PROTECTED] writes:
> It did teach me the importance of protecting against the
> man-in-the-middle attack. This is not often done, at least not by
> default, in many STARTTLS implementations.
Indeed. The problem is that it's pretty hard to determine
a priori what certificate the peer server
> From: [EMAIL PROTECTED]
> Reply-to: [EMAIL PROTECTED]
"[EMAIL PROTECTED]"?
I've been meaning to ask about that. If the goal is to avoid
Microsoft out-of-office noise and other hassles, wouldn't
[EMAIL PROTECTED] or some other obvious bit bucket be better?
> ...
> I actually encountered an IS
>The "nicest" solution that I can see is for the ISPs to transparently
>proxy port 25 to their MTA. They should offer STARTTLS.
Assuming you're not pulling my leg, I couldn't disagree more
strongly. This is even worse than blocking port 25 outright.
I actually encountered an ISP that does this. I
M
> To: RL 'Bob' Morgan
> Cc: IETF
> Subject: Re: IAB policy on anti-spam mechanisms?
>
>
> On Thu, Feb 27, 2003 at 12:41:41AM -0600, RL 'Bob' Morgan wrote:
> > Many sites, including my university, support STARTTLS+AUTH on the
> > Submission port (587, RF
-BEGIN PGP SIGNED MESSAGE-
> "Francis" == Francis Dupont <[EMAIL PROTECTED]> writes:
mcr> The "nicest" solution that I can see is for the ISPs to
mcr> transparently proxy port 25 to their MTA. They should offer
mcr> STARTTLS.
Francis> => I don't understand the word
>That being said, whining about lack of transparency is not going to
>change the behavior of the operators. The IETF should rather do
>something useful, e.g. make sure that IPSEC is easy to deploy...
In other words, we need to develop and deploy network architectures
and technologies that delibera
> From: "Christian Huitema" <[EMAIL PROTECTED]>
> ...
> > Millie, have any real idea what "internet transparency" might be. They
> > certainly have no clue that it might be as valuable and that it might
> > be what has made their mailboxes both useful and full of spam.
>
> SPAM is pretty high in
> I also don't want want to insult anyone by stating the obvious fact
> that almost no users, whether they are employed by ISPs and have titles
> like "super senior network operator guru" or are end users like my Aunt
> Millie, have any real idea what "internet transparency" might be. They
> certa
> From: "Dick St.Peters" <[EMAIL PROTECTED]>
> > I don't want to insult anyone, but subscribers treat spam filters like
> > the other black boxes they deal with. They don't care how a filter
> > works if it has less than 10%-15% false negatives and less than 1%
> > false positives.
>
> In other w
> From: Vernon Schryver <[EMAIL PROTECTED]>
> I don't want to insult anyone, but subscribers treat spam filters like
> the other black boxes they deal with. They don't care how a filter
> works if it has less than 10%-15% false negatives and less than 1%
> false positives.
In other words there i
Phil,
Wednesday, February 26, 2003, 9:14:01 PM, you wrote:
PK> I would like to propose that the IAB consider drafting and adopting a
PK> position statement on the highly deleterious effect that certain
PK> anti-spam mechanisms have on legitimate, efficient uses of the Internet.
The timing of you
> From: Keith Moore <[EMAIL PROTECTED]>
> To: Paul Vixie <[EMAIL PROTECTED]>
> > the maps dul is a list of dialups,
> > not a list of guilty spammers. anyone who subscribes to it knows what they
> > are getting.
That's both wrong and misleading.
It is misleading because the essentially none
> > the maps dul is a list of dialups, not a list of guilty spammers.
> > anyone who subscribes to it knows what they are getting.
>
> yes, but are they being misled into thinking it's a good idea to block
> smtp traffic just because it comes from a dialup line?
to keep that question from fitting
> the maps dul is a list of dialups,
> not a list of guilty spammers. anyone who subscribes to it knows what they
> are getting.
yes, but are they being misled into thinking it's a good idea to block smtp
traffic just because it comes from a dialup line?
phil wrote:
> Perhaps I should have used a better word, such as "selective", to
> imply methods that are much more likely to stop spam than
> non-spam. The MAPS DUL does not discriminate between spam or non-spam,
> or even between users who have generated spam in the past and those
> that do not.
>Could you elaborate a bit on what you mean by "meaningful"? As someone
>who uses the DUL list as an anti-spam mechanism and who experiments
>with turning it off and on, I can definitely say that turning it on
>reduces the amount of spam I receive (on the order of about 100
>messages a day).
Certa
[EMAIL PROTECTED] wrote:
Just about every ISP (except for those run as fronts by the spammers
themselves) has an acceptable use policy that prohibits spamming
Many of the ones that are, or at least seem to be, run by the spammers,
also have such AUPs. They just enforce them even less than Screw
At 5:34 PM -0800 2/27/03, [EMAIL PROTECTED] wrote:
Your question assumes that the DUL is actually a meaningful anti-spam
mechanism. It is not.
Could you elaborate a bit on what you mean by "meaningful"? As
someone who uses the DUL list as an anti-spam mechanism and who
experiments with turning it
At 12:55 AM 2/27/2003 -0500, Theodore Ts'o wrote:
Yup, some 802.11 wireless "hotspot" networks block port 25 as well.
Very annoying. My personal workaround to this is to have a personal
server tucked away at a colo facility, which among other things, runs
a SMTP server listening on port 2025 (to
On Fri, 28 Feb 2003 09:32:42 -0500, Robert Moskowitz wrote:
>Perhaps this is a business model for someone here?
>
>For a modest fee to run an SSH gateway to allow tunneling past ISP
policies :)
I have collected a whole potful of constructive suggestions and
workarounds from my friends on Spam-
At 10:22 PM 2/27/2003 +0700, Dr. Jeffrey Race wrote:
It seems there's a need to balance interests among different groups of
users. What is your proposed solution to prevent emission of
spam via dialup, if you propose to discourage the DUL? (My
proposal imposes a positive duty of care of ISPs to
In your previous mail you wrote:
The "nicest" solution that I can see is for the ISPs to transparently
proxy port 25 to their MTA. They should offer STARTTLS.
=> I don't understand the word "transparently" here (:-). If one of
my ISPs does such things, I'll sue it immediately: we have l
On Wed, 26 Feb 2003 19:49:15 -0800, [EMAIL PROTECTED] wrote:
[snip]
>
>There is precedent for the IAB taking a stand on this sort of
>thing. In particular, RFC2775 on "Internet Transparency" expresses the
>view that the end-to-end principle that underlies the Internet
>architecture is still vitally
I would like to propose that the IAB consider drafting and adopting a
position statement on the highly deleterious effect that certain
anti-spam mechanisms have on legitimate, efficient uses of the Internet.
I am thinking mainly of the MAPS DUL (Dialup User List), a remarkably
ill-conceived mec
On Thu, 27 Feb 2003 10:48:31 -0700 (MST), Vernon Schryver wrote:
>UUNet in particular has demonstrated this sad syndrome. For years,
>instead of ejecting its spamming and spam-friendly resellers, it lied.
>Then it lied for years about installing port 25 filtering. Finally,
>it got port 25 filter
On Thu, 27 Feb 2003 17:34:54 -0800, [EMAIL PROTECTED] wrote:
>Certainly. Just about every ISP (except for those run as fronts by the
>spammers themselves) has an acceptable use policy that prohibits
>spamming along with activities that are actually illegal. Nearly every
>ISP maintains an "abuse" a
> Ah, but then you're running a *mail server*, which puts you in
> violation of your local ISP's rules even if your MTA does not permit
> relaying!
>
> Believe it or not, I have actually been given this exact argument by
> someone at MAPS whom I've been trying (unsuccessfully) to convince
> that th
>Yup, the problem with well-known ports is that well-known port numbers
>get either (a) blocked by misguded ISP's, or (b) transparently proxed
>by misguided ISP's. Since I have no idea what sort of stupidity I
>might encounter at various different hotel, conference, or 802.11
>hotspot networks, it
>It seems there's a need to balance interests among different groups of
>users. What is your proposed solution to prevent emission of
>spam via dialup, if you propose to discourage the DUL? (My
>proposal imposes a positive duty of care of ISPs to prevent
>emission of spam, so I am quite concerne
At 01:13 PM 2/27/2003 -0600, Pete Resnick wrote:
On 2/26/03 at 7:49 PM -0800, Phil Karn wrote:
I would like to propose that the IAB consider drafting and adopting a
position statement on the highly deleterious effect that certain
anti-spam mechanisms have on legitimate, efficient uses of the Int
-BEGIN PGP SIGNED MESSAGE-
The "nicest" solution that I can see is for the ISPs to transparently
proxy port 25 to their MTA. They should offer STARTTLS.
If the client selects STARTTLS, their proxy should immediately connect
directly to the intended destination, permitting the connection
On 2/26/03 at 7:49 PM -0800, Phil Karn wrote:
I would like to propose that the IAB consider drafting and adopting
a position statement on the highly deleterious effect that certain
anti-spam mechanisms have on legitimate, efficient uses of the
Internet.
It seems to me that this is a perfect top
> From: "Mike O'Dell" <[EMAIL PROTECTED]>
> i think you'll find that port 25 is blocked going anywhere except
> the operator's outgoing MTA
Only by the slumlord ISPs.
> this is to require authentication to send email, exercise rate
> limiting, and other anti-spam-sending strategies
Or so they
i think you'll find that port 25 is blocked going anywhere except
the operator's outgoing MTA
this is to require authentication to send email, exercise rate
limiting, and other anti-spam-sending strategies
if the ISP is going to be held responsible for the behavior of
their clients, then the ISP
Phil et al, pls see inline comments. I am preparing a detailed
proposal on a related issue (releasing draft in a few days) and would
welcome your replies so as to incorporate inputs as appropriate.
On Wed, 26 Feb 2003 19:49:15 -0800, [EMAIL PROTECTED] wrote:
>I would like to propose that the IAB
On Thu, Feb 27, 2003 at 12:41:41AM -0600, RL 'Bob' Morgan wrote:
> Many sites, including my university, support STARTTLS+AUTH on the
> Submission port (587, RFC 2476), which I believe is the recommended
> service for clients to use to submit mail in any case (though not
> well-supported among MUAs,
On Thu, 27 Feb 2003, Theodore Ts'o wrote:
> On Wed, Feb 26, 2003 at 07:49:15PM -0800, [EMAIL PROTECTED] wrote:
> > Other widely deployed but similarly misguided anti-spam mechanisms
> > include blanket blocks on incoming or outgoing TCP connections to port
> > 25. I've even encountered on ISP tha
On Wed, Feb 26, 2003 at 07:49:15PM -0800, [EMAIL PROTECTED] wrote:
> Other widely deployed but similarly misguided anti-spam mechanisms
> include blanket blocks on incoming or outgoing TCP connections to port
> 25. I've even encountered on ISP that transparently and silently
> redirected my outboun
I would like to propose that the IAB consider drafting and adopting a
position statement on the highly deleterious effect that certain
anti-spam mechanisms have on legitimate, efficient uses of the
Internet.
I am thinking mainly of the MAPS DUL (Dialup User List), a remarkably
ill-conceived mechan
63 matches
Mail list logo
