- NANOG - lists.nanog.org

Re: Fun new policy at AOL
by Miquel van Smoorenburg 30 Aug '03

30 Aug '03

In article <cistron.5ED9A06E-DA3E-11D7-B146-00039388672E(a)muada.com>, Iljitsch van Beijnum <iljitsch(a)muada.com> 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

12 23

Re: Fun new policy at AOL
by Omachonu Ogali 30 Aug '03

30 Aug '03

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.

1 0

RE: dry pair
by Dr. Jeffrey Race 30 Aug '03

30 Aug '03

On Fri, 29 Aug 2003 11:24:35 -0500, Austad, Jay wrote: >I also tried asking for an Alarm Circuit. I even explained to them what it >was, but they still didn't understand. All of the people I talked to >wondered why in the world I would want a pair with no dialtone. This is what happens when you staff your "support" departments with dropouts from McDonalds. They need people who have climbed poles and been down in manholes (among other things). The training is abysmal and management doesn't care. Jeffrey Race

1 0

RE: dry pair
by Randy Neals (ORION) 29 Aug '03

29 Aug '03

>From: Dan.Thorson(a)seagate.com >>From what I recall there is no guarentee that the Qwest >tarrif for NB3 is actually a straight-through copper pair >[section 7.3.1.B.2.a.(4)]... note the restriction of >signaling frequency.... >see the Terms & Conditions in section 7.3.1.B.2.a.(2). By requesting a circuit that offers 60Hz and/or DC signalling that pretty much requires them to use Copper, if they have it available. The only way to know if they have it available is to order the circuit. After a few days the order will hit their design department which will look at the order and determine if facilities exist to provison the circuit. Some newer office towers and subdivisons/developments may be fed with fiber using Digital Loop Carrier(DLC/SLC) equipment in a CEV hut. While there is still a copper loop to each home or business from the CEV/Hut, the loop ends at the SLC and the voice is converted to PCM over fiber to extend to the C.O. Our Telco uses a slightly different wording in their Tariff for this lack of DC continuity disclaimer...: "The provisioning of metallic or DC continuity applied until 1993 12 31. Thereafter, the provisioning of metallic or DC continuity is provided only where metallic facilities currently exist, following normal provisioning practices. Where capacity is exhausted, or where appropriate facilities do not exist, the Company will evaluate all requests and only provide end-to-end metallic facilities at the customer's expense based on the cost incurred by the Company." The largest concern is usually the length of the circuit because how they route the circuit is not always intuitive and the cable may take a circuitous route between your two locations. Usually they can estimate the loop length when the do the design. The limitation on frequency/pulses is largely administrative verbiage. I highly doubt they will install a filter on the circuit to prevent higher speed. (Although it is possible) At one time I think the different speed circuits where priced differently. I suppose a few decades ago the differnce between 30 bits per second and 75 bits per second was considered a large amount of difference. ;-) -Randy

4 4

Re: Blaster author identified, about to be arrested...
by Brandon Butterworth 29 Aug '03

29 Aug '03

> > Where is he "now" and why won't he remove himself to "somewhere a long > > way away", overnight? Obviously, there is something more complex > > happening here. "don't give that lamer credit for my code. Doh!"

1 0

RE: Fun new policy at AOL
by Drew Weaver 29 Aug '03

29 Aug '03

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:nanog@internetpolicyagency.com] Sent: Friday, August 29, 2003 4:42 PM To: nanog(a)merit.edu Subject: Re: Fun new policy at AOL In article <20030829162412.GA9397(a)dipole.informationwave.net>, Omachonu Ogali <nanog(a)missnglnk.com> 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

2 1

RE: Measured Internet good v. "bad" traffic
by JC Dill 29 Aug '03

29 Aug '03

At 02:45 AM 8/28/2003, David Schwartz wrote: > > No that wouldnt work, that was be an analogy to non-usage based > > eg I buy a 10Mb port from you and you dont charge me extra for > > unwanted bandwidth across your network.. > > The point is that 'usage' is supposed to be 'what you use', not what >somebody else uses. 'My' traffic is the traffic I want, not the traffic you >try to give me that I don't want. An Internet-connected line is like an 800 phone line. You get connected, you "advertise" your presence, you have no control over who calls, you pay the bill for the incoming calls. That's just *how it is*. jc

2 1

Fun new policy at AOL
by Susan Zeigler 29 Aug '03

29 Aug '03

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 szeigler(a)spindustry.com | 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.

27 50

Re: Fun new policy at AOL
by Paul Vixie 29 Aug '03

29 Aug '03

