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 the
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 the
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
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
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
[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
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 of
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.
ironyIf it isn't, your trust in the CA
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
model.
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, that's true, but
[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:
Not clear. SMTP can relay a single copy of a message
to multiple
recipients
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 at the TLS
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
problem if
: 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, RFC 2476), which I believe is the recommended
service for clients to use to submit mail in any case
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
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 ISP
[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
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 so
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.
Indeed.
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
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
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 the
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
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 for any
-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 transparently
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 is
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 words there is
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
certainly
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 the list of
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
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 laws
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
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
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
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-L
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
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. If
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 of people
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 your
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?
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
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
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 say.
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
-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
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
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's
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 the MAPS
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 concerned
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
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 filtering
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 that
52 matches
Mail list logo
