into account the amount of time since the
first Last Call the Area Director and the editors decided to run again a
two weeks Last Call.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-hutzler-spamops-07.txt
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
the sign, since I knew they'd be closed
on Sunday. His comment was that tomorrow never comes.
Someday, indeed.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
/breakfast.pdf for details.
Please pass this note to anyone you feel might be interested in hearing about
it.
Thanks.
d/
--
Dave Crocker
Brandenburg InternetWorking
http://bbiw.net
)
--
Dave Crocker
Brandenburg InternetWorking
http://bbiw.net
a number of email boundary gateway mediating services
by then -- and very probably back to 1973. (I just know that some MIT type is
going to claim pre-1970, given the generality of the definition I offered.)
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t
is *strongly* encouraged.
--
d/
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
, given that no all policy-making is at the TLD level?
d/
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
of implementations, pointer to
mailing list, copies of specs, etc.
I'll try to get a cop of Eric's presentation.
--
d/
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
The DKIM announcement on Monday resulted in its having increased
attention
and Eric Allman gave an excellent presentation about it.
Does anyone know if any of these presentations are available anywhere?
eric's presentation is now at http://mipassoc.org/mass
--
d/
Dave
an excellent presentation about it.
--
d/
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
Roaylty-free does not mean it can be used by everyone.
it would probably help to debate the licensing details when folks have
looked at the specific language of the licensing agreement(s).
begin:vcard
fn:Dave Crocker
n:Crocker;Dave
adr:;;;Sunnyvale;CA;94086;USA
email;internet:dcrocker a t
...)
the effort is relying on IPv6 and on the disappearance of NATs, for v6. one
might consider these to be critical dependencies that are rather risky.
--
d/
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
. naive would be another term to
consider.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
In other words, SMTP does not have the equivalent of an
HTTP redirect which is what he wants here. Maybe SMTP
really is broken? ;-)
hmm.
i seem to recall a similar redirect mechanism in SMTP some time ago. not
worth the effort; broken; or somesuch.
anyhow, once you've hit a server, the
In his case, it sounds like he actually has a business case
for solution 3 above.
I think there is *always* a business case for making infrastructure
communications services work efficiently and reliably.
However the world is pretty consistent about efforts to fix long-standing
human
Many mail servers don't know
a user's forwarding address at SMTP time;
ahh, right.
something about email being s/f, and therefore not direct.
requiring 'the next hop' to have complete knowledge doesn't work. requiring a
particular hop to the 'the last hop' also causes problems.
hmm. i
I don't have the answers but I think the 10 years of
failure to put a dent in spam have shown beyond the
shadow of a doubt that Internet email is broken by
design and bandaids are not going to fix this, no matter
how many different bandaids are applied. It is time
to re-engineer with the
Andrew Staples wrote:
3. Change company policy to reflect names like [EMAIL PROTECTED],
[EMAIL PROTECTED], etc, where DNS would resolve to the correct server.
Doesn't give corporate the email image they are after.
4. Change robustness level at group HQ for relay to individual mail
are valid, but the reality is that they are not all that difficult to
appreciate, if one looks at the process of obtaining global adoption in a
voluntary environment.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
of best practises, and have organization commit to
supporting them.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
provide a basis for something a bit more scalable and a bit more formal.
That's where a membership organization that issues formal best practises
comes in.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
no. inadequate ops clue and sometimes overly eager/encroaching ops
efforts. perhaps this is an example?
and perhaps it isn't.
but thanks for such a constructive contribution.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED
.
This document is a limited, first-step in specifying voluntary standards
for service providers, in their cross-net email operations.
Please send your comments to:
To: ietf@ietf.org
cc: iesg@ietf.org
Thanks.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t
the criticisms of the basic path registration (somewhat akin to
registering source routes) schemes used by SPF and Sender-ID, those two
different specs have different constituencies and were not overly
successful as merging.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
.)
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
nanog?
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
cluster is primarily composed of people with serious
(and probably larger-scale) network services operation experience and the
other cluster has pretty much no one of that ilk...
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED
the web and email, given
that spam is a messaging phenomenon, not a publishing phenomenon.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
too cryptic. yes, they are using the term 'web' to mean 'the
internet'.
the problem is that professional writing needs to be careful, and a failure at
such a basic level as using web to apply to email does not bode well for the
utility of the article...
d/
--
Dave Crocker
Brandenburg
FYI.
I am forwarding this to nanog because there is a request for folks willing to
do field testing.
d/
--- Original Message ---
From: Dave Crocker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc:
Sent: Mon, 21 Feb 2005 15:18:11 +0900
Subject: Revised CSV-Intro and CSV-CSA specifications
Folks
/specifications/draft-crocker-email-arch-03.txt
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
in
the underlying technical architecture. The current doc uses it as an
operations construct.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
tonight's meeting?
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
as the AS-AS
requirement.
In fact, this is exactly the problem that CSV attends to.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
and csv (and maybe spf) are attempting to
provide.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
, and verify that you do
not get the (bad) differential performance there.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com
Cingular.)
d/
--
Dave Crocker dcrocker-at-brandenburg-dot-com
Brandenburg InternetWorking www.brandenburg.com
Sunnyvale, CA USA tel:+1.408.246.8253
Folks,
There is a proposal that should interest you. It is called Bounce Tag
Address Validation By Dave Crocker.
http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.html
This proposal is now in the IETF MASS WG.
TH There was a BoF called MASS held at the recent IETF
of legitimate mail
suggest per-user and per-message policy mechanisms are likely to have
a few scaling problems.
EBD No, SPF isn't perfect. I'm trying to decide if it's even good.
Would that more folks were trying to consider the various proposals
carefully.
d/
--
Dave Crocker mailto:[EMAIL
Folks,
Richard Cox and I participated in an anti-spam workshop in China last
month. A copy of our trip report is at:
http://brandenburg.com/reports/200404-isc-trip-report.htm
d/
--
Dave Crocker mailto:[EMAIL PROTECTED]
Brandenburg InternetWorking http://www.brandenburg.com
?
In other words, why trust the identifier? Or at least, how would
this identifier really be long term?
d/
--
Dave Crocker dcrocker-at-brandenburg-dot-com
Brandenburg InternetWorking www.brandenburg.com
Sunnyvale, CA USA tel:+1.408.246.8253
that there is a good basis for tracking down
problematic sources. That, too, is a good thing.
d/)
--
Dave Crocker dcrocker-at-brandenburg-dot-com
Brandenburg InternetWorking www.brandenburg.com
Sunnyvale, CA USA tel:+1.408.246.8253
time-frame.
And, oh by the way, all SPF tries to do is to authenticate the From field.
Forgive me for not being reassured that wide use of SPF will merely mean
that the spam I get will have a valid From field.
d/
--
Dave Crocker dcrocker-at-brandenburg-dot-com
Brandenburg InternetWorking
consensus that answers that
question in concrete and practical terms, then all our efforts are
losing and stop-gap.
d/
--
Dave Crocker dcrocker-at-brandenburg-dot-com
Brandenburg InternetWorking www.brandenburg.com
Sunnyvale, CA USA tel:+1.408.246.8253
Adi,
AL We're relying exclusively on SMTP AUTH for SMTP relaying.
what about port 25 blocking that is now done by many access providers?
this makes it impossible for mobile users, coming from those providers,
to access your server and do the auth.
d/
--
Dave Crocker dcrocker-at-brandenburg
the public
relations campaign that Verisign is conducting.
d/
--
Dave Crocker dcrocker-at-brandenburg-dot-com
Brandenburg InternetWorking www.brandenburg.com
Sunnyvale, CA USA tel:+1.408.246.8253
that your group intends to bring these
proposed standards to a venue that does open standards development and
adoption, to ensure that the specifications are subject to broad review
and commentary.
d/
--
Dave Crocker dcrocker-at-brandenburg-dot-com
Brandenburg InternetWorking www.brandenburg.com
contract with ICANN, and should they have
SMB such a right.
Is exactly the right way to approach this topic. (I think Howard's foray into
categorizing issues is also extremely constructive.)
d/
--
Dave Crocker dcrocker-at-brandenburg-dot-com
Brandenburg InternetWorking www.brandenburg.com
that DNS wildcards should not be used in a
zone unless the zone operator has a clear understanding of the risks, and
that they should not be used without the informed consent of those
entities which have been delegated below the zone.
d/
--
Dave Crocker dcrocker-at-brandenburg-dot-com
--
Dave Crocker dcrocker-at-brandenburg-dot-com
Brandenburg InternetWorking www.brandenburg.com
Sunnyvale, CA USA tel:+1.408.246.8253
they don't care about making money.
Spammers are like roaches. They are here to stay. They are aggressive.
They adapt.
We need to respond with a variety of mechanisms, preferably coordinated
to maximize the aggregate effect.
d/
--
Dave Crocker mailto:[EMAIL PROTECTED]
Brandenburg
Michael,
Wednesday, February 5, 2003, 1:04:08 AM, you wrote:
MDrc What would be the point? Well, if my MTA receives a connection on port 25
MDrc I could look up the source IP address in the LDAP directory to identify
MDrc the owner. Since an LDAP directory can contain arbitrary information
MDrc
Jack,
Tuesday, February 4, 2003, 7:16:04 AM, you wrote:
JB From: Daniel Senie
I'd be happy to see certs in use for MTA-MTA
(and indeed support this today on my systems when talking to other MTAs
which are using STARTTLS).
...
JB I'm concerned with MTA to MTA. ... A flag day is
JB necessary,
Al,
Tuesday, February 4, 2003, 10:20:50 AM, you wrote:
AR Don't even need that. I can telnet into the appropriate server/port
1. as you note, that is a solution that does not scale to millions of non-technical
users.
2. many people need access from their laptops (ie, their office),
rather
John,
Tuesday, February 4, 2003, 10:50:14 AM, you wrote:
IMHO, to block ALL outbound port 25 traffic
on the sending end is throwing the baby out with the bathwater.
JRL It certainly is, but for most ISPs, there's a very small baby in a huge
JRL tub of spam. Remember that this whole question
JC,
Monday, February 3, 2003, 9:43:01 PM, you wrote:
JD Dave Crocker wrote:
Recently I had protracted discussions with a number of Ops folks about
this issue and have chosen to drop that debate. I do not agree with
blocking port 25, either, but am far more concerned about having a
...
JD Why
Folks,
The Ops community and the IETF Email community appear to have different
views about appropriate methods for email posting. The difference
frequently means that an effort to post a new message from a network
with a firewall, to a remote SMTP, is blocked by the outbound firewall.
Blocking
Eliot,
Thursday, January 30, 2003, 7:25:05 PM, you wrote:
EL The submission port, according to IANA is 587.
Sorry about that detail. I searched the IANA port assignment file for
'submit' rather than 'submission'.
Luckily, the error does not affect the core concern I am raising.
EL I'm not a
and,
sometimes, software to support this. They also can learn what mechanisms
provide real security and what mechanisms do not.
d/
--
Dave Crocker mailto:[EMAIL PROTECTED]
TribalWise, Inc. http://www.tribalwise.com
tel +1.408.246.8253; fax +1.408.850.1850
into a false sense of security.
d/
--
Dave Crocker mailto:[EMAIL PROTECTED]
TribalWise, Inc. http://www.tribalwise.com
tel +1.408.246.8253; fax +1.408.850.1850
with smtpauth ensures full accountability and,
therefore, prevents spam. blocking 25 disables use of this mechanism.
d/
--
Dave Crocker mailto:[EMAIL PROTECTED]
TribalWise, Inc. http://www.tribalwise.com
tel +1.408.246.8253; fax +1.408.850.1850
then. Too bad the 100 million current Internet users do not know that.
d/
--
Dave Crocker mailto:[EMAIL PROTECTED]
TribalWise, Inc. http://www.tribalwise.com
tel +1.408.246.8253; fax +1.408.850.1850
/
--
Dave Crocker mailto:[EMAIL PROTECTED]
TribalWise, Inc. http://www.tribalwise.com
tel +1.408.246.8253; fax +1.408.850.1850
users and the implication for such minor opportunities such as
wireless hotspots.
d/
--
Dave Crocker mailto:[EMAIL PROTECTED]
TribalWise, Inc. http://www.tribalwise.com
tel +1.408.246.8253; fax +1.408.850.1850
, mobile users are hurt
badly. I know that *I* certainly am. Constantly and serously.
d/
--
Dave Crocker mailto:[EMAIL PROTECTED]
TribalWise, Inc. http://www.tribalwise.com
tel +1.408.246.8253; fax +1.408.850.1850
Shein wrote:
On September 10, 2002 at 10:16 [EMAIL PROTECTED] (Dave Crocker) wrote:
One of the basic problems with discussions about spam control is that it
focuses entirely on spam. Blocking output SMTP from individual dial-ups
has a serious negative consequence:
Yeah, well, too late
/
--
Dave Crocker mailto:[EMAIL PROTECTED]
TribalWise, Inc. http://www.tribalwise.com
tel +1.408.246.8253; fax +1.408.850.1850
, but consensus views should be helpful for making them.
d
--
Dave Crocker mailto:[EMAIL PROTECTED]
TribalWise, Inc. http://www.tribalwise.com
tel +1.408.246.8253; fax +1.408.850.1850
. The central authority in these cases is either some sort of
statute or the cooperative enforcement of the participation community.
d/
--
Dave Crocker mailto:[EMAIL PROTECTED]
TribalWise, Inc. http://www.tribalwise.com
tel +1.408.246.8253; fax +1.408.850.1850
69 matches
Mail list logo
