SNMP-ALG
Hi, can anyone recommend me anything that supports SNMP-ALG as per RFC2692? So far I only managed to find netfilter/iptables should support it, via a long-time no-progress plugin. However, the plugin simply does not seem to work (I've done loads of debugging, and as well I only managed to find other people complaining about the same symptoms, with no hints on how to resolve the issue). I'll post a summary to the list so direct reply is preferable. Thanks! -- Tomas Daniska systems engineer Tronet, a.s. Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 Nobody ever got rich by telling the American public that what they had was good enough and that they really didn't need anything better! -- Bob Atkins
Re: Why do so few mail providers support Port 587?
Internal users: With AUTH - correlate message with authenticated user, then forbid mail transmission for them only. I'd rather do that than slog through RADIUS logs. But, hey, maybe if I had more free time... Increasing the detail of an audit trail doesnt mean anyone will automatically use the information in an effective manner. This is why we need an Internet Mail Services Association in which email operators set standards and agree on how to operate the Internet email transport system. This group would have the goal of providing a high quality email service to all users. If that quality standard includes maintaining and using an audit trail, then the association members will do so. You cannot solve email operational problems by purely technical means. --Michael Dillon
Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?)
Unfortunately, providers seem to prefer unilateral heavy-handed behavior rather than acting professional. They prefer working out solutions in isolation or in small closed cabals working in secret in backrooms rather than working open to public scrutiny in an association. They prefer to operate in an environment in which there are no agreed policies for Internet email exchange rather than having a viable Internet email system in which everyone works together to add value to the users. They prefer to play secret games with blacklists, bayesian filters, hodge-podges tacked onto the Internet's DNS systems, and other antisocial behaviors rather than openly saying that people must meet certain standards in order to *SEND* email. Why do you believe more red tape will mean better service? You misunderstand me. I believe *LESS* red tape will mean better service. Today, an email operator has to deal with numerous blacklisting and spam-hunting groups, many of which act in secret and none of which have any accountability, either to email operators, email users or the public. I'd like to see all of this inscrutable red tape swept aside with a single open and public organization that I have been calling the Internet Mail Services Association. This will mean less red tape, more transparency, and more accountability. --Michael Dillon
RE: Why do so few mail providers support Port 587?
It's time to take this thread to SPAM-L or some other spam oriented list. I strongly disagree. This thread has not been about spam. For the most part it has dealt with technical operational issues of email services and therefore it is right on track for this list. --Michael Dillon
Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?)
On Mon, 28 Feb 2005 10:35:53 GMT, [EMAIL PROTECTED] said: You misunderstand me. I believe *LESS* red tape will mean better service. Today, an email operator has to deal with numerous blacklisting and spam-hunting groups, many of which act in secret and none of which have any accountability, either to email operators, email users or the public. Actually, most of those blacklisting groups have the *ultimate* accountability to e-mail operators - if the operators disagree with the way the group does things, they stop using the blacklist. I'm making the rash assumption that operators are klooed enough to either not use a blacklist they don't agree with, or know how to whitelist their disagreements. If the operator isn't, well.. consider it time for evolution in action. I'd like to see all of this inscrutable red tape swept aside with a single open and public organization that I have been And you intend to get enough consensus of goal amongst all these divergent groups with their differing goals and criteria, how, exactly? Remember that we as an industru (at least as represented on NANOG) can't even come to an agreement about port 587 or filtering 1918-sourced addresses. ;) pgp1Cdb7EYIdq.pgp Description: PGP signature
Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?)
[ This discussion should be moved to Spam-L. ] On Mon, Feb 28, 2005 at 10:35:53AM +, [EMAIL PROTECTED] wrote: You misunderstand me. I believe *LESS* red tape will mean better service. Today, an email operator has to deal with numerous blacklisting and spam-hunting groups, many of which act in secret and none of which have any accountability, either to email operators, email users or the public. Nonsense. Those groups are accountable to those who choose to avail themselves of their work. Mail system operators -- as they have already demonstrated by their actions -- will not use those resources which are run incompetently or which do not provide satisfactory results. And the wide range of resources available (there are probably about 500 DNSBLs at the moment) and the variety of policies by which they're run provides healthy competition as well as a selection of tools sufficient to allow just about any local policy to be implemented. There is no need for these operators of these resources (say, SPEWS) to be accountable to anyone else. Why should they be? They merely publish a list. If you don't like their list or the policies they use to build it: don't use it. But know that everyone else will make their choices according to their own needs, not yours. I'd like to see all of this inscrutable red tape swept aside with a single open and public organization that I have been calling the Internet Mail Services Association. This will mean less red tape, more transparency, and more accountability. It will also mean that anyone with deep enough pockets to buy their way in will get a pass to spam as much as they want. Sorry, but this experiment has already been run (see bonded spammer) and has been a miserable failure. Besides, there is no inscrutable red tape. Dealing with DNSBLs is quite easy. Of course, you may not get the results *you* wish to have, but if you're running or occupying a spammer-infested network, then the results *you* wish to have are unimportant. ---Rsk
Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?)
At 4:51 PM + 2/25/05, [EMAIL PROTECTED] wrote: I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection? Because that would require providers to act like professionals, join an Internet Mail Services Association, agree on policies for mail exchange, and require mail peering agreements in order to enable port 25 access to anyone. Nice in theory, but I don't think it would scale. In essence you are asking for a return to the UUCP model, where if you wanted to send mail on the network you had to have a deal with someone. The problem isn't agreements, the problem is that there are borders at which people will not be willing to block, even if there is bad behavior. After all, there's nothing stopping ISPs from blocking port 25 passing through their networks now. But, every time someone tries a blanket block of (for instance) China, or even appears to do so, there's a huge outcry. If you create an organization to do that, you'll not only have an outcry, you'll have a target for legal action (restraint of trade?). That kind of thing needs government level action. It's highly unlikely to happen, and it's far from clear that we would want it to. -- Kee Hinckley http://www.messagegate.com/ Enterprise Messaging Security and Compliance http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Re: SMTP Port Blocking: Success or Failure?
We put our blocks in place some time ago, Mainly on the Cable Modem side. We found our userbase was very prone to becoming zombie agents for spam. We did enhance our static i.p product by allowing statics to have port 25 open, this averted any real business class customers to continue to function. The benifiet was seen pretty quick here, That in combination with some throttles permiting the standard customer only to send 400emails in a hour has cleaned us up pretty significantly. Jason On Sat, Feb 26, 2005 at 07:04:26PM -0600, Claydon, Tom stated We are considering filtering outbound SMTP traffic from our ISP customers, except from our own mail servers, to help reduce the amount of spam originating from our network. How successful/unsucessful has implementing outbound SMTP filtering done in stopping or slowing down spam from your network? Also, if outbound SMTP filtering has not worked for you, are there any other things that you have implemented that have helped with spam traffic? Thanks, = TC -- Tom Claydon, IT/ATM Network Engineer Dobson Telephone Company http://www.dobsonteleco.com -- -- Jason Nealis Internet Systems and Services RCN
Re: Why do so few mail providers support Port 587?
In message [EMAIL PROTECTED], Sean Donelan writes: Requiring end-user computers to use authenticated Port 587 and blocking end-user computers access to port 25 has several advantages: 2. Lets the authenticated mail server conduct additional anti-virus checks on outgoing mail even if the end-user's computer was compromised or out-of-date virus definitions. 3. Separates authenticate mail submission (port 587) from other mail protocols (25, 110, 143, etc) simplfying network controls (no deep-packet inspection) for end-user computers. Eliminates some of the existing problems with trying to do transparent proxying of port 25 from end-user computers. What these two boil down it is a much simpler mail system architecture, which in turn translates to a more secure mail system and an easier-to-administer one. Consider the control flow if you're trying to use port 25 for everything: Send a 220 If you see an EHLO, advertise that you support STARTTLS If you receive a STARTTLS and another EHLO, advertise that you support AUTH -- you don't want to do authentication over insecure connections, especially if your goal is to support roaming wireless users. Accept inbound email. Check if the user was authenticated. If so, permit relaying; also do rate checks. If not, don't permit relaying, but do run anti-spam software. Do virus checks. If authenticated, notify the sender that either their machine is infested with *something* or their credentials have been stolen. If unauthenticated, discard; it's probably a joe job. The point is that authenticated status has to be retained and checked frequently. If you're using 587, the subscriber flow is like this: Send a 220 Don't accept anything until you see STARTTLS Don't do anything until you see an AUTH Accept inbound mail, do rate checks and virus checks, and bounce accordingly For port 25: Send a 220 Optionally permit (but don't require) STARTTLS Accept inbound mail. Do virus and spam checks, and drop as needed. Don't permit relaying Both are simpler; neither requires retained global state.
Re: Internet Email Services Association
On Mon, 2005-02-28 at 11:44 -0600, Kee Hinckley wrote: At 4:51 PM + 2/25/05, [EMAIL PROTECTED] wrote: Because that would require providers to act like professionals, join an Internet Mail Services Association, agree on policies for mail exchange, and require mail peering agreements in order to enable port 25 access to anyone. Nice in theory, but I don't think it would scale. In essence you are asking for a return to the UUCP model, where if you wanted to send mail on the network you had to have a deal with someone. The problem isn't agreements, the problem is that there are borders at which people will not be willing to block, even if there is bad behavior. Access providers ensuring machines from dynamic addresses are excluded from sinking or sourcing port 25 traffic would prevent residential customer's machines from acting as an anonymous SMTP client, with an exception often made between their own servers. Blocking port 25 traffic in both directions prevents address spoofing (done by tunneling reply traffic to an unblocked node elsewhere). This leaves the provider in control of their address space, as this space should not become blocked due to a history of abuse, largely due to customer's compromised systems. As an additional benefit, their networks should be less burdened on the up-link, and their customers less exposed to viruses, should blocking be done at the access interface, rather than upstream at more expensive routers. After all, there's nothing stopping ISPs from blocking port 25 passing through their networks now. Until alternative authenticated SMTP ports become prevalently used, there is potential for support issues, once a portion of their customers are unable to use their laptops at different locations. A solution is provided with alternative authenticated access ports, in conjunction with port 25 blocking, but this still involves a configuration change. The trade-off is less abuse reports, assuming this is monitored. But, every time someone tries a blanket block of (for instance) China, or even appears to do so, there's a huge outcry. Mapping dynamic addresses can be problematic from regions that do not cooperate, even when it is in their best interests to do so. A great deal of abuse is prevented using the black-hole listing methods, where, without this mechanism, email would not be practical. Capricious listings would be an expensive alternative for any listing service, however. If you create an organization to do that, you'll not only have an outcry, you'll have a target for legal action (restraint of trade?). That kind of thing needs government level action. It's highly unlikely to happen, and it's far from clear that we would want it to. There should be similar concerns regarding demands for DNS entries to register paths of a mailbox-domain before email is accepted. This approach attempts to burden the mailbox-domain owner, rather than the email service provider, with responding to abuse. Users of email services, however, often have no means to monitor abuse of these address based authorizations, which may result in their mailbox-domain becoming unusable. Attempting to track the source of a problem may become impossible should listing services refuse to provide sources, or providers refuse to share logs due to privacy issues. There is no standardization for path registration schemes, such as Sender-ID/SPF/SPF-Classic(new version of SPF). Although these three different schemes claim to use the same DNS record, they apply far different rules for various mailbox-domains. Asking for logs as to why mail has gone missing may require learning about everyone's use of RFC2822 FROM, or SENDER, or RESENT-FROM, or RESENT-SENDER, or RFC2821 MAILFROM depending upon which email filtering algorithm was applied. There is no means to discern which mailbox-domain within messages were subjected to filtering or reputation assessments. This says nothing of risks imposed by active content in DNS, the ignoring of exponential UDP back-off, and requiring compliant receivers to parse more than 100 DNS records, etc. -Doug
RE: SMTP Port Blocking: Success or Failure?
How effective is rate limiting - can anyone from Comcast reaply to me offlist, I would be very intersted in results ... PR -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Levine Sent: Sunday, February 27, 2005 11:20 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: SMTP Port Blocking: Success or Failure? What about rate limiting SMTP traffic rather than blocking it? That could allow legitimate use for most private customers, while preventing bulk traffic. Comcast has been doing something like that, looking for spikes of SMTP connects and blocking when they see them, done at the IP level. I can't say that I'm overly impressed with how well it's working, but it's better than nothing. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I dropped the toothpaste, said Tom, crestfallenly.
High volume WHOIS queries
I'm in a disagreement with ARIN about my application for bulk whois data. I've got a software program that needs resolve AS numbers to the Company Name of the owner. The software app has need to do this on a very high volume. E.g. I run a report that returns the top 100 AS destinations for my network and I want to resolve the numbers to the names as part of the report generation. Since ARIN throttles the number of queries that you can execute against their servers I seems to just make sense that you would do the processing using local data. That is all fine and good, but the problem comes when I distribute the software to users. ARIN's AUP for bulk whois states: Redistributing bulk ARIN WHOIS data is explicitly forbidden. It is permissible to publish the data on an individual query or small number of queries at a time basis, as long as reasonable precautions are taken to prevent automated querying by database harvesters. My original AUP application stated that I would transfer the data to the users using an XML file on a regular basis. Clearly in violation of the first point. Fine. But now after a phone conversation they are telling me that I can not operate a server to distribute the data on a per query basis too. Providing a server that answers whois queries just like ARIN seems to be clearly permissible based on the remaining AUP verbage. At this point the only thing I can get out of the guy/gal on the phone is NO!. Does anyone have any experience doing something like this? How about a sanity check? Am I completely wrong in how I'm interpreting the AUP? Thanks, Dan
Re: Why do so few mail providers support Port 587?
On Sat, Feb 26, 2005 at 03:10:42PM +0100, JP Velders wrote: From a security stance (well - partly ;D) I always like to emphasize that in The Real World port 25 is for traffic between MTA's *and* submission of mails to the local MTA. So to reduce the chance of one of my users abusing an Open Relay and to enforce corporate e-mail policies, only port 25 towards our mailserver is open. I do not know about your E-Mail Policy, but normally it is either allowed to use an external mailserver or not. If it is allowed, I can as well allow Port 25 outgoing. If it is not I will block 25 and 587. Port 587 on the other hand is meant for submission by clients. The security implications of allowing my users to contact such a port are very very low. If someone won't secure his mailserver on port 587, that's something different, but substantially different than if it were insecure on port 25... An interesting theory. What is the substantial difference? For me the security implications of allowing the user to bypass our mailsystem on port 25 and allowing the user to bypass our mailsystem on port 587 are not as obvious as they maybe are to you. Nils
Re: Why do so few mail providers support Port 587?
On Mon, 28 Feb 2005 16:54:23 EST, Nils Ketelsen said: An interesting theory. What is the substantial difference? For me the security implications of allowing the user to bypass our mailsystem on port 25 and allowing the user to bypass our mailsystem on port 587 are not as obvious as they maybe are to you. The big difference is that if they connect on outbound 25, they're basically unauthenticated at the other end. Port 587 should be authenticated, which means that the machine making the connection out is presumably a legitimate user of the destination mail server. If you're managing a corporate network, then yes, the distinction isn't that obvious, as you're restricting your own users. If you're running an ISP, you're being paid to *connect* people to other places, and making it more difficult than necessary is.. well... a Randy Bush quote. ;) pgpa6T1DY9Pcq.pgp Description: PGP signature
Multihoming for the small ISP ( search engine) ala 2005
Greetings folks, (It's been a long time :) I have some questions about multihoming that I can't seem to find by Google-ing for answers 1.) What ever happened to (Avi Freedman's?) Multihoming strategy using DNS(?), there are links to archives circa 1997 but nothing recent. 2) What is the preferred or correct way for a relatively small outfit (a small search engine) to implement Multihoming? Especially when most of the machines are a VLS cluster so we are not talking about a large address space here. It seems the outfit is having difficulty getting blocks that they can even run BGP with, (I know I'm missing a lot here) They can't even fill a /24, let alone anything greater :) I am willing to take my answers off line. I'm sure there is a way to do this that is so trivial to folks on this list that it's not talked about, but since I haven't done this type of thing in about 5 years I am really out of the loop. Thanks in advance and for all the great work over the years! Cheers Geoff White
Re: Multihoming for the small ISP ( search engine) ala 2005
On Mon, 28 Feb 2005, Geoff White wrote: 2) What is the preferred or correct way for a relatively small outfit (a small search engine) to implement Multihoming? Especially when most of the machines are a VLS cluster so we are not talking about a large address space here. It seems the outfit is having difficulty getting blocks that they can even run BGP with, (I know I'm missing a lot here) They can't even fill a /24, let alone anything greater :) Doesn't matter. Assuming we're talking about ARIN-region, if they're multihomed, one of their providers can assign them a /24 (even if they'll only use 2 IPs) so that they can announce that /24 to their other providers and have a chance of not being route filtered. ARIN rules specifically permit this, and it won't be held against the provider when they apply for more space. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
