Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
This is not true. Im not sure how many 'most' ISPs you are talking about, but I know quite a few ISPs that accept all email for a domain and forward to a customer. This is most prevalent in dialup/isdn situations where you basically 'store and forward' all email for customers that are mostly offline. When they come online that triggers a queuerun towards the customer. In many cases, this is handled not by server-to-server, but by a client contacting the ISP server and retrieving the e-mail and then sorting it out in whatever way. In many other cases this is handled by MTAMTA traffic. In any case, this is in reality no different from a client calling up and getting the mail from a server. Because the ISP is the only MX, it should know about all the deliverable addresses, simply to avoid dictionary e-mailings to these offline domains. In theory this sounds fine, in practise this is irrealistic. Im assuming you dont run an ISP? It would mean you would have to create automated emailalias syncing with every customer with this type of setup, no matter what their software is. I think I confuse ISP with quality ISP. There is no need to be abusive to try and make your point. It makes your point seem less valid. And again, you are wrong :) Not for real domains. If the ISP is the *only* MX and you retrieve your e-mail as if you are a client (not an MTA), then it is the responsibility of the MX machine to know what is and is not deliverable. And that's where the heart of this confusion is. We do indeed have tens of thousands of customers that pick up their email with client software. POP, IMAP, even webmail. But we have quite a few customers where this is done with MTA traffic. Customer comes online and the authentication itself triggers a push of the queue. I know several ISPs in our area alone that do this. And what do you think the command ETRN is for? One could give these hosts a lower MX, but on the other hand, if they're almost never online you'd have to wonder if thats a good thing. Dont forget, the internet is older than the spam problem. Im not saying these kinds of setups cant be changed, im saying they're not trivial to change. This discussion started with implementing SPF, and for an ISP implementing SPF has a lot of problems. Not unsolvable, but it wont be pretty. Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
Again, this completely solves the issue of forged return address bounce e-mails. Actually, no it doesn't. Let's try another ISP-as-MX scenario, this time where the company runs its own mail server as primary MX, but uses the ISP's server as a secondary: Whoa... stop right there. If ISPs do this, there's a growing onus to maintain a valid user list, even without spam/virus filtering. The details are up to the ISP to determine - whether they hook up a scheduled feed from the customer (via, say, LDAP) or whether they ask the user to manage valid users via a web interface. It's not a question of ISPs doing it, it's a fact that ISPs have been doing it for many many years. From way before spam became a problem. Changing it is not going to be pretty. Try and tell 100.000 customers that they have to maintain a valid userlist with you. It's possible (for certain interpretations of possible), but very very costly and timeconsuming. Ofcourse it's easy when you run your little homesystem for you and your wife. Sure it's easy when you have 15 employees that you can force a change upon. It is not easy, not by a long shot, to change the behavior of many many customers. It is not a question of 'changing a door'. It's a question of changing 10.000 doors, some of which you didnt even know existed, some of which baffle even you, and you run the damn system, some of which have had keys made in gold with jewels laid in, some of which have 5000 copy keys unbeknownst to you, and you need to tell the user of that door to please give everyone a new key and they dont even know who uses it. Some of these doors are used by lawfirms just aching to sue you. Changing anything, even something seemingly benign, often has large implications. Now dont think that that means ISPs dont want to fix things. ISPs have been fixing things and are fixing things. We are as we speak implementing a very large mimedefang system (50+ servers) to move more and more checks to the front door so we can reject there. But I am realistic enough to know it's never going to be 100%. There will always be noise on the line. But accept-everything-and-send-manual-undeliverable-reports-later is becoming less and less acceptable of a strategy. Just to clarify. The person you are replying on said that it might very well be that you are accepting for a valid recipient as a secondary MX, but the primary can still reject you for totally different reasons. The secondary would then have to bounce. Thats part of the noise.. How far are we from banning each and every bounce? :) Dear ISP, I got a bounce that my email cant be delivered, please stop! I dont want to know! :) I give it 1 year max. Regards, Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
If your ISP allows you to have mail servers behind theirs and they are the front line MX and forward everything to you, then your ISP is really odd. This is not odd at all. Now, for *real* ISPs (like, say Comcast, who provide both connectivity *and* service), most also will not be the MX for *your* domain, unless you set up the domain with them and tell them what e-mail addresses should be accepted for delivery. Even so, most still won't then pass that on to your server...they assume you are an individual or a group of individuals who don't know how to set up a server...that's why they offer the service. Basically, there are 2 ways to deal with domain e-mail: 1. receive it yourself on a server you control 2. contract out the receiving in some way The companies that offer #2 also offer ways for you to retrieve the e- mail with your MUA software, so they don't *want* to deal with passing it on to an MTA. This is not true. Im not sure how many 'most' ISPs you are talking about, but I know quite a few ISPs that accept all email for a domain and forward to a customer. This is most prevalent in dialup/isdn situations where you basically 'store and forward' all email for customers that are mostly offline. When they come online that triggers a queuerun towards the customer. You dont want that customer to have lower MX records because that would be unfair to senders who most of the time try in vain. You perhaps confuse ISP with US ISP? So, again, I think it's pretty odd for an ISP to be *the* MX for your domain but then just pass it along to your server. And again, you are wrong :) Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records
Let's say that I work for a hypothetical ACME Widgets, Inc. My e-mail address is [EMAIL PROTECTED] A potential customer, [EMAIL PROTECTED], tries to send me an e-mail message from his laptop using a public access point in his hotel. The network he's on is not listed as an allowed relay for example.com, according to their SPF record. My administrator (at acmewidgets.com) is honoring SPF records. What happens? That's just it - if your sales guy is at hotel with his laptop, he could use AUTH/STARTTLS and actually relay through his company's mail server. Thus the email from [EMAIL PROTECTED] would be delivered by mail.acmewidgets.com to where it needed to go... SPF would be valid. This no bounce at the destination. You try and tell that to thousands of customers. Who had their laptops set up in 1997 by a company that has long gone bankrupt. And will sue you if suddenly their email isnt working anymore :) Welcome to the world of ISPs :) I assume you mean that you're an ISP and that you've acquired customers from a now-defunct ISP and that they need to be able to send email as if it came from your domain (say big-isp.com) using whatever server was setup on their laptop by their previous ISP. No. I mean to say that customers are a weird bunch, with weird setups, that have always worked, and if we make it not work, we have some explaining to do. Not impossible, but not trivial either. Some people seem to think that because something is easy for them, it must be easy for everyone. We have for instance thousands of customers that have moved to a different ISP for access (for instance because we didnt offer DSL in their area so they got cable), but decided to keep services with us because they have email/homepage/whatever, or they just like us so much. Often they send out email themselves, or through their cable ISP, with our email address. They _should_ be using our servers with SSL/authentication but if you can say one thing about customers it's that they never do what you wish they'd do. Making customers, in the thousands of tens of thousands, change their configuration is not an easy task. And we do actually have cases where we changed something, it broke a customers config, they sued us because they couldnt change the source of their software because they only had the binaries and the company that had the source had long gone bankrupt. They're the exceptions, but again.. customers do weird stuff :) Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records
Let's say that the SPF record for futuresource.com says that the allowed relay is mail.futuresource.com. This means that mail coming from mail.futuresource.com (as the relay) is legitimate and that all other mail is likely to be forged. Now, why would mail.futuresource.com allow someone to spoof the envelope sender from its own domain? For example, my mail server has been configured to check all envelope sender addresses which are from local domains. Therefore, I can't send a message with an envelope sender of [EMAIL PROTECTED] If SPF was widely adopted, these two measures would effectively stop forgery of all wiktel.com addresses. Do you also check [EMAIL PROTECTED] What about people sending email themselves but receiving through your MX? What about people that have access through another company with one of your domains but they arent using your mailserver with authentication? What about receiving email from [EMAIL PROTECTED] from a mailserver that isnt listed as being from AOL, to a valid customer of yours? Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
How about scaling? I'm pretty sure my ISP will run (screaming, no doubt), from a scenario in which they rely on their customers to keep their list of valid addresses current. If your ISP allows you to have mail servers behind theirs and they are the front line MX and forward everything to you, then your ISP is really odd. This is not odd at all. Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records
Let's say that I work for a hypothetical ACME Widgets, Inc. My e-mail address is [EMAIL PROTECTED] A potential customer, [EMAIL PROTECTED], tries to send me an e-mail message from his laptop using a public access point in his hotel. The network he's on is not listed as an allowed relay for example.com, according to their SPF record. My administrator (at acmewidgets.com) is honoring SPF records. What happens? That's just it - if your sales guy is at hotel with his laptop, he could use AUTH/STARTTLS and actually relay through his company's mail server. Thus the email from [EMAIL PROTECTED] would be delivered by mail.acmewidgets.com to where it needed to go... SPF would be valid. This no bounce at the destination. You try and tell that to thousands of customers. Who had their laptops set up in 1997 by a company that has long gone bankrupt. And will sue you if suddenly their email isnt working anymore :) Welcome to the world of ISPs :) Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records
Seems to be the deadline date I keep hearing because that's when Microsoft will start checking SPF. Microsoft to enforce Sender ID checks http://www.infoworld.com/article/04/07/22/HNmicrosoftid_1.html http://www.DNSreport.com now gives a warning if your domain doesn't have SPF. I wonder what microsoft will do with SPF exactly. I cant imagine they'll reject based on SPF. Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Re: MimeDefang vs clamav
A trawl of the list archives would have provided you with the answer to this - see in particular http://lists.roaringpenguin.com/pipermail/mimedefang/2004-August/023645.html Actually, I did peruse the archives - for a ways back... Remember, my original said I was running SA 3.0pre2. For giggles, I verified that the newer code does not have the same exposure. Besides which, since I'm using the (Debian) supplied mimedefang-filter (which is the suggested windows version) - spamassassin is called *after* the virus scanners. Now, to me, it makes sense to do the spam check first - as I'd expect it to be the cheaper of the options... but I'd like to get what I've already got in working shape before I embark on the eternal quest to improve thing :) I would do the virus checks first. We have timing information in our mimedefang-filter. We use 2 virus scanners, which take 0.001 seconds a piece to finish (yes, around a thousandth of a second). We do about a dozen DNS blocklist tests, which take a total of 0.005 seconds on average. We do run local mirrors of all blocklists, but still. Then we run SA, which takes anywhere from 0.1 seconds to 1 second (once in a while even several seconds, which is usually a DNS timeout issue). Needless to say the impact of virus scanning and DNS blocklist lookups is virtually non-existant compared to SA. So we definately do SA last. Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Re: large mimedefang setup
Anyone know of any issues with clamd/freebsd 4.10 and faulty threading? Unlike 4.x, FreeBSD-5.x has real threads, and clamd is much more happy there. ... MFS mimedefang tmp directory. I'd suggest to avoid using MFS - the filesystem caching does pretty much the same or even a better job. MFS (md) in FreeBSD 5.x is still experimental (i.e. dangerous). Well, we're not running 5.x, were running 4.10. And ive been using MFS filesystems on very very veeery busy news servers with no problems. Ive done tests with seek speeds between disksetups (raid0/1/5) and MFS, and MFS was factors faster because you dont need to move spindles. Granted, mimedefang isnt seeking that much on it's tmp dir, so I think normal fs is probably fast enough, but im fairly sure it wont hurt. Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] large mimedefang setup
Hi all, we took a pretty large mimedefang setup in production today. We're scanning all outgoing customer email, about 3 million a day. In peak over 100 a second. We started out using 3 virus scanners but we quickly noticed clamd couldnt keep up. For some reason it was blocking all email if it was busy with scanning a virus. Seeing as it looks as if it uses a threaded model, it should be able to cope just fine. Our other 2 scanners were doing ok, with scantimes measured in 0,00X seconds. Anyone know of any issues with clamd/freebsd 4.10 and faulty threading? If anyone is interested, we're using 15 dual 3 ghz (hyperthreaded to 4) servers with 4GB memory each. MFS mimedefang tmp directory. The load on the servers is about 0.3, CPU around 90% idle. We use so many servers because we have a policy that 30% of the servers should be able to handle the load. Unfortunately it seems that means we need to add a few servers because at 5 servers the load goes up quite a bit. Anyone know of any performance figures we could compare against to see if we have some problem? The next phase will be even more interesting. That'll be for incoming email, which is quite a bit more. We already have 40 servers humming away for that :) That'll have user-configurable virus and spamfiltering. Fun fun, Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