> 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. Independent Paul Vixie (Ed.) Request for Comments: XXXX 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 XXXX 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 VIXIE(a)ISC.ORG, 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 used for repudiation purposes. Vixie Experimental [Page 2] RFC XXXX Repudiating MAIL FROM May 26, 2002 2.2. Second-stage relays such as ISP mail servers are often used and can be described by adding as many relays as necessary to the MAIL-FROM MX RRset. In our example, if ISC sometimes used UUNET for outbound mail services, the DNS data describing this relationship might be as follows: $ORIGIN isc.org. MAIL-FROM MX 0 rc MX 0 rc1 MX 0 uunet.uu.net. Let it be noted that a domain owner's power to repudiate forged e-mail is only as strong as the security policy of its registered inbound and outbound mail relays, and that if such a relay is (for example) open to third party relay, then no value will be added by registering a domain MAIL-FROM MX containing that relay, and no inbound MAIL-FROM checking will be possible on final delivery relays for a domain @ MX containing that relay. Multistage relays (both inbound and outbound) are a breeding ground for anonymity unless they are very carefully configured. 2.3. SMTP receivers wishing to attempt repudiation on inbound e-mail would check the SMTP (see [RFC2821]) MAIL FROM payload at the time of receipt. The precise method to be used is as follows: Vixie Experimental [Page 3] RFC XXXX Repudiating MAIL FROM May 26, 2002 on (MAIL FROM mailfrom) { switch (repudiated(mailfrom, ipsource)) case tempfail: smtpreply(450, "temporary dns failure, try again later") break case repudiated: smtpreply(550, "surely you're joking") dsn("5.7.1", "delivery not authorized") invalidate() // reject all but QUIT and RSET break } } repudiated(mailfrom, ipsource) = { (lhs, rhs) = parse_addr(mailfrom); // handle "MAIL FROM:<>" somehow mxset = get_mx("MAIL-FROM" "." rhs); if (mxset == NULL) return nonrepudiated; mxset += configured(perimeter_relays); foreach mx (mxset) { aset = get_a(mx.server); if (ipsource IN aset) return nonrepudiated; } return repudiated; } (EDITOR'S NOTE: need to establish a value for 5xx.) The method amounts to "if there's a MAIL-FROM for the purported domain and if the IP source isn't on the resulting list, then reject the mail". Multistage inbound relays are allowed for, by implicitly appending one's own outer perimeter relay names to every extant MAIL-FROM. 3 - Impact 3.1. This specification is optional, and will only affect cooperating parties. Any domain owner who does not enter a MAIL-FROM will be unaffected, and any SMTP receiver who does not look for a MAIL-FROM at time of receipt will be unaffected. However, both parties working together CAN work to repudiate forged e-mail return/source information. 3.2. Transport-level e-mail forwarding must be more explicit under this specification. For example if VIXIE(a)NETBSD.ORG's account has a Vixie Experimental [Page 4] RFC XXXX Repudiating MAIL FROM May 26, 2002 ".forward" file pointing at VIXIE(a)ISC.ORG, then e-mail sent to the former will be received by the latter, but with no change in the payload of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be configured to implicitly add NETBSD's outbound mail relays as "multistage inbound relays." This could scale poorly and may add pressure toward transport remailing (with a new envelope) rather than transport forwarding (reusing the old envelope.) 3.3. Roaming hosts such as laptop computers will probably not be able to be listed in the MAIL-FROM MX RR for their return address domain name, and may be forced to use an intermediary for outbound e-mail. STARTTLS or an SSL/SSH tunnel back "home" may become a necessary first hop for mobile e-mail. 3.4. The likely endgame for this behaviour is to force senders of unwanted bulk e-mail to stop lying about who they are, which is illegal in meatspace anyway -- but such laws are unenforceable due to the nature of the Internet's mail system. Under this proposal, any domain owner who is the victim of forgery can respond by adding MAIL-FROM data to their DNS zone, and any relay owner who is the victim of forged unwanted e-mail can respond by checking for MAIL-FROM data upon receipt of all incoming e-mail. 3.5. The DNS TTL for MAIL-FROM MX RRsets ought to be shorter than for the corresponding domain's apex MX RR, since the cost of widely cached wrong information is much higher for outbound repudiation data than for inbound delivery data. Consider that an incomplete apex MX RR can cause mail to be delivered by a suboptimal path, whereas an incomplete MAIL- FROM MX RR can cause valid mail to be rejected by relays who attempt repudiation. 4 - Security Considerations In the continuing absence of widely deployed security for DNS, this proposal effectively places an access control list for forged source/return information in a place where it can be attacked. However, it must be noted that the current senders of forged unwanted bulk e-mail are typically not technologically capable of attacking the DNS to insert forged MAIL-FROM data. 5 - Acknowledgements This idea originated with Jim Miller <jmiller(a)jcmco.com> in 1998. Vixie Experimental [Page 5] RFC XXXX Repudiating MAIL FROM May 26, 2002 5 - Author's Address Paul Vixie 950 Charter Street Redwood City, CA 94063 +1 650 779 7000 paul(a)vix.com Vixie Experimental [Page 6]

2 1

Trusecure estimate: one in three companies infected by blaster
by Sean Donelan 29 Aug '03

29 Aug '03

http://reuters.com/newsArticle.jhtml?type=businessNews&storyID=3359768 One in three North American companies are estimated to have had at least some of their computers infected since Blaster emerged in early August, according to new data from Internet security laboratory ICSA.

1 0