books
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=6965449804 Almost all the cisco press books on sale one auction winner reads all. Best deal better then happy hour.
Re: Email peering
My e-mail is [EMAIL PROTECTED], but I send it when I am on DSL with EthLink (and thru Earthlink SMTP). And it is 100% valid situation. - Original Message - From: John Levine [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, June 18, 2005 12:25 AM Subject: Re: Email peering In between the choice of accepting mail from *anybody* by default which we have now and the choice of accepting mail from *nobody* by default that explicit peering agreements represents there is another solution; which is to accept mail only from IPs that have *some relation* to the sender's From domain, for example by MX record or by reverse DNS (we implemented that test and call it MX+). This has the same problem as all of the other duct tape authorization schemes -- it breaks a lot of valid e-mail, so that you have to maintain a painfully large manual exception table, or write off a lot of mail that your users will not forgive you for losing, or more likely, both. In this particular case, the biggest issue is forwarders, commercial ones like pobox.com, associations like the ACM and IEEE (I get some odd mail being uucp at computer.org), and large numbers of colleges and universities which let graduates keep their email address. In all of those cases, the users send mail from their own ISPs, whatever they are, inbound mail is forwarded back to the ISP accounts, and there is no way to enumerate the valid sources of mail. There's also plenty of domains where the inbound and outbound mail servers are different, and neither one matches the domain name of the mail. For example, I host about 300 small mail domains on a pop toaster here. The MX is mail2.iecc.com, and the outbound host that many but not all of them use is xuxa.iecc.com. (Mail for iecc.com itself is on another host.) The IPs all happen to be in the same /24, but guessing whether two IPs are close enough is a poor way to authenticate or authorize anything. Before you point out that they could change the way those systems work to be compatible with your scheme, well, duh, sure. But if you're going to make people change their existing working mail setups, there's little point in going through the vast cost of a widespread change for such a marginal benefit. Read archives of SPF mailing lists for endless flamage on this topic, since SPF has the same problem. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor A book is a sneeze. - E.B. White, on the writing of Charlotte's Web
More long AS-sets announced
Lorenzo Colitti wrote:
as part of our AS-set stuffing experiments (announced, including links
to in-depth information, in [1]), we will be announcing unusually large
AS-sets tomorrow, Thursday 16 June.
Hi,
due to unforeseen technical difficulties, we have been forced to
postpone these experiments. We plan to make the announcements at the
same times on Monday 20 June.
The prefixes will be the same (84.205.73.0/24 and 84.205.89.0/24) and
will be originated by AS12654 as before, but the AS-set will consist of
AS2121 repeated n times, so the paths will look like 12654 {2121, 2121,
..., 2121}. AS2121 is the RIPE meeting AS, which is reserved for RIPE
meetings and does not currently appear in the global routing table.
As before, should anyone encounter a problem with these experiments,
please let me know and I will take immediate action.
Regards,
Lorenzo
--
[EMAIL PROTECTED] [EMAIL PROTECTED]
www.ripe.netwww.dia.uniroma3.it/~compunet
RIPE NCCRoma Tre Computer Networks research group
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
On Fri, 17 Jun 2005, [EMAIL PROTECTED] wrote: The thousands of bilateral BGP peering contracts are most definitely comparable to the email peering that I am proposing. Dude, it's 2005. You can put down the X.400 crack pipe now. Why does fixing the SMTP email architecture by applying some lessons learned from BGP peering lead people to talk about X.400, UUCP, Bitnet, Fidonet and other obsolete protocols? Because these protocols did EXACTLY the same thing you've been attempting to push: explicitly routed, trust-based-peering delivery. IT DOES NOT SCALE, and we know this because many of us have long since implemented it! Personally, I've directly used three of the above, and still do run one of them on my personal home server. There are far too many SMTP machines already deployed out there -- we're not talking thousands; here it's tens to hundreds of thousands worldwide -- to reel it back in and make widespread, mandatory mail peering anything but a bedroom fetish for high salaried security consultants. SMTP is not perfect; however, it is the de facto standard and is widely adopted BECAUSE it does not require any of this crap. In the ideal case, where remote networks do strive to keep themselves clean, it works well. Blacklisting a remote network for its failure to keep a clean house is also not perfect, nor are any of the other heuristic approaches being taken. In spite of their imperfections, these approaches are making an impact, and pointing the blame where it belongs: squarely at the misbehaving network. You may feel free to descend back into the world where control of e-mail is in the hands of a few, but the rest of us have given up the ghost on that approach. I do, however, know of a good clinic where they can help you fight your addiction, once you're ready to admit the problem -- that's the first step towards recovery. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
On Mon, 20 Jun 2005, Todd Vierling wrote: There are far too many SMTP machines already deployed out there -- we're not talking thousands; here it's tens to hundreds of thousands worldwide -- to It's actually millions. And I'm not just pulling that number out of someone's -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
