On Fri, Jun 17, 2005 at 11:48:58AM -0400, Ben Hubbard wrote:
You seem to repeatedly describe a solution that becomes so big that it (at
least substantially) replaces 25/SMTP. That's what I don't think will
work, or is needed.
Please let me borrow Ben's point and expand on it.
Spam as it's
Rich Kulawiec wrote:
The best place to stop abuse is as near its source as possible.
Meaning: it's far easier for network X to stop abuse from leaving its
network than it is for 100,000 other networks to defend themselves from it.
Especially since techniques for doing so (for instance,
There's no reason why one couldn't build a comparable model for mail,
with the SMTP speciality service provider offering SMTP transit to a
base of trusted customers. This comparatively small number of SMTP
speciality provider would then maintain good relations (peerings) with
the
I am not sure any level of security would make me feel good about
passing
my emails through a 'peering .. core' of SMTP relays.
However, if we do go in this direction, I plan on firing up my old
copies
of BinkleyTerm. FIDO and NetMail may be a good place to start :)
Back in the day,
On 19/06/05, Alexei Roudnev [EMAIL PROTECTED] wrote:
My e-mail is [EMAIL PROTECTED], but I send it when I am on DSL with EthLink
(and thru Earthlink SMTP). And it is 100% valid situation.
Sure is - which is one reason why spf just is not going to work for you
CSV on the other hand makes no
Back in the day, there were users of Fido technology networks
who were concerned with email privacy. They applied a technology
called PGP to secure the contents of their messages.
Folks,
We are talking about changing an existing system -- one with an installed base
of perhaps 1B users,
: Email peering
In between the choice of accepting mail from *anybody* by default
which we have now and the choice of accepting mail from *nobody* by
default that explicit peering agreements represents there is another
solution; which is to accept mail only from IPs that have *some
relation
On Fri, 17 Jun 2005, [EMAIL PROTECTED] wrote:
The thousands of bilateral BGP peering contracts are most
definitely comparable to the email peering that I am
proposing.
Dude, it's 2005. You can put down the X.400 crack pipe now.
Why does fixing the SMTP email architecture
On Mon, 20 Jun 2005, Todd Vierling wrote:
There are far too many SMTP machines already deployed out there -- we're not
talking thousands; here it's tens to hundreds of thousands worldwide -- to
It's actually millions. And I'm not just pulling that number out of
someone's
In between the choice of accepting mail from *anybody* by default
which we have now and the choice of accepting mail from *nobody* by
default that explicit peering agreements represents there is another
solution; which is to accept mail only from IPs that have *some
relation* to the sender's From
On 18 Jun 2005, John Levine wrote:
In between the choice of accepting mail from *anybody* by default
which we have now and the choice of accepting mail from *nobody* by
default that explicit peering agreements represents there is another
solution; which is to accept mail only from IPs that
This has the same problem as all of the other duct tape authorization
schemes -- it breaks a lot of valid e-mail, ...
In this particular case, the biggest issue is forwarders, ...
This gets into the discussion of what percentage of mail a user gets that
is like this. It varies widely.
, and that I suggested in my posting Informal
email peering please take a look at CSV http://mipassoc.org/csv as a
candidate mechanism for determining the operations-related identity to assess,
and for a means of querying a third party to obtain an assessment.
CSV is simple, uses efficient DNS
[EMAIL PROTECTED] wrote:
Today, if Joe Business gets lots of spam, it is not his
ISP's responsibility. He has no-one to take responsibility
for this problem off his hands. But if he only accepts
incoming email through an operator who is part of the
email peering network, he knows
Similar concept, same scaling problems; it just hides the explicit
routing
from the user (as would any modern peering system, presumably).
Then you are presuming wrongly. Nowhere in what I wrote have
I suggested any changes in the existing email technology. I am
not suggesting that we drop
of the
email peering network, he knows that somewhere there is
someone who will take responsibility for the problem.
That is something that businesses will pay for.
But first, ISPs have to put their hands up and take
collective responsibility for Internet email as a service
that has value and not just
The thousands of bilateral BGP peering contracts are most
definitely comparable to the email peering that I am
proposing.
Dude, it's 2005. You can put down the X.400 crack pipe now.
Why does fixing the SMTP email architecture by applying some
lessons learned from BGP peering lead
[EMAIL PROTECTED] wrote:
Similar concept, same scaling problems; it just hides the explicit
routing
from the user (as would any modern peering system, presumably).
snip
One way that it COULD be implemented is for people accepting
incoming email on port 25 to check a whitelist before
On 17/06/05, Joe Maimon [EMAIL PROTECTED] wrote:
DNSWL -- this is already being done. It is not widely viewed as being in
any way similar to a peering concept. What would be more similar would
be a consortium of large providers providing such a whitelist. That
would be something I would
[EMAIL PROTECTED] said:
That is something that businesses will pay for.
But first, ISPs have to put their hands up and take
collective responsibility for Internet email as a service
that has value and not just as some kind of loss leader
for Internet access services.
Many large
infrastructure worthwhile to them, and everyone is happy.
Sounds good.
I don't think what you have been talking about so far will work, and I
don't think I'm alone in that.
That's strange because you just finished describing how
SOME companies are already engaging in email peering
In message [EMAIL PROTECTED]
om, [EMAIL PROTECTED] writes:
Similar concept, same scaling problems; it just hides the explicit
routing
from the user (as would any modern peering system, presumably).
Then you are presuming wrongly. Nowhere in what I wrote have
I suggested any changes in the
On Fri, 17 Jun 2005 [EMAIL PROTECTED] wrote:
Similar concept, same scaling problems; it just hides the explicit
routing
from the user (as would any modern peering system, presumably).
Then you are presuming wrongly. Nowhere in what I wrote have
I suggested any changes in the existing
On Mon, Jun 13, 2005 at 11:32:31AM +0200,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote
a message of 21 lines which said:
The number of agreements needed in the email world is significantly
higher than what is needed for BGP.
The proponents of email peering typically want to switch from
The number of agreements needed in the email world is significantly
higher than what is needed for BGP.
The proponents of email peering typically want to switch from the
current model (millions of independant email servers) to a different
model, with only a few big actors.
* [EMAIL
, limits on how the technology is to be applied,
SLAs, processes for interoperation and communication between
NOCs, i.e. the people protocols.
The thousands of bilateral BGP peering contracts are most
definitely comparable to the email peering that I am
proposing. I have seen many of these contracts
contracts.
The thousands of bilateral BGP peering contracts are most
definitely comparable to the email peering that I am
proposing. I have seen many of these contracts in companies
that I worked for in the past. They are rather similar to
one another in many ways. Since the total number of BGP
Far not, I have nothing to add on the e-mail peering hand-waving,
but...
On 2005-06-16, at 11:49, [EMAIL PROTECTED] wrote:
If the BGP peering side of the business can sort out all of
this stuff, then why can't the email side of the business do
the same, or perhaps, do even better?
It's
Folks,
This might not turn out to qualify under the precise term of peering but I
like the general implication that things are not entirely open and that there
are service criteria.
...I described how it could be done so
that email peering IS NOT LIMITED to a few big actors.
What
On Thu, 16 Jun 2005, [EMAIL PROTECTED] wrote:
The proponents of email peering typically want to switch from the
current model (millions of independant email servers) to a different
model, with only a few big actors.
I don't know who these proponents are, that you refer to. However
Todd Vierling wrote:
On Thu, 16 Jun 2005, [EMAIL PROTECTED] wrote:
The proponents of email peering typically want to switch from the
current model (millions of independant email servers) to a different
model, with only a few big actors.
I don't know who these proponents are, that you
In message [EMAIL PROTECTED], Todd Vierling writes:
On Thu, 16 Jun 2005, [EMAIL PROTECTED] wrote:
The proponents of email peering typically want to switch from the
current model (millions of independant email servers) to a different
model, with only a few big actors.
I don't know who
On Thu, 16 Jun 2005, Steven M. Bellovin wrote:
You're lost in the past. Study history and stop repeating it back to us.
Although I agree that email peering is a seriously bad idea, I don't
think that the analogy to uucp is correct.
You're right -- I left out the routing table bit, which
Of course, there's already one application-level messaging
protocol that relies extensively on arranged peerings: Usenet.
Usenet doesn't rely on a *full* N-way mesh of arranged peerings,
it relies instead on a core of fairly well interconnected
backbone or core news sites who've agreed to do
[EMAIL PROTECTED] writes:
The thousands of bilateral BGP peering contracts are most
definitely comparable to the email peering that I am
proposing.
Dude, it's 2005. You can put down the X.400 crack pipe now.
---Rob
Part of the problem is that there are no agreed rules of engagement
for email abuse issues. By setting up email peering agreements in
advance, we could put those rules of engagement in place and we
could ensure that our email peers have the *RIGHT* contact
information.
Agreed. One
36 matches
Mail list logo
