IETF SMTP Working Group Proposal at smtpng.org
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. ---------------- As everyone I'm sure have seen on the last "why is spam a problem" and other similar threads on ietf as well as numerous similar threads on other lists and boards, there is a serious need to do something to limit amount of unsolicited email. While the roots maybe social issue I do not see why we can not work on it from technical point of view. In addition to that during last years, I'v seen real need for new features to be added into SMTP, such as ones for callback, delayed transmission, delivery notification,secure communications, etc, etc and there are in fact several drafts available on some issues. As far as anti-spam mechanisms I do not belive we should force some particular method on everyone but rather built several verification features into protocol and allow server operators to themselve choose if they want to use it. Where the features were use the email would be considered more secure and users can use that to sort out mail (as many do already with special filters). I believe its time we start working within IETF on new version of SMTP that would have more features and be more secure. I'v tried to point this out several times before on nanog and ietf hoping that someone would take the initiave but as this did not happen, I'm willing to do it now. At this point I'm proposing creation of IETF working group that would look into ways to extend SMTP. I'v created website and mailing list to discuss charter of the proposed working group at http://www.smtpng.org Those who agree with me, please subscribe to the mailing list and lets work on this futher in a kind-of BOF. I'm also looking for two co-chairs for the working group with at least one preferablly having been chair of ietf group before. I'm planning on sending final draft for working group charter in about two weeks time and right now I'm going to be contacting several people who have expressed interest in working on SMTP protocol as well as contacting IETF area director on proceeding with this. -- William Leibzon william@elan.net
On Tue, 20 Aug 2002, william@elan.net wrote:
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.
---------------- As everyone I'm sure have seen on the last "why is spam a problem" and other similar threads on ietf as well as numerous similar threads on other lists and boards, there is a serious need to do something to limit amount of unsolicited email. While the roots maybe social issue I do not see why we can not work on it from technical point of view. In addition to that during last years, I'v seen real need for new features to be added into SMTP, such as ones for callback, delayed transmission, delivery notification,secure communications, etc, etc and there are in fact several drafts available on some issues. As far as anti-spam mechanisms I do not belive we should force some particular method on everyone but rather built several verification features into protocol and allow server operators to themselve choose if they want to use it. Where the features were use the email would be considered more secure and users can use that to sort out mail (as many do already with special filters).
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.
On Tue, 20 Aug 2002, william@elan.net wrote:
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.
---------------- As everyone I'm sure have seen on the last "why is spam a problem" and other similar threads on ietf as well as numerous similar threads on other lists and boards, there is a serious need to do something to limit amount of unsolicited email. While the roots maybe social issue I do not see why we can not work on it from technical point of view. In addition to that during last years, I'v seen real need for new features to be added into SMTP, such as ones for callback, delayed transmission, delivery notification,secure communications, etc, etc and there are in fact several drafts available on some issues. As far as anti-spam mechanisms I do not belive we should force some particular method on everyone but rather built several verification features into protocol and allow server operators to themselve choose if they want to use it. Where the features were use the email would be considered more secure and users can use that to sort out mail (as many do already with special filters).
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.
On Tue, 20 Aug 2002, william@elan.net wrote:
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.... -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net When all else fails, let a = 7. If that doesn't help, then read the manual.
On Wed, Aug 21, 2002 at 10:00:02AM -0400, sjj@pobox.com wrote:
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.
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
On Wed, Aug 21, 2002 at 10:53:19AM -0400, Ron da Silva wrote:
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.
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.
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 -- MegaBIT - open air networking event - http://www.megabit.nl/
At 10:00 AM -0400 2002/08/21, sjj@pobox.com wrote:
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.
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. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On Wed, 21 Aug 2002, Avleen Vig wrote: :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, -- batz
Yo Avleen! On Wed, 21 Aug 2002, batz wrote:
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 --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
On Wed, 21 Aug 2002, Gary E. Miller wrote: :> 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, -- batz
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. On Wed, 21 Aug 2002, batz wrote:
On Wed, 21 Aug 2002, Gary E. Miller wrote:
:> 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,
-- batz
Yo batz! On Wed, 21 Aug 2002, batz wrote:
Actually, I'm bang on. :)
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
Or banging around senselessly... 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 --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
On Wed, 21 Aug 2002, Gary E. Miller wrote: :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. -- batz
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, _________________________ Alan Rowland -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of batz Sent: Wednesday, August 21, 2002 1:45 PM To: Gary E. Miller Cc: nanog@nanog.org Subject: Re: IETF SMTP Working Group Proposal at smtpng.org On Wed, 21 Aug 2002, Gary E. Miller wrote: 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. <snip> -- batz
participants (10)
-
Al Rowland -
Avleen Vig -
batz -
Brad Knowles -
Gary E. Miller -
Peter van Dijk -
Robert Blayzor -
Ron da Silva -
sjj＠pobox.com -
william＠elan.net