Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Filters are static things, that have to be updated, and can't see every case that comes thru. It might be possible to make filters that don't need to be updated that often if you apply AI techniques to recognizing SPAM. For instance, check out this new approach: http://www.paulgraham.com/paulgraham/spam.html --Michael Dillon
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
So what's so bad about forwarding all tcp/25 traffic over that relay and letting that relay decide if the MAIL FROM: is allowed to be relayed? Because I want to send mail through my own SMTP server that speaks STARTTLS and uses certificates that are under my control. Maybe I don't want my email sitting around in your MTA queue for your sysadmins to read. Or maybe you just don't have a clue about how to configure and run an MTA, therefore any mail I send through your enforced gateway gets silently black-holed. And if a client wants to mail from another domain which isn't relayed by it's upstream ISP, he/she could ask it's ISP to do so. Yes this will add an administrative hassle, but doesn't spam imply that also? Do you *honestly* believe what you wrote above? Do you have any experience trying to actually get these sort of changes made? Can you provide statistically valid numbers showing this is a realistic solution in the real world? (Frankly, this proposal is so absurd I have to wonder if you've even dealt with *an* ISP ...) The Internet is a peer-to-peer network, whether you like it or not. --lyndon Lizzie Borden took an axe, And plunged it deep into the VAX; Don't you envy people who Do all the things YOU want to do?
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
From: JC Dill [EMAIL PROTECTED] I guess you haven't read RFC 3098 yet then. http://www.geektools.com/rfc/rfc3098.txt Wow, I missed that. It's really quite good. So good, in fact, that I just sent copies of it out to the 300 MILLION ADDRESSES I have on this CD here... No, seriously, it's good stuff, thank you for pointing it out. Now how do we get legislators, judges, etc. and their staff to read it? (said somewhat rhetorically / thinking out loud, I'll print it nicely and send it to my reps with a cover letter.) -- -Barry Shein Software Tool Die| [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Maybe I don't want my email sitting around in your MTA queue for your sysadmins to read. Given the volumes of mail that pass through these kinds of things, that's not likely to be a problem. More likely to be a problem would be the fact that the mail might sit there for a week before it gets retried a second time. That takes careful system engineering for load, making sure to retry old messages often enough, etc I'm afraid the technology to rapidly sift through large volumes of information to search for specific areas of interest is widely available. It is totally reasonable to not want to send mail through your ISP's mail servers and perhaps directly to a trusted mail distributor over an encrypted link. Of course, you can easily use a port other than 25 for this purpose. The problem comes when the recipient tries to validate your origin address against your secure mail server. DS
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On Tue, 27 Aug 2002 19:40:16 -0700, Jim Hickstein wrote: --On Tuesday, August 27, 2002 6:13 PM -0700 David Schwartz [EMAIL PROTECTED] wrote: I'm afraid the technology to rapidly sift through large volumes of information to search for specific areas of interest is widely available. It is totally reasonable to not want to send mail through your ISP's mail servers and perhaps directly to a trusted mail distributor over an encrypted link. Of course, you can easily use a port other than 25 for this purpose. The problem comes when the recipient tries to validate your origin address against your secure mail server. Your secure mail server (i.e. me) just has to be named in a MAIL-FROM MX record. We do DNS for some of our customers, and can add this trivially; the others control their own zones. Works for me. How would this stop the destination mailservers from rejecting the mail forwarded by the secure server? Remember, the situation is that I don't trust my ISP to see my outbound mail (because that's where warrants are likely to be served or interception hardware would likely be surreptitiously inserted). So I don't want my outbound mail passing through my ISP unencrypted. And I can't just use an email address that is hosted by the secure mail server, because then that's where the warrant will be served or the interest will be focused, and my mail is decrypted there. Nobody inspecting the secure link could necessarily even tell that it was mail that was going over it or where it was actually decrypted -- the next hop could just be a forwarded outputting encrypted data to the ultimate decrypter. I don't think it's unreasonable to simply say that email can't provide this kind of feature unless the recipient and sender are part of the system. And in that case, all the problems go away because the recipient will do the right thing and no intermediate mail servers that don't know what to do are needed. DS
Re: IETF SMTP Working Group Proposal at smtpng.org
Brad Knowles [EMAIL PROTECTED] writes:
At 11:40 AM +0100 2002/08/23, Martin Cooper wrote:
How does it break mailing-lists? If the list sets the envelope sender
to [EMAIL PROTECTED] creating a MAIL-FROM shouldn't
be a problem.
You may be surprised to discover this, but most mailing lists are
not proper mailing lists and are not managed with proper mailing list
management software. Most mailing lists are actually handled as
aliases, and therefore do not modify the envelope sender address.
The only problem I can see is what to do about bounces
(i.e. with a null envelope sender) - guess you could use header From
instead maybe.
Actually, this is one area that the paper addresses.
repudiated(mailfrom, ipsource) = {
(lhs, rhs) = parse_addr(mailfrom);
// handle MAIL FROM: somehow
mxset = get_mx(MAIL-FROM . rhs);
if (mxset == NULL)
return nonrepudiated;
OK - but unconditionally permitting null-return paths means that
spammers can drive a coach and horses through the hole it leaves. :-(
Martin
Re: IETF SMTP Working Group Proposal at smtpng.org
[EMAIL PROTECTED] (Martin Cooper) writes: OK - but unconditionally permitting null-return paths means that spammers can drive a coach and horses through the hole it leaves. :-( that's how the proposal is optional. spammers who lie about their source/return addresses using nonexistent domain names are not the subject of http://www.vix.com/~vixie/mailfrom.txt; rather, i'm trying to address the issue of spammers who lie about _existing_ source/return domain names. -- Paul Vixie
Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Paul Vixie wrote: [EMAIL PROTECTED] (Martin Cooper) writes: OK - but unconditionally permitting null-return paths means that spammers can drive a coach and horses through the hole it leaves. :-( that's how the proposal is optional. spammers who lie about their source/return addresses using nonexistent domain names are not the subject of http://www.vix.com/~vixie/mailfrom.txt; rather, i'm trying to address the issue of spammers who lie about _existing_ source/return domain names. This indeed will fix a lot of problems, and force people to use their mail upstreams mail-relays. ISP's should actually block port 25 outgoing, or even better, reroute/forward it to their own mail relay. This will force people to use their upstreams email address though when sending email outbound. And this isn't always what someone wants. But because especially the big U has many 'users' who simply take a dailup account, spew spam to all kinds of taiwanese, chinese, etc servers those 'users' aren't hard to block out unfortunatly. IMHO, Paul's idea is quite a good one, but all servers will need to be upgraded, and all dns entries installed. Unfortunatly that will take some time, installing a tool like spamassasin/razor etc is much more effective even though those tools won't stop spammers. At least it will help a bit against one of the bigger internet problems. Greets, Jeroen
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On Mon, 26 Aug 2002 21:12:40 +0200, Jeroen Massar [EMAIL PROTECTED] said: IMHO, Paul's idea is quite a good one, but all servers will need to be upgraded, and all dns entries installed. Given the number of providers who seem to think ingress and/or rfc1918 filtering shouldn't be done, what makes you think that all servers will be upgraded to support THIS proposal? (If you don't want to re-start the RFC1918 war, feel free to substitute ANY OTHER thing that most people think is a Good Thing, but we've seen some sizable minority not deploy for reasons they consider perfectly valid). -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg04746/pgp0.pgp Description: PGP signature
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
David Van Duzer [EMAIL PROTECTED] writes: [...] The presumably appropriate topic for discussion on this list is why a system such as this would be a problem for network operators who choose not to implement such a callback feature. So far the only objection I've seen is It won't make any difference and that seems to be a flimsy argument. Please correct me if I'm missing something. The problems with it are clearly laid out within the document itself: 3.2. Transport-level e-mail forwarding must be more explicit under this specification. For example if [EMAIL PROTECTED]'s account has a .forward file pointing at [EMAIL PROTECTED], then e-mail sent to the former will be received by the latter, but with no change in the payload of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be configured to implicitly add NETBSD's outbound mail relays as multistage inbound relays. This could scale poorly and may add pressure toward transport remailing (with a new envelope) rather than transport forwarding (reusing the old envelope.) No real solution is proposed for the above; if you remail with a new envelope, how does the original sender get the bounce? And if you don't, the proposal isn't workable without refusing to support forwarding at all, which would just encourage mail service providers to enforce an annoying restriction. 3.3. Roaming hosts such as laptop computers will probably not be able to be listed in the MAIL-FROM MX RR for their return address domain name, and may be forced to use an intermediary for outbound e-mail. STARTTLS or an SSL/SSH tunnel back home may become a necessary first hop for mobile e-mail. The problem that this deals with is the user who needs to dial in to AOL and send mail from their corporate account. The proposed solution is to tunnel mail through the corporate server, by proving your right to relay via SMTP AUTH or else via a VPN. To make this work well requires support for SMTP AUTH and probably STARTTLS (unless the company implementing this proposal wants cleartext passwords flying over AOL's network) for all domains which want to support Paul's proposal. This isn't necessarily all that unreasonable, but should be spelled out more clearly, and makes implementation much more involved. ScottG.
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
David Van Duzer [EMAIL PROTECTED] writes: On Mon, 2002-08-26 at 15:47, Scott Gifford wrote: The problem that this deals with is the user who needs to dial in to AOL and send mail from their corporate account. The proposed solution is to tunnel mail through the corporate server, by proving your right to relay via SMTP AUTH or else via a VPN. To make this work well requires support for SMTP AUTH and probably STARTTLS (unless the company implementing this proposal wants cleartext passwords flying over AOL's network) for all domains which want to support Paul's proposal. This isn't necessarily all that unreasonable, but should be spelled out more clearly, and makes implementation much more involved. Precisely. It's only an issue for those who implement the feature. Another thought that came to mind was a sort of hybrid between this and the central registry of trusted servers. If a large ISP, say AOL, implements this, and I operate the mailserver with users who send (relay through me) mail with a from address of their (legitimate) AOL account, I'm choosing to ignore the feature entirely, but it's still affecting me and my users. If a large ISP, say AOL, implements this, and I'm an end-user trying to send mail with a from address at my (legitimate) AOL account, I'm choosing to ignore the feature entirely, but it's still affecting me. I know this isn't what you're looking for, but individual domains aren't so isolated that you can implement this sort of thing without zero effect on other mailservers. You really have to solve the whole problem before it becomes usable at all. I'm not saying it's an unsolvable problem, just that these two issues need to be better addressed before it's a usable suggestion. ScottG.
Re: IETF SMTP Working Group Proposal at smtpng.org
At 3:26 PM +0100 2002/08/26, Martin Cooper wrote: return nonrepudiated; OK - but unconditionally permitting null-return paths means that spammers can drive a coach and horses through the hole it leaves. :-( IIRC, the RFCs require that you accept mail from the null envelope sender. Yes, it does open a hole, but spammers have avoided using this address for a long time, for reasons I still don't understand. -- Brad Knowles, [EMAIL PROTECTED] 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(+++)
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Randy Bush wrote: ISP's should actually block port 25 outgoing, or even better, reroute/forward it to their own mail relay. Agreed. why not do it to port 80 as well? what the hell, why not do it to all ports? who the hell needs an internet anyway, let's all have a telco walled garden. string of expletives can we get back to operating the internet, not killing it? another, even longer, string of expletives Nice rant Randy, but if you even ever wondered why the wording Mail Relay exists you might see that if an ISP simply forwards all outgoing tcp port 25 traffic to one of their relays and protects that from weird spam addresses as a source and only allowing through configured addressess it would save you, me and the rest a load of crap which maybe could kill the internet... We didn't invent stuff like SMTP, POP3, IMAP and stuff to be run on EVERY single node on the internet. Indeed it limits your clients, just like a NAT does, just like firewalling does, but it also saves a load of problems. And maybe your view is operating the internet but some people have a too busy spam/abuse mailbox to be able to do usefull stuff like tracing ddosses, which is yet another thing people should do but aren't doing: egress filtering. If (and if) everybody did that, we wouldn't be seeing spoofed addresses, rfc1918's and other stuff on the internet either now would we? So pointing these facts out *HAS* something to do with operating the internet. hint http://as112.net/ /hint Greets, Jeroen
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Brad Knowles [EMAIL PROTECTED] writes: [...] Moreover, even if all servers on the Internet were secured in this manner and there were no open relays, it would also require perfect reverse DNS because the MXes are listed by name and not IP address -- that's assuming you do a reverse lookup on the IP address and require that the returned name is on the list. The proposal suggests that you get all of the A records for all of the accepted names, then make sure that one of the A records matches the address that the connection came from. See sec. 2.3. Even if it did require good reverse DNS, that would only be needed for domains that chose to implement this, and only for addresses that are allowed to send mail from that domain. ScottG.
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On Tue, 27 Aug 2002 00:59:49 +0200 Jeroen Massar [EMAIL PROTECTED] wrote: Nice rant Randy, but if you even ever wondered why the wording Mail Relay exists you might see that if an ISP simply forwards all outgoing tcp port 25 traffic to one of their relays and protects that from weird spam The point is that 25 is just a number. You'll eventually be blocking all numbers sooner or later (and re-inventing dumb terminals). John
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On August 27, 2002 at 00:59 [EMAIL PROTECTED] (Jeroen Massar) wrote: We didn't invent stuff like SMTP, POP3, IMAP and stuff to be run on EVERY single node on the internet. Actually, I think we did. Unfortunately it turned out to be a really, really, bad decision. -- -Barry Shein Software Tool Die| [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On 03:07 PM 8/26/02, Barry Shein wrote: Let me throw out the following to show how blind the technical community has been: There is no RFC or other public standards document which even attempts to define spam or explain, in a careful and professional manner, why it is a bad thing. (before you say the obvious, that's not what RFCs are for, read, e.g., RFC 2964) I guess you haven't read RFC 3098 yet then. http://www.geektools.com/rfc/rfc3098.txt How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $ MAKE ENEMIES FAST! $ Table of Contents 1. Introduction .. 2 2. Image and Perception of the Advertiser. 4 3. Collateral Damage . 5 4. Caveat Mercator ... 5 5. Targeting the Audience 7 6. Reaching the audience . 8 A. Dedicated website or web page 8 B. Shared Advertising website . 9 C. Netnews and E-Mailing list group postings 10 D. Compiled E-Mail Lists 11 7. Opt-In Mailing Lists .. 12 A. Privacy 13 B. Integrity .. 13 C. Protection . 16 8. Irresponsible Behavior 16 9. Responsible Behavior .. 17 10. Security Considerations ... 19 Appendices 20 A.1 The classic Pyramid 20 A.2 What about Ponzi? .. 22 A.3 So all multi-levels are evil? .. 22 B.1 Why Web Privacy? ... 23
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On Tue, 27 Aug 2002 01:54:39 +0200 Jeroen Massar [EMAIL PROTECTED] wrote: SMTP is a protocol which is based on relaying messages from one mailserver to another. An endnode (especially workstations) don't need to run SMTP. I'm not sure how to truly disable an SMTP server from running on an end host. You can block or force forward port 25, but that is just a number. Be prepared to start doing that for all ports, then protocols, then IP addresses, then protocols again. Furthermore, a forced relay, while perhaps helping to solve the immediate spam problem is most definitely interfering on other things with potentially harmful long term effects. Two of those are end-to-end transparency and the fixing of the real problem. You may not care about either of those, but I would argue they shouldn't be dismissed without very serious thought. So what's so bad about forwarding all tcp/25 traffic over that relay and letting that relay decide if the MAIL FROM: is allowed to be relayed? And if a client wants to mail from another domain which isn't There are some potential problems. Don't bother answering them, I'm sure they can be disputed, but I'm also sure there are plenty of other examples an SMTP expert could think of: What if there is a new SMTP specification that doesn't work through the forced relay? What about simply not trusting a relay to do the right thing or for fear of a forced relay adding/changing/snooping/delaying the traffic? What about when SMTP starts going over something other than TCP port 25? The whole problem is yet again that a small amount of people (this time spammers) make a whole lot of problems for a lot of people (we). Maybe some different thinking is called for. Here are some other suggestions, take them or leave them. They aren't perfect either (don't try and answer these either, I'm sure they can be disputed :-): Force forward by default, but allow anyone who wants to use TCP port 25 the ability to do so. They must sign an non-abuse agreement or whatever. Then they get their host/link put into the TCP port 25 open path. Do some rate-limiting by default. Perhaps coupled with the above? Start offering spam blocking and filtering services for end users. Get better at monitoring and incident response. This will pay dividends for lots of other areas as well. ...and finally to quote Randy, send code. :-) John
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Force forward by default, but allow anyone who wants to use TCP port 25 the ability to do so. They must sign an non-abuse agreement or whatever. Then they get their host/link put into the TCP port 25 open path. Every ISP I have ever worked for and every ISP I have ever used has eventually been convinced by me to come around to this policy. Do whatever you want by default, but let trusted/clueful people opt out of it and just get their IP datagrams from point A to point B. I personally wouldn't sign an agreement with an ISP that allowed them to molest my traffic in this manner unless it allowed me to opt out of it. I've seen the headaches such assumptions about what everybody else needs/wants to do can cause. DS
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
On Tue, Aug 27, 2002 at 12:14:46PM +1000, Martin wrote: but surely an MTA derives it's usefulness by running on port 25. i don't remember reading about where in the DNS MX RR you could specify what port the MTA would be listening on... Surely your not a spammer looking for tips are you? :-) John
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Martin Sent: August 26, 2002 10:15 PM To: [EMAIL PROTECTED] Subject: Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org) but surely an MTA derives it's usefulness by running on port 25. i don't remember reading about where in the DNS MX RR you could specify what port the MTA would be listening on... Well, it must specify it somewhere, since at least a couple of times a week we have our users ask how to stick a port number in an MX record. :) Where they got this idea is beyond me (unfortunately), but it's quite a common question... Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
$author = John Kristoff ; On Tue, Aug 27, 2002 at 12:14:46PM +1000, Martin wrote: but surely an MTA derives it's usefulness by running on port 25. i don't remember reading about where in the DNS MX RR you could specify what port the MTA would be listening on... Surely your not a spammer looking for tips are you? :-) hardly. just someone who has tried blocking traffic to dialup pools with DST port 25 and forced relay on all outbound traffic with DST port 25. it worked... for some values of worked. as most would know we broke smtp-auth for a small handful of people that were trying to use it. as joe pointed out to me privately RFC 2782 specifies SRV RRs which could be used to point an MX.SRV at a port other then 25. anyone got any examples of MTAs or MUAs that implement said RFC? marty -- My Everest is not in Nepal, She's sleeping in the bedroom second right down the hall. Ed Hiliary couldn't crack this nut, He'd be hiding in the lounge room with the rest of us. My Everest - Lazy Susan
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
as joe pointed out to me privately RFC 2782 specifies SRV RRs which could be used to point an MX.SRV at a port other then 25. anyone got any examples of MTAs or MUAs that implement said RFC? actually it would be _smtp._tcp.$DOMAIN but it's not in use for e-mail. or web, even though that's the example that appears in the rfc. the only users i'm aware of are Microsoft and Apple for their respective service discovery systems, and MIT Kerberos iff your domain name and your realm name are the same. -- Paul Vixie
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
Barry, I have a wrench :) Everything looks like a nut to me. But in all seriousness. I have to agree with Barry's statement here. Spam is very much a social, political, ethical, and financial issue. Filters are static things, that have to be updated, and can't see every case that comes thru. Even the Habeas idea, while novel and interesting, requires people to do quasi technical things. The average user isn't going to do those things. Much spam comes from relay servers outside of north america, but is targetted towards us yanks. Until we make the social or financial impact real enough to stop the spammers, they will continue. Enough people respond to spam, that its worth it to them to sell there warez via this method. I think we geeks would spend better time, trying to help adjust the social and financial changes, instead of smashing on the the bolt with the hammer... A stab at defining SPAM: The sending of email to a person, where there is a financial gain (directly or indirectly) to the sender, and where the receiver did not expressly request such email. Please DO NOT reply to my definition on the NANOG list, else the NANOG police will get you. john brown speaking for me On Mon, Aug 26, 2002 at 06:07:46PM -0400, Barry Shein wrote: Point of Information: Every single purely technical approach to stopping spam has been a complete loser. I understand the old adage that when all you have is a hammer the whole world looks like a nail. And that all many people on this list have is a technical hammer, some ability to hack around with cisco access lists or similar, so they tend to hold out hope that some new access list formula might be the one that saves the day (or similar, don't quibble the example!) But spam is as much a socio-legal problem as a technical one which is why, I'd claim, it's been so completely resistant to all purely technical approaches thus far. What we need are technical solutions which help with concomitant socio-legal solutions. If you haven't noticed, the spammers are winning completely, the waters are rising rapidly. More and more legitimate-sounding companies and products are spamming, and by and large the public perception in the non-anointed* business community are coming to the conclusion that they receive all this spam so it must be a legitimate form of advertising. Let me throw out the following to show how blind the technical community has been: There is no RFC or other public standards document which even attempts to define spam or explain, in a careful and professional manner, why it is a bad thing. (before you say the obvious, that's not what RFCs are for, read, e.g., RFC 2964) However, we expect lawmakers to recognize and define the problem and get it right when the engineers who understand the technology and problem, in nearly a decade of whining, can't even be bothered to provide them with robust definitions of what it is the whining is about. Food for thought, that's all. But, personally, I'm hesitant to spend my time trying to study the merits of yet another anti-spam miracle cure, even if it seems at first glance (like so many before) that it might foil some particular flavor of spam which has been prevalent in the past. Now, after sitting through this extended, multi-day discussion of spam someone can send me the standard discussion of spam is not a subject for nanog! because I'm not a member of the amen crowd. * non-anointed: not a member of the technical community hence indoctrinated into a particular ethical view of what's right and wrong on the net. -- -Barry Shein Software Tool Die| [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
RE: IETF SMTP Working Group Proposal at smtpng.org
You're assuming that these people aren't permanently online. I expect most of our users (I hesitate to call them customers, simply because a lot of them haven't paid anything) are using 24/7 type connections. Certainly, running your own mail server and being online two hours a day is foolish. But just the opposite, you're assuming they ARE permanently online. Even if it was a 50/50 mix, that's still quite a few. that met your static IP standard of approval, and yet was (unless he wanted to pay extra) only online 1/6th of the time. Now, most of our users may not have static IPs, but they're most likely online 24/7 or close enough. Which of the two uses more resources on your servers? I'm willing to bet the static IP dialup person will, so there goes your argument. The case you state is the norm. Most dialup people who want to run mail servers use backup MX's supplied by their ISP's. If they run a mail server without proper DNS and a static address, they are no better than the untracked rogue spam mail servers that appear from throw away accounts. Running mail servers on non-permanent dialup connections is foolish, I'll grant you that any day, but that wasn't the point you were making. Your point was that mail servers on dynamic IPs (and you never answered my question on how you define dynamic) are bad, no matter the circumstances surrounding them, and that's just plain not true. You claim that you have 10,000+ users using dynamic DNS to run SMTP services. That being said, every one of them violate the host requirements for SMTP outlined in RFC1123. Sections 5.3.1.2, 5.3.5, 6.1.1 (keyword MUST). Oh, and BTW, you're not benefiting our users by having your servers queue mail for our users. You're benefitting YOUR customers who presumably want to be able to send mail to our users, and who expect your servers to queue mail. Right, but your promoting your users to run SMTP servers that violate RFC. While you claim that many of them are online all the time, you can't say for sure that they are. That and the fact that by the RFC, they violate the DNS requirements outlined. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Unix is simple, but it takes a genius to understand the simplicity. - Dennis Ritchie
RE: IETF SMTP Working Group Proposal at smtpng.org
That's all well and good until said ISP's upstream servers go slow/break/take an age to deliver a message you can deliver from your own host immediately. [It also doesn't scale particularly well] I don't believe this at all. By going with a whitelist type system that can cache or do cached lookups locally, it wouldn't take any more time to deliver mail than it does today. In fact, it would probably be faster since mail systems would be a lot cleaner not dealing with all the crap that's out there now. I'm not saying that people can't run their own mail servers, certainlly your ISP can register your mail server for you, in their IP space, so that it can be tracked. I thought I was buying *Internet* access anyway... shouldn't that mean I have the right to talk which hosts I want on which port I want? Sure it does. But if the remote host says you need to ID yourself as a trusted source, and they require it, it's not just your right to connect to anyone you want, but the right of the remote server to require that of you. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] A computer program does what you tell it to do, not what you want it to do.
Re: IETF SMTP Working Group Proposal at smtpng.org
In my case it would be because my isp's has several of its own smtp server on many black hole lists for bring open relays. Luckily i have another domain i have access to but if i had to i would run a local SMTP server if i had no other opiton. May God Bless you and everything you touch. My foundation verse: Isiah 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. - Original Message - From: Robert Blayzor [EMAIL PROTECTED] To: 'Jeff Shultz' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, August 21, 2002 3:54 PM Subject: RE: IETF SMTP Working Group Proposal at smtpng.org I'm not a company, I'm Joe Blow private citizen - do you expect me to pay $100 just to sign up with AOL? If you are Joe Blow private citizen, why would you need to run a mail server? Would you not use your ISP's, at least as a smart relay? If running a mail server is that important to you, just like registering a domain, you'll pay it. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Profanity is the one language all programmers know best.
Re: IETF SMTP Working Group Proposal at smtpng.org
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 2 bounce messages. Spam? Yeh, but it would also help with things like KLEZ.
RE: IETF SMTP Working Group Proposal at smtpng.org
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 2 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 [EMAIL PROTECTED] When all else fails, let a = 7. If that doesn't help, then read the manual.
Re: IETF SMTP Working Group Proposal at smtpng.org
On Wed, Aug 21, 2002 at 10:00:02AM -0400, [EMAIL PROTECTED] 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 2 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
Re: IETF SMTP Working Group Proposal at smtpng.org
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 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
Re: IETF SMTP Working Group Proposal at smtpng.org
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
RE: IETF SMTP Working Group Proposal at smtpng.org
Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Treat them sort of like SSL certs now. Charge an annual registrar fee per company, not per server. (Something like $100 a year) The more they have to go out of their way to get their spam server online, the more they would be deterred to do so. They're only going to want to change so many ISP's, go through SWIP and then change their legal name for the registrar so many times. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Life would be much easier if I had the source code.
RE: IETF SMTP Working Group Proposal at smtpng.org
I really like this. A sort of IRR for mail servers. Maybe when registered it could even check if the server was an open relay, and not allow those servers to be registered until properly configured. Any thoughts? Righto, that would all be part of a registration process. As well as things like forward and reverse DNS matching for the mail server, etc. But whos to say that once they pass the test they just open up things. As well as the registrar, there would have to be a complaint and investigation department. But going that far legally tends to destroy good ideas. The most important things is the legal handling of exceptions and complaints and the actual steps on getting someone shut off. We all know how people are sue happy... -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
Re: IETF SMTP Working Group Proposal at smtpng.org
I'd seen back in the mid 1990s a user that got banned from all the isps on his island (or fairly close to it) due to abuse of services. obviously when you have a set of only 3-4 isps to choose from this makes it a lot easier to keep the guy from doing anything evil. but these days everyone that can negotiate a bulk-dial agreement with someone and run a radius server can sign up users and make the abuse a bit harder to track ... i do think some sort of smtp-callback would be nice/useful for validation of e-mail addresses. it'll make it so the bounces go to someplace at least instead of Postmaster. - jared On Wed, Aug 21, 2002 at 03:29:46PM -0400, Robert Blayzor wrote: Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Treat them sort of like SSL certs now. Charge an annual registrar fee per company, not per server. (Something like $100 a year) The more they have to go out of their way to get their spam server online, the more they would be deterred to do so. They're only going to want to change so many ISP's, go through SWIP and then change their legal name for the registrar so many times. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Life would be much easier if I had the source code. -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: IETF SMTP Working Group Proposal at smtpng.org
I'm not a company, I'm Joe Blow private citizen - do you expect me to pay $100 just to sign up with AOL? If you are Joe Blow private citizen, why would you need to run a mail server? Would you not use your ISP's, at least as a smart relay? If running a mail server is that important to you, just like registering a domain, you'll pay it. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Profanity is the one language all programmers know best.
RE: IETF SMTP Working Group Proposal at smtpng.org
What about individuals that run their own mail servers? (E.G. me).? On Wed, 2002-08-21 at 14:28, Derek Samford wrote: I really like this. A sort of IRR for mail servers. Maybe when registered it could even check if the server was an open relay, and not allow those servers to be registered until properly configured. Any thoughts? Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Segal Sent: Wednesday, August 21, 2002 3:12 PM To: 'Robert Blayzor'; [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org 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 Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
RE: IETF SMTP Working Group Proposal at smtpng.org
What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
RE: IETF SMTP Working Group Proposal at smtpng.org
On Wed, 2002-08-21 at 14:50, Robert Blayzor wrote: What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. Actually, it's swip'ed to me (I work for said ISP), but I also run a SMTP server on my laptop which bounces usually between two addresses (one at home, one at work), and I suppose that the work address (NOT swip'ed) would have a problem under this proposal. I DO understand the reasoning, but it is a **BIG** culture change, and would take a year or two or more to implement network wide. I think $100/year is STEEP, if it is PER SERVER, but per COMPANY/INDIVIDUAL it **might** be acceptable. (I have 3 boxes + the laptop that do SMTP regularly). Ideas given this? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: IETF SMTP Working Group Proposal at smtpng.org
If there were some sort of smtp callback pki, as long as you controled your dns and server you could do something useful on that front. here's an example i gave last night in a private e-mail: -- snip -- There is an important need to perform callback but allow for the ability to protect information from possible spammers for harvesting/verificiation. eg: 220 welcome, but no spam ehlo spammer 250-callback-secure 250 help mail from:[EMAIL PROTECTED] callback=spammer.example.com 250 ok rcpt to:[EMAIL PROTECTED] 451 try again, pending callback vs: 220 welcome, but no spam ehlo spammer 250-callback-secure 250 help mail from:[EMAIL PROTECTED] callback=spammer.example.com 250 ok rcpt to:[EMAIL PROTECTED] 550 no such user here there's also the need to do some sort of pki to allow callback to be secure. eg: the dns record for nether.net should have some public-key in it and then some other stuff like possibly mail from:[EMAIL PROTECTED] callback=validate.hotmail.com;key=alkjsdfj then pass the 'key' through the public-key availble via dns to provide back an authentication system to allow for more secure callback. but this can still be abused depending... just some thoughts, -- snip -- - jared On Wed, Aug 21, 2002 at 02:38:31PM -0500, Larry Rosenman wrote: What about individuals that run their own mail servers? (E.G. me).? On Wed, 2002-08-21 at 14:28, Derek Samford wrote: I really like this. A sort of IRR for mail servers. Maybe when registered it could even check if the server was an open relay, and not allow those servers to be registered until properly configured. Any thoughts? Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Segal Sent: Wednesday, August 21, 2002 3:12 PM To: 'Robert Blayzor'; [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org 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 Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: IETF SMTP Working Group Proposal at smtpng.org
On Wed, 21 Aug 2002 15:51:36 EDT, Jared Mauch said: i do think some sort of smtp-callback would be nice/useful for validation of e-mail addresses. it'll make it so the bounces go to someplace at least instead of Postmaster. The fact that you can call back in no way means that bounces won't double-bounce into the postmaster mailbox. I'm sure that yahoo.com would buy into a callback scheme, but it wouldn;t have done squat for this double-bounce: - Transcript of session follows - ... while talking to mx1.mail.yahoo.com.: DATA 554 delivery error: dd Sorry, your message to [EMAIL PROTECTED] cannot be delivered. This account is over quota. - mta461.mail.yahoo.com 554 5.0.0 Service unavailable (OK, so THIS double-bounce was a W32/Klez-H generated one, but I get enough of the same thing for spam with a Yahoo return adress). -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg04621/pgp0.pgp Description: PGP signature
Re: IETF SMTP Working Group Proposal at smtpng.org
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.
Re: IETF SMTP Working Group Proposal at smtpng.org
I agree with getting personal mail servers registered, as far as paying $100 for a mail server registration (as mentioned in previous messages)...that's no good. As a user with a personal mail server, it is bad enough to have pay for connectivity and a domain name. Having to pay for the privilege of running a mail server is too much. Robert Blayzor wrote: What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
RE: IETF SMTP Working Group Proposal at smtpng.org
Then the question becomes, Is running your own mail server worth some registration cost? Very similar to the I want my own special part of the Internet (web server). Okay, pay your $70 for two years (or whatever). BTW, just curious, who announces your MX records? Best regards, _ Alan Rowland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Larry Rosenman Sent: Wednesday, August 21, 2002 12:39 PM To: Derek Samford Cc: 'Mark Segal'; 'Robert Blayzor'; [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org What about individuals that run their own mail servers? (E.G. me).? On Wed, 2002-08-21 at 14:28, Derek Samford wrote: I really like this. A sort of IRR for mail servers. Maybe when registered it could even check if the server was an open relay, and not allow those servers to be registered until properly configured. Any thoughts? Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mark Segal Sent: Wednesday, August 21, 2002 3:12 PM To: 'Robert Blayzor'; [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org 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 Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: IETF SMTP Working Group Proposal at smtpng.org
I'm not saying it's a solution for all problems but that lets-say-for-example, AOL probally gets a lot of mail with forged yahoo,hotmail, btamail.net.cn or smiliar MAIL FROM:'s Lets say AOL, hotmail, yahoo all today had a way they could say we would like to cooperate in validating source addresses as at least somewhat more valid than today and had a mechanisim to do this with a patch to sendmail/qmail/postfix/zmailer. This would allow for while a few extra commands and bytes per smtp-transaction the ability to authenticate such data. You could also then start keeping statistics and rate-limit the callback mechanisim. AOL (and i'm sure others) have done so, you want to bulk-mail aol users, sign here. Including this ability to increase customer satisfaction is in all ISPS interest today. - jared http://story.news.yahoo.com/news?tmpl=storyu=/ap/20020820/ap_wo_en_po/fea_us_spammed_war_of_attrition_1 On Wed, Aug 21, 2002 at 04:17:53PM -0400, [EMAIL PROTECTED] wrote: On Wed, 21 Aug 2002 15:51:36 EDT, Jared Mauch said: i do think some sort of smtp-callback would be nice/useful for validation of e-mail addresses. it'll make it so the bounces go to someplace at least instead of Postmaster. The fact that you can call back in no way means that bounces won't double-bounce into the postmaster mailbox. I'm sure that yahoo.com would buy into a callback scheme, but it wouldn;t have done squat for this double-bounce: - Transcript of session follows - ... while talking to mx1.mail.yahoo.com.: DATA 554 delivery error: dd Sorry, your message to [EMAIL PROTECTED] cannot be delivered. This account is over quota. - mta461.mail.yahoo.com 554 5.0.0 Service unavailable (OK, so THIS double-bounce was a W32/Klez-H generated one, but I get enough of the same thing for spam with a Yahoo return adress). -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: IETF SMTP Working Group Proposal at smtpng.org
Title: RE: IETF SMTP Working Group Proposal at smtpng.org -Original Message- From: Robert Blayzor [mailto:[EMAIL PROTECTED]] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org I'm not a company, I'm Joe Blow private citizen - do you expect me to pay $100 just to sign up with AOL? If you are Joe Blow private citizen, why would you need to run a mail server? Would you not use your ISP's, at least as a smart relay? Because he doesn't want to. He already provides POP3/SMTP services to me under his own domain name, and why should he change his servers to permit me to send mail as if from another domain where I do have a real mail account? I hate the free stuff (no POP3/SMTP unless you pay), I already have my own on another domain (for which I pay), and I don't want his (because I don't want to keep changing email addresses everytime they get bought out/sold). In short, because if I have to depend on my ISP for my convenience, it won't get done, unless it's done their way. I use it for outbound only, I pop my mail from my other provider... James H. Smith II Speaking for myself...
[Fwd: Re: IETF SMTP Working Group Proposal at smtpng.org]
I agree with getting personal mail servers registered, as far as paying $100 for a mail server registration (as mentioned in previous messages)...that's no good. As a user with a personal mail server, it is bad enough to have pay for connectivity and a domain name. Having to pay for the privilege of running a mail server is too much. Robert Blayzor wrote: What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
RE: IETF SMTP Working Group Proposal at smtpng.org
Yea. Good luck getting a DSL provider to swip an IP to you or to be willing to register an IP for you. On Wed, 21 Aug 2002, Robert Blayzor wrote: What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
RE: IETF SMTP Working Group Proposal at smtpng.org
Yo Robert! How about moving this discussion to a more appropriate list? Nanog is not the place to discuss spam and we are re-inventing the wheel, badly, on nanog. Half the spam I get is from throw away AOL, netzero, earthlink, etc. accounts. Spend $10 for a new ISP account, sent 10,000 emails with MY return address which is valid and on whitelists. Do it on a long weekend and get 30k out before you get stopped. If the spammers can not run their own name servers then they will just use someone elses. Last I checked there where over 6,000 ISPs in the country. Cancel them one place and they just go to another. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Wed, 21 Aug 2002, Robert Blayzor wrote: Treat them sort of like SSL certs now. Charge an annual registrar fee per company, not per server. (Something like $100 a year) The more they have to go out of their way to get their spam server online, the more they would be deterred to do so. They're only going to want to change so many ISP's, go through SWIP and then change their legal name for the registrar so many times.
Re: IETF SMTP Working Group Proposal at smtpng.org
Treat them sort of like SSL certs now. Charge an annual registrar fee per company, not per server. (Something like $100 a year) The more they have to go out of their way to get their spam server online, the more they would be deterred to do so. They're only going to want to change so many ISP's, go through SWIP and then change their legal name for the registrar so many times. Why don´t you just start using SSL certs with SMTP ? The protocol is there, ways to get certificates are there, no need to start smoothing a square piece to make a new wheel. Pete
RE: IETF SMTP Working Group Proposal at smtpng.org
I agree with getting personal mail servers registered, as far as paying $100 for a mail server registration (as mentioned in previous messages)...that's no good. As a user with a personal mail server, it is bad enough to have pay for connectivity and a domain name. Having to pay for the privilege of running a mail server is too much. Well owners of the IP space that have accounts in the registrar pay the $100 per year, per account, not server. So if you have a personal mail server, but the space is not SWIP'd to you, you'd get your ISP to authorize it. Whether they charge you extra for it would be up to them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] I haven't lost my mind; it's backed up on tape somewhere.
RE: IETF SMTP Working Group Proposal at smtpng.org
but these days everyone that can negotiate a bulk-dial agreement with someone and run a radius server can sign up users and make the abuse a bit harder to track ... Well yes and no. Using a regisrar, people on dialups who want to run mail servers simply cannot do it. The IP space would be owned by the ISP, and the ISP would have to do the mail server registrations for the customer, or SWIP a block (on a dialup, oh boy) and let the customer do the registration themselves. (which would be a legal check as well as technical check). I guess it makes it a lot harder for those customers that setup not online all the time mail servers, and that rely on things like ETRN. But mail servers need static IP's, and network operators must know about those customers that need static addresses and if there is a mail server on the end of it. That's a major problem now, mail servers getting online are not tracked. i do think some sort of smtp-callback would be nice/useful for validation of e-mail addresses. it'll make it so the bounces go to someplace at least instead of Postmaster. I'm not disputing this at all, but I believe it would take a lot more work to get something set, agreed upon, standardized / RFC'd, the mail server software, etc., than it would to make a registrar type system. Most mail servers pretty much support this already with RBL functions, which would probably be moderately changed. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Never trust a program unless you have the source.
Re: IETF SMTP Working Group Proposal at smtpng.org
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
RE: IETF SMTP Working Group Proposal at smtpng.org
If you are Joe Blow private citizen, why would you need to run a mail server? the internet is a peer network. this is not pay to be screwed. randy
RE: IETF SMTP Working Group Proposal at smtpng.org
Actually, it's swip'ed to me (I work for said ISP), but I also run a SMTP server on my laptop which bounces usually between two addresses (one at home, one at work), and I suppose that the work address (NOT swip'ed) would have a problem under this proposal. No, it's not a problem. Your ISP is registered with the registrar. They can simply list your IP you've been assigned as a valid mail server. They then accept responsibility for your mail server registration. I DO understand the reasoning, but it is a **BIG** culture change, and would take a year or two or more to implement network wide. That I would agree. No disputing that. But at the same time, everyone agrees that SOMETHING needs to be done. Regardless of what is done, it will be a big change. I think $100/year is STEEP, if it is PER SERVER, but per COMPANY/INDIVIDUAL it **might** be acceptable. No, per company. Not per server. Per server would be a bit extreme. Especially for those that have dozens of legit mail servers. As a service provider you pay $100 a year for your account, in which you can manage adding and removing mail server IP addresses from the list. But only IP's that are in your SWIP'd space. Ideas given this? Above. Thanks for your input. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [ OK ]
RE: IETF SMTP Working Group Proposal at smtpng.org
I know the DSL provider doesn't for the /29 serving my mail server. It's under the general announcement for the ISP. I can't even get them to personalize reverse DNS without knowing someone that runs the DNS servers. On 21 Aug 2002, Larry Rosenman wrote: On Wed, 2002-08-21 at 15:25, Robert A. Hayden wrote: Yea. Good luck getting a DSL provider to swip an IP to you or to be willing to register an IP for you. If you have a /29 or shorter they **HAVE** to swip it. Else they can't get numbers from ARIN. So, that point is moot.
Re: IETF SMTP Working Group Proposal at smtpng.org
Your quite wrong. With email we do in fact know phone for the calling party - its their FROM address and for callback we can specify if we trust or do not trust the other party to provide some different domain, so they may not be given a change to specify where to callback to. As example If they are trying to send email from [EMAIL PROTECTED] the callback would have to go to somedomain.com mail server and the callback must use the authorization code given during initial mail call. The callback can also be authenticated with TLS giving even more security that somedomain.com is a real operation. This will prevent 99% of spammers just there. And as pointed an NANOG and other places other ways to verify that server is ok can also be used such as having whitelist for mailservers, using AUTH, etc. What is missing is glue in the protocol to allow servers to decide on level of trust as well as actual definitions for all these verification mechanisms. On Wed, 21 Aug 2002 15:55:41 EDT, Jared Mauch said: There is an important need to perform callback but allow for the ability to protect information from possible spammers for harvesting/verificiation. eg: 220 welcome, but no spam ehlo spammer 250-callback-secure 250 help mail from:[EMAIL PROTECTED] callback=spammer.example.com 250 ok rcpt to:[EMAIL PROTECTED] 451 try again, pending callback OK.. So now *you* have to callback and pick up the spammer's mail. What did that gain you? there's also the need to do some sort of pki to allow callback to be secure. eg: the dns record for nether.net should have some public-key in it and then some other stuff like possibly Much easier would be to use the existing STARTLS stuff and use the cert presented to decide if you want to accept the mail. mail from:[EMAIL PROTECTED] callback=validate.hotmail.com;key=alkjsdfj then pass the 'key' through the public-key availble via dns to provide back an authentication system to allow for more secure callback. Note that the concept of a callback doesn't mean the same things on an IP network as it did on a POTS network. Not that callback on the POTS network was ever as secure as people thought, anyhow... but this can still be abused depending... The only callback systems that ever came anywhere near working on the POTS network were ones that you told the callback this is Fred. Call me back at the home number you've been configured with, and it called you at Fred's previously-configured phone number. Having it say 'This is Fred, call me back at 127.0.4.5' doesnt do anything for security if you're just going to call 127.0.4.5.
RE: IETF SMTP Working Group Proposal at smtpng.org
Yo Robert! On Wed, 21 Aug 2002, Robert Blayzor wrote: But mail servers need static IP's, and network operators must know about those customers that need static addresses and if there is a mail server on the end of it. Uh, no. I have seen spammers use dynamic DNS to use throw away dial-ups accounts for incoming main service. How about moving this to an approriate forum where people really know spam and mail? Nanog is for moving packets. Nanog does not usually care what is in the packet unless it is a routing protocol. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
Re: IETF SMTP Working Group Proposal at smtpng.org
Larry Rosenman wrote: [...] I think $100/year is STEEP, if it is PER SERVER, but per COMPANY/INDIVIDUAL it **might** be acceptable. (I have 3 boxes + the laptop that do SMTP regularly). Ideas given this? Relay through your upstream (hierarchical approach)? i.e. Register your server(s) with your provider, who is presumably trusted (registered with the global system). A bit of an aside: I recall ATT Canada blocked all SMTP from exiting their network (excepting their own servers, of course) a few years back in response to a large spam. I don't know the details -- this is from a response to a complaint I filed. Interesting idea, though -- you then catch 'em when they attempt to relay through your server. And as far as that goes, I've seen a system that worked quite well... Larry might be familiar with it, as it was his. Peter E. Fry
RE: IETF SMTP Working Group Proposal at smtpng.org
At 11:50 AM -0400 2002/08/21, Robert Blayzor wrote: 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? -- Brad Knowles, [EMAIL PROTECTED] 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(+++)
RE: IETF SMTP Working Group Proposal at smtpng.org
At 3:50 PM -0400 2002/08/21, Robert Blayzor wrote: Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. When you're willing to do this for your own personal private mail server, and you're willing to lose e-mail until you get your mail server on all known whitelists in existence, I might reconsider. -- Brad Knowles, [EMAIL PROTECTED] 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(+++)
Re: IETF SMTP Working Group Proposal at smtpng.org
At 4:25 PM -0400 2002/08/21, Jared Mauch wrote: Lets say AOL, hotmail, yahoo all today had a way they could say we would like to cooperate in validating source addresses as at least somewhat more valid than today and had a mechanisim to do this with a patch to sendmail/qmail/postfix/zmailer. Doesn't help. AOL uses a proprietary MTA that they have developed in-house, which would need to be modified. Of course, you'd also need to modify all the other standard MTAs, too. And don't forget about all those Microsoft and Lotus Notes gateways out there. You could also then start keeping statistics and rate-limit the callback mechanisim. AOL (and i'm sure others) have done so, you want to bulk-mail aol users, sign here. Including this ability to increase customer satisfaction is in all ISPS interest today. AOL uses all sorts of mechanisms to try to detect and eliminate spam, but I wouldn't want to go into too much detail here. -- Brad Knowles, [EMAIL PROTECTED] 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(+++)
RE: IETF SMTP Working Group Proposal at smtpng.org
Uh, no. I have seen spammers use dynamic DNS to use throw away dial-ups accounts for incoming main service. Right, but to run a real mail server you need a static address. Which can be registered as a valid mail server. Dynamic IP's cannot. How about moving this to an approriate forum where people really know spam and mail? Nanog is for moving packets. Nanog does not usually care what is in the packet unless it is a routing protocol. The NANOG mailing list is established to provide a forum for the exchange of technical information and the discussion of specific implementation issues that require cooperation among network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, the list is governed by the following guidelines: ... Doesn't mention anything about Nanog is for moving packets. An anti-spam/security discussion seems perfectly acceptable to me. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
RE: IETF SMTP Working Group Proposal at smtpng.org
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Gary E. Miller Sent: August 21, 2002 5:57 PM To: Robert Blayzor Cc: [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org Uh, no. I have seen spammers use dynamic DNS to use throw away dial-ups accounts for incoming main service. Well, that's nice... until their dynamic DNS gets promptly killed (if they got it from us or someone responsible - I can't speak for everyone in this industry), at which point they're back at square one with all their email gone. A lot of people seem to think that dynamic DNS services are a way to cover up abuse (eg: spam, warez, etc); they're not, as a decent amount of spammers have found out the hard way. Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
RE: IETF SMTP Working Group Proposal at smtpng.org
Half the spam I get is from throw away AOL, netzero, earthlink, etc. accounts. Spend $10 for a new ISP account, sent 10,000 emails with MY return address which is valid and on whitelists. Do it on a long weekend and get 30k out before you get stopped. Of course my typical answer here is those ISP's need to be responsible. Quite honestly the simple fix is to firewall all outbound port 25 connections from non-static IP assignments, and force them to use specific SMTP servers. It's possible then to have mail servers detect incoming spam from customers through their mail server farms by counting a number of messages in a given period of time, then take action. These throw away accounts you claim are usually simple residential products in which 99% of all customers don't send over 1000 messages within ten minutes. (example) I'm just throwing out ideas on trying to deal with the problem. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
RE: IETF SMTP Working Group Proposal at smtpng.org
Yo Robert! On Wed, 21 Aug 2002, Robert Blayzor wrote: Uh, no. I have seen spammers use dynamic DNS to use throw away dial-ups accounts for incoming main service. Right, but to run a real mail server you need a static address. Which can be registered as a valid mail server. Dynamic IP's cannot. Read what I wrote again. Do not say it is not possible, I see it every day. These people, and others will be happy to help you set it up: http://www.no-ip.com Do you own a domain name? Run your own web, mail, ftp, or any server connected your cable, dsl, or dialup connection using your personal domain name. Do some googling before posting nonsense... Doesn't mention anything about Nanog is for moving packets. An anti-spam/security discussion seems perfectly acceptable to me. From the proposed nanog FAQ: Off-Topic Questions 1. Spam 2. Local DNS [...] So take this topic to somewhere it belongs. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
RE: IETF SMTP Working Group Proposal at smtpng.org
Look. The DNS is seriously screwed-up enough as it is. Let's not take a bad model and replicate it elsewhere. I'm not saying use DNS specifically, but using something DNS like. Whether it be a database of public keys or certs really doesn't make a difference at this level. Sure. Are you willing to be the first? If it came down to the wire and something like this were implemented, and enforced, then yes, I'd be the first in line. If the software, the system and the means are available, I'd make sure we were registered before the system went live. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
Re: IETF SMTP Working Group Proposal at smtpng.org
At 5:42 PM -0500 2002/08/21, Peter E. Fry wrote: (Checking... OK, whew -- it doesn't appear to be me...) Get a real provider. That's easier said than done, especially for DSL and cablemodem customers, who most likely have no other choice. -- Brad Knowles, [EMAIL PROTECTED] 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(+++)
Re: IETF SMTP Working Group Proposal at smtpng.org
At 5:35 PM -0500 2002/08/21, Peter E. Fry wrote: Relay through your upstream (hierarchical approach)? i.e. Register your server(s) with your provider, who is presumably trusted (registered with the global system). This is the approach I recommend, and have recommended for years. A bit of an aside: I recall ATT Canada blocked all SMTP from exiting their network (excepting their own servers, of course) a few years back in response to a large spam. AOL does the same. They have a transparent SMTP proxy for all outgoing connections. They've also explicitly asked to have this machine added to certain blacklists, so that people who don't want to receive what is almost certainly going to be spam can choose to do so. If you want to send real e-mail using AOL, then use the mail client provided by AOL. It's that simple. -- Brad Knowles, [EMAIL PROTECTED] 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(+++)
Re: IETF SMTP Working Group Proposal at smtpng.org
At 2:15 PM -0700 2002/08/21, [EMAIL PROTECTED] wrote: Your quite wrong. With email we do in fact know phone for the calling party - its their FROM address and for callback we can specify if we trust or do not trust the other party to provide some different domain, so they may not be given a change to specify where to callback to. As example If they are trying to send email from [EMAIL PROTECTED] the callback would have to go to somedomain.com mail server and the callback must use the authorization code given during initial mail call. The callback can also be authenticated with TLS giving even more security that somedomain.com is a real operation. This will prevent 99% of spammers just there. It's bad enough waiting for DNS responses so that you can determine whether or not the envelope sender domain even exists. Now you want to slow down every single e-mail transaction by many, many, many orders of magnitude so that you can do a callback on each and every connection?!? Man, wanna talk about ideas that would bring all e-mail to a complete stop across the entire Internet? Imagine what it would be like if AOL did this, so that it could take five, ten, or even fifteen minutes just to get one callback on one message, if the remote server was slow enough. Now, if you start up a sendmail queue runner every sixty minutes, you only need a very small number of messages in your queue before you start stacking up more and more and more sendmail processes, until such time as you run out of memory, your mail server crashes, and you might potentially lose all your queued e-mail. Jeezus. Do you have to be the one guy who got blamed for shutting down all e-mail across the entire Internet on Black Tuesday, just to see the flaws in this plan?!? -- Brad Knowles, [EMAIL PROTECTED] 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(+++)
RE: IETF SMTP Working Group Proposal at smtpng.org
At 7:23 PM -0400 2002/08/21, Robert Blayzor wrote: Sure. Are you willing to be the first? If it came down to the wire and something like this were implemented, and enforced, then yes, I'd be the first in line. If the software, the system and the means are available, I'd make sure we were registered before the system went live. Right. How are you going to enforce *anything* on the Internet? Every single RFC in existence is optional, at best. Every single black list is certainly optional. And until you can control the entire Internet and operate the mail servers for everyone in the world, there's no way in hell that you're going to get everyone to subscribe to the same white list. Sorry, guy. Ain't gonna happen. -- Brad Knowles, [EMAIL PROTECTED] 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(+++)
RE: IETF SMTP Working Group Proposal at smtpng.org
Read what I wrote again. Do not say it is not possible, I see it every day. These people, and others will be happy to help you set it up: http://www.no-ip.com Do you own a domain name? Run your own web, mail, ftp, or any server connected your cable, dsl, or dialup connection using your personal domain name. Do some googling before posting nonsense... I read what you wrote, but I'm trying to understand how dynamic DNS has anything to do with sending spam. Dynamic DNS only does forward DNS for a host IP assignment. If AOL issues an IP to a dialup customer, it's still an AOL address with AOL access restrictions, AOL reverse DNS, etc. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
RE: IETF SMTP Working Group Proposal at smtpng.org
Sure they can. For sending e-mail, all you need is an IP address. It would help if the reverse DNS is set up correctly, and that you claim this same name in the SMTP dialog, but this isn't required. Yes, I know they can today. My point is that with a registrar based system, they cannot, because they cannot be registered as valid mail servers. For receiving mail, all you need is a domain name, which has a set of advertised MXes. Those MXes could point to mail servers operated by friends of yours who might use UUCP, or some private routing method to send your mail to whatever your current IP address is. Those MXes could even point to your own host/domain names, and the mail would be deferred until such time as you re-connect with your dynamic DNS provider and update the IP addresses for these names. Correct, but MX's (mail servers) have static assignments, unless you change DNS every time. Running MX's on dynamic IP's to receive mail would be quite silly. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
RE: IETF SMTP Working Group Proposal at smtpng.org
At 7:13 PM -0400 2002/08/21, Robert Blayzor wrote: Right, but to run a real mail server you need a static address. Which can be registered as a valid mail server. Dynamic IP's cannot. Sure they can. For sending e-mail, all you need is an IP address. It would help if the reverse DNS is set up correctly, and that you claim this same name in the SMTP dialog, but this isn't required. For receiving mail, all you need is a domain name, which has a set of advertised MXes. Those MXes could point to mail servers operated by friends of yours who might use UUCP, or some private routing method to send your mail to whatever your current IP address is. Those MXes could even point to your own host/domain names, and the mail would be deferred until such time as you re-connect with your dynamic DNS provider and update the IP addresses for these names. Works just fine. -- Brad Knowles, [EMAIL PROTECTED] 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(+++)
RE: IETF SMTP Working Group Proposal at smtpng.org
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Blayzor Sent: August 21, 2002 7:14 PM To: 'Gary E. Miller' Cc: [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org Uh, no. I have seen spammers use dynamic DNS to use throw away dial-ups accounts for incoming main service. Right, but to run a real mail server you need a static address. Which can be registered as a valid mail server. Dynamic IP's cannot. Dynamic/static IPs, though, is a distinction that's much harder to make these days (ahhh, how I miss the days of dialup... NOT). There are plenty of people (myself included) who have cable/DSL connections at home with IPs that change every 6 months or a year. Similarly, people whose organizations can't justify the /20 from ARIN will have to renumber their servers every time they change ISPs (how many WorldCom/KPN Qwest/etc single-homed customers have switched or will switch?) or outgrow the ridiculously puny allocation they were able to justify from their upstream will have to change their static IPs. Oh, and what about a DHCP setup that's set to allocate the same IP to a certain MAC address? Is that static or dynamic? As for registration, well, let's try to avoid a mess like that created by the mandatory glue record creation process involved in name server registration, shall we? With the name server registration, you end up having all kinds of unnecessary glue records floating around which either a) drive someone crazy when they move their domain around, or b) cause random people out there to end up having DNS queries showing up at machines that aren't DNS servers (anyone care to guess how someone with a personal firewall would react when they see the queies on port 53/udp?). Same thing with SWIP delegations and the like; sadly, there are still all kinds of incorrect old information floating around in these databases, and I'd rather not rely on some three year old registration in deciding whether to trust some machine. I admit that something non-IP-specific, like SSL certificates, to me seem like a much more flexible long-term solution. Plus that way when you renumber your mail server, you wouldn't need to reregister the new IP, etc. That said, I (and our several tens of thousands of users running their own mail servers) would like to know how you define a real mail server. Is a real mail server a server that you've arbitrarily decided needs a static IP? Is a real mail server a closed relay (if so, someone on this list may feel insulted that his deliberately open relay isn't real by your standards)? Is your real mail server something operated by an organization with more than 200 accounts (in which case, you're telling me that my mail server with 25 or so accounts sitting in an Exodus colo with a perfectly static IP is not real?)? Etc. Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: IETF SMTP Working Group Proposal at smtpng.org
1. I want to create specification that would allow server operators themselve to decide what kind of verification they want, if you do not like callback, do not implement it. 2. Most estimate that up to 50% of mail system resources are used for processing unwanted email, viruses, etc. The amount of processing time due to new specification will be smaller then what has been gained from not having to deal with unwanted emails as much. 3. The processing is server cpu resource, while sending email is bandwidth used. I'll give up some more cpu resources to decrease used bandwidth. 4. For last years cpu speed hardware have been increasing at 2x per 2 years and are more and more powerfull. Even if the initiative goes through fairly fast (I projected2 years, that is already too optimistic), it'll be another 4 years at least before its used, by that time servers would be 8 times faster! At 2:15 PM -0700 2002/08/21, [EMAIL PROTECTED] wrote: Your quite wrong. With email we do in fact know phone for the calling party - its their FROM address and for callback we can specify if we trust or do not trust the other party to provide some different domain, so they may not be given a change to specify where to callback to. As example If they are trying to send email from [EMAIL PROTECTED] the callback would have to go to somedomain.com mail server and the callback must use the authorization code given during initial mail call. The callback can also be authenticated with TLS giving even more security that somedomain.com is a real operation. This will prevent 99% of spammers just there. It's bad enough waiting for DNS responses so that you can determine whether or not the envelope sender domain even exists. Now you want to slow down every single e-mail transaction by many, many, many orders of magnitude so that you can do a callback on each and every connection?!? Man, wanna talk about ideas that would bring all e-mail to a complete stop across the entire Internet? Imagine what it would be like if AOL did this, so that it could take five, ten, or even fifteen minutes just to get one callback on one message, if the remote server was slow enough. Now, if you start up a sendmail queue runner every sixty minutes, you only need a very small number of messages in your queue before you start stacking up more and more and more sendmail processes, until such time as you run out of memory, your mail server crashes, and you might potentially lose all your queued e-mail. Jeezus. Do you have to be the one guy who got blamed for shutting down all e-mail across the entire Internet on Black Tuesday, just to see the flaws in this plan?!?
RE: IETF SMTP Working Group Proposal at smtpng.org
Wow. I turned my back on this thread to move to my new office, and it got interesting. The answer to your quesiton is, the cert itself can do this, if it includes a unique/semi-unique identifier, such as an SSN, a name and address, etc. Many governments give their people some unique identifier. You sign up for my service and say you wanna send mail, I say, Sure! Lemmie just check your ID against the revocation list... -Dave On 8/21/2002 at 15:11:59 -0400, Mark Segal said: 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 Really good idea (no sarcasm, I actually like it).. But what stops spammers from registering their mail server?..Ie.. 1) Get a dsl account 2) Ips get swipped to you 3) Register the server 4) SPAM 5) Apologize, get a second chance 6) get booted off 7) Call the next ISP with a zero install 8) Rinse and repeat. Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -- Dave Israel Senior Manager, DNE SE
Re: IETF SMTP Working Group Proposal at smtpng.org
On Wed, 21 Aug 2002 [EMAIL PROTECTED] wrote: 1. I want to create specification that would allow server operators themselve to decide what kind of verification they want, if you do not like callback, do not implement it. Ultimately, only the system that is flexible in this regards will succeed as a viable solution. 3. The processing is server cpu resource, while sending email is bandwidth used. I'll give up some more cpu resources to decrease used bandwidth. The trick (and I steal this openly and completely from a recent thread on Cypherpunks) is make mail delivery computationally difficult - for the sender. This of course assumes that we are throwing out the fools gold of Hashcash itself. Presenting a computationally difficult problem to a connecting MTA moves the requirement for the CPU power to the sender while keeping the recipient site unfettered. Let's face it, the spam problem is merely one of cost shifting from sender to reciever, and this proposal shifts the load back. Any site that wishes to maintain the current system of email subsidies to the sender domain need only provide a computationally simple token. 4. For last years cpu speed hardware have been increasing at 2x per 2 years and are more and more powerfull. Even if the initiative goes through fairly fast (I projected2 years, that is already too optimistic), it'll be another 4 years at least before its used, by that time servers would be 8 times faster! Yet, all of this would not help the spam originating sites at all because of the sheer volume of mail they must send in order to turn a profit. Yours, J.A. Terranson
Re: IETF SMTP Working Group Proposal at smtpng.org
The problem with SSL is it doesn't include certificate chain to arbitrary authorities. However, there's a space for web of trust in SSL, I believe, so yeah, a new verison of SSL might be just the ticket. On 8/22/2002 at 00:02:24 +0300, Petri Helenius said: Treat them sort of like SSL certs now. Charge an annual registrar fee per company, not per server. (Something like $100 a year) The more they have to go out of their way to get their spam server online, the more they would be deterred to do so. They're only going to want to change so many ISP's, go through SWIP and then change their legal name for the registrar so many times. Why don´t you just start using SSL certs with SMTP ? The protocol is there, ways to get certificates are there, no need to start smoothing a square piece to make a new wheel. Pete
RE: IETF SMTP Working Group Proposal at smtpng.org
On 8/21/2002 at 15:11:59 -0400, Mark Segal said: 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. And of course, Netsol should be the only registrar for the first 75 years, not counting their first extension...
Re: IETF SMTP Working Group Proposal at smtpng.org
All very interesting discussion, but discussing it here on NANOG is probably about the worst idea ever -- No offense intended, I'm sure you had only good intentions. I will now go on to continue the discussion. grin As a sysadmin at a large ISP which provides DSL and dial (and hosting, colo, bla bla bla) I have to admit that I am very interested in seeing something like this happen (registration of mail servers, trustdb, anything...) as I've had a few similar thoughts in the past, but figured that something with such a global impact would be utterly unfeaseable (and likely is, but still it is fun to dream.) Spam definitely impacts services from time to time, even on the most robust servers I have. I catch customers spamming frequently (and of course follow through with my abuse team and suspend their account and kick them offline and clean their crap out of my queues, etc etc..) but the absolute worst is all the open proxies being used (not 3rd party mail relays, but hosts which are in fact not even mail servers at all, merely running an insecure proxy (socks, squid, analogx, etc..)) Anyhow, I don't want to go too far off topic, or rant about spam, or any of the other impolitic things folks do on this list, but I figured I'd let you all know that there's a sysadmin at a DSL provider who cares enough to show interest in this concept. :-) I'd have no issue with working on a system to allow customers to run their own mail servers. Then again, I'm not an engineer, or in marketing, or any of the other decision-making groups, so that'd be my opinion only I'm talking about there. (note: I rarely have time to read this list, it was pure accident that I switched to this mailbox and saw this thread, so if you wish to reply to me, please include me in the cc:--Thanks:) /wjr On Wed, Aug 21, 2002 at 03:25:50PM -0500, Robert A. Hayden wrote: Yea. Good luck getting a DSL provider to swip an IP to you or to be willing to register an IP for you. On Wed, 21 Aug 2002, Robert Blayzor wrote: What about individuals that run their own mail servers? (E.G. me).? Get your mail server registered just like everyone else I suppose. If your address space is not registered to you directly, your ISP would have to do this for you. You're ISP would then handle any complaints (if any) from the registrar and coordinate it with you directly. I honestly like that idea because as a network operator, I like to know what customers are running mail servers on our network, where they are, and who owns them. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan -- +--+ | William Rockwood | Sr. System Administrator | [EMAIL PROTECTED]| XO Communications, Chicago DCO +--+
RE: IETF SMTP Working Group Proposal at smtpng.org
The problem with SSL is it doesn't include certificate chain to arbitrary authorities. However, there's a space for web of trust in SSL, I believe, so yeah, a new verison of SSL might be just the ticket. Lets not forget that you need an SSL cert for every server with a different host name, and you need to go through companies like Verisign to get them. (yes, there are lesser evils I know). But using SSL certs could be more expensive then just registering your company, netblock or whatever with a management account. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
Re: [Fwd: Re: IETF SMTP Working Group Proposal at smtpng.org]
I agree with getting personal mail servers registered, as far as paying $100 for a mail server registration (as mentioned in previous messages)...that's no good. As a user with a personal mail server, it is bad enough to have pay for connectivity and a domain name. Having to pay for the privilege of running a mail server is too much. e-mail isn't free. in my own experience, i can pay a high price by just hitting delete a couple hundred times a day, or a medium price by turning on all kinds of anti-spam features in my MTA and sending complaints out to network owners on whatever sneaks through the blockade, or a low price by only accepting e-mail from people who have paid to register their servers with some certifier whom i am willing to trust. we'll be seeing this kind of require signed-by-trusted certificates before permitting use logic in the personal certificate field soon. why not do it at the mail server level, where there are fewer certificates and more total lifetime value per signature? the secret is in correctly answering the question who gets the money. i would love to see a bona fide nonprofit use this as a fundraising method. (any organized religion's church comes to mind here as an ideal candidate.) server-level openpgp is also an option, and would more closely reflect the social realities: (1) introducers i'm willing to trust may not be at the top of any virtual certification hierarchy other than my own; and (2) there's no compelling technical reason to keep the number of ultimately trusted keys small. (verisign/thawte may feel that there are compelling business reasons, however.) -- Paul Vixie
Re: IETF SMTP Working Group Proposal at smtpng.org
Lets not forget that you need an SSL cert for every server with a different host name, and you need to go through companies like Verisign to get them. (yes, there are lesser evils I know). But using SSL certs could be more expensive then just registering your company, netblock or whatever with a management account. i won't glock up this already busy list with a full copy of the proposal, but before y'all go off and invent something, here's some prior art that's been resoundingly pooh-pooh'd by the smtp community. http://www.vix.com/~vixie/mailfrom.txt Abstract At the time of this writing, more than half of all e-mail received by the author has a forged return address, due to the total absence of address authentication in SMTP (see [RFC2821]). We present a simple and backward compatible method whereby cooperating e-mail senders and receivers can detect forged source/return addresses in e-mail. -- Paul Vixie
RE: IETF SMTP Working Group Proposal at smtpng.org
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Blayzor Sent: August 21, 2002 7:39 PM To: 'Brad Knowles' Cc: [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org Correct, but MX's (mail servers) have static assignments, unless you change DNS every time. Running MX's on dynamic IP's to receive mail would be quite silly. Then perhaps you'd like to tell me how we have tens of thousands of users quite happily doing it? True, I wouldn't run Hotmail/AOL/EarthLink/etc's MXes off dynamic IPs, but for a home/small biz mail server... Oh, and one last thing, when you specify an MX (statically, as you say), you don't put in the IP but rather a name created with A record, so what prevents that A record from being a low-TTL dynamic DNS A record? Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
RE: IETF SMTP Working Group Proposal at smtpng.org
Then perhaps you'd like to tell me how we have tens of thousands of users quite happily doing it? True, I wouldn't run Hotmail/AOL/EarthLink/etc's MXes off dynamic IPs, but for a home/small biz mail server... Oh, and one last thing, when you specify an MX (statically, as you say), you don't put in the IP but rather a name created with A record, so what prevents that A record from being a low-TTL dynamic DNS A record? Running a mail server off a dynamically assigned dialup *CAN* work, but it really isn't the thing to do even if you put in a low TTL on the A record. Sure it works. But what about all the messages that will requeue on remote mail servers and depending on the remote queueing strategy of the remote mail server, it can take hours before mail could be re-attempted for delivery. A dynamically assigned MX box isn't really the best thing to do. If you want to do that then you should at least have a lower preference backup MX that is on 24/7 that will accept mail on your behalf, and when your server dynamic SMTP server comes online it can simply do an ETRN to requeue the mail on the backup MX. Having one MX on a dynamic DNS mail server is just rude to remote mail servers that try to deliver mail. Why should my servers consume more resources to benefit your customers? -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] Exclusive: We're the only ones who have the documentation.
RE: IETF SMTP Working Group Proposal at smtpng.org
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Blayzor Sent: August 21, 2002 10:53 PM To: 'Vivien M.'; [EMAIL PROTECTED] Subject: RE: IETF SMTP Working Group Proposal at smtpng.org Running a mail server off a dynamically assigned dialup *CAN* work, but it really isn't the thing to do even if you put in a low TTL on the A record. Sure it works. But what about all the messages that will requeue on remote mail servers and depending on the remote queueing strategy of the remote mail server, it can take hours before mail could be re-attempted for delivery. A dynamically assigned MX box isn't really the best thing to do. If you want to do that then you should at least have a lower preference backup MX that is on 24/7 that will accept mail on your behalf, and when your server dynamic SMTP server comes online it can simply do an ETRN to requeue the mail on the backup MX. Having one MX on a dynamic DNS mail server is just rude to remote mail servers that try to deliver mail. Why should my servers consume more resources to benefit your customers? You're assuming that these people aren't permanently online. I expect most of our users (I hesitate to call them customers, simply because a lot of them haven't paid anything) are using 24/7 type connections. Certainly, running your own mail server and being online two hours a day is foolish. However, this has NOTHING to do with IP allocation. A friend, years ago, had a static IP dialup with an ISP that billed him for an X hour/month package, where I think X was 120 or so. He could have run a mail server that met your static IP standard of approval, and yet was (unless he wanted to pay extra) only online 1/6th of the time. Now, most of our users may not have static IPs, but they're most likely online 24/7 or close enough. Which of the two uses more resources on your servers? I'm willing to bet the static IP dialup person will, so there goes your argument. Running mail servers on non-permanent dialup connections is foolish, I'll grant you that any day, but that wasn't the point you were making. Your point was that mail servers on dynamic IPs (and you never answered my question on how you define dynamic) are bad, no matter the circumstances surrounding them, and that's just plain not true. Oh, and BTW, you're not benefiting our users by having your servers queue mail for our users. You're benefitting YOUR customers who presumably want to be able to send mail to our users, and who expect your servers to queue mail. Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: IETF SMTP Working Group Proposal at smtpng.org
On Thu, 22 Aug 2002 01:08:52 +0200, Brad Knowles [EMAIL PROTECTED] said: It's bad enough waiting for DNS responses so that you can determine whether or not the envelope sender domain even exists. Now you want to slow down every single e-mail transaction by many, many, many orders of magnitude so that you can do a callback on each and every connection?!? Worse yet, under his proposal, you're calling back to a callback address provided by the spammer on the MAIL FROM, to verify a spammer-provided token. What's wrong with this picture? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg04708/pgp0.pgp Description: PGP signature
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 [EMAIL PROTECTED]
Re: IETF SMTP Working Group Proposal at smtpng.org
On Tue, 20 Aug 2002, [EMAIL PROTECTED] 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.
Re: IETF SMTP Working Group Proposal at smtpng.org
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, [EMAIL PROTECTED] 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.
