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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mark Segal Sent: Wednesday, August 21, 2002 3:12 PM To: 'Robert Blayzor'; nanog@nanog.org 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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mark Segal Sent: Wednesday, August 21, 2002 3:12 PM To: 'Robert Blayzor'; nanog@nanog.org 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: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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 rblayzor@inoc.net YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
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: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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 rblayzor@inoc.net Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [ OK ]
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 AT&T 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
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 AT&T 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, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
--On 22 August 2002 01:16 +0200 Brad Knowles <brad.knowles@skynet.be> wrote:
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.
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 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?
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 rblayzor@inoc.net A computer program does what you tell it to do, not what you want it to do.
At 12:45 PM +0100 2002/08/22, Ian Cooper wrote:
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 didn't see any scalability problems when I was running the mail servers at AOL. At least, not on this side.
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?
Just because you bought bargain-basement lowest-possible-cost Internet access doesn't mean that you bought the right to set up whatever servers you want and to have completely and totally unfettered access. If you want completely unrestricted access, then you should be prepared to pay extra for it. If you don't like that policy, you can always go somewhere else. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
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 rblayzor@inoc.net
YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
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 rblayzor@inoc.net I haven't lost my mind; it's backed up on tape somewhere.
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 rblayzor@inoc.net
YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
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. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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.
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.
If they've given you a /29 and they refuse to SWIP the block to you, report them to ARIN along with the super block your on. Also CC that message to the contact listed on the ISP's ARIN admin contact. I'm sure you'll get someones attention or chances are they'll have a lot harder time getting their next IP block assignment. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net (A)bort, (R)etry, (T)hrow up?
"Robert A. Hayden" wrote:
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.
(Checking... OK, whew -- it doesn't appear to be me...) Get a real provider. Peter E. Fry
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, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
Yea. Good luck getting a DSL provider to swip an IP to you or to be willing to register an IP for you.
Most DSL providers won't even give you a static IP address, if they do, and they know it's for a mail server, they should handle this for you as a value added service. Many of them out there I'm sure won't do it correctly, but there are ones out there that can, you just need to find them. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net Sleep: A completely inadequate substitute for caffeine.
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 rblayzor@inoc.net
YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan
-- +------------------+ | William Rockwood | Sr. System Administrator | wjr@op.xo.com | XO Communications, Chicago DCO +------------------+
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, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
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:<spammer@hotmail.com> callback=spammer.example.com 250 ok rcpt to:<jared@nether.net> 451 try again, pending callback vs: 220 welcome, but no spam ehlo spammer 250-callback-secure 250 help mail from:<spammer@hotmail.com> callback=spammer.example.com 250 ok rcpt to:<nouser@nether.net> 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:<realuser@hotmail.com> 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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mark Segal Sent: Wednesday, August 21, 2002 3:12 PM To: 'Robert Blayzor'; nanog@nanog.org 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: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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:<spammer@hotmail.com> callback=spammer.example.com 250 ok rcpt to:<jared@nether.net> 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:<realuser@hotmail.com> 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...
Well, given that the spammer is given the opportunity to specify where to call back *TO*, you're not buying yourself anything- of COURSE the spammer is going to point you at a system where they control the horizontal and vertical. 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. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
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 <me@somedomain.com> 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:<spammer@hotmail.com> callback=spammer.example.com 250 ok rcpt to:<jared@nether.net> 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:<realuser@hotmail.com> 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.
At 2:15 PM -0700 2002/08/21, <william@elan.net> 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 <me@somedomain.com> 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, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
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, <william@elan.net> 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 <me@somedomain.com> 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?!?
On Wed, 21 Aug 2002 william@elan.net 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
At 7:20 PM -0500 2002/08/21, J.A. Terranson wrote:
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.
Now this is more plausible. You'd still need something akin to a PKI to distribute the computationally simple tokens, and you'd need a way to easily revoke them. But if this was implemented by default in the standard MTAs, you would go from hundreds or thousands of message deliveries per minute to five or more minutes per un-authenticated message delivery. This is something that might be worth discussing in the appropriate forums, such as the SMTP-related working groups of the IETF. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
If you want slower e-mail delivery why not just put sleeps into the receiving MTA? I've often wondered if keeping a little db of who has connected lately and using the number of connects from a particular address as a factor in a delay calculation wouldn't help against certain common spam attacks. An exception list of known big sites you get a lot of mail from would be a desireable, additional feature, maybe optionally as a fudge factor since large sites can also be spam sources. etc etc etc. But so would refinements like increase the slope if (some criteria like serious mismatch between from and relay or can't DNS relay or IP addr is in known suspect range.) On August 22, 2002 at 22:45 brad.knowles@skynet.be (Brad Knowles) wrote:
At 7:20 PM -0500 2002/08/21, J.A. Terranson wrote:
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.
Now this is more plausible. You'd still need something akin to a PKI to distribute the computationally simple tokens, and you'd need a way to easily revoke them. But if this was implemented by default in the standard MTAs, you would go from hundreds or thousands of message deliveries per minute to five or more minutes per un-authenticated message delivery.
This is something that might be worth discussing in the appropriate forums, such as the SMTP-related working groups of the IETF.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
At 7:43 PM -0400 2002/08/22, Barry Shein wrote:
If you want slower e-mail delivery why not just put sleeps into the receiving MTA?
That's basically what postfix does. Based on the types of abuse (e.g., too many bounces in a given period of time), it goes into a bounded exponential backoff for the amount of time that it will sleep between operations. I am proud to say that I was a champion of this kind of behaviour, and I helped convince Wietse that this was a good thing to do. However, what we're talking about here is a way to know, a priori, whether or not you should start immediately sleeping long periods of time between transactions, based on a "cookie" that is transmitted early in the SMTP dialog. If you've got the cookie, then there is no extra sleeping added. If you don't, then there are added sleep loops for the very first message and all following messages (maybe you would even refuse to accept more than one message per connection, slowing them down even more). The only way to get the cookie is to be a good netizen and sign up with a well-maintained central white list operator, who would then issue you the cookie in question. What becomes interesting in this kind of case is handling the cookie distribution infrastructure, as well as the cookie revocation infrastructure. However, all of this is way off-topic for NANOG, according to the proposed FAQ. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On Thu, 22 Aug 2002, Brad Knowles wrote:
At 7:20 PM -0500 2002/08/21, J.A. Terranson wrote:
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.
Now this is more plausible. You'd still need something akin to a PKI to distribute the computationally simple tokens, and you'd need a way to easily revoke them. But if this was implemented by default in the standard MTAs, you would go from hundreds or thousands of message deliveries per minute to five or more minutes per un-authenticated message delivery.
This is something that might be worth discussing in the appropriate forums, such as the SMTP-related working groups of the IETF.
Thank You Brad. I think it is aslo and elegant very cleasn solution to a divisive social issue - the placing of the transmission costs on firmaly of the SELLER, without binding up the innoced receipient, I have very serious deoubts that a sender will even offer you the oppotunity if they get you Ba computationally difficult token.
At 4:40 PM -0700 2002/08/21, <william@elan.net> 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.
If it's not implemented by default in the standard MTAs, then it is useless.
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.
No, the numbers are more like 75-80% at many sites. But you're talking many, many orders of magnitude worse. You'd cause 99.999999% of all work done on all mail servers around the world to be nothing but waiting for callbacks to occur, and maybe some year an actual mail message might be delivered.
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.
This has absolutely nothing whatsoever to do with bandwidth. You're trading a few milliseconds of latency for dozens, hundreds, thousands, millions of seconds of latency. Try doing the math sometime.
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!
The biggest thing that you need to work to eliminate in any heavily loaded mail server is latency. Specifically, what you tend to work hardest to eliminate is latency caused by waiting on the disk. Now, disks typically have latencies measured in terms of a few milliseconds, and you want to replace this latency by another process that will have latency that can be measured in minutes, hours, and days?!? So, just what kind of drugs have you been taking lately, eh? -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
Why you think server should wait for callback or that I was proposing that? I'd not want seconds of latency either. Maximum that would happen is need to keep hash of key codes for expected callbacks (cashed in memory or on disk). In any case, I'm not going to debate this here any more, number of people do not understand what I have in mind and have misconceptions about it so per multiple requests I'm putting my notes in order and will publish them on the website to be futher discussed on the maillist I setup. If you're interested take a look at the website in a week or two and read the notes there. On Thu, 22 Aug 2002, Brad Knowles wrote:
At 4:40 PM -0700 2002/08/21, <william@elan.net> 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.
If it's not implemented by default in the standard MTAs, then it is useless.
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.
No, the numbers are more like 75-80% at many sites. But you're talking many, many orders of magnitude worse. You'd cause 99.999999% of all work done on all mail servers around the world to be nothing but waiting for callbacks to occur, and maybe some year an actual mail message might be delivered.
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.
This has absolutely nothing whatsoever to do with bandwidth. You're trading a few milliseconds of latency for dozens, hundreds, thousands, millions of seconds of latency. Try doing the math sometime.
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!
The biggest thing that you need to work to eliminate in any heavily loaded mail server is latency. Specifically, what you tend to work hardest to eliminate is latency caused by waiting on the disk.
Now, disks typically have latencies measured in terms of a few milliseconds, and you want to replace this latency by another process that will have latency that can be measured in minutes, hours, and days?!?
So, just what kind of drugs have you been taking lately, eh?
At 3:50 PM -0700 2002/08/22, <william@elan.net> wrote:
Why you think server should wait for callback or that I was proposing that?
Okay, so you queue the incoming messages until you can get an asynchronous callback. One of the biggest performance wins for mail servers is to completely avoid any disk I/O at all in the case of the successful initial delivery attempt. You would cause this feature to be effectively eliminated, by forcing the majority of all incoming mail to be queued. Now, I guess you could temporarily refuse to accept the message, forcing it to be queued on the remote end. But certainly large mailing lists take big advantage of the "no disk I/O" feature, so you would be penalizing all your users who are subscribed to mailing lists that operate this way. Indeed, by making their mail delivery significantly slower, there's a good chance that the mail might be removed from the queue before the callback is successful, and they would be likely to be much less happy with slow message delivery caused by your system.
I'd not want seconds of latency either. Maximum that would happen is need to keep hash of key codes for expected callbacks (cashed in memory or on disk).
Right. Check the logs of your mail servers. How many unique servers contact your machine to deliver mail to your users in a day? Maybe at your site this would be a manageable number, but I can guarantee you that with many millions of messages handled per day, this kind of thing is simply unthinkable at larger sites.
In any case, I'm not going to debate this here any more, number of people do not understand what I have in mind and have misconceptions about it so per multiple requests I'm putting my notes in order and will publish them on the website to be futher discussed on the maillist I setup. If you're interested take a look at the website in a week or two and read the notes there.
Setting up your own mailing list for this stuff is not likely to result in any useful outcome. If you want to create your own proposal and write it up, please do so. But when you're done, you should discuss that proposal in the places that already exist to discuss these sorts of things, such as some of the IETF mailing lists, certain other popular mailing lists (other than NANOG), certain popular USENET newsgroups, etc.... -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On Thu, 22 Aug 2002 01:08:52 +0200, Brad Knowles <brad.knowles@skynet.be> 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
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Larry Rosenman Sent: Wednesday, August 21, 2002 12:39 PM To: Derek Samford Cc: 'Mark Segal'; 'Robert Blayzor'; nanog@nanog.org 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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mark Segal Sent: Wednesday, August 21, 2002 3:12 PM To: 'Robert Blayzor'; nanog@nanog.org 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: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
The only promising long-term solution to spam is to begin charging for all received commercial e-mail and make that the industry standard. A quick FAQ on this idea Q1. How does charging solve anything? A1. a) It renders unpaid-for spam mere theft-of-service, criminally prosecutable under current laws. Not immediately, but as the custom of charging matures courts would come to accept that evading payment is simple theft. b) It provides income, at least you'd get paid something for dealing with the problem. c) Some of that income could be used to fund an industry organization to help enforce against abuse. Q2. How can you determine what is commercial and what isn't? A2. It's your system, other than a few possibly illegal motivations you can do anything you want. But more importantly, if the telcos can have residential vs business rates, etc., then so can you. There is nothing that says your lines have to be absolutely perfectly drawn or satisfy everyone. It'd be a lot better than what we have now with minors being flooded with explicit porn spam, obviously fraudulent schemes spewing at everyone, etc. if we could get it mostly under control. "Perfect" might take more time. Q3. Do you mean charging someone like Microsoft for their newsletters? A3. Maybe, the specifics are ultimately up to you, whatever maximizes your profits and keeps your customers happy. Q4. Wouldn't that anger those companies? A4. Maybe, maybe not. If you could reduce commercial mailing to only those who could pay then perhaps it suddenly becomes worth something. Right now I bet many of you delete mail from legitimate companies almost as fast as you delete spam because you have no time for any of it, you're overloaded. Let's state it extremely: How much would it be worth to a major company to know that for the month of September they will be the only commercial advertisement any of your customers would see? No (other?) spam, no nothing, just "``Lord of the Rings: Book 4'' Opens December 32nd" once a day (whatever!), plus their expected, personal mail. Ok, now work backwards to the only ad today, one of only five today, but not one of several hundred today. Marketeers understand that you pay for exclusivity, this concept won't be foreign to them. One reason you can't really sell it now is, in part, because you've let your "product" (i.e., access to your customers' mailbox) become so diluted it's just about worthless. Q5. WAIT A MINUTE YOU'RE ADVOCATING SPAMMING! A5. Not at all. You could opt to not take any commercial email (or any fees for delivering it), that's up to you and your business model. This idea simply tries to make this controllable by those who ultimately have to provide the infrastructure to deliver the mail. You could say I'm advocating turning commercial advertising via e-mail into a legitimate business. But it would be between an ISP and their customers, not some chicken-boner and the open relays. Q5a. What's a "chicken-boner"? A5a. Oh, it's an expression used in the spam community for a particular imagery of a common type of spammer. An anti-social loser in his double-wide, knee-deep in KFC bones, spewing millions of spam msgs for $50 a contract. Q5b. Isn't that kind of an unfair stereotype? What have you got against KFC? A5b. ENOUGH! Ok? It's an expression, a term of art, and spam is really, really a luncheon meat manufactured by Hormel, Inc. Q6. But many of these spammers work off-shore, they'll just keep doing what they're doing. A6. I can't prove otherwise to you. But my assumption is that given a revenue stream for this kind of advertising (i.e., money to spend) enforcement would become more plausible. You can't sue or prosecute some spammer in Korea now because it would be too much expense and trouble, it's lost money. But a well-funded industry association? Perhaps they could pursue evasion internationally. Also, given a revenue stream model, I'd expect int'l ISPs to get involved in this sort of business (where it's legal), so int'l cooperation to prevent theft-of-service would start to become a possibility. Q7. Ok, so why doesn't anyone do this now if it's such a smart idea? A7. Well, to some extent it will take a groundswell of ISPs moving in this direction, no one of them can really do it on their own. For starters we'd have to get the potential advertisers comfortable with the merits of the idea. The real problem is that certain aspects of the net have evolved badly by themselves, so we need to begin pushing back and creating new realities, such as "if you send out commercial e-mail on the net you will have to pay for it". Q8. Pay who? Every ISP? There are thousands of them! A8. There are thousands of magazines, newspapers, etc. Somehow those ad businesses are manageable. Perhaps many (e.g., smaller ISPs) would give their business to the same agency which would set things up and get them paid, I don't know, but it's hardly evidence of unworkability! Given almost any advertising medium there are thousands of outlets. The advertisers have no particular "right" to be able to advertise to every single internet customer for one easy monthly payment. Q9. Won't this annoy customers? A9. Again, whether and under what conditions your customers get commercial advertising email is between you and your customers (it's your business model to chose.) They don't have to get any if you think that's best. But let's be honest: Times have changed. You can't tell me that your customers don't tolerate commercial e-mail because right now they're getting dozens of such messages per day, maybe per hour. The only problem is that you're not being paid so, for example, the cost of those is just being ripped out of your budgets and hence their customer fees. Maybe you could lower prices or add new services given new revenue sources. Or maybe you just fold it in half and put it in your pocket, again that's your business model to pursue. Q10. How would you make this work? A10. One idea is a cryptographically generated "stamp" which could go in the header of anyone's mail who has paid you to receive their commercial e-mail. Beyond the technical solidity, anyone who tries to thwart the method is clearly counterfeiting and defrauding, so again regular business law applies. Obviously there's more to that but it's beyond the scope of a little FAQ like this. Q11. I dunno, it seems so...different...something has to be wrong. A11. That's not much of an objection, or a question. Q12. If this is a FAQ who asked you all these questions? A12. Um, ok, you caught me, I made them up! But I've certainly heard many of the above objections when I've sounded out this idea before and thought it might be helpful to try to deal with the obvious issues up front rather than as a tedious, piecemeal thread. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
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 rblayzor@inoc.net Exclusive: We're the only ones who have the documentation.
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 rblayzor@inoc.net Life would be much easier if I had the source code.
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 rblayzor@inoc.net
Life would be much easier if I had the source code.
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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 xxxxxxxx@yahoo.com 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
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=story&u=/ap/20020820/ap_wo_en_po/fea_us_spammed_war_of_attrition_1 On Wed, Aug 21, 2002 at 04:17:53PM -0400, Valdis.Kletnieks@vt.edu 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 xxxxxxxx@yahoo.com 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 jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
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 rblayzor@inoc.net Never trust a program unless you have the source.
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 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
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 rblayzor@inoc.net Exclusive: We're the only ones who have the documentation.
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 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
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 rblayzor@inoc.net Exclusive: We're the only ones who have the documentation.
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, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
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 rblayzor@inoc.net Exclusive: We're the only ones who have the documentation.
Yo Robert! On Wed, 21 Aug 2002, Robert Blayzor wrote:
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.
I have complained about every spam I have received in the last ten years. Part of my job as abuse coordinator. I get 50+ spams a day that is 50 complaints a day. I have also called registrars on the phone to complain. None of them has ever done a thing about spammer. Most, if they answer, will send you a form letter saying there is no way they will intervene. They do not want to get in the middle and no-one can put them there.
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.
Why is it silly? I know lots of folks on cable modems that do this. It is not silly when it works and is your only choice. It is not silly for the spammers when it allows them to dodge anti-spam hacks and make more money. I hearby proclaim all spammers to be like nazi propagandists and invoke godwins law to terminate this thread. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Robert Blayzor Sent: August 21, 2002 7:39 PM To: 'Brad Knowles' Cc: nanog@nanog.org 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. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.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 rblayzor@inoc.net Exclusive: We're the only ones who have the documentation.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Robert Blayzor Sent: August 21, 2002 10:53 PM To: 'Vivien M.'; nanog@nanog.org 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. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.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 rblayzor@inoc.net "Unix is simple, but it takes a genius to understand the simplicity." - Dennis Ritchie
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Robert Blayzor Sent: August 21, 2002 7:14 PM To: 'Gary E. Miller' Cc: nanog@nanog.org 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. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
On 04:13 PM 8/21/02, 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.
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".
*yet* The FAQ is a work in progress. Expect to see the "moving packets" phrase added Real Soon Now. jc
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Gary E. Miller Sent: August 21, 2002 5:57 PM To: Robert Blayzor Cc: nanog@nanog.org 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. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.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 gem@rellim.com 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.
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 rblayzor@inoc.net Exclusive: We're the only ones who have the documentation.
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
participants (20)
-
Al Rowland -
Barry Shein -
Brad Knowles -
Derek Samford -
don＠westermann.org -
Gary E. Miller -
Ian Cooper -
J.A. Terranson -
Jared Mauch -
JC Dill -
Larry Rosenman -
Mark Segal -
Peter E. Fry -
Petri Helenius -
Robert A. Hayden -
Robert Blayzor -
Valdis.Kletnieks＠vt.edu -
Vivien M. -
William Rockwood -
william＠elan.net