[Mimedefang] mimedefang compalins about suspicious char, but none present
I've just got an email that was rejected by MIMEDefang. It complained about suspicious chars. After examining copy of message in quarantine, it doesn't seem to contain anything suspicious. Only printable ASCII and tabs. Any other explanation for this? Sorry for not including the offending message (too much data useful for identity theft in it). Hope you understand. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Which is worse?
Dave Williss wrote: I think to myself... If I go out of my way to block spam, I'm probably NOT going to be inclined to buy anything from a spammer anyway. So why do they bother? Spam is usually blocked by sysadmins. They are attempting to bypass that and reach end users that might be inclined to click on the message. It's like those no soliciting signs on doors (on both private properties and bussinesses). From time to time you get uninvited salesman ignoring the sign, trying out his luck. Anyhow, it doesn't cost a thing, so why not try it. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] 0-byte attachments
Stewart wrote: So right now my panic subsides, just slightly, but i'd like to know why mimedefang might be passing on messages without their attachments and not warning the users inline, or me via syslog, that there's some sort of problem ... that wouldn't be an approved behaviour i'm sure! :-/ Depending on configured milter log level (can be controlled separately in sendmail config, by default same as general log level), you should see in sendmail's log files whenever message body was altered by a filter (in this case MIMEDefang). I think log level of 9 should log it (either general, or raised for milter only). ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] New Sober version bringing MD to its knees?
David F. Skoll wrote: Fernando Gleiser wrote: It worked flawlessly until the last version of sober hit it a couple of days ago. Since then that piece of cr*p is hitting it with bursts where the server gets 60+ mails in less than 10seconds, so MD runs out of slaves. You might want to set the ConnectionRateThrottle parameter in Sendmail (confCONNECTION_RATE_THROTTLE in sendmail.mc) quite low, like to around 3. That delays connections if more than 3/second come in. For 40+ mail accounts? Set it to 1. Way more than enough. He probably receives at most several emails per minute (if that much). Also. Set number of slaves to something hardware can handle. Worst case is, some email will get delayed when he gets hit. Usually, not really a big deal. Make sure virus scanner runs first (ClamAV is usually light weight enough not to kill machine), and that no filtering is done if virus is detected (like it is done in default MD configuration). No point in running SpamAssassin on something that is going to be rejected anyhow... ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Semi-OT: ClamAV Vulnerability
Kenneth Porter wrote: Additionally the Fedora wiki has a page for registered system uid's, and defang is defined there. Hm, search on the Fedora Wiki hasn't found the page. Could you post the link to it? ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Bare returns in message body
Quoting Steffen Kaiser [EMAIL PROTECTED]: On Thu, 17 Nov 2005, Aleksandar Milivojevic wrote: If any of $SuspisiousCharsIn* are true, I'm doing (as one of the first things in filter_begin, even before checking for viruses): action_quarantine_entire_message('descriptive msg'); return action_bounce('descriptive msg'); I did so for some time, too, but had to disable it, because some (important) people are subscribed to some CVS-has-changed notification lists, which send embedded CRs and NULs. The sender was complaining, that I'm the only person who thinks the mails are bad. Sounds familiar. People are too often completely ignorant. They don't care that simple upgrade of any component of email system (from email client to SMTP server to IMAP/POP3 server) can couse problems again (crashing the email clients or simply causing delivery problems again). The only thing they care about is to delegate problem to somebody else. If your organization decides to swtich to Cyrus IMAPD (for example) in the future, his emails are going to start bouncing again. Luckily, this time, you would be able to tell I can't do anything about it, it is erorr in client's software that generated those emails, and it can only be fixed in that software. This message was sent using IMP, the Internet Messaging Program. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Skip checks for localhost
Jon Fullmer wrote: Here's probably a rookie question. How can I configure Mimedefang to skip checks for messages originating from localhost? At a higher level, I have a script that runs on the mail server and generates e-mail messages to some of my users. MD keeps rejecting the message due to suspicious_chars. I can't seem to figure out what characters it has a problem with, so I'm at the point where I want it to just skip checking the message all together and just SEND the message. Suggestions? Fix the buggy program that generated the messages? ;-) For real, why don't you try to quarantine the message before rejecting it. Then you'll have a copy of the message on the disk that you can look into and see what is wrong. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Bare returns in message body
Quoting Tomasz Ostrowski [EMAIL PROTECTED]: So I'd propose something like: /* after message_contains_virus() */ if ($SuspiciousCharsInBody) { action_rebuild(); } If any of $SuspisiousCharsIn* are true, I'm doing (as one of the first things in filter_begin, even before checking for viruses): action_quarantine_entire_message('descriptive msg'); return action_bounce('descriptive msg'); I have this setup for very long time, and so far zero complaints from users. Even if there were complaints, this is part of anti-virus and anti-spam policy, so I couldn't do anything about it ;-) Looking at the log files, more than 99% of bounced stuff are viruses and spam, and remainder is mainly chain letters and similar stuff that nobody really cares if it gets bounced. I've just checked this week's log files. Almost all bounced messages (due to suspisious chars in either body or headers) were from senders like [EMAIL PROTECTED] (guess what those are). Only two were from something that looked like it might have been real email address. Checking the quarantine showed those two were viruses. There was only one email adress in log files that was constantly bounced because of this (in the beggining, when we started using MIMEDefang), but it seems whoever owned it have fixed his/hers email setup very fast after emails started to bounce. So bouncing isn't as bad as it may sound, it helps people to fix problems ;-) This message was sent using IMP, the Internet Messaging Program. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] how to disable notify=success
Quoting Mark [EMAIL PROTECTED]: One of our bigger customers are rejecting all messages from , Then you need to wax their ears some, and set them straight a bit. Do not accommodate to their gross brokenness. It might be that they are simply rejecting return receipts as such. However, if they are rejecting them, they should be making sure no requests for them are leaving their organization. See the second part of my previous reply. Although, if email originated from outside of their organization (for example, user sends email from his laptop from home using his ISPs mail server and organization's email address), there is little they can do to prevent it. This message was sent using IMP, the Internet Messaging Program. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] how to disable notify=success
Quoting Marco Berizzi [EMAIL PROTECTED]: Hello. I'm using a sendmail/MIMEDefang box as a gateway for my M$ Exchange 5.5 internal mail server. One of our bigger customers are rejecting all messages from , so MDN and return receipt from my M$ exchange relayed through the sendmail/MD box are rejected. I would like to know if there is a way to disable NOTIFY=SUCCESS with MD. Return receipts can be reqested on two levels. On SMTP level and in headers. In former case they are handled by MTA, and in later by MUA. To block any disposition notification, also known as return receipts (these are not bounces): sub filter_end ($) { my ($entity) = @_; if ($entity-head-get(Content-Type) =~ m+multipart/report.*disposition-notification+igs) { return action_bounce(Disposition notifications prohibited); } } You can also prevent requests for them to hit your users. IMO, this is good things, since return receipts are very handy way for spammers to verify that an email address exists. To disable them on SMTP level, simply tell sendmail you want to disable the feature. Add noreceipts to confPRIVACY_FLAGS in sendmail.mc and reubuild sendmail.cf from it. For example: define(`confPRIVACY_FLAGS', `goaway,restrictqrun,noreceipts,noetrn') To disable them in the headers, you can siply remove offending headers from the message (you'd do this in filter_end function). The headers you want to ruthlessly remove are: Disposition-Notification-To Disposition-Notification-Options Return-Receipt-To X-Confirm-Reading-To For example, add this to the above filter_end function: my @hremove = (Disposition-Notification-To, Disposition-Notification-Options, Return-Receipt-To, X-Confirm-Reading-To); foreach my $h (@hremove) { if ($entity-head-get($h)) { action_delete_all_headers($h); } } This message was sent using IMP, the Internet Messaging Program. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] how to disable notify=success
Quoting Kevin A. McGrail [EMAIL PROTECTED]: I have to concur but I'll give you more ammunition. This is pretty broken and large ISPs like AOL and Yahoo may block mail servers that do not accept bounces. For example, from: http://postmaster.aol.com/guidelines/standards.html AOL may reject connections from senders who are unable to accept at least 90% of the bounce-return messages (mailer-daemon failure/error messages) destined for their systems. Which in turn is also broken. To make a DOS attack (prevent AOL subscribers to send email to particular domain), one would just generate bunch of emails to non-existing AOL addresses that would have envelope sender set to non-existing user at particular domain. Attacker generates fake emails, AOL generates bounces, bounces fail, AOL blocks domain. Nice. This message was sent using IMP, the Internet Messaging Program. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Bare returns in message body
Quoting Jan Pieter Cornet [EMAIL PROTECTED]: Patching sendmail to reject on bare LF terminated lines is likely asking for a LOT of trouble. Since traditionally sendmail doesn't care if you used CRLF or just LF, it's likely that lots of (local, unix- specific) programs submit messages using only LF line endings. Some programs might even implicitly rely on the fact that sendmail corrects the line endings. You are right there. Sendmail is one of the be liberal what you accept, be strict what you send projects. Unfortunately in this case, it is not strict enough in what it is sending... Kinda getting of topic for this mailing list... This message was sent using IMP, the Internet Messaging Program. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] initializing database connection
Hi, I need to connect to SQLite database from some functions in mimedefang-filter. Not sure if I got the docs right. What I currently have is something like this. The semaphores stuff is just to serialize transactions (SQLite pukes when more than one process is accessing same file). I'm also using semaphores in other functions, so only one slave at a time can access database. use IPC::SysV qw(IPC_CREAT IPC_EXCL SEM_UNDO); use DBI; sub filter_initialize { $semid = 0; if ($semid = semget($semkey, 1, 0600 | IPC_CREAT | IPC_EXCL)) { # we are creating the semaphore, set the green light semop($semid, pack(s!3, 0, 1, 0)); } else { # assume semaphore was already created and in use $semid = semget(0x12345678, 1, 0600) || die $!; } # red light semop($semid, pack(s!3, 0, -1, SEM_UNDO)); if (-f $dbfile) { $dbh = DBI-connect(dbi:SQLite:dbname=$dbfile,,); } else { $dbh = DBI-connect(dbi:SQLite:dbname=$dbfile,,); my $sth_create = $dbh-prepare($sql_create_table); $sth_create-execute(); } $dbh-{AutoCommit} = 0; $sth_insert = $dbh-prepare($sql_insert); $sth_update = $dbh-prepare($sql_update); $sth_select = $dbh-prepare($sql_select); $sth_delete = $dbh-prepare($sql_delete); # green light semop($semid, pack(s!3, 0, 1, SEM_UNDO)); } And than I'm using $dbh, $sth_insert, $sth_update and so on in other filter_* functions (again, using semaphores to serialize access to database). Is this the right way to do it? Even if this is the right way of doing it, if I got manual page right, each slave will have its own connection to the database. Since I needed to use semaphores to serialize things anyhow (AFAIK, limitation of SQLite), is it possible to (somehow) create one connection and share it among all the slaves? This message was sent using IMP, the Internet Messaging Program. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Bare returns in message body
Quoting David F. Skoll [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: How about --dont-fix-line-endings Then I have to use getopt_long and portability goes to hell. :-( Choose a letter for beta options, and do them like '-B fix-line-endings=off' (replace '-B' with whatever letter is free). Then you just need some short portable code to parse key-value pair. Or you could have a letter for long options '-o fix-line-endings=off'. This message was sent using IMP, the Internet Messaging Program. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Bare returns in message body
Quoting David F. Skoll [EMAIL PROTECTED]: David F. Skoll wrote: Sigh. When you send body chunks back to Sendmail, it converts CRLF to LF, because it's writing it to a queue file, which is stored with UNIX-convention line endings. Also, when Sendmail reads the queue file and sends it to MIMEDefang, it converts LF to CRLF. So: - There is no way to see a lone LF from milter. - There IS a way to see a lone CR. - There is no way to know if the CRLF you see in your milter was REALLY a CRLF on the wire, or just a LF on the wire. - When you send a body BACK to Sendmail, it makes no difference if you terminate lines with LF or CRLF. What a mess. In other words, it should be Sendmail that should be patched to reject bare CR and bare LF. Patch against Sendmail (as config option)? I know of at least one popular IMAP server, namely Cyrus IMAPD, that does such checks and rejects messages that contain bare newlines. Furthermore, it is not conditional (unless you hack Cyrus code, it is not possible to turn it off). So this is nothing new, and could be considered common practice at many sites (be them aware of it or not). IMO, MIMEDefang should at least set suspicios char flag when it encounters bare CR or LF (well, the later is probably not possible to detect on Unix systems). This message was sent using IMP, the Internet Messaging Program. ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How can I get just the domain from $sender
Seigafuse, Mike wrote: We use confidentiality statements as well, but we split in and outbound on different servers so we don't have this particular issue. The issue we haven't solved yet is how to avoid adding it every time replies go back and forth. If someone figures that out please share :). I have a friend who is unfortunate to work in a company that insist on this kind of stupidity for all employees (big insurance company). It seems that their mail server is configured not to add disclaimers if both of these are true: Subject header starts with re: (case insensitive) In-Reply-To header is present I'm not sure if they also keep some kind of database of message id's to check and see if this is reply to a message that already got disclaimer or not (don't remember really if hers first reply to my initial email gets the disclaimer or not). Implementing a database like that should be simple, if you want to be that fancy. Something like this should work for you too, if you have enforced company policy on allowed mail readers (and your company's mail reader of choice inserts in-reply-to header). If you have a user prepared to manually circumvent this in order not to have disclaimer added, you have a bigger problems to worry about anyhow. Glad to help reduce number of useless disclaimers ;-) -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] off topic: rfc-ignorant
May make couple of people here smile (at least). The rfc-ignorant seems to be ignorant themself. My log files are full of these: lame server resolving '4.3.2.1.ipwhois.rfc-ignorant.org'(in 'ipwhois.rfc-ignorant.ORG'?): 127.0.0.1#53 They are delegating ipwhois.rfc-ignorant.org to localhost (127.0.0.1). Wooohooo :-) (OK, I haven't checked RFCs, but delegating domain to localhost is simply plain wrong) -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Problem with virus bounces
Ronald Vazquez NLM wrote: The Problem seems to be that they're all bounces from nonexistant accounts/domains where the mailer there returns the WHOLE email as text inside the message. It seems that the risk is small that someone could actually execute the virus as it just appears as text-garbage in the text-part of the mail and local antivirus programs detect it... My manager is not liking this situation because I'm letting the virus in... I've seen several commercial AV scanners that have the same problem (Trend isn't the only one). The problem is that those bounces (usually generated by qmail or postfix, don't remember which one of those two) are not really MIME formatted emails. They are text/plain, so when analyzing them, virus scanners (or anything else) will not see and decode/scan attachment. A solution could be to try out ClamAV and add it as second virus scanner. It is free and it seems to be good at detecting (at least some) viruses that are hidden in broken bounced messages. Anyhow, having mail scanned by two different virus scanners is always a good idea. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] message/partial
Carlton Thomas wrote: We advise our clients to send multi-part messages to overcome the 10 meg limit we impose on a single message. We understand that this can allow viruses to slip through our defences, but we had to impose a limit and we had to find some way of allowing messages larger than that limit to be sent. Huh. Yeah, the problem sounds familiar. Long time ago, users would upload 100kb file on FTP server and send email where the file is. Today, users would click attach icon and select 1GB file without thinking twice. It's like going to Rona or Home Depot web site, buying everything you need to build new house online (from concrete for foundations to roof shingles), and selecting FedEx or UPS as shipping method. They'll do the job, but they are far from optimal. Just as the E-mail servers and clients will do the job of transferring 1GB file, but they are far from optimal solution for transferring the file of such size. One possible solution to handle viruses in these types of messages is to create a mimedefang filter which recognises the first part of a multipart message and impose a minimum size limit on that part. This is consistent with the assumption that most messages which contain viruses tend to be small. Mimedefang currently allows the admin to make that assumption and to only scan messages below a certain size. Would this be a suitable compromise, and is it possible to implement it using in a mimedefang filter? If you are willing to live with the risks, yes it is possible. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Rejecting mail during SMTP transmission?
Dan Ferreira wrote: Hi all, I was wondering if this has been considered or done before: an SMTP server configured to receive email data, perform the required checks on it, and NOT send an OK reply to the DATA command if the email is to be rejected. This is exactly what action_bounce() does. So this behaviour would be somewhat against RFC guidelines, but I'd like you to consider what I think are major benefits to this kind of preemptive rejection. No. RFC says that you should either accept or reject. It only says you can't partially reject (which is impossible to do on SMTP level anyhow). When you reject, you can reject temporary (telling other side you currently have some problems, so it should retry) or permanently (telling other side it isn't going to happen). -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ 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: Lycos Screen saver that attacks Spammers, Ah more off topic...
Ian Mitchell wrote: Honestly though, what can legislation do to prevent spamming? Ohio passed a nice little bill that provides prison time if you spam someone in Ohio. Oh hell, I guess this email can be considered Spam since it's off topic, and there's likely someone who lives in Ohio reading this now... Well, I guess I'll just have to live with the warrant. Virginia has anti-spam laws too. And there have been some long-time sentences already: http://www.computerweekly.com/articles/article.asp?liArticleID=134815liArticleTypeID=1liCategoryID=2liChannelID=28liFlavourID=1sSearch=nPage=1 I don't know about Ohio, but in Virginia the address needs to be forged, so you are on the safe side of the law at least in Virginia ;-) Honestly, I don't see Ohio having the ability to extradite someone from Bangladesh because they sent someone an email that the recipient didn't ask for. Can you see the state department for China now? You wanna what? ummm... No. Me neither. But at least extradiction works inside US (between states), which is better than nothing. Also, braking laws remotely isn't something to take easilly. As soon as you leave your contry of origin, you must be carefull where you go. Your government might not be willing to extradite you (and many countries have laws that prevent extradiction of its own citizens, US included). But a foreign one couldn't care less. Vacation in that nice tropical paradise? Maybe not, too risky, they have extradiction agreement ;-) -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] message/partial
Rolf wrote: what is the security risk with message/partial? Sending 7 emails each with a picture attachment doesn't seem to me to be an issue per se, so I presume that their mail client might have split it up. Any clients known to do this? Workarounds? If the email is JPEG image, as in your case, there's no harm. However, if the email contains virus, and it is sent as message/partial, it can't be detected by virus scanners. Theoreticall, each mail could contain only one byte of the actuall virus code. There's no way for virus scanners to scan such an email. Most commercial anti-virus tools will block message/partial by default also. None that I know of will attempt to reassemble the email. There are handfull of mail clients that support the feature. One of them is MS Outlook Express. In preferences you can set that messages exceeding certain size should be split up. In that case, Outlook Express will generate message/partial. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] removing mimedefang
dr john halewood wrote: On Friday 26 Nov 2004 11:59, Andrew Jayes wrote: I tried to put # Disable ClamAV $Features{'Virus:CLAMAV'} = 0; Should I have put it somewhere else or wrapped it up in brackets? It's a global variable so I'd suggest putting it at the very top of your mimedefang-filter script. That way it should propogate to all functions (failing that, if you're feeling really hackish, you could edit it in mimedefang.pl, but there shouldn't be any need for this and it will disappear whenever you upgrade mimedefang). Virus scanning is explicitly called from mimedefang-filter. If you do not ask for it, it will not be performed. Usual place where it is invoked is filter_begin (if you want to scan entire email once, and than make accpet/reject decision). Some people call it from filter and filter_multipart instead (if you want to scan each part separately, and than only remove infected parts instead of blocking entire email). So basically, commenting or deleting parts of mimedefang-filter where you are checking for viruses should prevent any virus scanning from taking place, regardless of values assigned to global variables. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] spamtrap on secondary MX
-ray wrote: I read an article in SysAdmin that talked about setting up a spamtrap on a secondary or tertiary MX box. The box would look like a good MTA, answers helo and 'mail from', but on 'rcpt to' always returns 451 Try again later. The idea being spammers prefer secondary MX's, but will never try again. A legit host that happens to connect will of course try again later (hopefully to primary MX). The author claims this reduced spam intake by 10%. Anyone done anything similar? Any thoughts? Seems like a simple way to catch a lot of spam... 10% doesn't sound like lot of spam. Dedicating entire machine just for this seems more like waste of resources. Plus you risk some brainded MTA always reattempting connection to secondary MX, and thus never delivering otherwise legitimate email. Refinement of the above idea is gray listing. You keep database of sender/recipient pairs and tempfail them for 5 minutes (or you simply accept second retrasmission, whenever it happens). Than you start accepting them. If remote side hasn't attempted retransmission in five days, you remove the entry from database after it is 5 days old (that is for how long the remote side will usually keep retrying anyhow). If remote side did (accepted) retransmission, you keep entry in database for some period of time (couple of hours, up to one day) after last successfull mail exchange between sender and recipient (this will ensure that if two persons are exchaning several emails during short period of time, only the first email will be delayed). Of course, you would bypass gray-listing for outgoing mail (no point in delaying your local site's email). Unlike previous idea, this can be implemented on all MXs. I'm not particualry fond of gray-listing either. The amount of spam it blocks isn't worth the delay in legitimate email exchange between two individuals. Your spam problems don't need to be identical to mine, so it might work better for you. There are cuople of filters floating around that implement gray-listing. Theoretically, it should be possible to implement it directly in mimedefang-filter, but don't know anybody that did that. Basically what you would do is create filter_recipient function, and place some code that creates and maintains database (Berkely DB files, for example). You'd keep in there sender/recipient pair, and timestampt with flag telling if timestamp is time of initial (tempfailed) transmission or if timestamp is time of last accepted email exchange. Depending on this you either accept or tempfail. From filter_sender you can check for too old entries, and purge them (filter_recipient is called once for each recipient, so it might be more efficient to purge entries in filter_sender or fiter_end that are called once per email). Gray listing can be implemented using remote side's IP address instead of sender/recipient pair, or by using only sender's email address (probably not as efficient). Implementing it using IPs isn't good idea. Remote side might have farm of mail servers operating on shared mail queue (I'm not aware of any such existing configuration, but that doesn't mean it does not exist somewhere out there), so theoretically each retransmission attempt might come from different IP address. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] timeout before data read / smfi_chgheader returned MI_FAILURE
Jurgen Botz wrote: Sorry, I should have mentioned that I saw that discussion, but my problem seems to be different. I didn't see the same symptoms of the defang process being restarted quickly, for example, and there definitely seems to be a connection to this error: Nov 22 09:33:54 kahuna mimedefang[5656]: iAMHXhdD005903: smfi_addheader returned MI_FAILURE You will get that error if sendmail gave up on MIMEDefang (milter timeout for example), and MIMEDefang attempted to add the header. Also, do note that MIMEDefang process doesn't need to restart quickly. How quickly it will restart dependes on the MTA configuration of connecting (remote) end. It has nothing to do with you. If remote MTA has retry interval set to something low (1, 5 or 10 minutes), your MIMEDefang will restart quickly. If remote MTA has retry interval set to one hour or even longer, than your old MIMEDefang process will probably finish long before the other side tries to retransmit, and you will not see MIMEDefang processes accumulating (as was discussed in previous thread). However the couse of the problem is probably still the same: timeouts set too low so MIMEDefang can't finish processing large emails. Either set longer timeouts (in both MIMEDefang and Sendmail), or lower the maximum size of email you accept, or both. Also, make sure that you are not feeding emails larger than ~100kB to SpamAssassin. SpamAssassin takes forever to process them, and it is very unlikely that spam will be that big. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] using action_add_part on msgs to be quarantined
Rolf wrote: hello Try as I might I cannot add the spamassassin report to the mail msg prior to it being quarantined. [snip] # If you find the SA report useful, add it, I guess... action_add_part($entity, text/plain, -suggest, $report\n, SpamAssassinReport.txt, inline,0); action_quarantine_entire_message(); action_discard(); This one-liner should do the trick: # Quarantine mail and save report action_quarantine_entire_message($report); # Second line of one-liner ;-) return action_bounce(Smile, be happy, don't send spam); You will find the report in file MSG.0 (unless you had some other action_quarantine_* with message included, each goes in its own MSG.n file). Side-effect: When/if you send quarantine notifications later on, they will contain the report. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] timeout before data read / smfi_chgheader returned MI_FAILURE
Jurgen Botz wrote: MIMEDefang suddenly stopped working on one of my servers this morning. I get the following errors... anyone have any idea what might be causing this? There was discussion about this last week. You probably set Milter timeouts in sendmail.mc (INPUT_MAIL_FILTER line) too low. You got large email, MIMEDefang wasn't able to process it in less than timeout time, sendmail rejected mail with tempfail (as you instructed it to do when it timeouts in the very same INPUT_MAIL_FILTER line). Try raising timeouts to at least 15 minutes. If you are accepting huge emails (definition of huge 10MB or larger), half an hour or even an hour (if you don't have any limits on the size of emails you accept) might be good idea too. More than one hour doesn't make any sense (remote side will usually timeout after one hour of waiting for response from your sendmail). -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ 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: Virus getting by MD
Alan Lehman wrote: I'm also having problems with Exploit-MIME.gen.b getting through. I just upgraded to MD 2.48 with clamav-0.80 and uvscan 4.32 but the problem continues. Have you upgraded MIME-Tools? Do you still have old version of MIME-Tools hanging around (make sure MD is not using it)? -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MD 2.48 , SA 3.0001 CHARSET_FARAWAY_HEADERS
alan premselaar wrote: I've only got the sa-mimedefang.cf file in /etc/mail/spamassassin and i double-checked the debug information from spamassassin -D to confirm that it was using the same config file. Starting with MD 2.46 (or 2.47?) location of sa-mimedefang.cf was moved from /etc/mail/spamassassin to /etc/mail. Try moving the file, or making symbolic link, and see if that is going to make any difference. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Sendmail MIMEDEFANG and SA
[EMAIL PROTECTED] wrote: Hi all, I'm having trouble making SPAMASSASSIN work with MIMEDEFANG. Installed everything correctly. Configured sa-mimedefang.cf. But : I don't have any logs in maillog. SA and MIMEDEFANG don't seem to work. Do I have to specify something in sendmail for it to work with MIMEDEFANG ?. Yes. You need to add INPUT_MAIL_FILTER to your sendmail.mc and rebuild sendmail.cf from it. See INSTALL/README files that came with MIMEDefang for example how that line should look like. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Custom Configuration
Yang Xiao wrote: Hi all, I'm using amavisd-new and Maia as the web interface so that users can easily manage their w/b lists and spam/virus/attachment settings. However, I would still like to use MIMEDefang for 1. Envelope/header checking in filter_recipient() : reject anyone claims to be sending from the internal domain. 2. LDAP lookup on RCPT TO: verify valid mailbox before accepting data. but not anything else, because I want amavisd-new to handle spam and virus checking, is this possible? and how should I go about it? Simply. Install both Amavisd-new and MIMEDefang, and define both in sendmail.mc. Sendmail will call them in order you put them in .mc file. Second filter will see changes made by the first filter. In your case, it seems it would be best to call MIMEDefang first, and amavisd-new second (no point doing expensive aniti-virus/spam if mail is going to be rejected earlier because of invalid envelop, plus you save some bandwith since message body is not transffered). In MIMEDefang, you would use filter_sender (to check sender's address), filter_recipient (to check if recipient is valid, do not drop entire email here, simply reject recipients that are invalid here, mail can have more than one, and some might be valid), and filter_end (to check headers). You'd probably need to install some LDAP perl modules. If you are going to have persistent connection to LDAP server, make sure it is made from filter_init. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] tmpfs on Linux
Greg Miller wrote: Currently not using bayesian or whitelist. This is a dedicated sendmail box. You can use bayesian and/or whitelist on dedicated sendmail box (no local users). There are two solutions. More complicated is to keep them in SQL database. That way you can have them on per-user basis. Simpler is to have them global for all users. For later (simpler) global solution, just add these lines to sa-mimedefang.cf: # Enable AWL use_auto_whitelist 1 auto_whitelist_path /var/spool/MIMEDefang/awl auto_whitelist_file_mode 0640 # Enable Bayes use_bayes1 use_bayes_rules 1 bayes_path /var/spool/MIMEDefang/bayes bayes_file_mode 0640 bayes_auto_learn 1 You'll probably need DB_File Perl module installed. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] tmpfs on Linux
Jeff Rife wrote: On 12 Nov 2004 at 9:03, Aleksandar Milivojevic wrote: For later (simpler) global solution, just add these lines to sa-mimedefang.cf: auto_whitelist_path /var/spool/MIMEDefang/awl bayes_path /var/spool/MIMEDefang/bayes These are really *bad* paths if you put /var/spool/MIMEDefang on any sort of ramdisk (like many of us do). In my defense, those were example paths (mine don't look like that either). I've put them as examples since MIMEDefang directory is owned by defang user, so it is one possiblity (if, as you said, one doesn't use ramdisk for that directory). If somebody does use ramdisk, he'll probably have enough of common sense to change them to some more permanent location. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Additional rules, Overseas IP, no reverse Lookup
Tory Blue wrote: Hey all, I'm wondering if there are exmples or clean methods to achieve the following, it would be nice to have MimeDefang have the option to add the following headers to allow clients to block based on more information vs just spam score, they may be able to block more, I do, with the following information. X-Header-Overseas: Mail.from.Overseas.source.211.246.165.209 X-Header-NoReverseIP: IP.name.lookup.failed[211.246.165.209] Ideas? You can add/change/delete whatever headers you want in filter_begin and/or filter_end. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIME Virus Issue?
Quoting Chris Masters [EMAIL PROTECTED] Date: Thu, 11 Nov 2004 06:21:16 Hi All, We've just had an incident where 2 or more viruses have got through our scanners. The virus was [EMAIL PROTECTED] and was packaged with the following Content-Type header: Content-Type: multipart/mixed; boundary= We're using mimedefang-2.43 and *old* MIME-tools-5.411a-RP-Patched-02. There was a bug in old versions of MIME-tools. If boundary was empty string (as in your case), mail was not parsed correctly. It was fixed in version 5.415. It might be good idea to upgrade MIMEDefang to current 2.48, since there were couple of small bugs fixed there too (although not as important as the bug in MIME-tools). -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: Timeout settings (was Re: [Mimedefang] tmpfs on Linux)
Quoting David F. Skoll [EMAIL PROTECTED] Date: Thu, 11 Nov 2004 17:06:13 On Thu, 11 Nov 2004, Greg Miller wrote: During my investigations I noticed that many of my sendmail processes hang around for quite some time, presumably because the host on the other end is slow. I stumbled across a recommendation that the sendmail default timeouts be tuned as follows: Anyone else doing this? Some of those numbers are way too short. In particular, a confTO_DATAFINAL of 5 minutes is definitely too low. RFC 2821 says that one SHOULD be at least 10 minutes, and I would be conservative and make it 30 minutes. I'd leave that one at Sendmail's default one hour. Setting it too low may result in bandwith waste and multiple copies of email delivered. I've saw ClamAV + MIMEDefang taking some 10-15 minutes to complete when scanning emails with huge compressed attachments (on reasonably fast machine). If receiving side has some more milters, or is simply overloaded because it got several large emails to process at the same time, it could easilly take even longer. If somebody is going to DOS you, even timeout set to as short as one minute would be more than enough to allow for DOS attack. And you would need to be the one connecting to attacker's server (that's what this timeout controls). So really there's no point in lowering this. If you already transferred the email, give the other side as much time as it needs to do whatever it needs to do before accepting that email. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: Off-topic: Silly error messages (was RE: [Mimedefang] MIMEtype message/partial)
Dave Williss wrote: My favorite was on an old Data General workstation... Kernel Panic Would you like to take a system dump? These days it would probably be: Kernel Panic Would you like to supersize it? ;-) -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] milter to multiplex via TCP
David F. Skoll wrote: On Tue, 9 Nov 2004, Marco Supino wrote: How can i tell the mimedefang milter to access the multiplexor via TCP ? You can't. The multiplexor only uses UNIX-domain sockets and must be on the same machine as the milter. But he should still be able to run sendmail on one machine, and mimedefang milter and multiplexor on another machine? -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] From header information
Lavoie,Alain [CMC] wrote: Is it possible to access the From header like I can acces the Subject header with the variable $Subject in mimedefang-filter? $entity-head-get(From) will return whatever is in From header in filter, filter_multipart and filter_end. You can't use it in filter_begin (it is not defined there). Of course, you can use $entity-head-get() function to get value of any header. Note that you will need at least MIMEDefang 2.48 to use this (it was broken in previous versions). -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] New to Mimedefang
Lisa Casey wrote: Hi, I got Mimedefang working now. Question: what are these directories for in /var/spool/MIMEDefang and do I need all these? Seems like a new directory is created with each e-mail. At this rate, might this eventually cause disk space problems? Can I delete these? drwxr-x---2 defang defang 4096 Nov 3 16:36 mdefang-iA3La54E029919 [snip] mdefang-something (actually, something is sendmail queue ID) are temporary spool directories. Check how MIMEDefang is being called. It might be that it is called with -d option instructing it not to delete temporary spool files (which is usefull for debugging only, but you usually don't want it on production system, since it will quickly fill up file system). Another possiblity is if you killed MIMEDefang while it was still processing an email, directory might be left over. During normal MIMEDefang operation, you should see those directories created and than removed by MIMEDefang as it process email. If you MIMEDefang was not started with -d, and you still see those directories left over, something is not working right. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Frustration...
Lisa Casey wrote: and Spamassassin adds a SpamAssassinReport.txt as an attachment to each spam mail. But I've been reading websites for two days now and can't figure out how to do anything else with this. Basically I don't want spam coming into my users mailboxes, they don't want it. I understand there will be some amount of false positives, but I just want to drop (or bounce or whatever) the spam before it reaches the mailboxes. Actually, SpamAssassinReport.txt is added by MIMEDefang. If you want to drop spam, instead of flagging email as being spam, than you'll need to change your filter_end to look something like this: if ($Features{SpamAssassin}) { if (-s ./INPUTMSG 100*1024) { my($hits, $req, $names, $report) = spam_assassin_check(); if ($hits = $req) { return action_bounce(Suspected spam - blocked); } } } I'ld also like to drop, bounce, whatever mail that has certain words in the subject, such as rolex, penis, viagra, etc. Insert this in filter_begin: $badwords = (rolex|penis|viagra|etc); if ($Subject =~ m/$badwords/i) { return action_bounce(F-words detected - blocked); } Also, I'm not sure how I'm supposed to feed it spam. I have Sendmail/Qpopper and most of my users pick up their mail using Outlook Express. I understand I can't just forward spam to a spam mailbox and run sa-learn on that as the forwarding will not get the original headers. Not sure if I understood what you wanted here. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking spam senders using IPTables?
James Ebright wrote: I am not sure you understand how an SMTP conversaation takes place... it is my understanding that the client cannot ignore a 5xx response and continue blasting data... since the server will not talk to a client after sending a 5xx response and closes the connection. Thus after recieving a 5xx return code a client would have to start over, generating another 5xx... etc. Client can ignore 5xx response from Sendmail. For example, if you have 1.2.3.4 REJECT in access file, and client ignores 5xx, conversation would look something like: 220 foobar.com ESMTP Unauthorized access prohibited ehlo barfoo.com 250-foobar.com Hello barfoo.com [1.2.3.4], pleased to meet you 250 ENHANCEDSTATUSCODES MAIL FROM:[EMAIL PROTECTED] 550 5.7.1 Access denied RCPT TO:[EMAIL PROTECTED] 550 5.7.1 Access denied DATA 550 5.7.1 Access denied From: [EMAIL PROTECTED] 550 5.7.1 Access denied To: [EMAIL PROTECTED] 550 5.7.1 Access denied Subject: buy something 550 5.7.1 Access denied and so on, until spammer disconnects... Try it out. Sendmail will close network socket only when other side disconnects, sends QUIT, or in case of timeout. This is because we have only error built-in mailer in Sendmail. If we had disconnect built-in mailer, things would probably be a bit different. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: Forcing Sendmail to close connection (was Re: [Mimedefang] Blocking spam senders using IPTables?)
David F. Skoll wrote: On Wed, 3 Nov 2004, Aleksandar Milivojevic wrote: This is because we have only error built-in mailer in Sendmail. If we had disconnect built-in mailer, things would probably be a bit different. From reading the Sendmail source code, it looks like Sendmail 8.13.1 treats a 421 reply code from a milter magically, and shuts down the connection. See line 3376 of sendmail/milter.c and line 848 of sendmail/srvsmtp.c. I do not believe this feature exists in Sendmail 8.12.x. It looks like some rule sets can also force the connection to be terminated by returning 421. Not treating it magically. It treats it logically. ;-) 421 is used when server side of connection must close its end. For example, if you send SIGTERM to Sendmail (or any other MTA), it *must* attempt to asynchroniously send 421 to all connected clients before it exits, in the hope that client will pick it up when it tries to issue next command. Basically, it is a way to say client Something is killing me, I wan't be able to finish this transaction, try again later. Basically, after sending 421, there's no point in keeping the connection open anymore. I've attempted to put this into access file on 8.12.x, and also to send it from MIMEDefang, and Sendmail doesn't close the connection. So I guess it is something new in 8.13.x. Also 4xx codes are temp failures, instructing client to try again later... So there are some drawbacks in case of false positives. For starters. Legitimate senders will not be notified right away that teir mail hasn't made it (usually delay of around 5 days). If filter becomes trigger happy, bunch of sites will constantly retry to deliver bunch of emails to you (which is good and bad, you can quicly fix the filter before anything is permanently rejected)... I guess this works nicely with logic behind Can-It? -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] New to Mimedefang
Lisa Casey wrote: - Original Message - From: David F. Skoll [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 8:35 AM Subject: Re: [Mimedefang] New to Mimedefang On Wed, 3 Nov 2004, Lisa Casey wrote: su -c 'cp examples/init-script /etc/init.d/mimedefang' in examples, there was not a file called init-script. There is an init-script.in which is what I copied over. Well, that's your problem -- that won't work. When you ran ./configure, it should have created init-script from init-script.in. Did you run ./configure? -- David. Yes, but I reran ./configure (and read the instructions that came with MD) and now MIMEDefang starts up when I start Sendmail. Here's another problem (?) though: I added this to my sendmail.mc: INPUT_MAIL_FILTER(`mimedefang', `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, T=S:5m;R:5m') and regenerated sendmail.cf from sendmail.mc. But when I look at sendmail.cf, I don't see anything referring to MIMEDefang, or MAIL_FILTER at all. I'm wondering if this got into my sendmail.cf at all. How do I tell if MIMEDefang is working? Grep for 'mimedefang' (all lowercase). You should see a line starting with 'O' and a line starting with 'X'. You can tell that MIMEDefang is working if your machine start to feel slow ;-) Lines like the one bellow in Sendmail log files is good indication that it is running: Milter add: header: X-Scanned-By: MIMEDefang 2.xx on 1.2.3.4 Good idea when you are still building mimedefang-filter file is to have it log everything it does. My personal preference is using md_syslog() for this (not md_graphdefang_log()). -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
Brenden Conte wrote: 15 minutes seems extremely long... I'm curious, could you explain the rational for that time length? I admit, its longer than I've ever considered reasonable. It depends on how large messages you are accepting. If you set limit to say 1 or 10MB, than 15 minutes is way too much. If you set it to 100MB, and you happen to get 90MB ZIP archive, it might take long time for AV to scan it, plus MIMEDefang will also spend considerable time (and memory) to digest it. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
Button, Shawn wrote: For some reason mail is still being rejected when the filter times out...is there a way to allow the mail through instead of rejecting it if the filter times out? We removed the F=T flag in the mc but this didn't seem to help. It would at least buy us some time to hunt this down more. Hm, removing F=T from mc file, rebuilding cf and restarting sendmail should have helped. The only case where it wouldn't help is if client MUA (or connecting MTA) is too impatient and timeouts connection on its end too soon (default in Sendmail is to wait for response 1 hour after it sends lone dot to remote server). If it is limited to only mails from some sites, it might indicate somebody played with these timeouts in his configuration file. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
David F. Skoll wrote: If you hit MX_BUSY, then the mail will be tempfailed regardless of the F=T setting, because that's a policy decision made by mimedefang rather than by sendmail. I'll just add to this that it is rather trivial to check which part was failing. If mail is tempfailed by MIMEDefang, than sendmail will log only single line that it is tempfailing message: Milter: data, reject=retrun code) If mail is tempfailed by sendmail because MIMEDefang took too long, you'll see these three lines in sendmail logs: Milter (mimedefang): timeout before data read Milter (mimedefang): to error state data, reject=451 4.7.1 Please try again later If MIMEDefang took too long, and sendmail is accepting the mail (since F=T was ommited), you'll see first two lines, and than a line saying that mail was accepted. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] slaves
Button, Shawn wrote: This is a typical section of the log file that starts with the failure... Nov 2 10:42:03 oslo mimedefang-multiplexor[15811]: Killing busy slave 1 (pid 17209): Busy timeout Nov 2 10:42:03 oslo mimedefang[17903]: Error from multiplexor: ERR Filter timed out - check filter rules or system load Nov 2 10:42:03 oslo sendmail[17902]: iA2HfX9j017902: to=[EMAIL PROTECTED], delay=00:00:30, pri=32632, stat=Please try again later Looking at this, it seems it's MX_BUSY being set too low, just as David pointed out earlier. mimdefang-multiplexor killed the slave, and instructed Sendmail to tempfail the message. Sendmail should have logged another line just after it got 'MAIL FROM', (grep for iA2HfX9j017902 in logs). It will give you an idea for how long MIMEDefang was processing the email, before it gave up. If what David pointed out to you is correct, the time difference will match your current MX_BUSY seting (give or take couple of seconds). Try boosting MX_BUSY to 600 (10 minutes) or even 900 (15 minutes). BTW, don't let huge mails go through SpamAssassin. Anything larger than say 100k isn't likely to be spam, and it will take *really* long time and huge amount of memory for SpamAssassin to digest large emails. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SURBL lookups no longer happening after upgrade to 2.48
Martin Blapp wrote: Works still here with SpamAssassin 3.01 and Mimedefang 2.48 ... Nov 2 16:02:12 mx1 sm-mta[13819]: iA2F1oSl013819: Milter add: header: X-Spam-Status: Yes, hits=49.893 required=5 scantime=13.5556 seconds tests=BAYES_99,DOMAIN_RATIO,HTML_90_100, HTML_FONT_BIG,HTML_IMAGE_ONLY_08,HTML_MESSAGE,\n\tHTML_TITLE_EMPTY,MIME_HTML_ONLY, MSGID_SPAM_CAPS,RBL_COMBO_A_2,RBL_COMBO_B_2,RBL_COMBO_C_2,RBL_COMBO_F_3, RCVD_HELO_IP_MISMATCH,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_SORBS_WEB, RCVD_IN_SWINOG_SPAM,RCVD_IN_XBL,RCVD_NUMERIC_HELO,URIBL_OB_SURBL,URIBL_SBL,URIBL_WS_SURBL Not directly related to discussion. I guess that header was added by MIMEDefang? How do you fetch original SpamAssassin headers into MIMEDefang? I'd rather have SpamAssassin style headers appended (X-Spam-Status, X-Spam-Report, and so on) than X-Spam-Score from example mimedefang-filter. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] auto white lists and lock files
I'm starting to see more and more lines in my log files about failures to create lock file for auto white list database that MIMEDefang uses. Basically, they look something like this: Nov 1 10:49:57 foobar mimedefang-multiplexor[27632]: Slave 0 stderr: unlock: 27632 failed to create lock tmpfile /var/spool/MIMEDefang/mimedefang-autowhitelist.lock.foobar.27632 at /path/to/SpamAssassin/Locker/UnixNFSSafe.pm line 144. Nov 1 10:52:24 foobar mimedefang-multiplexor[27632]: Slave 2 stderr: lock: 27632 unlink of temp lock /var/spool/MIMEDefang/mimedefang-autowhitelist.lock.foobar.27632 failed: No such file or directory As soon as I'm starting to see them, MIMEDefang more or less gets stuck, and Sendmail starts rejecting mails with 451 please try again later. The non-standard stuff I have in config files is: MX_EMBED_PERL yes MX_REQUESTS 10 MX_IDLE 15 In sa-mimedefang.ca: auto_whitelist_path/var/spool/MIMEDefang/mimedefang-autowhitelist And in mimedefang-filter enabled standard initialization stuff for auto white lists as distributed in stock mimedefang-filter. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding virus scanning after MIMEDefang installation
Mark Osbourne wrote: From what I can tell, it looks like I probably need to update /usr/bin/mimedefang.pl and change $Features{'Virus:CLAMD'} so that it is set to 1 and make sure that the clamd processes is running as the defang user and writing it's socket in /var/spool/MIMEDefang/clamd.sock. I'm not sure if you are going to need to reinstall MIMEDefang. However, documentation for MIMEDefang is proposing some not needed changes for it to interoperate with ClamAV. I don't know why. All clamd needs is read access to the file that it is supposed to scan. That can be done by adding user clamav (that clamd is running under) to group defang (/var/spool/MIMEDefang is owned and readable by group defang, if not than make it that way). Also you don't need to change ClamAV socket. Actually, you can't because /var/spool/MIMEDefang will not be writtable for clamd. You can leave it at its default value (/var/run/clamav/clamd.sock) and use $ClamdSock variable in mimedefang-filter to point MIMEDefang to the right place. That way you will achieve: - two daemon processes (MIMEDefang and ClamAV) will be separated, which is nice from security point of view - you run ClamAV in more or less default mode, which makes it easier to maintain - makes it possible to use clamd from other appliactions (/var/spool/MIMEDefang is not world accessible, /var/run/clamav is world accessible) IMHO, this is better and much cleaner configuration than the one proposed by MIMEDefang documentation. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Killing slaves after max number of requests is processed
While I was running MIMEDefang 2.46, I've noticed in logs that if max requests per slave is set to 500, that slaves do not exit normally, and must be killed with SIGTERM ten seconds later. This was happening every time slave gets to 500 requests and is instructed to exit. After I decreased it to 100 (and upgraded to 2.47), all seems to work normal. Mimedefang-multiplexor doesn't need to send SIGTERM to the slave anymore. I don't see anything in changelog mentioning this, so I guess what helped was lowering max requests to 100. 10 seconds for the slave to exit seems reasonable, so I haven't attempted to experiment with that. Anybody else seeing this? -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Easy way to scan for List-Id's
Ben Kamen wrote: Since I'm on a couple of lists and wish they'd put [list] in the subject line (and don't) is there an easy way to do this via MimeDefang? (this way, every place I look at my mail doesn't have to have duplicate mail filter setups.. it would just be done on the server..) Most of the lists use the header List-Id: Funny thing is, I'd wish none of the lists put [list] in Subject. I'm sorting lists in separate IMAP folders on the server, so it is kind of reduntant and just wastes the space on the Subject line ;-) Anyhow, if you are using IMAP, it might be easier to just use procmail or sieve (depending on IMAP server you use) to sort mailing lists into separate folders. That way, from wherever you look your mail, you get same view of it, and you manage filtering at single spot (the mail server itself). If you still want to add tags to Subject, you can do it in MIMEDefang. You can change Subject line in filter_end. Use $entity-head-get(List-Id) to check for headers, and if found rewrite Subject line to contain appropriate tag. You might want to remove tag from emails that you send out in other not to pollute mailing lists that I'm subscribe to ;-). And you'll need to handle 'Re: ' and similar prefixes, and make sure you don't add tag if it is already there. BTW, wanted to send to you directly instead of mailing list (original reply didn't had MIMEDefang part), but you completely blocked off my ISP (GT). Actually, after that guy from US who blocked entire .ca domain because of spam, you are the first one who bounced my mail back, eh ;-) -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] MIMEDefang + SpamAssassin AWL
I just wanted to check if what I did was correct. To get AWL working, I first attempted to only uncomment couple of lines in mimedefang-filter as instructed in comments: # If you want to use auto-whitelisting: if (defined($SASpamTester)) { use Mail::SpamAssassin::DBBasedAddrList; my $awl = Mail::SpamAssassin::DBBasedAddrList-new(); $SASpamTester-set_persistent_address_list_factory($awl) if defined($awl); } Hower, it didn't work, so I added these to sa-mimedefang.cf auto_whitelist_path/var/spool/MIMEDefang/mimedefang-awl auto_whitelist_file_mode 0640 After that, things started to work (or at least it looks like that). Question is, is this correct way to do it? -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.46-BETA-2 is available
David F. Skoll wrote: Hi, MIMEDefang 2.46-BETA-2 is available at http://www.mimedefang.org/node.php?id=1 This release addresses the problems identified by Aleksandar Milivojevic. It greatly improves the sanity of the message-rebuilding algorithm. Also, I've changed it so the append_boilerplate functions refuse to monkey with S/MIME signed or encrypted parts. I've just compiled and tested it. Seems to work nicely. The only (rather minor thing) is that if there's no content-type header in the message, $entity-head-get() will return multipart/mixed (plus internally generated boundary), while $sa_stat-get() (where $sa_stat is of type Mail::SpamAssasin::PerMsgStatus from my workaround) will correctly return undef. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.46-BETA-2 is available
David F. Skoll wrote: Rats... you shouldn't be seeing those. Are your slaves printing anything else to STDERR? Only MD-MX-STATUS messages, as the one I reported. Sometimes they are broken over several lines, sometimes they look like interpolated from several slaves. Another thing I noticed is that (sometimes, not every time) if I run md-mx-ctrl busyslaves, I'm getting this message logged (from multiplexor): reply_to_mimedefang: EventTcp_WriteBuf failed: Interrupted system call And no output from md-mx-ctrl. If I get output from md-mx-ctrl, there's no error logged. I'd say probability of getting response from slaves vs getting that error message logged is somewhere around fifty-fifty. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Detecting content-type of message in filter_end
Aleksandar Milivojevic wrote: I wanted to extend my mimedefang-filter to block disposition notifications (return receipts). In short, what I attempted to do in filter_end was the following: if (lc($entity-head-get(content-type)) =~ m+multipart/report.*disposition-notification+) { md_graphdefang_log('disposition-notification'); return action_bounce(Disposition notifications not allowed); } [snip] I've found workaround that can be used after SpamAssassin check (spam_assassin_check()) is done: $sa_status = spam_assassin_status(); $ct = $sa_status-get(content-type); $dn = $sa_status-get(disposition-notification-to); ... and so on ... will fetch correct header info (for all headers). Using SpamAssassin just to fetch header values would be an overkill, but if SpamAssassin is used anyhow, above will work. Hopefully, the bug in MIMEDefang will be completely resolved soon, so that $entity can be used for this... -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIME::Tools 5.415 is available
David F. Skoll wrote: Hi, MIME-tools 5.415 is available at http://www.mimedefang.org/node.php?id=1 Please note that thet patch I posted earlier does **NOT** completely fix the problem with boundary=. Version 5.415 does contain a complete fix, and I recommend that everyone upgrade. Anybody attempted upgrade on RedHat 7.3 (perl-5.6.1-34.99.6, gcc-2.96-110)? New MIME-tools requires MIME::Base64 = 3.03. However when I try to compile MIME::Base64 3.03, it fails when running tests: t/bad-sv..skipped all skipped: Perl::API needed for this test t/base64..ok t/quoted-printok t/unicode.ok t/warnFAILED test 1 Failed 1/1 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/warn.t 11 100.00% 1 1 test skipped. Failed 1/5 test scripts, 80.00% okay. 1/339 subtests failed, 99.71% okay. The old (patched) version of MIME-tools worked fine with MIME::Base64 2.xx (that comes standard with RedHat 7.3). -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Detecting content-type of message in filter_end
David F. Skoll wrote: There's a bug in MIMEDefang; the rebuilt entry that gets passed to filter_end is always of type multipart/mixed, multipart/alternative or multipart/digest. The next release will fix this. BTW, while we are at it. Is there a reason why $entity is not passed as an argument to filter_begin? It could be usefull if it was possible to do some checks on the message before it is modified by MIMEDefang. It would be more efficient if I don't need to wait until filter_end to do some simple checks. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Detecting content-type of message in filter_end
David F. Skoll wrote: There's a bug in MIMEDefang; the rebuilt entry that gets passed to filter_end is always of type multipart/mixed, multipart/alternative or multipart/digest. The next release will fix this. I see there's MIMEDefang 2.45 on the web site (I was still using 2.44). I guess the release that fixes this bug will be 2.46? -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Detecting content-type of message in filter_end
I wanted to extend my mimedefang-filter to block disposition notifications (return receipts). In short, what I attempted to do in filter_end was the following: if (lc($entity-head-get(content-type)) =~ m+multipart/report.*disposition-notification+) { md_graphdefang_log('disposition-notification'); return action_bounce(Disposition notifications not allowed); } But, for some reason it hasn't worked. To find out what's going on, I've added call to md_syslog: md_syslog(notice, Content type is . lc($entity-head-get(content-type))); What I get logged in the syslog is: Oct 25 14:13:49 somehost mimedefang.pl[14322]: Content type is multipart/mixed; boundary=mdn020605010008050205010504 None of the parts of the test message were of the type multipart/mixed. Test message was actual return receipt generated by Mozilla Thunderbird. It containted these top-level headers: MIME-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary=mdn020605010008050205010504 As you can see, boundary is the same as logged by md_syslog, however content-type itself was wrongly reported. There's nothing in mimedefang-filter that would change top-level content-type of the message, and when I examine the message after it was delivered to my mailbox, it contains correct headers. Is this known issue with MIMEDefang? Documentation says that $entity argument of filter_end will contain original message (unless modified by previous filter* funcitions). MIMEDefang version 2.44, MIME-tools version 5.411a-RP-Patched-02. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang