Re: well-known NTP? (Re: Open Letter to D-Link about their NTP vandalism)
Sorry for the noise again. Yes, you can edit /etc/hosts No, the box does not care. Neither voipd nor multid care for it Apr 13 05:25:17 voipd[402]: >>> Request: SUBSCRIBE sip:[EMAIL PROTECTED] Apr 13 05:25:17 voipd[402]: dns: _sip._udp.sipgate.de: query Apr 13 05:25:17 voipd[402]: dns: _sip._udp.sipgate.de: "0 0 5060 sipgate.de" ttl=584 from 192.168.180.1. Apr 13 05:25:17 voipd[402]: dns: sipgate.de: query Apr 13 05:25:17 voipd[402]: dns: sipgate.de: 217.10.79.9 ttl=4786 from 192.168.180.1. Apr 13 05:25:18 voipd[402]: <<< Status: 200 OK Apr 13 02:27:25 multid[360]: dns: 0.europe.pool.ntp.org: query Apr 13 02:27:25 multid[360]: dns: 0.europe.pool.ntp.org: 85.214.32.50 ttl=1619 from 192.168.180.1. Apr 13 02:27:25 multid[360]: sending SNTP request to server 0.europe.pool.ntp.org (85.214.32.50) Apr 13 02:27:25 multid[360]: The NTP time is 13.4.2006 00:27:24.133000 UTC Apr 13 02:27:25 multid[360]: system time is 1.02 seconds ahead Apr 13 02:27:25 multid[360]: adjusting time backward 1.02 seconds Regards, Peter and Karin Peter Dambier wrote: Just for curiousity, you can change it. /etc/hosts is a link /etc/hosts -> ../var/tmp/hosts you can edit but you cannot permanently save it. cat /etc/hosts 127.0.0.1 localhost 192.168.178.1 fritz.box 217.10.79.8 0.europe.pool.ntp.org ntp.sipgate.de Now I dont bother pool.ntp.org but ask my sip provider. That trick might work for the D-Link too. Of course 0.europe.pool.ntp.org is alright but that ntp server D-Link has is not. You have to insert the hostname plus ip into /var/tmp/hosts or the box will ask DNS. Cheers Peter and Karin Peter Dambier wrote: From my Fritzbox log: Apr 12 06:27:29 multid[360]: dns: 0.europe.pool.ntp.org: query Apr 12 06:27:30 multid[360]: dns: 0.europe.pool.ntp.org: 82.71.9.63 ttl=79 from 192.168.180.1. Apr 12 06:27:30 multid[360]: sending SNTP request to server 0.europe.pool.ntp.org (82.71.9.63) Apr 12 06:27:30 multid[360]: The NTP time is 12.4.2006 04:27:29.15 UTC Apr 12 06:27:30 multid[360]: system time is 1.007000 seconds ahead Apr 12 06:27:30 multid[360]: adjusting time backward 1.007000 seconds Seems to do that every 8 hours. I could not find a config file. Compiled into "/sbin/multid" ? I guess similar devices like the maudit D-Link are much the same. Only that multid deamon seems to be AVM specific. If that NTP thing is from the non disclosed und unGPLed TI source then best forget about it. Replace it by some wellknown software that is known not to be nasty. Another router that is not compatible and not especially a good router - has an html interface where you can put it your favourite NTP server. I still wonder why I cannot configure the NTP server but at least it is not as nasty as the D-Link. Peter Stephane Bortzmeyer wrote: On Tue, Apr 11, 2006 at 10:01:10PM +, Edward B. DREGER <[EMAIL PROTECTED]> wrote a message of 27 lines which said: AS112-style NTP service, anyone? That would be cooperative and possibly even useful. It already exists (Security warning: do not use it on strategic machine, there is no warranty that these servers are trustful): http://www.pool.ntp.org/ Active server count on 2006-04-12 Africa 1 Asia 24 Europe 368 North America 223 Oceania 26 South America 7 Global 582 All Pool Servers 653 The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable easy to use NTP service for millions of clients without putting a strain on the big popular timeservers. Adrian von Bidder created this project after a discussion about resource consumption on the big timeservers, with the idea that for everyday use a DNS round robin would be good enough, and would allow spreading the load over many servers. The disadvantage is, of course, that you may occasionally get a bad server and that you usually won't get the server closest to you. The workarounds for this is respectively to make sure you configure at least three servers in your ntp.conf and to use the country zones (for example 0.us.pool.ntp.org) rather than the global zone (for example 0.pool.ntp.org). Read more on using the pool. The pool is now enormously popular, being used by at least hundreds of thousands and maybe even millions of systems around the world. The pool project is now being maintained by Ask Bjørn Hansen and a great group of contributors on the mailing lists. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
Re: Open Letter to D-Link about their NTP vandalism
Alain Hebert wrote: With the way you named your address book (North American Noise and Off-topic Gripes). We now know where to fill your futur comments. (In the killfile that is) You don't seem to want to act very responsibly, based on your comments here, so it doesn't surprise me that you don't want to see Richard taking you to task for not acting responsibly. What bothers me is that you seem to think you are in the right and don't want to listen to suggestions to the contrary. The intended audience of the NANOG mailing list consists primarily of professionals who are paid to operate computer networks on behalf of large numbers of other people. Said professionals have a responsibility to operate said networks in a professional manner. You're wrong. Richard is right. **SJ "you're allowed to express your opinion here, just as I'm allowed to tell you your opinion is silly" S -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Apple Valley, CA Resident of Southern California - the home of beautiful people and butt-ugly traffic jams
SMTP: run-to-completion, backscatter, et cetera (Re: Spam filtering bcps ...)
ST> Date: Wed, 12 Apr 2006 18:56:44 -0700 (PDT)
ST> From: Steve Thomas
ST> If you accept the message, you can presumably deliver it. In this
Possibly. However, insufficient storage is not the only cause of 4xx
status.
ST> day and age, anyone accepting mail for a domain without first
ST> checking the RCPT TO - even (especially?) on a backup MX - should
ST> have their head examined.
Especially.
ST> IN the event that the RCPT TO is valid but the message truly can't
ST> be delivered for some other reason, you should bounce the message
ST> and fix the problem.
*Iff* the bounce can be sent to the correct location. That's a big
iff these days.
ST> My point was that when it comes to spam, it should either be rejected
ST> inline or delivered.
That's ideal. I can think of several realistic conditions where a
message could be queued but not validated until later. I'm simply
stating that { accepted | pending | refused } is a reasonable set of
responses. From an end-to-end perspective, SMTP transactions are
asynchronous and not guaranteed, anyway.
You're advocating run-to-completion. I'm suggesting an asynchronous
realtime system instead. Polls could be coalesced.
Note also the implications of polling for message status: Eliminate
bounces. Want to know if a message went through? Poll. Receive bounce
inline if appropriate. That seems better than the current push-based
crapshoot.
Want to confirm that a user has retrieved a message? Now possible at
the MX level. Want to confirm receipt by the server without divulging
if the user has retrieved the message? Return a status code indicating
such.
Frankly, I'd go for pull-based response codes just to be rid of
backscatter. The rest is gravy.
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Open Letter to D-Link about their NTP vandalism
Well, With the way you named your address book (North American Noise and Off-topic Gripes). We now know where to fill your futur comments. (In the killfile that is) Richard A Steenbergen wrote: On Wed, Apr 12, 2006 at 01:32:26PM -0500, Stephen Sprunk wrote: On the plus side, after seeing D-Link's (lack of) reaction to this, I'll bet none of us will buy another of their products again. If it was legal to sell whatever you people are smoking that makes you think dlink gives a flying crap about you as customers, I'd be a very rich man. What part of "mass consumer product" isn't clear here, 99.9% of their target market doesn't know NTP is, and doesn't care. I am absolutely appalled by the number of "slashdot warriors" here, ready to launch a crusade of spreading misinformation to the media in hopes of obtaining a large monetary payout or otherwise causing dlink, in the name of "doing the right thing", and without any consideration or understanding of the facts at hand. You know why dlink can't just come forward and say "woops we're sorry, we didn't see that you wanted this used for DIX members only, our bad"? Because they have to contend with people who will take that apology and then use it in court as an admission of guilt, and seek many tens of thousands of dollars or more in non-existent damages. As a (older, since '87) operator of a small network, I'll always help other operators when its question of making the 'net better. Good luck advocating the next turd coming from sub-standard design flow that contributed to the DIX issues with DLink. Me, I prefer to strive for excellence... I think we all know that dlink was wrong. They should have double-checked the list of NTP servers they included in their default shipping firmware to make certain that the owners were ok with having their services used publically, there is no question about this. However, just because they made this mistake, it is not an excuse for everyone involved to start cashing in like they hit the lottery. Imagine that you get rear ended in traffic by an inattentive driver, and they dent your bumper. Yes it is their fault, yes they made a mistake and they should be responsible for it, but it is not okay for you to start screaming whiplash as soon as you see that you got hit by a Mercedes. It also doesn't mean that you are going to get a new car instead of them paying to have your bumper fixed. FYI I didn't read anything about somebody looking to make money on this... If anyone else is going to carry this as a story, please act responsibly and do a little fact checking. We're talking about 37 packets/sec, less than a dialup worth of bandwidth, and any number of technical solutions which could completely mitigate that traffic without ANY additional expenses. Also, IANAL, but I think that refusing to take reasonable action to mitigate the damages because you feel the other party is "at fault" and should be 100% responsible is probably a good way to hurt any kind of case you might actually have against them too. Yeap x packets/sec times millions... -- Alain Hebert[EMAIL PROTECTED] PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.netfax 514-990-9443
anyone with network/bgp clue @ cogent onlist?
Please hit me offlist. I've already attempted all regular means of communication. Thanks, Andrew
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
> How does one properly report delivery failure to a guerrilla spammer? If you accept the message, you can presumably deliver it. In this day and age, anyone accepting mail for a domain without first checking the RCPT TO - even (especially?) on a backup MX - should have their head examined. In the event that the RCPT TO is valid but the message truly can't be delivered for some other reason, you should bounce the message and fix the problem. My point was that when it comes to spam, it should either be rejected inline or delivered. Unless your spam scanner has 100% accuracy, 100% of the time, there is no justification for sending anything not addressed to you to /dev/null. > "Please automatically delete anything that might be spam. They'll call > me if it's important. I know I'll lose some mail, but that's okay." If you have an agreement with a customer that specifically allows for such behaviour, great. We can get into individual cases for any concievable scenario, but that would be silly. It was pretty clear, to me at least, that we were discussing this as it would pertain to a system-wide configuration. > As for MUST bounce using return-path... perhaps you've never experienced > blowback from a joe job. It can be unpleasant. Yes, I have. And yes, it is. However, I never suggested bouncing spam, as my last message clearly stated. My position is that if you accept the message (250 OK), you have an obligation to deliver it. If you can't scan it during the SMTP transaction, do it after and mark up the headers, drop it in a junk folder - whatever - but don't delete it. St-
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
ST> Date: Wed, 12 Apr 2006 10:16:53 -0700 (PDT) ST> From: Steve Thomas ST> RFC 2821? ST> ST> ...the protocol requires that a server accept responsibility ST> for either delivering a message or properly reporting the ST> failure to do so. How does one properly report delivery failure to a guerrilla spammer? ST> Unless you're the final recipient of the message, you have no business ST> deleting it. If you've accept a message, you should either deliver or ST> bounce it, per RFC requirements. "Please automatically delete anything that might be spam. They'll call me if it's important. I know I'll lose some mail, but that's okay." Throwing RFC 2821 at that user probably would not have made them happy. As for MUST bounce using return-path... perhaps you've never experienced blowback from a joe job. It can be unpleasant. RFCs are for maintaining interoperability. They are not infallible. When a system is clearly broken, it's time to examine alternatives -- not to say that the RFC was handed down from on high. Proposal: MXes can say "2xx message queued with ID blahblahblah". They also can return 4xx "try back later codes". Yes? How about some return code that says "poll by $deadline if you want to know whether message ID blahblahblah was accepted or rejected"? No need to retransmit the entire message, and the sender can learn whether the message was actually accepted. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Open Letter to D-Link about their NTP vandalism
On Wed, Apr 12, 2006 at 01:32:26PM -0500, Stephen Sprunk wrote: > > On the plus side, after seeing D-Link's (lack of) reaction to this, I'll > bet none of us will buy another of their products again. If it was legal to sell whatever you people are smoking that makes you think dlink gives a flying crap about you as customers, I'd be a very rich man. What part of "mass consumer product" isn't clear here, 99.9% of their target market doesn't know NTP is, and doesn't care. I am absolutely appalled by the number of "slashdot warriors" here, ready to launch a crusade of spreading misinformation to the media in hopes of obtaining a large monetary payout or otherwise causing dlink, in the name of "doing the right thing", and without any consideration or understanding of the facts at hand. You know why dlink can't just come forward and say "woops we're sorry, we didn't see that you wanted this used for DIX members only, our bad"? Because they have to contend with people who will take that apology and then use it in court as an admission of guilt, and seek many tens of thousands of dollars or more in non-existent damages. I think we all know that dlink was wrong. They should have double-checked the list of NTP servers they included in their default shipping firmware to make certain that the owners were ok with having their services used publically, there is no question about this. However, just because they made this mistake, it is not an excuse for everyone involved to start cashing in like they hit the lottery. Imagine that you get rear ended in traffic by an inattentive driver, and they dent your bumper. Yes it is their fault, yes they made a mistake and they should be responsible for it, but it is not okay for you to start screaming whiplash as soon as you see that you got hit by a Mercedes. It also doesn't mean that you are going to get a new car instead of them paying to have your bumper fixed. If anyone else is going to carry this as a story, please act responsibly and do a little fact checking. We're talking about 37 packets/sec, less than a dialup worth of bandwidth, and any number of technical solutions which could completely mitigate that traffic without ANY additional expenses. Also, IANAL, but I think that refusing to take reasonable action to mitigate the damages because you feel the other party is "at fault" and should be 100% responsible is probably a good way to hurt any kind of case you might actually have against them too. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Spam filtering bcps
Bryan Bradsby wrote: Silently deleting other people's e-mail should never even be considered. Unless that email is a virus, or a spam with a forged envelope sender. Why? - You can scan for viruses inline using a variety of products (eg: I have patched Postfix to use clamav inline on modest hardware (single CPU AMD64 will do it, so will a Dual PIII 866) and it will accept messages at 50 messages per second (sustained load) and scan for viruses before responding to the end-of-data command, rejecting if a virus is detected.). Spam is a different subject altogether - are you that sure you can detect spam without a false positive? If so then why aren't you doing it inline? If you can't why are you blindly deleting the messages? - My BCP comment is if you can't detect inline (eg for performance reasons) tag it and deliver it (if you have the capabilities, deliver it to a junk folder) - that way you are following the RFC's and no non spam mail is deleted by the system. Regards, Mat
Re: How to handle AAAA query for v4 only host
--On April 13, 2006 8:13:27 AM +0930 Mark Smith <[EMAIL PROTECTED]> wrote: On Wed, 12 Apr 2006 17:27:54 -0400 Owen DeLong <[EMAIL PROTECTED]> wrote: Apologies if anyone thinks this does not require coordination or is somehow not operational. However, I have a situation where some nameservers for which I am responsible are receiving queries for hosts for which we are authoritative. We return the SOA only as it seems we are supposed to, but, we are seeing a significant delay before we get an A query back from the resolver, which, we believe represents a significant delay for the end user in getting to the web page in question. I'd have thought you were supposed to return a record not found error, which would then cause the remote resolver to immediately revert to performing an A query. Strangely enough, RFCs 1866, 3596, and 4074 seem to specifically say this is a bad thing. Is there a better way to answer an query for a v4 only host? Is it permitted and/or desirable to return a 6to4 or IPv4-Mapped address? Is there some other preferable thing to return? As long as you don't not respond, like doublelclick don't or didn't used to. Very frustrating waiting for queries to timeout before a page will fully load. Nope... As near as I can tell, responding with SOA only data is the right thing to do. FWIW, that's what f.root-servers.net seems to do as well. Owen pgpnotvLagSrW.pgp Description: PGP signature
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
Steve Thomas wrote: Earlier today, I said: Unless you're the final recipient of the message, you have no business deleting it. If you've accept a message, you should either deliver or bounce it, per RFC requirements. I just want to clarify that I was in no way suggesting that anyone bounce spam - I was merely pointing out that if you choose to 250 a message, you have to deliver it. The much better option is to 550 it after DATA if you don't like what you see. Silently deleting other people's e-mail should never even be considered. This policy I whole heartedly agree with, and I strive where ever possible to enforce this in every place I work, where ever people get listed in SORBS for backscatter, I work with them telling them how they can do this With the current technologies available there is no reason a small-medium organisation cannot virus and spam scan mail inline at the SMTP transaction stage. (Even the barracuda's can spamassassin scan at around 8 messages per second - my previous employment were receiving around 4 messages per second - which translated to 1-2 million emails per day) It is possible to do inline scanning in larger ISPs (I personally have configured a 'system' to handle upto 90 message per second inline scanning) - though it requires a lot more planning, thought, and careful consideration. Regards, Mat
Re: How to handle AAAA query for v4 only host
>Apologies if anyone thinks this does not require coordination or is somehow >not operational. > >However, I have a situation where some nameservers for which I am=20 >responsible >are receiving queries for hosts for which we are authoritative. We >return the SOA only as it seems we are supposed to, but, we are seeing a >significant delay before we get an A query back from the resolver, which, >we believe represents a significant delay for the end user in getting to >the web page in question. Both NAME ERROR and NOERROR NODATA responses can include the SOA record in the authority section (RFC 1034, RFC 2308). You don't give enough information to determine which of the abore responses you are talking about. >Is there a better way to answer an query for a v4 only host? Is it >permitted and/or desirable to return a 6to4 or IPv4-Mapped address? >Is there some other preferable thing to return? > >Thanks, > >Owen NOERROR NODATA is the correct response. As for why there is a delay between the and A queries there are lots of possible reason. Non RFC1535 aware resolvers. Not looking for /A in parallel when walking the search list. Firewalls block EDNS queries so you only see plain DNS queries. Sending NAME ERROR not NOERROR NODATA. Mark
Re: Open Letter to D-Link about their NTP vandalism
Steve Sobol wrote: On Tue, 11 Apr 2006, Alain Hebert wrote: Because its DIX ressources... They can do whatever they want with it. They owe nothing to DLink customers, and DLink customers should know to buy equipments from a better company that do not trespasses on other properties. And how exactly will the typical person buying a consumer-grade router even know something's wrong, in this case? (A NTP/KOD packet should be nice...) The cattle that buy those products dont care about DIX. But DLink might start to care if it gets in the media... -- Alain Hebert[EMAIL PROTECTED] PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.netfax 514-990-9443
How to handle AAAA query for v4 only host
Apologies if anyone thinks this does not require coordination or is somehow not operational. However, I have a situation where some nameservers for which I am responsible are receiving queries for hosts for which we are authoritative. We return the SOA only as it seems we are supposed to, but, we are seeing a significant delay before we get an A query back from the resolver, which, we believe represents a significant delay for the end user in getting to the web page in question. Is there a better way to answer an query for a v4 only host? Is it permitted and/or desirable to return a 6to4 or IPv4-Mapped address? Is there some other preferable thing to return? Thanks, Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgptERTCJCB8D.pgp Description: PGP signature
Re: Spam filtering bcps
On Wed, 12 Apr 2006 14:28:59 -0500 (CDT) Bryan Bradsby <[EMAIL PROTECTED]> wrote: Silently deleting other people's e-mail should never even be considered. Unless that email is a virus, or a spam with a forged envelope sender. -bryan bradsby Aha, so there are situtations where this is acceptable? What about deleting viral attachments or altering subject lines...is that permissible? The sweeping generalizations I've read leave little room for responding to real-world situations. matthew black california state university, long beach
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
On Wed, 12 Apr 2006 14:18:24 -0400 [EMAIL PROTECTED] wrote: On Wed, 12 Apr 2006 10:16:53 PDT, Steve Thomas said: > I haven't seen any succinct justification for providing a > 550 message rejection for positively-identified spam versus > silently dropping the message. Lots of how-to instructions > but no whys. RFC 2821? ...the protocol requires that a server accept responsibility for either delivering a message or properly reporting the failure to do so. Your statement is open to multiple interpretations. I argue that anytime our system identifies a message as spam that it gets delivered to the system bit bucket. RFC-821 and netiquette also "mandate" e-mail be properly addressed. System manufacturers and administrators make compromises because strict adherence to the rules is not always possible from an operational perspective. Elsewhere in 2821 (6.1, to be specific): When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage. Lost me on that part about crashes being frivolous reasons. This is a political statement not an indisputable matter of fact. OK? Got that? You '250 OK' it, you got a *serious* responsibility. Losing the message because the whole damned machine crashes is considered a frivolous reason. And throwing it away because you don't like the way it looks is OK? Man, ...*** you're in for some severe karmic protocol payback down the road... ;) I'm not the one throwing them away and never look at them; watch the finger wagging. And thanks for the karma heads up, Bhudda. matthew black california state university, long beach
Re: Open Letter to D-Link about their NTP vandalism
On Tue, 11 Apr 2006, Alain Hebert wrote: > Because its DIX ressources... They can do whatever they want with it. > > They owe nothing to DLink customers, and DLink customers should > know to buy equipments from a better company that do not trespasses on > other properties. And how exactly will the typical person buying a consumer-grade router even know something's wrong, in this case? -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Apple Valley, CA Resident of Southern California - the home of beautiful people and butt-ugly traffic jams
Re: Open Letter to D-Link about their NTP vandalism
On Wed, 12 Apr 2006, Steve Sobol wrote: On Tue, 11 Apr 2006, Steven M. Bellovin wrote: By the way, since we're talking about D-Link, it's instructive to read the warnings on their firmware update pages. Do NOT upgrade firmware on any D-Link product over a wireless connection. Failure of the device may result. Use only hard-wired network connections. Cisco/Linksys says the same thing. It is safe to do it with openwrt at least. scp the firmware to a local file, then update flash from that file. -Dan
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
On Wed, Apr 12, 2006 at 12:03:51PM -0400, Joe Maimon wrote: > Matthew Black wrote: > > > there's no bandwidth savings from silently dropping the message > > versus providing a 550 rejection. In the best of all worlds, > > it would be nice to give feedback. No system is perfect and a > > false-positive rate of less than one in a million "220" accepted > > messages seems pretty small. > > Let me ask you this simple question: > > If you know at close of DATA whether you are going to actually perform > final delivery, what does it cost you to follow standards and issue a > 550 instead of a 220 and discard it? > > If you use a 550, a real live person sending an email that somehow gets > FP will actually benefit. In today's world, at least with the spamtorrent I see at my clients, that's just untrue. If your filtering is set up well, and you mark an e-mail as SPAM, it almost certainly is (yes, I'll certainly concede FP's exist, but again, it almost certainly doesn't matter that much in that teensy number of occurrences); and 99-plus-percent of spam is emitted from spambots who don't give a $expletive about return status one way or another. If you're worrying about "no-status" in the context of FP's, then your filtering isn't set up well, which really means you've got larger problems. > I am with Suresh on this, just like in the past threads. Search the archive. Though not contradicting what I just wrote, so am I. However, header-forged and multi-chained spam from firehose-like spambots don't play by any of our rules; all they do is blast away in a largely one-way transaction (guess which direction!). A 550 now-a-days has nowhere to "go" (and those "commercial" akak "legit") spamhouses don't wash their lists even on 550's. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
Re: Spam filtering bcps
On Wed, 12 Apr 2006 14:28:59 CDT, Bryan Bradsby said: > > > Silently deleting other people's e-mail should never even be considered. > > Unless that email is a virus, or a spam with a forged envelope sender. No, in that case you 550 the sucker. pgpOxV2xehNAo.pgp Description: PGP signature
Re: Open Letter to D-Link about their NTP vandalism
On 4/12/06, Steve Sobol <[EMAIL PROTECTED]> wrote: > On Tue, 11 Apr 2006, Steven M. Bellovin wrote: > > By the way, since we're talking about D-Link, it's instructive to read the > > warnings on their firmware update pages. > > > > Do NOT upgrade firmware on any D-Link product over a wireless > > connection. Failure of the device may result. Use only hard-wired > > network connections. > > Cisco/Linksys says the same thing. Who here hasn't been burned at least once by changing packet filters, routes or interface configurations over the wire/air? Or maybe getting your userland and kernel out of sync on a *NIX machine? It's not really that surprising that they put that in there, other than maybe the fact that it's useful advice. And maybe it'll reduce support costs. Loading a new firmware is a risky operation - I don't know of too many consumer network widgets with a reflash safety protocol to prevent you from destroying the device with an aborted upload. Heck, that's still a pretty rare feature in pee-cees. Sure it's easy to implement such a thing, but that would cost money. I think this thread has done a good job of demonstrating that those who would choose the right (and maybe slightly more expensive up front) solution are outvoted by those who would just take a quick, cheap and easy hack. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: Spam filtering bcps
> Silently deleting other people's e-mail should never even be considered. Unless that email is a virus, or a spam with a forged envelope sender. -bryan bradsby
[non-operational] possible IXP operators BOF in San Jose in June
Hi all, Any IXP operators on this list interested in participating in a BOF at NANOG 37 in San Jose? This would be a get-together for exchange point operators to discuss back-end automation and measurement, switches, etc, not a place for ISPs to discuss peering. If anybody is interested, drop me a note directly, off-list. Thanks! Joe
Re: Open Letter to D-Link about their NTP vandalism
On Tue, 11 Apr 2006, Steven M. Bellovin wrote: > By the way, since we're talking about D-Link, it's instructive to read the > warnings on their firmware update pages. > > Do NOT upgrade firmware on any D-Link product over a wireless > connection. Failure of the device may result. Use only hard-wired > network connections. Cisco/Linksys says the same thing. -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Apple Valley, CA Resident of Southern California - the home of beautiful people and butt-ugly traffic jams
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
Earlier today, I said: > Unless you're the final recipient of the message, you have no business > deleting it. If you've accept a message, you should either deliver or > bounce it, per RFC requirements. I just want to clarify that I was in no way suggesting that anyone bounce spam - I was merely pointing out that if you choose to 250 a message, you have to deliver it. The much better option is to 550 it after DATA if you don't like what you see. Silently deleting other people's e-mail should never even be considered. Returning to lurk status... St-
Re: Open Letter to D-Link about their NTP vandalism
Thus spake "Alexei Roudnev" <[EMAIL PROTECTED]> Hmm, if some idiot wrote my NTP IP into his hardware, I just stop to monitor my NTP and make sure that it have few hours of error in time. No one require me to CLAIM that I set up wrong time, BUT no one can require me to maintain correct time just because some idiots use my server. What most people participating in this subthread seem to be missing is that if one did decide to send (or accidentally sent) false time to these D-Link devices, NOBODY WOULD EVER KNOW OR CARE. Doing so does not solve any problems, so whatever the legal risk of acting is, no matter how small, it's not worth it. On the plus side, after seeing D-Link's (lack of) reaction to this, I'll bet none of us will buy another of their products again. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
On Wed, 12 Apr 2006 10:16:53 PDT, Steve Thomas said: > > > I haven't seen any succinct justification for providing a > > 550 message rejection for positively-identified spam versus > > silently dropping the message. Lots of how-to instructions > > but no whys. > > RFC 2821? > > ...the protocol requires that a server accept responsibility > for either delivering a message or properly reporting the > failure to do so. Elsewhere in 2821 (6.1, to be specific): When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage. OK? Got that? You '250 OK' it, you got a *serious* responsibility. Losing the message because the whole damned machine crashes is considered a frivolous reason. And throwing it away because you don't like the way it looks is OK? Man, you're in for some severe karmic protocol payback down the road... ;) pgpmW5ds5R1xP.pgp Description: PGP signature
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
> I haven't seen any succinct justification for providing a > 550 message rejection for positively-identified spam versus > silently dropping the message. Lots of how-to instructions > but no whys. RFC 2821? ...the protocol requires that a server accept responsibility for either delivering a message or properly reporting the failure to do so. ... If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path). Unless you're the final recipient of the message, you have no business deleting it. If you've accept a message, you should either deliver or bounce it, per RFC requirements.
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
Matthew Black wrote: there's no bandwidth savings from silently dropping the message versus providing a 550 rejection. In the best of all worlds, it would be nice to give feedback. No system is perfect and a false-positive rate of less than one in a million "220" accepted messages seems pretty small. I thought I had already participated in beating this dead horse sufficiently in multiple threads in multiple forums on multiple occasions. Maybe I am in your killfile or something. If I post again on this topic, I certainly will deserve to be. Let me ask you this simple question: If you know at close of DATA whether you are going to actually perform final delivery, what does it cost you to follow standards and issue a 550 instead of a 220 and discard it? If you use a 550, a real live person sending an email that somehow gets FP will actually benefit. I am with Suresh on this, just like in the past threads. Search the archive.
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
On Wed, 12 Apr 2006 21:12:44 +0530 "Suresh Ramasubramanian" <[EMAIL PROTECTED]> wrote: On 4/12/06, Matthew Black <[EMAIL PROTECTED]> wrote: Where is the bandwidth savings once we've accepted an entire message, scanned it, determined it was spam, then provided a 550 rejection versus silently droping? If you can scan it inline, you can stop, issue a 550 and drop the SMTP connection any time you want. Like for example, midstream when you discover a fake header pattern. You'd start with whatever can be rejected in session - fake HELOs, blocklist listed IPs, random faked headers, dodgy attachment types that are more likely to be viruses than not Then apply the heavier and more cpu intensive filters later, on a much smaller volume of spam We already do this. Maybe not all that much of a bandwidth / cpu saving, but saving remote postmasters the hassle of troubleshooting lost email is always a good idea. After all said methods have been performed and the message gets through reputation filtering; blacklists; forged/munged headers, e-mail addresses, domain names the message comes in and then there's that final dot. Up to this point, the message hasn't proven to be spam until it can be scanned using BrightMail, SpamAssassin, Baysian filters, DCC lists, or other methods. All I'm saying is that once the full DATA submission has completed, there's no bandwidth savings from silently dropping the message versus providing a 550 rejection. In the best of all worlds, it would be nice to give feedback. No system is perfect and a false-positive rate of less than one in a million "220" accepted messages seems pretty small. matthew black california state university, long beach
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
On 4/12/06, Matthew Black <[EMAIL PROTECTED]> wrote: > Agreed, but we're willing to live with an error rate of less > than one in a million. This isn't a space shuttle. I don't think > the USPS can claim 99.% delivery accuracy. Nonetheless, to I'm not even saying five nines. Spam filtering - even with heuristics etc - is less than perfect, and per user spam filtering, however idiot proof, sometimes turns out to be like giving Acme Inc gadgets to Wile E Coyote. [users having fun with procmail and .forwards should already be a familiar story I guess?] > We already reject most connections with a 550 or TCP REFUSE > based on reputation filtering and blacklists, et al. That works just fine. I dont have any argument with it > Where is the bandwidth savings once we've accepted an entire message, > scanned it, determined it was spam, then provided a 550 rejection > versus silently droping? If you can scan it inline, you can stop, issue a 550 and drop the SMTP connection any time you want. Like for example, midstream when you discover a fake header pattern. You'd start with whatever can be rejected in session - fake HELOs, blocklist listed IPs, random faked headers, dodgy attachment types that are more likely to be viruses than not Then apply the heavier and more cpu intensive filters later, on a much smaller volume of spam Maybe not all that much of a bandwidth / cpu saving, but saving remote postmasters the hassle of troubleshooting lost email is always a good idea. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
On Wed, 12 Apr 2006 20:30:16 +0530 "Suresh Ramasubramanian" <[EMAIL PROTECTED]> wrote: On 4/12/06, Matthew Black <[EMAIL PROTECTED]> wrote: I haven't seen any succinct justification for providing a 550 message rejection for positively-identified spam versus silently dropping the message. Lots of how-to instructions but no whys. For viruses - fine. But you are not going to find any spam filter in the world that doesnt have false positives. And in such cases its always a good idea to let the sender know his email didnt get through. Agreed, but we're willing to live with an error rate of less than one in a million. This isn't a space shuttle. I don't think the USPS can claim 99.% delivery accuracy. Nonetheless, to allay worries, we are considering spam quarantines to allow recipients an opportunity to review spam messages themselves, much like Yahoo! Mail. Complaints about e-mail not getting through won't be solved with a 550 versus silently dropping spam because most users aren't willing to sift through e-mail errors to find the specific cause for delivery failure. Members of this list are a rare exception. Like for example - you see a large webmail provider whose hosts and domains keep getting forged into spam, misread the headers and block that provider. In such cases, its your users who arent getting a lot of valid email from their friends and relatives who are using that provider, and 550'ing instead of trashing email saves the senders, and their provider, quite lot of time that'd otherwise be spent troubleshooting the issue. Plus, 5xx smtp rejects tend to save your bandwidth a bit compared to accepting the entire email (not that it matters on a small university domain where your userbase is going to be fairly small, and bandwidth available quite generous .. but for larger sites, or sites with bandwidth issues, that's definitely a concern) We already reject most connections with a 550 or TCP REFUSE based on reputation filtering and blacklists, et al. Where is the bandwidth savings once we've accepted an entire message, scanned it, determined it was spam, then provided a 550 rejection versus silently droping? matthew black california state university, long beach
Re: well-known NTP? (Re: Open Letter to D-Link about their NTP vandalism)
Just for curiousity, you can change it. /etc/hosts is a link /etc/hosts -> ../var/tmp/hosts you can edit but you cannot permanently save it. cat /etc/hosts 127.0.0.1 localhost 192.168.178.1 fritz.box 217.10.79.8 0.europe.pool.ntp.org ntp.sipgate.de Now I dont bother pool.ntp.org but ask my sip provider. That trick might work for the D-Link too. Of course 0.europe.pool.ntp.org is alright but that ntp server D-Link has is not. You have to insert the hostname plus ip into /var/tmp/hosts or the box will ask DNS. Cheers Peter and Karin Peter Dambier wrote: From my Fritzbox log: Apr 12 06:27:29 multid[360]: dns: 0.europe.pool.ntp.org: query Apr 12 06:27:30 multid[360]: dns: 0.europe.pool.ntp.org: 82.71.9.63 ttl=79 from 192.168.180.1. Apr 12 06:27:30 multid[360]: sending SNTP request to server 0.europe.pool.ntp.org (82.71.9.63) Apr 12 06:27:30 multid[360]: The NTP time is 12.4.2006 04:27:29.15 UTC Apr 12 06:27:30 multid[360]: system time is 1.007000 seconds ahead Apr 12 06:27:30 multid[360]: adjusting time backward 1.007000 seconds Seems to do that every 8 hours. I could not find a config file. Compiled into "/sbin/multid" ? I guess similar devices like the maudit D-Link are much the same. Only that multid deamon seems to be AVM specific. If that NTP thing is from the non disclosed und unGPLed TI source then best forget about it. Replace it by some wellknown software that is known not to be nasty. Another router that is not compatible and not especially a good router - has an html interface where you can put it your favourite NTP server. I still wonder why I cannot configure the NTP server but at least it is not as nasty as the D-Link. Peter Stephane Bortzmeyer wrote: On Tue, Apr 11, 2006 at 10:01:10PM +, Edward B. DREGER <[EMAIL PROTECTED]> wrote a message of 27 lines which said: AS112-style NTP service, anyone? That would be cooperative and possibly even useful. It already exists (Security warning: do not use it on strategic machine, there is no warranty that these servers are trustful): http://www.pool.ntp.org/ Active server count on 2006-04-12 Africa 1 Asia 24 Europe 368 North America 223 Oceania 26 South America 7 Global 582 All Pool Servers 653 The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable easy to use NTP service for millions of clients without putting a strain on the big popular timeservers. Adrian von Bidder created this project after a discussion about resource consumption on the big timeservers, with the idea that for everyday use a DNS round robin would be good enough, and would allow spreading the load over many servers. The disadvantage is, of course, that you may occasionally get a bad server and that you usually won't get the server closest to you. The workarounds for this is respectively to make sure you configure at least three servers in your ntp.conf and to use the country zones (for example 0.us.pool.ntp.org) rather than the global zone (for example 0.pool.ntp.org). Read more on using the pool. The pool is now enormously popular, being used by at least hundreds of thousands and maybe even millions of systems around the world. The pool project is now being maintained by Ask Bjørn Hansen and a great group of contributors on the mailing lists. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
On Wed, 12 Apr 2006, Matthew Black wrote: > > I haven't seen any succinct justification for providing a > 550 message rejection for positively-identified spam versus > silently dropping the message. If you are wrong about the message being spam, then the sender gets a bounce. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 5 OR 6, PERHAPS INCREASING 7 LATER IN NORTH. RAIN AT FIRST. MAINLY GOOD. SLIGHT OR MODERATE.
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
On 4/12/06, Matthew Black <[EMAIL PROTECTED]> wrote: > > I haven't seen any succinct justification for providing a > 550 message rejection for positively-identified spam versus > silently dropping the message. Lots of how-to instructions > but no whys. > For viruses - fine. But you are not going to find any spam filter in the world that doesnt have false positives. And in such cases its always a good idea to let the sender know his email didnt get through. Like for example - you see a large webmail provider whose hosts and domains keep getting forged into spam, misread the headers and block that provider. In such cases, its your users who arent getting a lot of valid email from their friends and relatives who are using that provider, and 550'ing instead of trashing email saves the senders, and their provider, quite lot of time that'd otherwise be spent troubleshooting the issue. Plus, 5xx smtp rejects tend to save your bandwidth a bit compared to accepting the entire email (not that it matters on a small university domain where your userbase is going to be fairly small, and bandwidth available quite generous .. but for larger sites, or sites with bandwidth issues, that's definitely a concern) --srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
Several people kindly contacted me off list with laborious explanations of how to implement delayed 550 rejections using sedmail, et al. We gave up sendmail years ago in favor of a competing solution. I haven't seen any succinct justification for providing a 550 message rejection for positively-identified spam versus silently dropping the message. Lots of how-to instructions but no whys. matthew black california state university, long beach
Re: Open Letter to D-Link about their NTP vandalism
At 10:15 AM -0400 4/12/06, Alain Hebert wrote: FYI: a couple of update at http://people.freebsd.org/~phk/dlink/ I've summited a suggestion for a story to Wired... We'll see. Perhaps they could also talk to someone who actually knows how ntp works as well. -M< -- Martin Hannigan(c) 617-388-2663 Renesys Corporation(w) 617-395-8574 Member of Technical Staff Network Operations [EMAIL PROTECTED]
Re: Open Letter to D-Link about their NTP vandalism
FYI: a couple of update at http://people.freebsd.org/~phk/dlink/ I've summited a suggestion for a story to Wired... We'll see. -- Alain Hebert[EMAIL PROTECTED] PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.netfax 514-990-9443
Re: Open Letter to D-Link about their NTP vandalism
"M. David Leonard" <[EMAIL PROTECTED]> writes: > What is to prevent a network from providing unjittered NTP to its > downstream clients/customers BUT jittered NTP to outsiders? How is this > different from providing up-to-the-millisecond stock exchange data to > paying customers but delaying the same data provided to the general public > by some time period? "All quotes and all NTP ticks are delayed 15 minutes" is an amusing concept. > Are we constrained by fear of litigation from > taking appropriate pro-active measures to protect services from abuse and > from discriminating between legitimate and questionable requests for data > from our own servers? Is it time to bail out of the Internet business? Listen to Paul; he's a past master at defending against gratuitous/stupid lawsuits. You're under no obligation to provide the service, but actively providing bad info could be construed as a tort, and defending/filing lawsuits, like horse racing (owning the horses, not going to the races), is a sport for the super-well-heeled. ---Rob
Re: Open Letter to D-Link about their NTP vandalism
On Wed, 12 Apr 2006, M. David Leonard wrote: > > This reminds me of "selective availability" (I think that's the > correct term) in the GPS stream coming from US DOD orbital platforms. > Sure, the data is jittered. Hasn't been for several years. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 5 OR 6, PERHAPS INCREASING 7 LATER IN NORTH. RAIN AT FIRST. MAINLY GOOD. SLIGHT OR MODERATE.
Re: Open Letter to D-Link about their NTP vandalism
This reminds me of "selective availability" (I think that's the correct term) in the GPS stream coming from US DOD orbital platforms. Sure, the data is jittered. Who sues because only authorized clients (in that case, US military forces) get unjittered time and position but folks without authorization get severely compromised time and position data? What is to prevent a network from providing unjittered NTP to its downstream clients/customers BUT jittered NTP to outsiders? How is this different from providing up-to-the-millisecond stock exchange data to paying customers but delaying the same data provided to the general public by some time period? Are we constrained by fear of litigation from taking appropriate pro-active measures to protect services from abuse and from discriminating between legitimate and questionable requests for data from our own servers? Is it time to bail out of the Internet business? David Leonard ShaysNet On 11 Apr 2006, Paul Vixie wrote: > > > > > > > I've said in other forums the only solution for this sort of > > > > > > software is to return the wrong time (by several months). The > > > > > > owner might actually notice then and fix the problem. > > > > > > that creates new liability, and isn't realistic in today's > > > > > litigious world. > > > > > (Suprise to read that from PV.) > > > > Why? It may be the voice of experience. ... > > > Because its DIX ressources... They can do whatever they want with it. > > actually, not. who owns the resources isn't as important, to a judge, as > whether someone is damaged and whether that damage resulted from an > intentional act. the "voice of experience", if i have one, says that if > DIX wants to cease providing this service they can do so safely, but if > they decide to deliberately return the wrong time, and if that wrong time > costs or loses somebody else some money, then a judge would take it seriously. > > again, denying service (assuming there's no explicit contract to provide > it) is unquestionably safe. i was responding to the proposal that the wrong > time be deliberately returned. you'd be betting that nobody would notice > or that it would cost nobody money -- which isn't a safe bet, since someone > can always find ways to allege that your intentional actions cost them money. > (as opposed to your deliberate inaction, as in the case of denying service.) > > note, IANAL. but i've been sued by experts, and even stupid lawsuits cost a > lot to answer/defend, and not all stupid lawsuits are provably frivolous. > -- > Paul Vixie >
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
Matthew Sullivan wrote: Suresh Ramasubramanian wrote: On 4/11/06, Matthew Black <[EMAIL PROTECTED]> wrote: Are you suggesting that we configure our e-mail servers to notify people upon automatic deletion of spam? Frequently, spam cannot be properly identified until closure of the SMTP conversation and that final 200 mMESSAGE ACCEPTED...or do you think that TCP/IP connection should be held open until the message can be scanned for spam and viruses just so we can give a 550 MESSAGE REJECTED error instead of silently dropping it? You can reject right after DATA, at the . stage, before QUIT That's still an in line smtp reject rather than an accept + bounce DSN. Exim with the spamassassin patches (sa-exim) does this, for example. -srs Of course Postfix can be setup (using spampd) with spamassassin to do exactly the same. I believe Sendmail+MimeDefang+Spamassassin will also reject inline if set to do so. Regards, Mat As will sendmail+spamass-milter+spamassassin In fact there are quite a few milters that can be used in between sendmail and spamassassin Joe
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
Suresh Ramasubramanian wrote: On 4/11/06, Matthew Black <[EMAIL PROTECTED]> wrote: Are you suggesting that we configure our e-mail servers to notify people upon automatic deletion of spam? Frequently, spam cannot be properly identified until closure of the SMTP conversation and that final 200 mMESSAGE ACCEPTED...or do you think that TCP/IP connection should be held open until the message can be scanned for spam and viruses just so we can give a 550 MESSAGE REJECTED error instead of silently dropping it? You can reject right after DATA, at the . stage, before QUIT That's still an in line smtp reject rather than an accept + bounce DSN. Exim with the spamassassin patches (sa-exim) does this, for example. -srs Of course Postfix can be setup (using spampd) with spamassassin to do exactly the same. I believe Sendmail+MimeDefang+Spamassassin will also reject inline if set to do so. Regards, Mat
Re: Open Letter to D-Link about their NTP vandalism
Miquel van Smoorenburg wrote: In article <[EMAIL PROTECTED]>, Matt Ghali <[EMAIL PROTECTED]> wrote: .or do you think that TCP/IP connection should be held open until the message can be scanned for spam and viruses just so we can give a 550 MESSAGE REJECTED error instead of silently dropping it? absolutely. is that actually a problem, today, in 2006? RCPT TO: <[EMAIL PROTECTED]> RCPT TO: <[EMAIL PROTECTED]> DATA . .. after content scanning, user1 wants the mail, user2 doesn't. Now what ? Mike. Three choices Screw user1 Screw user2 Screw sender by dropping user2 from recipient list Its only on the third choice that you have to decide whether or not to notify the sender with a bounce. A patched sendmail can prevent a milter from performing a reject of an email as requested by a milter, if some of the recipients do not want the protection offered.
Re: well-known NTP? (Re: Open Letter to D-Link about their NTP vandalism)
From my Fritzbox log: Apr 12 06:27:29 multid[360]: dns: 0.europe.pool.ntp.org: query Apr 12 06:27:30 multid[360]: dns: 0.europe.pool.ntp.org: 82.71.9.63 ttl=79 from 192.168.180.1. Apr 12 06:27:30 multid[360]: sending SNTP request to server 0.europe.pool.ntp.org (82.71.9.63) Apr 12 06:27:30 multid[360]: The NTP time is 12.4.2006 04:27:29.15 UTC Apr 12 06:27:30 multid[360]: system time is 1.007000 seconds ahead Apr 12 06:27:30 multid[360]: adjusting time backward 1.007000 seconds Seems to do that every 8 hours. I could not find a config file. Compiled into "/sbin/multid" ? I guess similar devices like the maudit D-Link are much the same. Only that multid deamon seems to be AVM specific. If that NTP thing is from the non disclosed und unGPLed TI source then best forget about it. Replace it by some wellknown software that is known not to be nasty. Another router that is not compatible and not especially a good router - has an html interface where you can put it your favourite NTP server. I still wonder why I cannot configure the NTP server but at least it is not as nasty as the D-Link. Peter Stephane Bortzmeyer wrote: On Tue, Apr 11, 2006 at 10:01:10PM +, Edward B. DREGER <[EMAIL PROTECTED]> wrote a message of 27 lines which said: AS112-style NTP service, anyone? That would be cooperative and possibly even useful. It already exists (Security warning: do not use it on strategic machine, there is no warranty that these servers are trustful): http://www.pool.ntp.org/ Active server count on 2006-04-12 Africa 1 Asia24 Europe 368 North America 223 Oceania 26 South America 7 Global 582 All Pool Servers653 The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable easy to use NTP service for millions of clients without putting a strain on the big popular timeservers. Adrian von Bidder created this project after a discussion about resource consumption on the big timeservers, with the idea that for everyday use a DNS round robin would be good enough, and would allow spreading the load over many servers. The disadvantage is, of course, that you may occasionally get a bad server and that you usually won't get the server closest to you. The workarounds for this is respectively to make sure you configure at least three servers in your ntp.conf and to use the country zones (for example 0.us.pool.ntp.org) rather than the global zone (for example 0.pool.ntp.org). Read more on using the pool. The pool is now enormously popular, being used by at least hundreds of thousands and maybe even millions of systems around the world. The pool project is now being maintained by Ask Bjørn Hansen and a great group of contributors on the mailing lists. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
Re: Open Letter to D-Link about their NTP vandalism
In article <[EMAIL PROTECTED]>, Matt Ghali <[EMAIL PROTECTED]> wrote: >> .or do you think that TCP/IP connection >> should be held open until the message can be scanned for spam and >> viruses just so we can give a 550 MESSAGE REJECTED error instead of >> silently dropping it? > >absolutely. is that actually a problem, today, in 2006? RCPT TO: <[EMAIL PROTECTED]> RCPT TO: <[EMAIL PROTECTED]> DATA . .. after content scanning, user1 wants the mail, user2 doesn't. Now what ? Mike.
Re: Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]
On Wed, 12 Apr 2006, Suresh Ramasubramanian wrote: > > Exim with the spamassassin patches (sa-exim) does this, for example. SpamAssassin support is built in to Exim since version 4.50. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 5 OR 6, PERHAPS INCREASING 7 LATER IN NORTH. RAIN AT FIRST. MAINLY GOOD. SLIGHT OR MODERATE.
Re: well-known NTP? (Re: Open Letter to D-Link about their NTP vandalism)
On Tue, 11 Apr 2006, Edward B. DREGER wrote: > > AS112-style NTP service, anyone? That would be cooperative and possibly even > useful. pool.ntp.org Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 5 OR 6, PERHAPS INCREASING 7 LATER IN NORTH. RAIN AT FIRST. MAINLY GOOD. SLIGHT OR MODERATE.
Re: Open Letter to D-Link about their NTP vandalism
On 12/04/06, Alexei Roudnev <[EMAIL PROTECTED]> wrote: Hmm, if some idiot wrote my NTP IP into his hardware, I just stop to monitormy NTP and make sure that it have few hours of error in time. No one require me to CLAIM that I set up wrong time, BUT no one can require me to maintaincorrect time just because some idiots use my server. That works well as long as you don't have any legitimate users of your NTP service.-- Tony Sarendal - [EMAIL PROTECTED]IP/Unix -= The scorpion replied, "I couldn't help it, it's my nature" =-
Re: well-known NTP? (Re: Open Letter to D-Link about their NTP vandalism)
On Tue, Apr 11, 2006 at 10:01:10PM +, Edward B. DREGER <[EMAIL PROTECTED]> wrote a message of 27 lines which said: > AS112-style NTP service, anyone? That would be cooperative and > possibly even useful. It already exists (Security warning: do not use it on strategic machine, there is no warranty that these servers are trustful): http://www.pool.ntp.org/ Active server count on 2006-04-12 Africa 1 Asia24 Europe 368 North America 223 Oceania 26 South America 7 Global 582 All Pool Servers653 The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable easy to use NTP service for millions of clients without putting a strain on the big popular timeservers. Adrian von Bidder created this project after a discussion about resource consumption on the big timeservers, with the idea that for everyday use a DNS round robin would be good enough, and would allow spreading the load over many servers. The disadvantage is, of course, that you may occasionally get a bad server and that you usually won't get the server closest to you. The workarounds for this is respectively to make sure you configure at least three servers in your ntp.conf and to use the country zones (for example 0.us.pool.ntp.org) rather than the global zone (for example 0.pool.ntp.org). Read more on using the pool. The pool is now enormously popular, being used by at least hundreds of thousands and maybe even millions of systems around the world. The pool project is now being maintained by Ask Bjørn Hansen and a great group of contributors on the mailing lists.
Re: Open Letter to D-Link about their NTP vandalism
Hmm, if some idiot wrote my NTP IP into his hardware, I just stop to monitor my NTP and make sure that it have few hours of error in time. No one require me to CLAIM that I set up wrong time, BUT no one can require me to maintain correct time just because some idiots use my server. The same in this case - instead of long claiming, complaining and so on they could just set up wrong time (and never claim that they did it - just _oo, we have a wrong time.. Thanks, but we do not maintain this NTP server and we cannot change anything on this server so we cannot correct it_ - and problem could be solved forever. And even could maintain different NTP translation fro their customers. Just again, no one can prohibit it, even in USA. Just _DO NOT CLAIM_ that it was intentionally. Here is a difference - _coffee is hot, someone's server is brokn, if 'Ivan||Paul||Lisa' have a CD he/she always can make a copy, fire can burn, dog can bite_ - everyone should know it; if he do not know, it's his personal problems, not someone's liability. Kids MUST learn such things when they are young. It is COMMON SENSE. - Original Message - From: "Michael Froomkin - U.Miami School of Law" <[EMAIL PROTECTED]> To: "Alexei Roudnev" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "John Dupuy" <[EMAIL PROTECTED]> Sent: Tuesday, April 11, 2006 11:29 AM Subject: Re: Open Letter to D-Link about their NTP vandalism > I'd really suggest that readers confirm this claim (that > intentional sending of false data with a malicious purpose is perfectly > acceptable) with a local lawyer before trying it at home or at work. professor> > > I also bet that the claim of widespread acceptability would fail badly if > we weigh countries by population. Or even connectivity. > > Not to mention the fact that your packets might stray across borders > sometimes. > > On Tue, 11 Apr 2006, Alexei Roudnev wrote: > > > > > It's legal to have broken NTP server in ANY country, and it's legal in most > > (by number) countries to send counter-attack (except USA as usual, where > > lawyers want to get their money and so do not allow people to self-defence). > > > > -- > http://www.icannwatch.org Personal Blog: http://www.discourse.net > A. Michael Froomkin |Professor of Law| [EMAIL PROTECTED] > U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA > +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm > -->It's warm here.<--
