Re: Fun new policy at AOL
On Fri, 29 Aug 2003 00:05:50 +0100 (BST), Stephen J. Wilcox wrote: On Fri, 29 Aug 2003, Dr. Jeffrey Race wrote: On Thu, 28 Aug 2003 12:07:30 -0400, Matthew Crocker wrote: It can be built without choke points. ISPs could form trust relationships with each other and bypass the central mail relay. AOL for example could require ISPs to meet certain criteria before they are allowed direct connections. ISPs would need to contact AOL, provide valid contact into and accept some sort of AUP (I shall not spam AOL...) and then be allowed to connect from their IPs. AOL could kick that mail server off later if they determine they are spamming. Now there is an idea! However an improved variant is to make the entire internet a 'trust relationship' using the (obvious) steps you propose. For several months I have been pondering possible details of implementing same; see http://www.camblab.com/misc/univ_std.txt. Comments welcome. Surely it already is ? That is I only announce routes of my customers who I trust, my upstreams and peers trust me and what i announce to them, their upstreams/peers do and so on. And yet we still have hijacked netblocks and ddos's with uncaring sysadmins. Why should email be any different? And if you do implement such a system, the spammers will just adapt.. the recent viruses (sobig) are an example of how spammers can open up end user machines to facilitate sending of email, providing they can control such a host they can simply relay thro the providers' smtps.. they dont need open relays to send out their junk! The proposal at http://www.camblab.com/misc/univ_std.txt provides that mail from compromised sources shall be rejected. This forces the host sysadmin to secure his system if he wants to communicate with the rest of the internet. Presently the penalty for negligence is borne by the victim, not the perpetrator. The unique aspect of the proposal is to attach consequences to actions, a principle which is used everywhere in society except the Internet. Jeffrey Race
Re: Fun new policy at AOL
How does this sound for a new mail distribution network. Customers can only send mail through their direct provider ISPs can only send mail to their customers and their upstream provider. Sounds like NIMTP. See Google for more... --Michael Dillon
Re: Fun new policy at AOL
On Fri, Aug 29, 2003 at 02:15:49PM -0400, Matthew Crocker wrote: SMTP_AUTH authenticated users to a mail server. What I'm talking Postfix will let you do SMTP authentication from one mail server to another, and to address the person who said a school was brute- forced, this is from server to server, not everyday-client to server. If you can't set a secure password on server to server relations (it's not like you need to remember it, generate some random concoction of 1-100 characters and use that as a password). It's like the same thing as setting up a BGP password or a RADIUS secret, once it's set, it's not going to be changed often (or at all), let alone remembered.
RE: Fun new policy at AOL
Quoting Vivien M. [EMAIL PROTECTED]: You seem to be misunderstanding the issue. Let's say you work at someplace.edu. You want to send mail from home. With the SPF-type schemes being discussed, your mail MUST come from someplace.edu's server. If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your dialup account will let you use the dialup ISP's mail server... But your mail will get bounced because it's not something from someplace.edu. Hence, if no SMTP AUTH relay, you're screwed. If someplace.edu understands the the basic idea being discussed, one might assume that they wouldn't implement Jim Miller's idea until they've implemented SMTP AUTH (or POP before SMTP) as well. If they don't know about / know how to implement SMTP AUTH, they probably wouldn't bother to make the proper DNS changes to make this idea work. One might also assume that if the MTA used by someplace.edu implements Jim Miller's idea, said MTA is also is modern enough to have support for SMTP AUTH. You may find those to be doubious assumptions, but I don't think they're that unreasonable. The only weakness I see is that spammers could find a domain that doesn't implement Jim Miller's idea and forge mail in their name instead. So what if hotmail.com implements the system? There are 100 million other domain names the spammers could pick from. It's not a solution. It will slow the spammers down. It will inconvenience them. It won't stop them. That doesn't mean it shouldn't be done... just that it's not a panacea, and might not even be that effective. (I wonder if I would get less SPAM if every SMTP server were still an open relay.) By the way, a strengh of this idea that I haven't seen discussed here is that such a system would cut down on the spread (and worthless bounce reports) of current viruses that forge the From: header. -Adam
Re: Fun new policy at AOL
On Fri, Aug 29, 2003 at 04:08:52PM -0400, Vivien M. wrote: If this solution had been implemented 5 years ago instead of the no third party relays system now in place, I wouldn't be opposed to it... But the issue is that the use the local SMTP server to send model is the main one deployed in the field today, and if you start staying NOW that mail must be relayed through a domain's particular SMTP server and that server doesn't support SMTP AUTH relaying, you're now screwed... If spam was as rampant 5 years ago, perhaps this would be in place. Change sucks, doesn't it.
Re: Fun new policy at AOL
On Fri, Aug 29, 2003 at 04:04:42PM -0400, Vivien M. wrote: You seem to be misunderstanding the issue. Let's say you work at someplace.edu. You want to send mail from home. With the SPF-type schemes being discussed, your mail MUST come from someplace.edu's server. If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your dialup account will let you use the dialup ISP's mail server... But your mail will get bounced because it's not something from someplace.edu. Did I miss the obvious? This is not a technical issue. You have presented a case where one lacks the (free) resources needed to perform one's job. This is something you take up with your manager. I could easily do this part during my off hours, it just requires the mail server admin to setup (free) SMTP AUTH s/w to limit access to us employees. If not, the company policy is not to do work during off-hours. It can wait until you get in the next business day. (Note that policy here is defined by the actual behavior, not the statement of policy, which can be wrong) Hence, if no SMTP AUTH relay, you're screwed. Sure. And if they throw the (power) circuit breakers at work, none of my computers work (for long) either. That's not a limitation of the grid. -- Ray Wong [EMAIL PROTECTED]
Re: Fun new policy at AOL
On Fri, 29 Aug 2003, Omachonu Ogali wrote: On Fri, Aug 29, 2003 at 04:08:52PM -0400, Vivien M. wrote: If this solution had been implemented 5 years ago instead of the no third party relays system now in place, I wouldn't be opposed to it... But the issue is that the use the local SMTP server to send model is the main one deployed in the field today, and if you start staying NOW that mail must be relayed through a domain's particular SMTP server and that server doesn't support SMTP AUTH relaying, you're now screwed... If spam was as rampant 5 years ago, perhaps this would be in place. Change sucks, doesn't it. It really doesnt make any difference, if you change the rules by implementing auth etc the spammers will just adopt and it follows that the more thorough you are in the anti-spam measures, the more drastic the spammers will become to maintain their business.. Steve
Re: Fun new policy at AOL
On Sat, Aug 30, 2003 at 12:21:02PM +0100, Stephen J. Wilcox wrote: It really doesnt make any difference, if you change the rules by implementing auth etc the spammers will just adopt and it follows that the more thorough you are in the anti-spam measures, the more drastic the spammers will become to maintain their business.. Yes, it does make a difference. a) Now, there is no longer a gray area with spam, if they are successfully bruteforcing your users' passwords, I believe that falls under unauthorized entry (now, there is no need to go to your senator to ASK them to put anti-spam laws in place), and you can follow this up with your local law enforcement agency. b) This adds an extra step, therefore slowing down their dictionary attacks and relay abuse, resulting in a lot LESS spam. c) I'm also asking for server-to-server authentication among trusted mail servers and administrators, at which point you can ask the other mail server to sign a contract laying out the terms of sending mail to your server (and they can do the same to you) and make them legally liable for any breaches. Hey, now you can actally implement those per message fines in all of your AUPs. d) After reptitive breaches, I'm sure users and administrators would be willing to chip into a lawyer pot (kinda like ISPC) which would make it easier to sue offenders rather than asking themselves is it really worth it to plunk down $10k for some penis enlargement mail. Think of something along the lines of USENET peering, but now with SMTP.
Re: Fun new policy at AOL
In the immortal words of Matthew Crocker ([EMAIL PROTECTED]): Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? Given the way that most ISP shared resource machines (including but hardly limited to DNS caching/recursive resolves, NNTP servers, web caches, and SMTP smarthosts) are administered, the answer to that question is Only if they don't actually care if that mail is ever delivered. -n [EMAIL PROTECTED] For years, I've been predicting that artists, writers, and filmmakers would be paid by the government not to produce work, just like farmers are paid not to grow food. Or that they'd be paid to make their work, but would then be forced to store it in a silo unshown or unread. But now I see I was a little off in my prediction. The Internet is that silo. (--Slotcar Hatebreath) http://blank.org/memory/
Re: Fun new policy at AOL
On Thu, 28 Aug 2003 13:13:31 -0500, John Palmer wrote: I connect with my laptop from 3 or 4 locations to drop off mail to my servers. I cannot use their mail servers from other locations other than when I am connected to them. I have about 2 dozen e-mail accounts defined in outlook express and would have to change the outbound mail server setting for EACH one ever time I move off the RCN connection to one of the other locations from which I work and then back again when I get back to RCN. Do you mean you SEND from each of the two dozen accounts at the new location each time? (I experience the same inconvenience when travelling with my notebook computer i.e. I need to amend the outgoing SMTP server in my mail client on the fly. But it takes only a moment [admittedly I use only two accounts] but it seems like a reasonable rule.) Jeffrey Race
Re: Fun new policy at AOL
On Fri, 29 Aug 2003, Dr. Jeffrey Race wrote: On Thu, 28 Aug 2003 12:07:30 -0400, Matthew Crocker wrote: It can be built without choke points. ISPs could form trust relationships with each other and bypass the central mail relay. AOL for example could require ISPs to meet certain criteria before they are allowed direct connections. ISPs would need to contact AOL, provide valid contact into and accept some sort of AUP (I shall not spam AOL...) and then be allowed to connect from their IPs. AOL could kick that mail server off later if they determine they are spamming. Now there is an idea! However an improved variant is to make the entire internet a 'trust relationship' using the (obvious) steps you propose. For several months I have been pondering possible details of implementing same; see http://www.camblab.com/misc/univ_std.txt. Comments welcome. Surely it already is ? That is I only announce routes of my customers who I trust, my upstreams and peers trust me and what i announce to them, their upstreams/peers do and so on. And yet we still have hijacked netblocks and ddos's with uncaring sysadmins. Why should email be any different? And if you do implement such a system, the spammers will just adapt.. the recent viruses (sobig) are an example of how spammers can open up end user machines to facilitate sending of email, providing they can control such a host they can simply relay thro the providers' smtps.. they dont need open relays to send out their junk! I think we're still trying to treat the symptom tho not the cause. Most of these spammers are companies based within our countries, if we can make their kind of advertising illegal the spam will reduce (not sure if it will disappear, it could be like tax - companies may open offshore offices to facilitate this, but we need to keep working on the cause... ) Steve
RE: Fun new policy at AOL
Susan,
It just ticks me off because I know there are a lot of
others who will be in this boat.
Indeed, there are. I have numerous small customers that have either a
single static IP or a /29 block from {Pacific Bell | your ISP} and that
occasionally are blocked because either the block is marked as
residential or the reverse lookup contains the string dsl.
However, trying to be pragmatic, this is a situation that will
eventually solve by itself: Since having {Pacific Bell | your ISP} do
anything about it is not an option, when these customers are trying to
email to {AOL | some ISP} and are blocked, they will try first to have
if {AOL | some ISP} to whitelist the address; if it can't be done they
will say get an ISP that does not suck.
There are two sides on this coin; one is that indeed this stinks, but
the other one is that AOL receives several billion spams a day, so I can
understand that they're trying to control the problem with the tools
they have.
Curious, have you tried to call AOL to get the IP of the customer
whitelisted?
Michel.
Re: Fun new policy at AOL
On Thu, Aug 28, 2003 at 09:29:42PM -0700, Michel Py wrote:
However, trying to be pragmatic, this is a situation that will
eventually solve by itself: Since having {Pacific Bell | your ISP} do
anything about it is not an option, when these customers are trying to
email to {AOL | some ISP} and are blocked, they will try first to have
if {AOL | some ISP} to whitelist the address; if it can't be done they
will say get an ISP that does not suck.
Of course, it's also possible people will just work around it, like so
many other things. Postfix transport maps allow relaying of specific
domains through (for example) pacbell's mail server, as does Qmail's
smtproute file, no? I'm supporting a handful of smaller sites, and don't
have the time to chase down some support drone to request whitelistings.
It's just too easy to add aol.com SMTP:mail.sbcglobal.net or whatever.
If an incompetently run ISP relay server makes AOL happy, then their
customers can enjoy having mail delayed for the extra hours and maybe
dropped altogether.
Eventually things will implode. Until then, I predict poorly thought
out hacks will be answered with other poorly thought out hacks. =)
--
Ray Wong
[EMAIL PROTECTED]
RE: Fun new policy at AOL
Yo All!
On Thu, 28 Aug 2003, Michel Py wrote:
Indeed, there are. I have numerous small customers that have either a
single static IP or a /29 block from {Pacific Bell | your ISP} and that
occasionally are blocked because either the block is marked as
residential or the reverse lookup contains the string dsl.
Maybe if PacBell (and others) actually disciplined their more out of
control DSL customers then other ISPs would not feel the need to do it
for them.
RGDS
GARY
---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
Re: Fun new policy at AOL
Gary E. Miller wrote: Maybe if PacBell (and others) actually disciplined their more out of control DSL customers then other ISPs would not feel the need to do it for them. It doesn't matter. A large percentage of open proxies are on dynamic DSL. Since a lot of ISPs will not handle proxy reports and take care of the problem, and the blacklists are about useless since the open proxy will switch IPs, it's just best to wipe out the entire dynamic range. -Jack
RE: Fun new policy at AOL
Michel Py writes eating some email from no reason, having limits in attachment size, you can't have a mailing list that way, etc. Roland Perry wrote: Isn't this where we started? One ISP I know decided to limit customers to 200 outgoing recipients a day. Great for stopping spammers, great for stopping anyone running a mailing list, It is where we started indeed. Today it does not really matter if you have 80 persons in the cc: field or if you send 80 individual emails; the individual ones will have the same from: and the same subject and will be blocked as well. And yes I also send email from my mail server with a subject line that contains the name of that drug that everyone wants to sell me or the name of the organ that everyone wants me to enlarge because I want to test the anti-spam system I just configured at some customer site and I don't want that to be blocked either. If ISPs don't want people to run SMTP servers on their DSL line they should provide a top-notch smarthost, which most don't. Michel.
Re: Fun new policy at AOL
Michel Py wrote: If ISPs don't want people to run SMTP servers on their DSL line they should provide a top-notch smarthost, which most don't. The one's that don't provide a top-notch smarthost usually don't handle abuse complaints either. Just what do they do for their customers? I'm curious. -Jack
RE: Fun new policy at AOL
Michel Py wrote: If ISPs don't want people to run SMTP servers on their DSL line they should provide a top-notch smarthost, which most don't. Jack Bates wrote: The one's that don't provide a top-notch smarthost usually don't handle abuse complaints either. True. sigh. Just what do they do for their customers? I'm curious. They provide the local loop and IP transit, which are the only two things a significant part of non-dial-up customers care about. Michel.
Re: Fun new policy at AOL
On Thu, Aug 28, 2003 at 10:06:10AM -0400, Roland Perry wrote: Here's another tale of undeliverable email. It seems that [at least] one of those organisations you mention assigns IP addresses for its ADSL customers from the same blocks as dial-up. Which means that organisations using MAPS-DUL reject email from teleworkers (or indeed people running businesses with an ADSL connection) who run their own SMTP servers. In which case, the telecommuters should use their organization's mail servers with SMTP authentication (yes, authentication, not pop-before-smtp). If I'm a corporation, and you're my employee, you should be using my VPN, not sending mail from your unsupported remote installation running sendmail, qmail, exim, postfix, or whatever. As for the business people, can't give you any advice there. Maybe it's time to invest in some mail services from mail.com, Critical Path, or maybe even your ISP.
Re: Fun new policy at AOL
At 08:37 AM 8/29/2003, Jack Bates wrote: Michel Py wrote: If ISPs don't want people to run SMTP servers on their DSL line theyshould provide a top-notch smarthost, which most don't. The one's that don't provide a top-notch smarthost usually don't handle abuse complaints either. Just what do they do for their customers? I'm curious. They provide a low priced connection between the customer's location and a router connected to the Internet. The biggest problem is that to most customers, there's not a lot of obvious difference between a poorly supported cheap DSL line from ISP A and a well supported more expensive DSL line from ISP B. So they don't see the point in paying anything more than the rock-bottom-lowest-price for DSL service. The fact that they get what they pay for is overlooked. jc
Re: Fun new policy at AOL
On donderdag, aug 28, 2003, at 20:10 Europe/Amsterdam, Paul Vixie wrote: Play with DNS MX records like QMTP does. here are at least two problems with this approach. one is that an mx priority is a 16 bit unsigned integer, not like your example. another is that spammers do not follow the MX protocol, they deliberately dump on higher cost relays in order to make the victim's own inbounds carry more of the total workload of delivery. (additionally, many hosts do more spam filtering on their lower cost MX's than on their higher cost (backup?) MX's, and the spammers know this, and take advantage of it.) Yes, that's why I don't use my ISP's servers as MX for my domains anymore. Having fallback MXes that only queue the mail for a while don't provide any real benefits anyway. But how about this: in addition to MX hosts, every domain also has one or more MO (mail originator) hosts. Mail servers then get to check the address of the SMTP server they're talking to against the DNS records for the domain in the sender's address. Then customers who use an email address under their ISP's domain have to use the ISP's relay, while people with their own (sub) domain get to use their own. For AOL and the likes this would also help against spam as they can rate limit incoming mail from unknown domains. Spammers are forced to register new domains all the time in addition to having to find abusable IP addresses so hopefully life for them will be a little more miserable too. (Could reuse MX for this if a new RR is too much hassle, but large ISPs don't use the same SMTP servers for incoming as for outgoing.)
Re: Fun new policy at AOL
But how about this: in addition to MX hosts, every domain also has one or more MO (mail originator) hosts. Mail servers then get to check the address of the SMTP server they're talking to against the DNS records for the domain in the sender's address. Then customers who use an email address under their ISP's domain have to use the ISP's relay, while people with their own (sub) domain get to use their own. a fine idea. thank jim miller for it if you see him. For AOL and the likes this would also help against spam as they can rate limit incoming mail from unknown domains. Spammers are forced to register new domains all the time in addition to having to find abusable IP addresses so hopefully life for them will be a little more miserable too. (Could reuse MX for this if a new RR is too much hassle, but large ISPs don't use the same SMTP servers for incoming as for outgoing.) see below. IndependentPaul Vixie (Ed.) Request for Comments: Category: Experimental June 6, 2002 Repudiating MAIL FROM Status of this Memo This memo describes an experimental procedure for handling received e-mail. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract At the time of this writing, more than half of all e-mail received by the author has a forged return address, due to the total absence of address authentication in SMTP (see [RFC2821]). We present a simple and backward compatible method whereby cooperating e-mail senders and receivers can detect forged source/return addresses in e-mail. 1 - Introduction and Overview 1.1. Internet e-mail return addresses are nonrepudiable by design of the relevant transport protocols (see [RFC2821]). Simply put, there is no cause for ANY confidence in the proposition this e-mail came from where it says it came from. 1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail routinely use this designed-in lack of source/return authenticity to hide their point of origin, which usually involves forging a valid return address belonging to some highly visible and popular ISP (for example, HOTMAIL.COM). 1.3. Recipients who wish to reject unwanted bulk e-mail containing forged source/return addresses are prevented from doing so since the addresses, as presented, are nonrepudiable by design. Simply put, there would be too many false positives, and too much valid e-mail rejected, if one were to program an e-mail relay to reject all e-mail claiming to be from HOTMAIL.COM since, statistically, most e-mail claiming to be from HOTMAIL.COM is actually from somewhere else. HOTMAIL.COM, in this example, is a victim of forgery. Vixie Experimental [Page 1] RFC Repudiating MAIL FROM May 26, 2002 1.4. What's needed is a way to guaranty that each received e-mail message did in fact come from some mail server or relay which can rightfully originate or relay messages from the purported source/return address. 1.5. Approaches of the form use PGP and use SSL are not scalable in the short term since they depend on end-to-end action and there are just too many endpoints. An effective solution has to be applicable to mail relay, not just final delivery. 1.6. Valid (wanted) e-mail must not be rejected by side effect or partial adoption of this proposal. Source/return authenticity must be a confidence effector, as in we can be sure that this did not come from where it claims and simple uncertainty must remain in effect otherwise. 2 - Behaviour 2.1. Domain owners who wish their mail source/return information to be repudiable will enter stylized MX RR's into their DNS data, whose owner name is MAIL-FROM, whose priority is zero, and whose servername registers an outbound (border) relay for the domain. For example, to tell the rest of the Internet who they should believe when they receive mail claiming to be from [EMAIL PROTECTED], the following DNS MX RR's should be entered: $ORIGIN isc.org. MAIL-FROM MX 0 rc MX 0 rc1 In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as appropriate places to originate mail from @ISC.ORG. Note that this differs from the normal inbound MX RRset for this example domain: $ORIGIN isc.org. @ MX 0 rc MX 0 isrv4 So, the inbound mail server set partially overlaps with, but differs from, the example outbound mail server set. This is quite common in the Internet, and is the reason why the normal inbound mail server set described by a domain's apex MX RRset cannot be
Re: Fun new policy at AOL
trusted-mx.crocker.com uses DNSRTTL (Real Time Trust List) to only accept connections from IPs it trusts. Hate to break up your envisionary experiences and insight into reinventing the wheel, but what happened to consideration of SMTP authentication?
Re: Fun new policy at AOL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Omachonu Ogali wrote: |trusted-mx.crocker.com uses DNSRTTL (Real Time Trust List) to only |accept connections from IPs it trusts. | | | Hate to break up your envisionary experiences and insight into | reinventing the wheel, but what happened to consideration of | SMTP authentication? It's only as good as the strength of your user community's passwords. A friend of mine supports a school's servers and they were brute forced the other day resulting in essentially an open relay for the spammers. Auth is nice, but not enough. = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (MingW32) iD8DBQE/T5N3E1XcgMgrtyYRAhEqAJ0WiFj5AsQ/PxVngx2UGglN9QkPfACg3rKY gr9y5pQalwSdaqKVgkuJKQM= =UF7i -END PGP SIGNATURE-
Re: Fun new policy at AOL
In article [EMAIL PROTECTED], Iljitsch van Beijnum [EMAIL PROTECTED] wrote: But how about this: in addition to MX hosts, every domain also has one or more MO (mail originator) hosts. Mail servers then get to check the address of the SMTP server they're talking to against the DNS records for the domain in the sender's address. Then customers who use an email address under their ISP's domain have to use the ISP's relay, while people with their own (sub) domain get to use their own. Google for RMX DNS. There's a few other proposals too; see for example http://spf.pobox.com/ Mike. -- RAND USR 16514
Re: Fun new policy at AOL
But how about this: in addition to MX hosts, every domain also has one or more MO (mail originator) hosts. Mail servers then get to check the address of the SMTP server they're talking to against the DNS records for the domain in the sender's address. Then customers who use an email address under their ISP's domain have to use the ISP's relay, while people with their own (sub) domain get to use their own. I travel around. I read my email by POP3/IMAP, I use local ISP's SMTP server for outgoing - surely that means I can't use my own domain for email? Simon -- Simon Lockhart | Tel: +44 (0)1628 407720 (x37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x37701) | non sit, noli BBC Internet Operations | Email: [EMAIL PROTECTED]| id reficere BBC Technology, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK
Re: Fun new policy at AOL
On Fri, 29 Aug 2003, Simon Lockhart wrote: I travel around. I read my email by POP3/IMAP, I use local ISP's SMTP server for outgoing - surely that means I can't use my own domain for email? Time to switch to SMTP AUTH and use the same relay always. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: Fun new policy at AOL
[Note: I posted something else on this topic, but it doesn't appear to have made it through yet...] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mikael Abrahamsson Sent: August 29, 2003 3:20 PM To: [EMAIL PROTECTED] Subject: Re: Fun new policy at AOL On Fri, 29 Aug 2003, Simon Lockhart wrote: I travel around. I read my email by POP3/IMAP, I use local ISP's SMTP server for outgoing - surely that means I can't use my own domain for email? Time to switch to SMTP AUTH and use the same relay always. And what do you do if you're not the admin for the relay? And what about if the admin tells you This is why we installed some webmail package. Use that instead.? Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: Fun new policy at AOL
I travel around. I read my email by POP3/IMAP, I use local ISP's SMTP server for outgoing - surely that means I can't use my own domain for email? Your ISP should support SMTP_AUTH with TLS for you. You would continue to use their mail servers no matter where you are or how you are connected to the Internet. -Matt Simon -- Simon Lockhart | Tel: +44 (0)1628 407720 (x37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x37701) | non sit, noli BBC Internet Operations | Email: [EMAIL PROTECTED]| id reficere BBC Technology, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK
RE: Fun new policy at AOL
On Fri, 29 Aug 2003, Vivien M. wrote: And what do you do if you're not the admin for the relay? And what about if the admin tells you This is why we installed some webmail package. Use that instead.? You switch service provider or give them a whack with the cluebat. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: Fun new policy at AOL
-Original Message- From: Mikael Abrahamsson [mailto:[EMAIL PROTECTED] Sent: August 29, 2003 3:44 PM To: Vivien M. Cc: [EMAIL PROTECTED] Subject: RE: Fun new policy at AOL On Fri, 29 Aug 2003, Vivien M. wrote: And what do you do if you're not the admin for the relay? And what about if the admin tells you This is why we installed some webmail package. Use that instead.? You switch service provider or give them a whack with the cluebat. And if the service provider is your employer/educational institution? You quit your job? Drop out of school? Swallow your pride and suffer with webmail? Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: Fun new policy at AOL
Mikael Abrahamsson wrote: You switch service provider or give them a whack with the cluebat. Some providers don't support auth do to the insecure passwords their users have. Having your server opened up to relay spam because your user had a bad password is not a good prospect. -Jack
RE: Fun new policy at AOL
At 12:32 PM 8/29/2003, Vivien M. wrote: Time to switch to SMTP AUTH and use the same relay always. And what do you do if you're not the admin for the relay? And what about if the admin tells you This is why we installed some webmail package. Use that instead.? Either the webmail solution meets your needs, or you need to obtain service from a company that offers a solution that meets your needs. Why is this so hard to understand? jc
Re: Fun new policy at AOL
You switch service provider or give them a whack with the cluebat. And if the service provider is your employer/educational institution? You quit your job? Drop out of school? Swallow your pride and suffer with webmail? Spend $19.95 getting a dialup account for an ISP with a clue and use their mail servers. If employed charge the $20/month on your expense report.
RE: Fun new policy at AOL
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Crocker Sent: August 29, 2003 3:58 PM To: Vivien M. Cc: 'Mikael Abrahamsson'; [EMAIL PROTECTED] Subject: Re: Fun new policy at AOL You switch service provider or give them a whack with the cluebat. And if the service provider is your employer/educational institution? You quit your job? Drop out of school? Swallow your pride and suffer with webmail? Spend $19.95 getting a dialup account for an ISP with a clue and use their mail servers. If employed charge the $20/month on your expense report. You seem to be misunderstanding the issue. Let's say you work at someplace.edu. You want to send mail from home. With the SPF-type schemes being discussed, your mail MUST come from someplace.edu's server. If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your dialup account will let you use the dialup ISP's mail server... But your mail will get bounced because it's not something from someplace.edu. Hence, if no SMTP AUTH relay, you're screwed. Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
RE: Fun new policy at AOL
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JC Dill Sent: August 29, 2003 3:43 PM To: [EMAIL PROTECTED] Subject: RE: Fun new policy at AOL At 12:32 PM 8/29/2003, Vivien M. wrote: Time to switch to SMTP AUTH and use the same relay always. And what do you do if you're not the admin for the relay? And what about if the admin tells you This is why we installed some webmail package. Use that instead.? Either the webmail solution meets your needs, or you need to obtain service from a company that offers a solution that meets your needs. Why is this so hard to understand? Because you're not understanding the issue... If you get an email account from your employer/educational institution/etc and have to access it from home and send mail from it, you can't obtain service from a company that offers a solution that meets your needs. If you can't convince your admins (and good luck if you don't work in the IT department) that they need to set up SMTP AUTH, then you are screwed... Get used to dialing into your employer/educational institution/etc's network to do email, simply to comply with these things, or hello webmail. And how will you explain to people who quite happily have their POP3 clients set up to get mail from their work's POP3 server, and SMTP to their local ISP that suddenly they can't do it that way anymore? If this solution had been implemented 5 years ago instead of the no third party relays system now in place, I wouldn't be opposed to it... But the issue is that the use the local SMTP server to send model is the main one deployed in the field today, and if you start staying NOW that mail must be relayed through a domain's particular SMTP server and that server doesn't support SMTP AUTH relaying, you're now screwed... Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
RE: Fun new policy at AOL
At 12:45 PM 8/29/2003, Vivien M. wrote: On Fri, 29 Aug 2003, Vivien M. wrote: And what do you do if you're not the admin for the relay? And what about if the admin tells you This is why we installed some webmail package. Use that instead.? You switch service provider or give them a whack with the cluebat. And if the service provider is your employer/educational institution? You quit your job? Drop out of school? Swallow your pride and suffer with webmail? You do the same thing you do when they implement other stupid policies - you live with the policy, or you work around it. If your school makes a stupid policy that you can't park your car between the hours of 8 am and 9 am, you get there before 8 or after 9, or you have a friend drop you off, or take the bus, or you pay to park in the lot across the street. jc
Re: Fun new policy at AOL
On Fri, 29 Aug 2003 14:47:50 CDT, Jack Bates said: Mikael Abrahamsson wrote: You switch service provider or give them a whack with the cluebat. Some providers don't support auth do to the insecure passwords their users have. Having your server opened up to relay spam because your user had a bad password is not a good prospect. So the provider allows the user to pick an insecure password, and then complains that they can't support a security measure because of their poor policy choices/enforcement? Hey Mikael, hand me that cluebat.. pgp0.pgp Description: PGP signature
Re: Fun new policy at AOL
You seem to be misunderstanding the issue. Let's say you work at someplace.edu. You want to send mail from home. With the SPF-type schemes being discussed, your mail MUST come from someplace.edu's server. If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your dialup account will let you use the dialup ISP's mail server... But your mail will get bounced because it's not something from someplace.edu. Hence, if no SMTP AUTH relay, you're screwed. Port forward 127.0.0.1:25 through to someplace.edu:25 using SSH. Or VPN. Or ... More than one way to skin this cat. -matt
RE: Fun new policy at AOL
-Original Message- From: Matthew Crocker [mailto:[EMAIL PROTECTED] Sent: August 29, 2003 4:16 PM To: Vivien M. Cc: 'Mikael Abrahamsson'; [EMAIL PROTECTED] Subject: Re: Fun new policy at AOL Port forward 127.0.0.1:25 through to someplace.edu:25 using SSH. Or VPN. Or ... More than one way to skin this cat. If you have a shell account on someplace.edu, yes, I agree, that's probably the best way (and if anyone looks at the headers of this message, that's how I've been doing SMTP for like three years now... Too lazy to set up SMTP AUTH somewhere where I'm the admin). But if you have no shell account, or you're not technologically clueful, you're still hopeless... So, the conclusion still seems to be that SPF and such things will break your email, unless i) SMTP AUTH is available ii) You're sufficiently clueful (and required things like VPN, SSH, etc are available) that you can implement a workaround. Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: Fun new policy at AOL
Is this being added to a bind 9 rewrite? If so, when can we expected it to be released? :) On Fri, Aug 29, 2003 at 04:47:58PM +, Paul Vixie wrote: But how about this: in addition to MX hosts, every domain also has one or more MO (mail originator) hosts. Mail servers then get to check the address of the SMTP server they're talking to against the DNS records for the domain in the sender's address. Then customers who use an email address under their ISP's domain have to use the ISP's relay, while people with their own (sub) domain get to use their own. a fine idea. thank jim miller for it if you see him. For AOL and the likes this would also help against spam as they can rate limit incoming mail from unknown domains. Spammers are forced to register new domains all the time in addition to having to find abusable IP addresses so hopefully life for them will be a little more miserable too. (Could reuse MX for this if a new RR is too much hassle, but large ISPs don't use the same SMTP servers for incoming as for outgoing.) see below. IndependentPaul Vixie (Ed.) Request for Comments: Category: Experimental June 6, 2002 Repudiating MAIL FROM Status of this Memo This memo describes an experimental procedure for handling received e-mail. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract At the time of this writing, more than half of all e-mail received by the author has a forged return address, due to the total absence of address authentication in SMTP (see [RFC2821]). We present a simple and backward compatible method whereby cooperating e-mail senders and receivers can detect forged source/return addresses in e-mail. 1 - Introduction and Overview 1.1. Internet e-mail return addresses are nonrepudiable by design of the relevant transport protocols (see [RFC2821]). Simply put, there is no cause for ANY confidence in the proposition this e-mail came from where it says it came from. 1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail routinely use this designed-in lack of source/return authenticity to hide their point of origin, which usually involves forging a valid return address belonging to some highly visible and popular ISP (for example, HOTMAIL.COM). 1.3. Recipients who wish to reject unwanted bulk e-mail containing forged source/return addresses are prevented from doing so since the addresses, as presented, are nonrepudiable by design. Simply put, there would be too many false positives, and too much valid e-mail rejected, if one were to program an e-mail relay to reject all e-mail claiming to be from HOTMAIL.COM since, statistically, most e-mail claiming to be from HOTMAIL.COM is actually from somewhere else. HOTMAIL.COM, in this example, is a victim of forgery. Vixie Experimental [Page 1] RFC Repudiating MAIL FROM May 26, 2002 1.4. What's needed is a way to guaranty that each received e-mail message did in fact come from some mail server or relay which can rightfully originate or relay messages from the purported source/return address. 1.5. Approaches of the form use PGP and use SSL are not scalable in the short term since they depend on end-to-end action and there are just too many endpoints. An effective solution has to be applicable to mail relay, not just final delivery. 1.6. Valid (wanted) e-mail must not be rejected by side effect or partial adoption of this proposal. Source/return authenticity must be a confidence effector, as in we can be sure that this did not come from where it claims and simple uncertainty must remain in effect otherwise. 2 - Behaviour 2.1. Domain owners who wish their mail source/return information to be repudiable will enter stylized MX RR's into their DNS data, whose owner name is MAIL-FROM, whose priority is zero, and whose servername registers an outbound (border) relay for the domain. For example, to tell the rest of the Internet who they should believe when they receive mail claiming to be from [EMAIL PROTECTED], the following DNS MX RR's should be entered: $ORIGIN isc.org. MAIL-FROM MX 0 rc MX 0 rc1 In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as appropriate places to originate mail from @ISC.ORG. Note that this differs from the normal inbound MX RRset for this example domain: $ORIGIN isc.org. @ MX 0 rc MX 0 isrv4
Re: Fun new policy at AOL
In article [EMAIL PROTECTED], Omachonu Ogali [EMAIL PROTECTED] writes In which case, the telecommuters should use their organization's mail servers with SMTP authentication (yes, authentication, not pop-before-smtp). I'm a telecommuter, I'm also a freelance, so my organisation is me. I like the idea of running a reliable mail server with authentication, at my home base. Which is my home. I just have to get AOL not to define it as residential. -- Roland Perry
RE: Fun new policy at AOL
Then why not just pay a Virtual Mail hosting company to host a mail server for you via Imail or one of the other virtual email service packages out there. It is very inexpensive most of the time. That way you have the flexibility of having your own mail server, plus (most of the time) the server is hosted in a controlled environment (ie power, AC, network) et cetera, the benefits are endless. Thanks, -Drew -Original Message- From: Roland Perry [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 4:42 PM To: [EMAIL PROTECTED] Subject: Re: Fun new policy at AOL In article [EMAIL PROTECTED], Omachonu Ogali [EMAIL PROTECTED] writes In which case, the telecommuters should use their organization's mail servers with SMTP authentication (yes, authentication, not pop-before-smtp). I'm a telecommuter, I'm also a freelance, so my organisation is me. I like the idea of running a reliable mail server with authentication, at my home base. Which is my home. I just have to get AOL not to define it as residential. -- Roland Perry
Re: Fun new policy at AOL
JC Dill wrote: Either the webmail solution meets your needs, or you need to obtain service from a company that offers a solution that meets your needs. Why is this so hard to understand? Or people implement a protocol that doesn't break existing uses of the system (let's not forget the issues with many mailing-lists and .forward files). Personally, I like the idea of verifying that an IP address that is sending mail is allowed to send mail according to domain X, which is either verified by the mail from rhs or by the (he|eh)lo parameter. One or the other should be able to be verified; mail from rhs when at the home network and (he|eh)lo parameter at remote sites. Checking the MX records for each would make a good portion of the current mail servers compliant (except those with seperate outbound/inbound servers) and having a different tag (txt, new DNS record, special dns tag like outmail.fqdn) would allow outbound only servers to quickly meet compliance. It's quicker and more simplistic than any proposal I've read. It doesn't break anonymous forwarding or sending mail through other provider's smtp servers. What it does do is verify that someone is responsible for that mail connection and that someone is domain X without arguement. I don't care if envelopes appear to be forged. It's done regularly in production. What I do care about is being able to say that someone is responsible for the email. If domain X said that a server can send mail outbound and it's not the mail I wanted, holder of domain X is liable and lawyers can do the dirty work they are paid for. Or at a minimum, I can block domain X and not feel bad about it. -Jack
Re: Fun new policy at AOL
In article [EMAIL PROTECTED], Drew Weaver [EMAIL PROTECTED] writes Then why not just pay a Virtual Mail hosting company to host a mail server for you via Imail or one of the other virtual email service packages out there. It is very inexpensive most of the time. That way you have the flexibility of having your own mail server, plus (most of the time) the server is hosted in a controlled environment (ie power, AC, network) et cetera, the benefits are endless. I do that for POP3, but suppliers of a similar service for outbound mail clearly need a new marketing department. -- Roland Perry
Re: Fun new policy at AOL
[EMAIL PROTECTED] wrote: So the provider allows the user to pick an insecure password, and then complains that they can't support a security measure because of their poor policy choices/enforcement? You have an easy way to change password enforcement of an existing user base? Dealing with people infected with the latest worms has increased workloads across the board. That's only a small percentage of the user base. Password enforcement on an existing user base will cause problems for a majority of the user base. Proprietary dialers help, but have their own problems. If you use the mail interface to change the dialup passwords, you'll get calls from users that can no longer dial in; otherwise you fragment passwords on an account and add overhead that's unnecessary. Adding the policy and waiting for it to rotate out would take over a decade. I wouldn't recommend a policy change like that for any user base over 10,000. -Jack
Re: Fun new policy at AOL
On Fri, 29 Aug 2003 16:19:28 CDT, Jack Bates said: I wouldn't recommend a policy change like that for any user base over 10,000. So you're saying that because you've got too many users with dumb passwords, that's justification for not fixing it? ;) /Valdis (and yes, we're in the middle of a multi-month deployment of better password policies for some 40K entities, so been there, done that) pgp0.pgp Description: PGP signature
Re: Fun new policy at AOL
At 02:34 AM 8/28/2003 -0500, Susan Zeigler wrote: WTF. This IP is NOT dynamic. The client has had it for about two years. What is the IP address they are rejecting ? Unless AOL is downloading the entire routing pools from all ISPs on a daily basis, how do they know which IPs are dynamic and which are static;) What would BGP tables tell you about internal routing and DNS ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Fun new policy at AOL
I just looked on their website to file a complaint and ask how they determined what was dynamic and what was static and couldn't find a contact email address. I did find the following statement: AOL's mail servers will not accept connections from systems that use dynamically assigned IP addresses. It was on the following page: http://postmaster.info.aol.com/standards.html Whoa.. thats crazy. Obviously its an effort to stop relay forwarding from cable modem and DSL customers but there are *lots* of legitimate smtp servers sitting on customer sites on dynamic addresses. I've numerous customers I can think of straight away who use setups such a MS Exchange on dynamic addresses where they poll POP3 boxes and send their own SMTP!
Re: Fun new policy at AOL
On Thu, 28 Aug 2003 10:10 (UTC) Stephen J. Wilcox [EMAIL PROTECTED] wrote: | Whoa.. thats crazy. Obviously its an effort to stop relay forwarding | from cable modem and DSL customers but there are *lots* of legitimate | smtp servers sitting on customer sites on dynamic addresses. And at one time it was considered helpful for mail servers to relay anything that was presented to them. We don't think that way now, as a DIRECT result of the way in which that arrangement has been abused. So with legitimate smtp servers sitting on customer sites on dynamic addresses: the flexibility and convenience of such arrangements became subsidiary to the abuse and security issues they facilitated. Now if the abuse and security teams of the large providers would move *quickly* to isolate compromised machines and deal with other security related issues when they arise, the flexibility and convenience would probably win out in the end. But as things stand it isn't going to. We can thank the usual suspects - Cogent, Qwest, ATT, Comcast - and in Europe: BT, NTL and possibly the world-abuse-leader, Deutsche Telekom (who run dtag.de and t-dialin.net) for this being the situation. They may think it's better for their bottom line to de-resource their security and abuse departments, and better for their customers to let them stay online while issues are resolved, but they remain oblivious to the harm this policy is doing to the internet community as a whole. | I've numerous customers I can think of straight away who use setups | such a MS Exchange on dynamic addresses where they poll POP3 boxes | and send their own SMTP! The fact that it is impossible to readily distinguish between their IPs and those of compromised boxes running Jeem etc, will mean that those sites are already likely to be experiencing significant mail rejection - and that will get worse, not better. Unless there is a turn-around soon in the attitude of backbones and other providers, I can see a registered SMTP senders only policy being put in place by the majority of sites by the end of 2004. Or possibly sooner. AOL's mail handling policy may be disappointing - but those of us who have been hit by their other disappointing mail policy (of accepting all undeliverable mail and then bouncing it to the (forged) sender), may see this as actually improving the situation because it visibly reduces the quantity of forged bounces *we* see originating from AOL! -- Richard Cox %% HELO - the first word of every Email transaction - is in Welsh! %%
Re: Fun new policy at AOL
Funny, I didn't think this was 'aol-mail-policy-list'. This isn't new, crazy, nor out of step with generally accepted practices. They [and many others] have been doing it for a while. A dynamic block is generally listed as such in a service provider's reverse DNS and also often in a voluntary listing such as the DUL. AOL's specific definition is point 12 on their postmaster FAQ (http://postmaster.info.aol.com/faq.html). If a service provider is providing business/static addressing and not making it clear, thats a customer-provider issue. Whoa.. thats crazy. Obviously its an effort to stop relay forwarding from cable modem and DSL customers but there are *lots* of legitimate smtp servers sitting on customer sites on dynamic addresses. I suspect your definition of legitimate is different than the service providers' on whose network these machines are sitting. Use the submit protocol for client/end stations. SMTP is for inter-server traffic; if you have a server on a residential connection, check your service agreement. If you have a business service being incorrectly tagged as residential, then you have a legitimate beef - with your provider. Not AOL and not NANOG. I've numerous customers I can think of straight away who use setups such a MS Exchange on dynamic addresses where they poll POP3 boxes and send their own SMTP! POP XMIT; SUBMIT [even MS products support it]. Use TLS if you care that your customers are sharing their passwords in the clear. Anyway, [EMAIL PROTECTED] might be more interested in your concerns. Then again, they set the rules for their network, so they might not. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Fun new policy at AOL
On Thu, 28 Aug 2003, Stephen J. Wilcox wrote: I just looked on their website to file a complaint and ask how they determined what was dynamic and what was static and couldn't find a contact email address. I did find the following statement: AOL's mail servers will not accept connections from systems that use dynamically assigned IP addresses. It was on the following page: http://postmaster.info.aol.com/standards.html Whoa.. thats crazy. Obviously its an effort to stop relay forwarding from cable modem and DSL customers but there are *lots* of legitimate smtp servers sitting on customer sites on dynamic addresses. I've numerous customers I can think of straight away who use setups such a MS Exchange on dynamic addresses where they poll POP3 boxes and send their own SMTP! ...and I can think of alot of servers that will BL those customers. DUL blacklists are very commonly used. However legitimate these MS Exchange servers are, they'd better get a static IP if they want to avoid problems with many recipients. My guess is that since many of the BL's are being DDoS'd. perhaps AOL came up with their own, possibly out of date DUL-type BL... James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: Fun new policy at AOL
In article [EMAIL PROTECTED], Joe Provo nanog- [EMAIL PROTECTED] writes AOL's specific definition is point 12 on their postmaster FAQ (http://postmaster.info.aol.com/faq.html). That's their definition of Residential IP, not Dynamic IP. if you have a server on a residential connection, check your service agreement. My own ISP has DSL products called Home Based Business (and provide static IP addressing). Residential and Business are not mutually exclusive. -- Roland Perry
Re: Fun new policy at AOL
In article [EMAIL PROTECTED], Richard Cox [EMAIL PROTECTED] writes We can thank the usual suspects - Cogent, Qwest, ATT, Comcast - and in Europe: BT, NTL and possibly the world-abuse-leader, Deutsche Telekom (who run dtag.de and t-dialin.net) for this being the situation. Here's another tale of undeliverable email. It seems that [at least] one of those organisations you mention assigns IP addresses for its ADSL customers from the same blocks as dial-up. Which means that organisations using MAPS-DUL reject email from teleworkers (or indeed people running businesses with an ADSL connection) who run their own SMTP servers. -- Roland Perry
Re: Fun new policy at AOL
In article [EMAIL PROTECTED], Richard Cox [EMAIL PROTECTED] writes We can thank the usual suspects - Cogent, Qwest, ATT, Comcast - and in Europe: BT, NTL and possibly the world-abuse-leader, Deutsche Telekom (who run dtag.de and t-dialin.net) for this being the situation. Here's another tale of undeliverable email. It seems that [at least] one of those organisations you mention assigns IP addresses for its ADSL customers from the same blocks as dial-up. Which means that organisations using MAPS-DUL reject email from teleworkers (or indeed people running businesses with an ADSL connection) who run their own SMTP servers. -- Roland Perry Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? We block outbound port 25 connections on our dialup and DSL pool. We ask our customers that have their own mail servers to configure them to forward through our mail servers. We get SPAM/abuse notifications that way and can kick the customer off the network. We also block inbound port 25 connections unless they are coming from our mail server and require the customer setup their MX record to forward through our mail server. We virus scan all mail coming and going that way. We protect our customers from the network and our network from our customers. We are currently blocking over 3k Sobigs/hour on our mail servers. I would rather have that then all my bandwidth eaten up by Sobig on all of my dialup/DSL connections. SMTP DNS should be run through the servers provided by the ISP for the exact purpose. There is no valid reason for a dialup customer to go direct to root-servers.net and there is no reason why a dialup user should be sending mail directly to AOL, or any mail server for that matter (besides their host ISP) -Matt
Re: Fun new policy at AOL
Sometime mid last week, one of my clients--a state chapter of a national association--became unable to send to all of their AOL members. Assuming it was simply that AOLs servers were inundated with infected emails, I gave it some time. The errors were simply delay and not delivered in time specified errors. AOL appear to have recently changed their MX receiving policies, see the following demon.announce post: http://groups.google.com/groups?selm=xVIP4XA5f7M%24EwzW%40demon.netoe=UTF-8 output=gplain --- cut here --- One such scheme uses a list of end user IP addresses on the basis that such users will only be sending legitimate email via their own ISP's smarthost email server. The idea is that the blocklist will be able to block non-legitimate email because it arrives directly. In particular it should block spam sent via insecure systems or virus/worm infections. We have recently been in discussion with AOL who are, at a future date, planning to implement just such a scheme as they have found, working with many ISPs around the world, that it significantly impacts their incoming spam volumes. --- cut here --- Regards, Jonathan
Re: Fun new policy at AOL
On Thursday, August 28, 2003 4:18 PM, Matthew Crocker [EMAIL PROTECTED] wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? At least here in DE there are resellers of DTAG which offer DSL connections without any SMTP relay. If you want relaying you also have to order a domain via them. More funny: you cannot deliver mails to DTAG (actually T-Online) as the resellers use address space of DTAG and hence the DTAG servers believe you are a customer of them and should use the internal relays ... Arnold
Re: Fun new policy at AOL
On Thu, 28 Aug 2003, Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? Also depends on how much clue said ISP has. I have a DSL-like connection at home from a large LEC/ISP, but half the time their mail server either doesn't respond or rejects me. If I was more concerned, I would just set up my own mail server here and be done with it. As it is, I use ssh/pine. But there's another good reason for customers to use their own mail server. Aaron
Re: Fun new policy at AOL
On Thu, 28 Aug 2003, Nipper, Arnold wrote: On Thursday, August 28, 2003 4:18 PM, Matthew Crocker [EMAIL PROTECTED] wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? At least here in DE there are resellers of DTAG which offer DSL connections without any SMTP relay. If you want relaying you also have to order a domain via them. More funny: you cannot deliver mails to DTAG (actually T-Online) as the resellers use address space of DTAG and hence the DTAG servers believe you are a customer of them and should use the internal relays ... I think that is also true of BT in the UK who as the incumbent are the only provider of things like unmetered dialup.. Steve
Re: Fun new policy at AOL
SMTP DNS should be run through the servers provided by the ISP for the exact purpose. There is no valid reason for a dialup customer to ^ OH YES THERE IS (at least to a different resolver other than yours) go direct to root-servers.net and there is no reason why a dialup user should be sending mail directly to AOL, or any mail server for that matter (besides their host ISP) -Matt Except for the fact the your DNS server may be using a root cache file that points to the restrictive USG root network that is currently controlled by a a corrupt monopoly. What about customers who want to use ORSC or Pacificroot? There are about 11,000 TLDs out there and you want to limit your customers to have to suffer under the current totalitarian dictatorship? I wouldn't ever be a customer of your's.
Re: Fun new policy at AOL
In article [EMAIL PROTECTED], Matthew Crocker [EMAIL PROTECTED] writes Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? We block outbound port 25 connections on our dialup and DSL pool. [snip] there is no reason why a dialup user should be sending mail directly to AOL, or any mail server for that matter (besides their host ISP) Dial-up, I agree. DSL is a slightly different story. And I'm as much against Spam as anyone. -- Roland Perry
Re: Fun new policy at AOL
Speaking on Deep Background, the Press Secretary whispered: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? applying that standard just how large do you have to get before you graduate to running your own smtp server. I'm sorry we won't accept mail from you because you're not an lir? Yea! I think the registry should run the mail server. That way, there's just 3 or 4 nationwide. Makes it easier for Ashcroft and RIAA, to boot. And we all know how well NSI does on complex things... -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: Fun new policy at AOL
On Thu, 28 Aug 2003, Roland Perry wrote: In article [EMAIL PROTECTED], Stephen J. Wilcox [EMAIL PROTECTED] writes BT in the UK who as the incumbent are the only provider of things like unmetered dialup.. I have a 19.99 a month unmetered dialup from Freeserve (based on FRIACO). There must be others. i was avoiding going into detail as most ppl here are probably not that interested in the uk setup.. its complicated, energis, worldcom operate their own pstn friaco, there are also ways of buying it in at sufficient volume as isdn or modem terminated l2tp or buying ports on someone elses platform. but my generalisation is that there is a dominant player in this market who is dominant as they can offer things which the others cant afford to do ! Steve
Re: Fun new policy at AOL
Matthew Crocker wrote: SMTP DNS should be run through the servers provided by the ISP for the exact purpose. There is no valid reason for a dialup customer to go direct to root-servers.net and there is no reason why a dialup user should be sending mail directly to AOL, or any mail server for that matter (besides their host ISP) ...and there is no reason for dialup customer to have direct access to any other port either, they´ll just use the www-proxy and other ALG services from the ISP ? This is a self-solving problem. Pete
RE: Fun new policy at AOL
-On Thursday, August 28, 2003 4:18 PM, Matthew Crocker [EMAIL PROTECTED] -wrote: - - Shouldn't customers that purchase IP services from an ISP use the ISPs - mail server as a smart host for outbound mail? - -At least here in DE there are resellers of DTAG which offer DSL connections -without any SMTP relay. If you want relaying you also have to order a domain -via them. More funny: you cannot deliver mails to DTAG (actually T-Online) -as the resellers use address space of DTAG and hence the DTAG servers -believe you are a customer of them and should use the internal relays ... - -Arnold I wouldn't say that the answer is to use a relay.. I have had the problem, and due to the business we are in, we sometimes are forced to email proofs that can be as big at 10 Meg, zipped Don't think many would allow us to realy that.. J
Re: Fun new policy at AOL
- Original Message - From: David Lesher [EMAIL PROTECTED] To: nanog list [EMAIL PROTECTED] Sent: Thursday, August 28, 2003 10:22 Subject: Re: Fun new policy at AOL Speaking on Deep Background, the Press Secretary whispered: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? applying that standard just how large do you have to get before you graduate to running your own smtp server. I'm sorry we won't accept mail from you because you're not an lir? Yea! I think the registry should run the mail server. That way, there's just 3 or 4 nationwide. Makes it easier for Ashcroft and RIAA, to boot. And we all know how well NSI does on complex things... This brings up a more general point about the dangers of blocking everything under the sun. When you limit yourself to just a few chokepoints, its easier for those who would stifle communications to shut things down. This is a very dangerous path to take. Not that we shouldn't consider some sort of port restrictions to stop spam, but there are undesirable long term effects that need to be considered. Those on the dark side will be considering them, you may be sure, while licking their chops.
Re: Fun new policy at AOL
On Thursday, August 28, 2003, at 11:07 AM, Joel Jaeggli wrote: On Thu, 28 Aug 2003, Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? applying that standard just how large do you have to get before you graduate to running your own smtp server. I'm sorry we won't accept mail from you because you're not an lir? If a larger corporation showed that they have a clue we remove the filters. If we start getting virus/spam notifications on again we re-enable the filter. We are either primary or backup MX for all of our customers. We can implement a port 25 inbound filter on a customer and their inbound mail is unaffected. We can then contact the customer and work with them to fix their broken mail server and remove the filter. We make the determination based on skill level of the customer, not their size. How does this sound for a new mail distribution network. Customers can only send mail through their direct provider ISPs can only send mail to their customers and their upstream provider. They purchase the ability to send mail to the upstream as part of their bandwidth. ISPs can contact and work out other direct mail routing arrangements between themselves. For example, ISP A could send directly to ISP B if there is a large amount of A - B mail. Both ISPs have to agree. ISPs form a trusted ring of mail servers for direct connection. All others get shipped upstream to the next available mail server. All mail servers are known, logged and can be kicked off the network by the upstream provider. A central core of distributed mail servers gets built by each backbone ISP. The backbone ISPs peer with one another (trust each others mail). backbone ISPs accept mail from their customers and can block that mail if their customer doesn't have a clue. Everything is logged, everything is validated. Setting up a mail server involves more than getting a static IP and setting up an MX record. SPAM is eliminated because it can't enter the trust ring unless it goes through an ISP. That ISP can be kicked off if they allow spammers. Viruses are managed because they can be tracked back to their origin. block at the core. virus protection could also be made a requirement for entering the trusted mail ring. Mail servers are set to deny all mail by default, opening up connections from trusted hosts as you build trusts relationships. Contact information needs to be maintained. I can't get into Sprints trust ring unless I can contact them This can be phased into service by setting up trusted and untrusted mail servers. All mail entering untrusted mail servers has a higher spam score and cannot be forwarded outside the local network. Trusted mail (i.e. from customers) can be forwarded upstream to other trusted,non-trusted mail servers. -Matt
Re: Fun new policy at AOL
On Thursday, August 28, 2003, at 11:31 AM, Petri Helenius wrote: Matthew Crocker wrote: SMTP DNS should be run through the servers provided by the ISP for the exact purpose. There is no valid reason for a dialup customer to go direct to root-servers.net and there is no reason why a dialup user should be sending mail directly to AOL, or any mail server for that matter (besides their host ISP) ...and there is no reason for dialup customer to have direct access to any other port either, they´ll just use the www-proxy and other ALG services from the ISP ? This is a self-solving problem. Technically no, There is no reason for a customer to have direct access to the net so long as the ISP can provide appropriate proxies for the services required. It gets complex, it gets hard to manage but it can be done. There is a stigma against proxing because of the early days when stale content was all over the place. Does a dynamically assigned dialup/DSL user even need a valid routable IP? For games? Maybe games should be more NAT friendly. We do remove the filters for customers that have a valid need and show that they have a clue out it all works. -Matt
Re: Fun new policy at AOL
This brings up a more general point about the dangers of blocking everything under the sun. When you limit yourself to just a few chokepoints, its easier for those who would stifle communications to shut things down. This is a very dangerous path to take. Not that we shouldn't consider some sort of port restrictions to stop spam, but there are undesirable long term effects that need to be considered. Those on the dark side will be considering them, you may be sure, while licking their chops. It can be built without choke points. ISPs could form trust relationships with each other and bypass the central mail relay. AOL for example could require ISPs to meet certain criteria before they are allowed direct connections. ISPs would need to contact AOL, provide valid contact into and accept some sort of AUP (I shall not spam AOL...) and then be allowed to connect from their IPs. AOL could kick that mail server off later if they determine they are spamming. -Matt
Re: Fun new policy at AOL
Matthew Crocker wrote: Technically no, There is no reason for a customer to have direct access to the net so long as the ISP can provide appropriate proxies for the services required. It gets complex, it gets hard to manage but it can be done. There is a stigma against proxing because of the early days when stale content was all over the place. Does a dynamically assigned dialup/DSL user even need a valid routable IP? For games? Maybe games should be more NAT friendly. How many ISPs actively provide ALG´s for the 50% of their traffic which consists of the peer2peer applications? Or is the most popular killer app not a required service? RIAA friends would love you if you declared HTTP the only allowed protocol. Would also give a boost to the applications implementing IP over HTTP. Pete
Re: Fun new policy at AOL
On Thu, 28 Aug 2003 12:00:29 EDT, Matthew Crocker said: How does this sound for a new mail distribution network. Only a few problem here: 1) Bootstrapping it - as long as you need to accept legacy SMTP because less than 90% of the mail is being done the new way, you have a hard sell in getting anybody to go to the effort of buying in. 2) Feel free in working out arrangements with 4,000 other ISPs, or getting stuck with a provider. You thought it sucked trying to get a route announced for multihoming, this is going to be a lot worse. 3) Go read up on why ADMD/PRMD sucked in X.400 (hint - see (2)). pgp0.pgp Description: PGP signature
Re: Fun new policy at AOL
On 28 Aug 2003 16:07 UTC Matthew Crocker [EMAIL PROTECTED] wrote: | AOL for example could require ISPs to meet certain criteria before | they are allowed direct connections. ISPs would need to contact AOL, | provide valid contact into and accept some sort of AUP (I shall not | spam AOL...) and then be allowed to connect from their IPs. AOL could | kick that mail server off later if they determine they are spamming. If you replace AOL with some body or set of bodies, unrelated to (but trusted by) large numbers of networks, then you have what I regard as the only ultimately workable solution to the present situation. The devil is in the details - finding and trusting such bodies: however it may be that they are already amongst us but under a different name! -- Richard Cox %% HELO - the first word of every Email transaction - is in Welsh! %%
Re: Fun new policy at AOL
On Thu, Aug 28, 2003 at 12:04:09PM -0400, Matthew Crocker wrote:
Technically no, There is no reason for a customer to have direct
access to the net so long as the ISP can provide appropriate proxies
for the services required.
It gets complex, it gets hard to manage but it can be done. There is a
stigma against proxing because of the early days when stale content was
all over the place. Does a dynamically assigned dialup/DSL user even
need a valid routable IP? For games? Maybe games should be more NAT
friendly.
We do remove the filters for customers that have a valid need and show
that they have a clue out it all works.
There is a perfectly good reason for direct access: We buy IP
connectivity. We don't buy {list of specific applications} connectivity.
If I create a new network application, how many ISPs are going to sit
there and create a new proxy so it will work? Even on the outside chance
that I could talk my own ISP into it since I pay them, it's not going to
be a very useful app if one of the prerequisites is must be a customer
of ISP X.
-c
Re: Fun new policy at AOL
On Thu, Aug 28, 2003 at 10:18:45AM -0400, Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? We block outbound port For some, sure. Maybe even most. That doesn't mean all. Are you a fairly small, perhaps boutique, provider? Such players have very different rules than ones with more than one kind of customer. 25 connections on our dialup and DSL pool. We ask our customers that have their own mail servers to configure them to forward through our mail servers. We get SPAM/abuse notifications that way and can kick Asking is one thing, forcing is another. Giving the option but leaving the choice entirely up to the customer's discretion is yet another. Giving a default, but allowing customers to request exceptions, with reasonably automated tests to verify they can handle it... well, you get the idea. You get SPAM/abuse notifications without diverting all mail through you. You need to investigate either way (unless you trust unknown third parties more than your own customers), which still doesn't require all mail to pass through your server. the customer off the network. We also block inbound port 25 connections unless they are coming from our mail server and require the customer setup their MX record to forward through our mail server. We virus scan all mail coming and going that way. We protect our customers from the network and our network from our customers. We are currently blocking over 3k Sobigs/hour on our mail servers. I would rather have that then all my bandwidth eaten up by Sobig on all of my dialup/DSL connections. Do you also limit your customers' use of web traffic? Bandwidth, at the end of the day, is still bandwidth. Having it all eaten up is a problem, but not enough justification to take away all choice. Your own border shouldn't be that much greater than the aggregate total of your customers, should it? That'd be bandwidth you pay a lot for and can't use. Usual model would suggest your downstream customers represent some value more bandwidth from you than your incoming server could get, or perhaps 1:1. What if I have my own virus scanner? What if your mail server is too slow because all those scans chew up a lot more resources than my own traffic on my server will? What size attachments do you allow? What spam filters do you run; do they account for sender IP in the same probability weighting that mine does? Even per-user configuration of filters like Postini represents a reduction in choice that may not fly with all customers, particularly small and home busineses. Finding solutions that account for the broadest number of cases is useful. If you provide a server architecture doc the way I can expect to see line topo docs, then maybe I'll trust you to get it right, or maybe not. Expecting to tell customers, I know how to run an email server better than you, doesn't fly in this age of bonehead ISPs, at least not for a lot of us/them. Perhaps you do the former; if so, please let me know if you provide service in the San Francisc/Sillycon Valley area, as our choices in home/small pipe have declined quite a bit these years. =) SMTP DNS should be run through the servers provided by the ISP for the exact purpose. There is no valid reason for a dialup customer to go direct to root-servers.net and there is no reason why a dialup user should be sending mail directly to AOL, or any mail server for that matter (besides their host ISP) Let's back up. It's entirely possible, even probable, that any ISP I go to will provide good Internet (pipe) and bad Service (protocols), or vice-versa. If they're good pipe, I can setup my own server, and have everything I need. Providing reliable and high-rate connectivity does not mean I trust you, or anyone else, to run an extra man in the middle. You, of course, are not required to trust your customers, and your policy will self-select out the ones who disagree, but suggesting it's applicable in enough cases to be a general standard misses the point. I can think of a number of businesses (including some who are fairly well known in email software, services, etc) who came up with the use of DSL as a server home. They may not rely on it for their primary bandwidth (which would probably be foolish), but particularly for things like DNS and SMTP, both of which provide for multiple addresses and locations, could sanely choose to maintain secondary servers over a completely isolated alternate pipe. Remember, BGP fails, ISPs fail, T1 cards fail, routers fail, etc. Having that last home DSL connection may just save some companies from going totally unreachable at times. That's worth $79.99/month in many books. -- Ray Wong [EMAIL PROTECTED]
Re: Fun new policy at AOL
In article [EMAIL PROTECTED], Matthew Crocker [EMAIL PROTECTED] writes ISPs would need to contact AOL, provide valid contact into and accept some sort of AUP (I shall not spam AOL...) and then be allowed to connect from their IPs. AOL could kick that mail server off later if they determine they are spamming. Next time I'm lobbying about the cost of Spam, I'll have to remember to add in all this activity as well as the end user perspective (and the more traditional we need to buy bigger servers and pipes stuff). -- Roland Perry
Re: Fun new policy at AOL
In article [EMAIL PROTECTED], Matthew Crocker [EMAIL PROTECTED] writes Everything is logged I have some policemen friends who will immediately add you to their Xmas card list! -- Roland Perry
RE: Fun new policy at AOL
Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? Trouble is with some ISPs you get more rejections when using their mail servers than when havong your own, not to mention theirs eating some email from no reason, having limits in attachment size, you can't have a mailing list that way, etc. Michel.
Re: Fun new policy at AOL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Demon announcement was interesting to me as a subscriber. Historically Demon allocated static IP addresses to (nearly) all dial up users. For many businesses this was a cheap and effective way to have their own email servers running. For those of us running businesses (from home) in areas without ADSL, it is still convenient, although suddenly looks a lot less good value for money. I understand AOL have asked Demon for a list of all legitimate sources of SMTP traffic. Seems AOL intend to maintain a whitelist of senders, where as historically I was led to believe they maintained their own blacklist. The policy is flawed, as maintaining a straight list of legitimate senders is a huge task. They have already failed at maintaining accurate blacklists, and accurate lists of dynamic IP address ranges, so I don't see why this one will work better. I can't believe the effort wouldn't be better spent on some easier task (like replacing SMTP! or agreeing reverse DNS entries to indicate legitimate mail senders (or entries to flag dynamic IP addresses - probably easier to implement) which stops virus and spam email (sent without the DNS maintainers knowledge) - obviously should be called an XM record). I understand the issues with dynamic IP addresses, but where an IP address is readily traceable, blacklisting, not whitelisting seems the obvious answer. End users do have a various legitimate reasons for wanting to send SMTP mail from their own static IP addresses. Not least for Demon it has been more reliable, their own servers often being overworked through mailing lists, viruses and spam. Also the SMTP relays often ended up in various blacklists because they were relaying spam from one of the many thousands of subscribers. Being forced to use the ISP SMTP relay merely means more multistage relays, and big ISP SMTP servers relay spam much more efficiently than their subscribers boxes on the end of narrow pipes, and worse you can't blacklist the big ISPs SMTP relays without losing bucket loads of genuine mail. In a similar fashion as someone who does work with DNS I run my own DNS caching server (sometimes even caching off the ICANN root servers ;-). I'd be somewhat upset if my ISP insisted I send all DNS queries via their caches. The various country code maintainers would probably get less reports, so I guess that is a plus for someone ;-) Not every end user is some naive computer user who needs lots of hand holding. -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/TjywGFXfHI9FVgYRApWxAKCuVNkifrrKkHhUm5Fvgxoge3OXfwCdFSoS Hrl4YkfjXYRrMeHDD0zke60= =r5d+ -END PGP SIGNATURE-
Re: Fun new policy at AOL
Speaking on Deep Background, the Press Secretary whispered: Trouble is with some ISPs you get more rejections when using their mail servers than when havong your own, not to mention theirs eating some email from no reason, having limits in attachment size, you can't have a mailing list that way, etc. And this assumes your upstream does a better job than you do on running mail -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: Fun new policy at AOL
In article [EMAIL PROTECTED] py.sacramento.ca.us, Michel Py [EMAIL PROTECTED] writes eating some email from no reason, having limits in attachment size, you can't have a mailing list that way, etc. Isn't this where we started? One ISP I know decided to limit customers to 200 outgoing recipients a day. Great for stopping spammers, great for stopping anyone running a mailing list, or mailing to big cc: lists [1]. Hey, on a good day, I can even send 200 one-to-one emails. [1] I regularly get emails with 60-80 people listed, bad practice perhaps, but it's all some users seem to be able to implement. -- Roland Perry
Re: Fun new policy at AOL
Matthew Crocker [EMAIL PROTECTED] wrote: Technically no, There is no reason for a customer to have direct access to the net so long as the ISP can provide appropriate proxies for the services required. Good idea. I'll start working on the SSH proxy tomorrow. -Matt --Johnny
RE: Fun new policy at AOL
I think the inherent mantra and wise philosophy that gets tossed out the window by AOL in this policy change is be strict in what you send, and liberal in what you accept. I'll gladly publish my dialup loozer list in a voluntary RBL so that other sites won't be forced to accept mail from hit and run spammers, but broadband connected users should have the right to run their own SMTP, and I don't trust AOL to be able to determine one from the other. Plus, it would be much better to fix SMTP once and for all than to create an e-mail schema that would allow Ashcroft and his gang of wrinkly re-hashed reaganite hawks any access to data that they could use to further violate individual citizen's privacy. Jay Stewart You can't enslave a free man, the most you can do is kill him. - Robert Anson Heinlein -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Lesher Sent: Thursday, August 28, 2003 10:22 AM To: nanog list Subject: Re: Fun new policy at AOL Speaking on Deep Background, the Press Secretary whispered: Trouble is with some ISPs you get more rejections when using their mail servers than when havong your own, not to mention theirs eating some email from no reason, having limits in attachment size, you can't have a mailing list that way, etc.
Re: Fun new policy at AOL
On Thu, 28 Aug 2003, Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? Shouldn't. There are privacy implications of having mail to be recorded (even temporarily) at someone's disk drive. --vadim
Re: Fun new policy at AOL
Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? Shouldn't. There are privacy implications of having mail to be recorded (even temporarily) at someone's disk drive. If your ISP violates your privacy or has a privacy policy you don't like, find another one. If your ISP doesn't allow your domain through, attachments of a certain size or quantity of RCPT TOs, find another one. If the ISP is too restrictive you can't do what you want, find another one If the ISP isn't restrictive and your IP gets black holed because of another customer, find another one. The market will decide what is acceptable. I filter a chunk of stuff for my users. It is a service to help protect them as well as me. If they ask for and appear to have a clue I will remove filters for customers. I'll never force them to do it 'my way or the highway' but by default customers are filtered. 99% of them are happy that I am doing it and think it is a good thing. 1% call and I remove the filters. Simple RADIUS update and they are back to full, unfiltered Internet. I do this on all my dialup, DSL, dedicated circuits. Everything is built from either LDAP or RADIUS (which comes from LDAP anyway) information about the customer. Pull down menu to select/deselect a filter and reconnect. It isn't all that hard and for 99% of my customers I am saving myself a ton of work in the long run. I'm not huge by any stretch of the imagination but I'm pretty good sized for my area. I think my current network design/management could easily scale to the 100's of thousands and/or millions of customers. I'm in the 10's of thousands now. -Matt
Re: Fun new policy at AOL
Play with DNS MX records like QMTP does. Something like crocker.com. MX 65000 trusted-mx.crocker.com. MX 66000 untrusted-mx.crocker.com. there are at least two problems with this approach. one is that an mx priority is a 16 bit unsigned integer, not like your example. another is that spammers do not follow the MX protocol, they deliberately dump on higher cost relays in order to make the victim's own inbounds carry more of the total workload of delivery. (additionally, many hosts do more spam filtering on their lower cost MX's than on their higher cost (backup?) MX's, and the spammers know this, and take advantage of it.) -- Paul Vixie
Re: Fun new policy at AOL
I have RCN cable internet in Chicago and they recently implemented blocking port 25 access outbound. They say that we should just use their mail servers instead. I connect with my laptop from 3 or 4 locations to drop off mail to my servers. I cannot use their mail servers from other locations other than when I am connected to them. I have about 2 dozen e-mail accounts defined in outlook express and would have to change the outbound mail server setting for EACH one ever time I move off the RCN connection to one of the other locations from which I work and then back again when I get back to RCN. More than a few people have this problem. I'm lucky because I run the mail server myself and can configure it to listen on an alternative port as well as 25 (authentication is required to relay, though). Again, any provider that wants to start blocking ports should do so only very carefully and should make exceptions for users who need them AT NO ADDITIONAL COST TO THE USER because there will be competitors that will treat the customer better. - Original Message - From: Michel Py [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 28, 2003 12:11 Subject: RE: Fun new policy at AOL Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? Trouble is with some ISPs you get more rejections when using their mail servers than when havong your own, not to mention theirs eating some email from no reason, having limits in attachment size, you can't have a mailing list that way, etc. Michel.
Re: Fun new policy at AOL
I think the inherent mantra and wise philosophy that gets tossed out the window by AOL in this policy change is be strict in what you send, and liberal in what you accept. that policy was wiser when everyone who could get an internet connection saw the merits of it. in an assymetric warfare situation where the good guys follow the above policy and the bad guys do not, it's a slaughter. -- Paul Vixie
Re: Fun new policy at AOL
On Thu, 28 Aug 2003, Matthew Crocker wrote: If your ISP violates your privacy or has a privacy policy you don't like, find another one. How do I know that? As a hobby, I'm running a community site for an often misunderstood sexual/lifestyle minority. Most of patrons would be very unhappy if there was an uncontrolled record of their affiliation with the community (such as mail logs) - they may trust me, but not some anonymous tech at the ISP! So, no third-party SMTP relays for me. --vadim
Re: Fun new policy at AOL
In article [EMAIL PROTECTED], Matthew Crocker [EMAIL PROTECTED] writes If your ISP ... does a bad thing ... find another one. Great in theory, but the market is imperfect. Even if money (and the loss you'd incur from terminating your current ISP early) isn't the main issue. Many countries, even those with de-regulated comms markets, don't have a very wide choice. Ask for something a bit out of the ordinary (like a dial-up account with static IP), and the choice is reduced even further. That's why we must encourage all ISPSs to be good guys, because we don't want Government Regulators setting standards in these areas, do we? -- Roland Perry
RE: Fun new policy at AOL
Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? Look carefully at that question and find the logic error. ... In case you missed it, the customer purchased 'IP' service, not 'ISP mail service'. We block outbound port 25 connections on our dialup and DSL pool. We ask our customers that have their own mail servers to configure them to forward through our mail servers. We get SPAM/abuse notifications that way and can kick the customer off the network. We also block inbound port 25 connections unless they are coming from our mail server and require the customer setup their MX record to forward through our mail server. We virus scan all mail coming and going that way. We protect our customers from the network and our network from our customers. We are currently blocking over 3k Sobigs/hour on our mail servers. I would rather have that then all my bandwidth eaten up by Sobig on all of my dialup/DSL connections. Running a walled garden is fine as long as that is what your customers are signing up for. One question though, why aren't you also running a web proxy and NetNanny to protect your customers from the 'bad' content on port 80? What makes port 25 so special? SMTP DNS should be run through the servers provided by the ISP for the exact purpose. There is no valid reason for a dialup customer to go direct to root-servers.net and there is no reason why a dialup user should be sending mail directly to AOL, or any mail server for that matter (besides their host ISP) This line of thinking leads us to a cabal that has complete control over communication. Think about it, a few large organizations allow/encourage abuse, then claim that the only resolution to the abuse is to route all communication through the centrally controlled servers. We end up back in the PTT style monopolies where censorship becomes trivial. Tony
Re: Fun new policy at AOL
That's why we must encourage all ISPSs to be good guys, because we don't want Government Regulators setting standards in these areas, do we? if recent activity in the VoIP market is any indication, then we here won't have much input as to when and how the ISP market gets regulated. -- Paul Vixie
RE: Fun new policy at AOL
At 12:53 PM 8/28/2003, Tony Hain wrote: Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? Look carefully at that question and find the logic error. ... In case you missed it, the customer purchased 'IP' service, not 'ISP mail service'. If the customer is purchasing IP only service, then they need to either purchase the *right* kind of IP service to operate their own ISP services off that connection, or they need to purchase ISP services from another vendor and then use that vendor's smarthost. If the company they purchase IP services from blocks outbound port 25 except to their own smarthost, then the customer needs to buy ISP services from a vendor who offers mail services on an alternate port, or use the IP provider's smarthost. This is not rocket science here. The days of I'm not an ISP but I play one on my residential-service dynamically allocated IP connection to the Internet are over, just as the days of open relays are over. Adjust, adapt, and move on. jc
Re: Fun new policy at AOL
Mike Tancsa wrote: At 02:34 AM 8/28/2003 -0500, Susan Zeigler wrote: WTF. This IP is NOT dynamic. The client has had it for about two years. What is the IP address they are rejecting ? Unless AOL is downloading the entire routing pools from all ISPs on a daily basis, how do they know which IPs are dynamic and which are static;) What would BGP tables tell you about internal routing and DNS ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike It's 216.161.123.79 IP does match forward and reverse. As a few others have mentioned, the mail server behind their firewall is handling outbound mail only. It pops their inbound mail from another source. We've chosen this solution due to how their membership database is integrated with the address books in their Exchange server and due to the limitations that their mail service provider has put on them--not to mention the fact that their mail service provider has been unstable in the past for sending. Internet service provided is great, they just can't do mail well. I've got an external server I can relay through if need be--and since their IP _IS_ static, it's not really a problem. It just ticks me off because I know there are a lot of others who will be in this boat. -- -- -Susan -- Susan Zeigler | Technical Services [EMAIL PROTECTED] | Spindustry Systems 515.225.0920 | You cannot strengthen the weak by weakening the strong. -- Abraham Lincoln Spindustry Systems, Inc. DES MOINES / CHICAGO / INDIANAPOLIS / DENVER CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message including any attachments.
RE: Fun new policy at AOL
Does the IP address of your client's SMTP server have a reverse DNS entry (PTR record) assigned to it? It seems to be a new best practice to not accept e-mail from an IP address that doesn't have a PTR record assigned. Furthermore, if those PTR records indicate anything like dial dns cable then more 'strict' policies tend to reject them. If you can't get your upstream to modify the PTR records to your specifications (or delegate the block to you) then another way around this would be to configure your client's SMTP server to forward to the provider's smart host (e.g. a SMTP relay server with a known address and appropriate PTR record configured to accept relay traffic from customer IP's). Not the most elegant but a serviceable workaround none the less. HTH Ben ~~ R. Benjamin Kessler Network Engineer CCIE #8762, CISSP, CCSE Kessler Consulting Email: [EMAIL PROTECTED] http://www.kesslerconsulting.com Phone: 260-625-3273 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Zeigler Sent: Thursday, August 28, 2003 2:35 AM To: [EMAIL PROTECTED] Subject: Fun new policy at AOL Sometime mid last week, one of my clients--a state chapter of a national association--became unable to send to all of their AOL members. Assuming it was simply that AOLs servers were inundated with infected emails, I gave it some time. The errors were simply delay and not delivered in time specified errors. Well, it was still going on today. So, I went on site and upped the logging on the server. What to my surprise did appear but a nice little message informing us that I'm sorry, your IP is dynamically assigned and aol doesn't accept dynamic IPs. WTF. This IP is NOT dynamic. The client has had it for about two years. I just looked on their website to file a complaint and ask how they determined what was dynamic and what was static and couldn't find a contact email address. I did find the following statement: AOL's mail servers will not accept connections from systems that use dynamically assigned IP addresses. It was on the following page: http://postmaster.info.aol.com/standards.html So, since I know someone from AOL does lurk on this list, what's my recourse. Feel free to email me offlist. Thanks. On a side note, my client is also curious who's going to help pay the bill that they shouldn't have needed to pay me due to AOL changing policy and blocking them needlessly. Unless AOL is downloading the entire routing pools from all ISPs on a daily basis, how do they know which IPs are dynamic and which are static;) And, since static IPs can actually be assigned out of a DHCP pool as well, even that won't work. -- -- -- -Susan -- Susan Zeigler | Technical Services [EMAIL PROTECTED] | Spindustry Systems 515.225.0920 | You cannot strengthen the weak by weakening the strong. -- Abraham Lincoln Spindustry Systems, Inc. DES MOINES / CHICAGO / INDIANAPOLIS / DENVER CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message including any attachments.
Re: Fun new policy at AOL
On Thu, 28 Aug 2003, Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? Shouldn't. There are privacy implications of having mail to be recorded (even temporarily) at someone's disk drive. If your ISP violates your privacy or has a privacy policy you don't like, find another one. If your ISP doesn't allow your domain through, attachments of a certain size or quantity of RCPT TOs, find another one. If the ISP is too restrictive you can't do what you want, find another one If the ISP isn't restrictive and your IP gets black holed because of another customer, find another one. The market will decide what is acceptable. If one ISP (Demon has been mentioned) has the ability for end users on static IPs to smtp to other major ISPs (AOL has been mentioned) but lots of other ISPs cant send mail from end users to these major ISPs .. arent these major ISPs producing an anti-competitive market? Steve
Re: Fun new policy at AOL
At 03:48 PM 28/08/2003 -0500, Susan Zeigler wrote: Unless AOL is downloading the entire routing pools from all ISPs on a daily basis, how do they know which IPs are dynamic and which are static;) What would BGP tables tell you about internal routing and DNS ? It's 216.161.123.79 If they are creating lists by regex / name analysis 79.123.161.216.in-addr.arpa name = ddslppp79.desm.uswest.net looks awfully 'dynamic'/pool like... If AOL wants to do something so shotgun like, thats their prerogative. But apart from examining the name, there is no way to tell that that IP address is being assigned to the same customer. ---Mike
Re: Fun new policy at AOL
Bob Bradlee wrote: Road-Runner pulled the same stunt with a chain of radio stations I have as clients. We went ON-AIR with a NEWS story, and recomended that everyone effected should call Roadrunner or AOL. AOL contacted me, verified the problem, and had my IP's whitelisted in a matter of hours. Both SBC and WOW were happy to sign up the few that switched before AOL woke up. Good luck, I hope for your sake that your national association has a national name and is ready to black list AOL in their news letter for this. We dont care, we dont have to, were AOL Back to lurking... Bob ps: I dont think I have posting rights, or I would have sent this to the list, back when it happened. I am sure there are a lot of people out there who dont know they are Blacklisted by AOL/Timewarner yet. Thanks Bob!!! Someone else has sent me the right phone number and I'm working on that. I'm forwarding this to the list as well so others can see we're not alone:) -- -- -- -Susan -- Susan Zeigler | Technical Services [EMAIL PROTECTED] | Spindustry Systems 515.225.0920 | You cannot strengthen the weak by weakening the strong. -- Abraham Lincoln Spindustry Systems, Inc. DES MOINES / CHICAGO / INDIANAPOLIS / DENVER CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message including any attachments.
Re: Fun new policy at AOL
On Thu, 28 Aug 2003 12:07:30 -0400, Matthew Crocker wrote: It can be built without choke points. ISPs could form trust relationships with each other and bypass the central mail relay. AOL for example could require ISPs to meet certain criteria before they are allowed direct connections. ISPs would need to contact AOL, provide valid contact into and accept some sort of AUP (I shall not spam AOL...) and then be allowed to connect from their IPs. AOL could kick that mail server off later if they determine they are spamming. Now there is an idea! However an improved variant is to make the entire internet a 'trust relationship' using the (obvious) steps you propose. For several months I have been pondering possible details of implementing same; see http://www.camblab.com/misc/univ_std.txt. Comments welcome. Jeffrey Race
