This is copy of the message sent to IETF mail list. As subject said,
I'd like to organize IETF working group to define new additions to SMTP.
William,
While not trying to discourage you from your efforts, I would like to
recommend that you not reinvent the wheel. The list you have presented
already has some possible solutions to it which I have listed below.
Delayed transmission: Are we talking about rate limiting, or delivery of
specific messages at specific times? Either way this is more an MTA issue
in my eyes, than a protocol issue. Rate limiting is already availible in
at least one major Unix MTA.
Delivery notification: Possibly a protocol issue. This is availible as a
semi-standard. RFC1891 is your friend:
ftp://ftp.isi.edu/in-notes/rfc1891.txt
Secure communication: TLS, SSL.
Several (if not most) of the issues indeed have solutions available (which
is BIG plus for this project), almost none have any standards and there
is no wide use at all. I want standards to be defined and in a way that
would encorage worldwide use of these features and in my view it means
new version of the protocol (with backward compatibility). I fully
understand that this will not be implemented in couple years and if this
all goes though, we'll be lucky to see the features used in any serious
manner in no less then 5 years.
As you say there are a number of good solutions availible for most of the
problems that you have shown.
Unfortuantely I don't believe the lack of uptake is due to either
complexity, unavailibility, or lack of standardization.
Rather, it is a matter of convenience to not use some features, or lack of
need to use other features.
For example, there is very little need to use protocol level server <->
server encrypted links, as it's more preferable to use user-level
encryption such as PGP. This is prefered because I cannot guarantee that
every hop in my transmission will be secure, or that the level of security
will be sufficient for my needs.
SMTP AUTH is availible, but only really required where one wants to allow
relaying through servers from remote netblocks. So there's no great need
to do it.
I have a feeling I understand what you're trying to accomplish, but maybe
we should work at this from another angle - what are the more basic
problems oyu're trying to fix? Spam? Lack of encryption? Remote relaying?
Understand that they are NOT the same problem and should be handled
seperately. You can't say spam is a 'security' problem - it's a social
problem.
what are the more basic problems you're trying to fix?
I'd like to be able to publish DNS records announcing my domain's *outbound*
mail servers, with nice abbreviated forms to say "they're the same as my
inbound (MX) records" or "any IP in x.y.z/24". Then cooperative ISPs (like say
America Online) could refuse any email from my domain that originated from some
random cable modem, instead of accepting it and then flooding me with 20000
bounce messages.
Spam?
Yeh, but it would also help with things like KLEZ.
I'd like to be able to publish DNS records announcing my
domain's *outbound*
mail servers, with nice abbreviated forms to say "they're the
same as my
inbound (MX) records" or "any IP in x.y.z/24". Then
cooperative ISPs (like say
America Online) could refuse any email from my domain that
originated from some
random cable modem, instead of accepting it and then flooding
me with 20000
bounce messages.
It's almost to the point to where mail servers need their own
"registrar", sort of the way domains are tracked now, track mail
servers. Give mail server admins the option to accept mail from
registered mail servers only or from any mail server. Of course there
would need to be a ramp up period, like six months to a year, to make
sure all of your mail servers are registered. And of course one should
only be able to register mail servers if the IP space is actually SWIP
to them. If the IP space is NOT SWIP, it would need to be registered by
the customer ISP or via owners rwhois server. Just my $.02; for what
it's worth....
What about this email from you which came to me from Merit and not your
mail server? Would break mailing lists and listserves unless the from
field is overwritten.
-ron
No, because a mailer doesn't look at headers - it looks at the SMTP
envelope, and mailinglists set this to point to an address of
themselves to monitor bounces.
Greetz, Peter
A user/server certification system would be nice, as long as the
certificate issuers held the right balance between ease of getting a
cert and security in proving the identity of the cert holder. That
would take away the anonymous nature of SPAM, and make enforcement
possible. If an authority consistently fails to respond to
complaints, you don't accept mail certified from them. And a
certificate train will get you mail from small folks (I trust ALGX's
CA, ALGX trusts AOL's, therefore AOL will accept my mail until I screw
up, and ALGX revokes my server cert and/or turns me in to the FBI, or
fails to and AOL revokes their trust of ALGX.)
The only down side is the politics involved.
-Dave
A user/server certification system would be nice, as long as the
certificate issuers held the right balance between ease of getting a
cert and security in proving the identity of the cert holder. That
would take away the anonymous nature of SPAM, and make enforcement
possible. If an authority consistently fails to respond to
complaints, you don't accept mail certified from them. And a
certificate train will get you mail from small folks (I trust ALGX's
CA, ALGX trusts AOL's, therefore AOL will accept my mail until I screw
up, and ALGX revokes my server cert and/or turns me in to the FBI, or
fails to and AOL revokes their trust of ALGX.)
Well yes, it could be done with certificates, but it can also be done
via some type of "root server" system like DNS uses. A database
distributed among many root servers from the registrars is proven.
Tracking valid servers seems much easier to track rather than
blacklisting IP's that are not mail servers at all or are abusive
servers. IMHO I don't think it would be that horrible of an idea with
the right amount of notification and education to state something such
as "register your mail servers by this date or risk service
interruption". Of course this period would be several months, if not a
year+ .
The only down side is the politics involved.
Politics and legalities are 95% of the reason a lot of good ideas have
yet to materialize.
:I have a feeling I understand what you're trying to accomplish, but maybe
:we should work at this from another angle - what are the more basic
:problems oyu're trying to fix? Spam? Lack of encryption? Remote relaying?
:Understand that they are NOT the same problem and should be handled
:seperately. You can't say spam is a 'security' problem - it's a social
:problem.
Spam is very much a security problem.
Spam would not exist if both MUA's and MTA's had adequate policy
enforcement features on them, so that users could set granular
controls on what was allowed into their mailboxes.
Policy enforcement is explicitly a security function, and spam can
even be defined as any message that relies on this lack of policy
enforcement tools for it to be delivered.
It is not a social problem, or even a matter of personal taste if
it leverages the inability of the user to enforce a policy on
what enters their mail servers.
TMDA (Tagged Message Delivery Agent) is an excellent example of
how policy can be set on MTA's and MUA's. It's rough ( tmda.net)
but IMHO, it offers a glimpse at what the future of mail delivery is
going to look like.
Any attempt to circumvent the policy becomes (by definition) a
network policy violation, and unauthorized access, and there
are social and legal tools to deal with unauthorized access.
I can see why this group is looking at adding features to SMTP,
as everyone understands that it is limited, and those limitations
have become an expensive liability.
Meaningful Secrity/policy enforcement options would be a welcome
addition to both MUA/MTA software, or maybe even the protocol itself.
Cheers,
Yo Avleen!
Spam is very much a security problem.
Spam would not exist if both MUA's and MTA's had adequate policy
enforcement features on them, so that users could set granular
controls on what was allowed into their mailboxes.
Nice try, but not close enough.
Spam is a LEGAL problem.
There are many cases where spammers negotiated a service contract with
out anti-spamming clauses. Then when the ISP figures out they have
a bulk spammer for a custmoer they can not shut down the spammer because
the spammer gets a court order to enforce the service agreement.
Same goes on the other side. Many BLs have been sued, AND LOST, for
putting spammers on their BLs.
Put those two together and no technical solution will fix the problem.
If legislatures say Pi is equal to 3 then there is not much we
can do to fix it except fight the legislature.
RGDS
GARY
:> Spam would not exist if both MUA's and MTA's had adequate policy
:> enforcement features on them, so that users could set granular
:> controls on what was allowed into their mailboxes.
:
:Nice try, but not close enough.
:
:Spam is a LEGAL problem.
Actually, I'm bang on. 
It's not a legal problem, yet. The reason for this is that there
is no legal definition of spam that is applicable outside a small
number of jurisdictions. In fact, there is no single
comprehensive definition of spam other than that its most
consistent attribute, which is users inability to filter it
without losing legitimate mail.
Look at CAUCE, Brightmail, SpamAssassin. None of them provide
a comprehensive definition of all spam, rather, they define it by
some of its effects, or deal with it as a matter of heuristic
scoring.
By looking at its one unique attribute, we see that it is a direct
leveraging/exploitation of the openness of the SMTP protocol and
the culture of the Internet SMTP was designed to serve.
That "openness" used to be the social contract of email, now it
is simply a lack of enforcable policy and tools.
:There are many cases where spammers negotiated a service contract with
:out anti-spamming clauses. Then when the ISP figures out they have
:a bulk spammer for a custmoer they can not shut down the spammer because
:the spammer gets a court order to enforce the service agreement.
Yes, but that does not give the end recipient any direct recourse,
and also defines spam as a contract violation between an ISP and its
client, and has no regard for the messages themselves.
:Put those two together and no technical solution will fix the problem.
Actually it will. The model that TMDA uses (whitelists and confirmed
corespondant registration with the recipient) is partial example of a
solution that will make all spam an explicit case of unauthorized
access, which can then be a legal issue.
One of the most basic principles of computer security is:
No Policy = No Crime. Until users have adequate tools and
protocol support to control of what comes into their mailboxes,
there will be spam.
Cheers,
SPAM is neither stricly legal or technical nor social problem, but
preventing it is a challenge in technical, legal and social areas.
Social challenge (stopping spam before it happened): Educate people and
companies about harm of SPAM, educate users not to accept something
that spammer may offer and companies from providing advertising
revenue to spammers.
Technical challenge (stop spam from being delivered): Try to prevent
spammers from being able send email directly to ISP servers and make best
effort to prevent spammers from abusing other system resources.
Legal challenge (stop spam after its delived by provide ways to
compensate for harm that was done): Define what SPAM, outlaw it and
provide legal mechanisms to go after spammers. Provide working legal
mechanisms for prosecuting those that abuse network resources and ways to
compensate owner when it happens.
Neither of the above is sufficient on itself but all together it should
allow us to stop it. I'm engineer - that is why I want to focus on
technical issue, if there are those who will do better at social
or legal challenge I welcome your involvement there.
Yo batz!
Actually, I'm bang on.
Or banging around senselessly...
It's not a legal problem, yet.
Then how do you account for all the lawsuits? MAPS would love to hear
you say they have no legal problems. The CA and WA legislatures that
passed laws defineing and banning spam would love to hear you as well.
:Put those two together and no technical solution will fix the problem.
Actually it will. The model that TMDA uses (whitelists and confirmed
corespondant registration with the recipient) is partial example of a
solution that will make all spam an explicit case of unauthorized
access, which can then be a legal issue.
I set up a lot of help desks, online shopping carts, etc. White lists
do not work in those roles. The mail is just too all over the place
and telling a boss that he is only losing a few orders or losing a
few customers due to a white list is not an option.
A lot of tech support calls are people emailing to say they are on
a friends account and locked out of their real account, or forgot
their password, or...
No Policy = No Crime. Until users have adequate tools and
protocol support to control of what comes into their mailboxes,
there will be spam.
Policies do not define crimes, Common Law and Written Law do.
RGDS
GARY
IMHO I don't think it would be that horrible of an idea with the right amount
of notification and education to state something such as "register your mail
servers by this date or risk service interruption".
] but I also run a SMTP server on my laptop which bounces usually between two
] addresses (one at home, one at work)
Actually, I don't care too much about "the rest of you", nothing would force
you to publish your outbound mail servers. As long as a few big sites (spam
targets) honor the white list I publish for *my* own domain, great. It's
voluntary, and to your advantage both as a sender and a receiver to adopt it
(assuming the mailing list thing is resolvable).
Domains like pobox.com wouldn't be able to use this, so it shouldn't be a
requirement.
Of course this period would be several months, if not a year+ .
Planned obsolescence is another interesting idea, but a sure way to implement
it isn't coming to mind. Basically I want my MTA to refuse deliveries from
MTAs 'X' years/days older than itself. "Years older" vs absolute age is
important, so that an isolated enterprise network somewhere could continue to
inter-operate with itself no matter how old it grew.
How about: use the skey style unrolling (or is that "pre-rolled"?) passwords
to generate cookies. Someone we trust creates the 'generation 0' cookie,
one-way encrypts it one thousand times, and tells us all the 'generation 1000'
cookie, which we put into our MTA configs. At the next tick of the clock (one
year later), the authority releases the cookie for 'generation 999', and some
of us update our configs (or Microsoft and Sendmail update their new
distributions - but NOT Windows Update?). You can go 'X' years without
updating your configs if you want - for whatever 'X' you think most of the
Internet has chosen.
Talking to MTAs newer than me: If my MTA is setup with cookie 'generation 950'
and an MTA connects to me offering cookie 'generation 948', then I should be
able to one-way encrypt the offered cookie twice and compare it to my cookie
and verify that they really are two generations ahead of me, and allow the
connection. The skey trick means I don't need to know future cookies to accept
email from them.
Talking to MTAs older than me: I don't talk to machines 'X' generations older
than me. I have the last 'X' cookies hard coded in my configs, or I just (at
start time) one-way encrypt my current cookie a maximum of 'X' times to
generate all of the valid old cookies I'll accept.
The idea isn't to take live humans (including spammers) out of the loop, just
the no-admin Windows/Solaris/Linux/whatever machines that haven't been patched
in 'X' years. This year's cookie isn't a secret, just next year's and the year
after's, so an admin can't setup a box with 'generation 0' and leave it alone
for a thousand years to annoy the rest of us.
:Then how do you account for all the lawsuits? MAPS would love to hear
:you say they have no legal problems. The CA and WA legislatures that
:passed laws defineing and banning spam would love to hear you as well.
The lawsuits were against the solution providers, not against the spammers.
In the few cases where there were lawsuits against spammers, it was
a civil suit, as there isn't an existing legislative solution that
spans more than a few jurisdictions.
California and Washington may seem like important jurisdictions,
but not compared to .kr, .cn, .ru, .br, .mx, or even .ca.
:I set up a lot of help desks, online shopping carts, etc. White lists
:do not work in those roles. The mail is just too all over the place
:and telling a boss that he is only losing a few orders or losing a
:few customers due to a white list is not an option.
I do IT secuirity incident response for about 60k
people, 45k hosts, their AV gateways, IDS's and firewalls and
I can assure you, spam is a security problem. Security as
a discipline is uniquely positioned to articulate solutions
to spam.
Read the tmda.net site. Read the FAQ and the README files. Mail
isn't lost, it is queued. See myprivacy.ca for an example of
how it operates.
The system works as follows:
Sender sends message to recipient.
Recipients MTA/MUA checks to see if they are a registered recipient.
If yes, mail is delivered.
If no, mail is queued, and a confirmation asking if they they are a
legitimate corespondant is sent to the sender.
The sender responds with the confirmation ticket, and is whitelisted.
Queued mail is delivered.
Now, the confirmation message will also include a policy stating
that UCE, solicitations and all the other crap that people associate
with spam are not to be sent to this address and by returning
this message you accept this policy.
It doesn't matter if even if someone comes up with a way to
autorespond to this message, as if they violate the recipients
policy, they are commiting unauthorized access, theft of
services etc..
What TMDA-like systems do is escalate a problem that engineering
and regular expressions do not have the adequate breadth
to comprehensively express, and into a question of policy, where
the conceptual and legal tools already exist.
What this doesn't cover is everything that AV gateway filters do,
but that's another story.
:Policies do not define crimes, Common Law and Written Law do.
There is a reason why there have to be notices that unauthorized
access to systems is prohibited in /etc/motd in any government
system you access. It is so that there is no legal ambiguity
when someone gets caught hacking and the case shows up in court.
Ask any CISA, CISSP, computer forensics specialist, or
anyone else who deals professionaly in information security,
and they will tell you, that if you don't have a policy, you
will have trouble convincing anyone a crime has been committed.
Doesn't work.
Back when I was working at AOL, every three or four months some new VP would come up with the "bright" idea that we should not accept mail from an AOL e-mail address that does not come from our own servers.
The answer is the same -- doesn't work. The reason is that there are these things called mailing lists. Any user from any site in the world (including AOL) could post to the list, and then there would be e-mail claiming to be from an AOL user which is addressed to other AOL users, but which does not come from the AOL servers.
Now, I'm sure that the next thing you're going to tell me is that we'd be talking about envelope sender addresses, not the "From:" address. Well, many people run mailing lists as simple aliases, as opposed to using "real" mailing list management software.
I'll say it again -- doesn't work.
Well yes, it could be done with certificates, but it can also be done
via some type of "root server" system like DNS uses. A database
distributed among many root servers from the registrars is proven.
Look. The DNS is seriously screwed-up enough as it is. Let's not take a bad model and replicate it elsewhere.
Tracking valid servers seems much easier to track rather than
blacklisting IP's that are not mail servers at all or are abusive
servers.
Sure. Only accept e-mail from white-listed servers. You don't need a complex system to manage that.
IMHO I don't think it would be that horrible of an idea with
the right amount of notification and education to state something such
as "register your mail servers by this date or risk service
interruption".
Sure. Are you willing to be the first?
If you check on the GNP and Internet statistics for California, you
might come up with a different opinion/order.
i.e. Southern California, fith largest GNP in the world. 11% of
registered domains (although that has changed with dot.bomb, maybe up,
maybe down), etc. Take a look at any Internet map before making
comparisons to .kr, .mx, .br or others. Hint, count major IXs.
Some of the proposals in this thread also have scaling issues. Think
transiting millions of E-mails a day at a reasonable cost to the
consumer.
Fast, cheap, good. Choose two. McDonalds proves most consumers opt for
the former over the latter. I personally make every effort to be the
exception, but it's an uphill battle.
Just my 2�
Best regards,