RE: [Mimedefang] How to verify that Network tests are workingforspamassassin
Sherifd30 [EMAIL PROTECTED] danced on the keyboard and produced: No, but I tried now with defang user, and DCC check worked ok for the sample-spam.txt file, but still it does not work for messages comming from sendmail, although I send the same file by email from an extrenal server. That doesn't mean that it'll catch it - keep in mind that most of the network tests will be impacted by the way you send the test mail to yourself. You need to inject it directly to your SMTP server, ie: sendmail [EMAIL PROTECTED] sample-spam.txt sendmail is running as smmsp, MIMEDefang as defang, clamd is runnig as root, spamassassin is installed as root but it is executable for all. You're running clamd as root? That's not good - run it as either defang or it's own user account. You should never run any program as root where there's an option not to. What if somebody finds a way to exploit it by sending a mail message through it? clamd checks messages fine, spamassassin check only local rules, not network rules like DCC and RBL for messages going through sendmail. ---SNIP--- I have this same problem on Linux and solaris! Which suggests a config problem. Ok, jog the memory please: Version of MIMEDefang? Version of Sendmail? Version of SpamAssassin? Version of Razor-agents? Version of DCC? Entire (non comment) contents of your spamassassin .cf file? Changes made to mimedefang-filter? You may want to place the last 2 on a web site, rather than mailing them to the list, if they're over a few dozen lines each. PLEASE - keep list traffic on the list. Email sent directly to me may be ignored utterly. -- Rob | What part of no was it you didn't understand? ___ 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
On Tue, 10 Aug 2004, Cor Bosman wrote: I mean, one of your customers (employees, whatever) sending email through your server using [EMAIL PROTECTED] (basically their own hotmail account). They can in the From: header, but in the envelope your MTA is to ensure that DSNs have a valid return address, hence, the envelope must be some local account. Sure, but if they are sending themselves (and have for years) and suddenly people are implementing SPF and we dont list their dynamic dialup host as a valid senderhost, their mail will be suddenly rejected. Yup. That's is what happening now already, because of DUL blacklists. Do you participate in some SourceForge projects? I do. And I painfully noticed that I cannot run those mails through my mail server at home. Yeah, they could/should use our mailserver, but im just trying to say implementing SPF has a _lot_ of side effects. Too much, for what I see currently. Plaintext, you need to use SSL. How do you 'make' them use authentication? Turn off non-authentificated access. You dont control if they decide to use the hotspot's email smarthost, or use software that does the delivery itself. If you publish SPF records, then their email will be rejected. Maybe not such a big deal in your case, but im sure we have thousands of customers emailing with our domain name from remote locations not using our mailservers. That is one problem of the current SPAM. Because legit mail may flow in non-signed and from any host. If anyone would use PGP or S/Mime, there would be no forged senders, if one would use a confirm-style certificate check-in mechanism (like when you join a mailing list that sends back a message to your mail account to verify that a) the address really exists and b) you are the particular person that initiated the join) -- at least not forged in the sense there is an existing mailbox, as one could allocate easily one at any freemail (web) hoster, Bye, -- Steffen Kaiser ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MUA for multiple senders
On Tue, 10 Aug 2004, [EMAIL PROTECTED] wrote: The other day someone asked about an MUA that would support sending from different addresses. Last night I was looking at my Mozilla Thunderbird setup where I have my primary home accoount, as well as my rarely used ISP If you mean me, that's true, you can have any (??) number of mailboxes in Mozilla (it would be cool to have roles there, instead to force you to setup different mailboxes for each From: address). My question was how I can have: - an user-specified From: address and - a valid local-server-based envelope address. I considered this was in the line with the distinction between MTA and MSA, but I haven't found any pointers in the sendmail README's or google. Bye, -- Steffen Kaiser ___ 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*
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] Question about Virus Scanners
On Wed, 11 Aug 2004, Kevin A. McGrail wrote: However, I haven't found much issues with Beagle/Bagle, etc. since I switched to using File::Archive that searches for bad_exts and blocks them. If the defs don't get them, the zip scanning has been. Instructions on how I installed McAfee: http://www.peregrinehw.com/downloads/MIMEDefang/INSTALL-MCAFEE Actually I'm surprised. I had installed the command line scanner, too, a while back, but it was slow. And it seemed to consume lots of resources in memory. I had ordered the scanners like so: first File::Scan(), then McAfee and McAfee _never_ found a virus! It did, when I reversed the processing order, so I'm certain the scanner and stuff were working. Do you catch virii with McAfee, that slipped through the other scanners? Bye, -- Steffen Kaiser ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MUA for multiple senders
[EMAIL PROTECTED] wrote on 08/12/2004 04:09:47 AM: If you mean me, Cuold be. I didn't have the original quesiton in my trash when I stumbled on the settings at home. (This is my work account) My question was how I can have: - an user-specified From: address and - a valid local-server-based envelope address. I considered this was in the line with the distinction between MTA and MSA, but I haven't found any pointers in the sendmail README's or google. You do need to set up the account for each From: address, and it's a roundabout way to specify what outbound server to use (if you need to use different servers for each account). But if there are a limited number of addresses you would send from, it could be an option. If many accounts would be needed, it would be very cumbersome. I suppose something could be scripted that creates a text file that could then be dumped on a mail server via port 25 that filled in the Mail from: and header from: information on the fly. ___ 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*
[EMAIL PROTECTED] wrote on 08/12/2004 04:20:31 AM: 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. ETRN requires the queueing MX to be able to resolve the requsting host. ETRN only tells the server that it should process and deliver any mail mail destined to the requesting server via a new connection. It does not simply reverse the direction of mail flow over the exisiting connection. TURN used to do that, but it was very insecure having no validation for who was asking for the email. You still need a lower preference MX, if only on an internal DNS zone, to deliver the mail after ETRN. 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. Yep, and it's a pain in the a$$ to replace the door on your house, but if it keeps the unwated (cold air,burglars) out, it might be worth the cost/effort. ___ 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*
At 06:27 PM 8/11/2004, Jeff Rife wrote: it is the responsibility of the MX machine to know what is and is not deliverable. 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: 1. Spammer targets the backup MX (us), assuming it's less protected. 2. We queue, reject, or discard the message. 3. Mail ends up at customer's primary mail server, which rejects *on different criteria*. 4. Customer's server issues an SMTP reject to our server. At this point, we technically *should* generate a bounce. The address we sent it on to was valid, but the message could not be delivered. We have no way of knowing, short of something SPF-like provided by the apparent sender's domain, whether the return address is valid, invalid, or valid-but-forged. On the other hand, if we *did* have that information, we could have blocked the mail without even queueing it up for the primary MX. Now if you run all your MXes yourself, you can make sure they all use the same criteria and only reject mail at the border. But that's a bit more difficult when one is in-house and the other belongs to your ISP, who may not even be running the same mail server software as you, never mind the same filtering software. And then there's the scenario in which the forged message makes it through to a valid address, someone reads it and fires off a complaint to the person they think sent it... Kelson Vibber SpeedGate Communications www.speed.net ___ 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*
Kelson Vibber wrote:
At 06:27 PM 8/11/2004, Jeff Rife wrote:
it is the responsibility of the MX machine to know what is and is
not deliverable.
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.
But accept-everything-and-send-manual-undeliverable-reports-later is becoming less and
less acceptable of a strategy.
[EMAIL PROTECTED] 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
perl -emap{y/a-z/l-za-k/;print}shift Jjhi pcdiwtg Ptga wprztg,
___
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*
[EMAIL PROTECTED] wrote on 08/12/2004 01:55:55 PM: But accept-everything-and-send-manual-undeliverable-reports-later is becoming less and less acceptable of a strategy. Hear! Hear!! I looked at a number of spam filters that did this before I came across MIMEDefang (and CanIT Pro which we use). One of the strongest points in my mind is the fact that it rejects the message during the SMTP conversation. We purchased CaniIT Pro for the ability to handle different filtering streams. ___ 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*
On Thu, 12 Aug 2004 [EMAIL PROTECTED] wrote: But accept-everything-and-send-manual-undeliverable-reports-later is becoming less and less acceptable of a strategy. I concur. I suspect ISPs will find it less and less attractive to offer backup MX services, and will either get out of that business or start charging (a lot) more. Regards, David. ___ 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*
I strongly agree with Matthew and David's statements about offering backup MX services. There is a lot of liability involved with offering that service, not to forget the enormous overhead. As an ISP we're always faced with this dilemma when offering mail routing services for clients that host their own MX/mail accounts, so in essence we still haven't escaped 100%, but certainly will never offer up any of our servers for backup MX purposes, just too risky. - Chris -- Chris Gauch Systems Administrator Digicon Communications, Inc. [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:mimedefang- [EMAIL PROTECTED] On Behalf Of David F. Skoll Sent: Thursday, August 12, 2004 2:38 PM To: [EMAIL PROTECTED] Subject: RE: [Mimedefang] Deadline for SPF records *long w/morbid horoscope* On Thu, 12 Aug 2004 [EMAIL PROTECTED] wrote: But accept-everything-and-send-manual-undeliverable-reports-later is becoming less and less acceptable of a strategy. I concur. I suspect ISPs will find it less and less attractive to offer backup MX services, and will either get out of that business or start charging (a lot) more. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ 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*
Kelson Vibber wrote:
Bad recipients are NOT the only problem!
I agree. Rejecting-bad-emails-at-the-gateway is a Good Idea (tm), but it doesn't
solve everything.
[EMAIL PROTECTED] 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
perl -emap{y/a-z/l-za-k/;print}shift Jjhi pcdiwtg Ptga wprztg,
___
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*
On 12 Aug 2004 at 10:20, Cor Bosman wrote: 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? The company I work for provides Internet services to clients. If you want to use your own mail server, you can, and e-mail goes directly to you through our link to the Internet (in other words, we provide connectivity only). If not, our server is MX and you give us the list of valid e-mail addresses and retrieve via POP (no IMAP because we don't want to be storing all their e-mail). You can have a server of your own to distribute e-mail, but you must get it off our server using client tools (like fetchmail or any MUA). The result is close to zero bogus e-mails hitting the postmaster account(s). 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. I'm not being abusive. More and more ISPs are heading towards things that reduce network abuse. One thing that does is having the full list of legal addresses on the answering MX. This is obviously more work for them in some ways, but the work it saves is worth the trouble to them and it has the nice side effect of reducing work for *other* Internet users. That's being quality or responsible in my book. And what do you think the command ETRN is for? It's an optional part of SMTP that doesn't have to be supported, and does have some security issues. 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. If they are almost never online, they are clients, not servers, so they need to be treated as such. Harsh, I know, but treating them as clients in other ways (forcing them to use your server through the MSP port instead of the MTA port, for example) goes a long way to combatting network abuse. This discussion started with implementing SPF, and for an ISP implementing SPF has a lot of problems. Not unsolvable, but it wont be pretty. On that, we agree. The biggest issue I see is the return-on-investment for making sure that everything is correct. In some cases, many just won't do things 100% because the goal (spam-reduction) doesn't seem to be something that SPF really will do. -- Jeff Rife| SPAM bait: | http://www.nabs.net/Cartoons/OverTheHedge/HDTV.gif [EMAIL PROTECTED] | [EMAIL PROTECTED] | ___ 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*
On 12 Aug 2004 at 10:14, Kelson Vibber wrote: 1. Spammer targets the backup MX (us), assuming it's less protected. 2. We queue, reject, or discard the message. 3. Mail ends up at customer's primary mail server, which rejects *on different criteria*. 4. Customer's server issues an SMTP reject to our server. At this point, we technically *should* generate a bounce. The address we sent it on to was valid, but the message could not be delivered. I admit that I used shorthand to describe the process of making sure that the MX has the list of valid addresses. I should expand on that to say that if the MX accepts it, then it is deliverable. My solution to this would be if I had to use different rejection criteria from the MX that gets the mail first, I would not bounce the message, but instead just eat it. That's not the best thing to do, but my contract with the Internet is that once an MX that answers for me accepts the mail, the Internet doesn't need to be bothered any more. On the other hand, if we *did* have that information, we could have blocked the mail without even queueing it up for the primary MX. Now if you run all your MXes yourself, you can make sure they all use the same criteria and only reject mail at the border. But that's a bit more difficult when one is in-house and the other belongs to your ISP We solve this merely by have a point of presence with enough ISPs (we have divisions or even just workers like me who use a different ISP) to allow us to run multiple MXs each with different connections to the backbone. And then there's the scenario in which the forged message makes it through to a valid address, someone reads it and fires off a complaint to the person they think sent it... That's something that only user education will fix, so I'm not counting on seeing it happen anytime soon. :) -- Jeff Rife| SPAM bait: | http://www.nabs.net/Cartoons/Dilbert/LostNetworkPassword.gif [EMAIL PROTECTED] | [EMAIL PROTECTED] | ___ 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*
On 12 Aug 2004 at 12:33, Kelson Vibber wrote: - Some of those criteria (such as spam filters) are hard to keep in sync across multiple implementations. Spam isn't really a big deal in the bounce area. For us, once it hits analysis (SpamAssassin through MIMEDefang), we never send anything back to the sending server. DNSBL, forged HELO and virues get REJECTed (no bounce e-mail), but SPAM is silently dropped (for high scores) or sent on to the user. I just don't feel that any spammer deals with bad addresses well enough to make rejection worth while, nor is there a reason to tell somebody that they sent me spam, since the scores we use make it obvious that they already know. -- Jeff Rife| SPAM bait: | http://www.nabs.net/Cartoons/UserFriendly/GeekCommunication.gif [EMAIL PROTECTED] | [EMAIL PROTECTED] | ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
