Re: [Mimedefang] X-Auto-Response-Suppress header
On Mon, 2012-05-21 at 12:22 -0700, kd6...@yahoo.com wrote: --- On Mon, 5/21/12, Bernd Petrovitsch be...@petrovitsch.priv.at wrote: On Don, 2012-05-17 at 16:02 -0700, kd6...@yahoo.com wrote: ... Beliefs like yours are the problem. Policies like mine cause the solution. Perhaps it is more annoying if you add these rules to SpamAssassin and score spam points for it. Definently not. A rejected message (returned to the sender) gets more action (or administrative notice) than one accepted as spam therefore unanswered. Maybe, but in commercial environments it depends if the sender needs more from the receiver (or has more force/power/) or vice versa to decide which of both opinions on the issues decide the following actions. And that can well be turn off the blocking. Please note that I didn't mention anything on what is correct and what is wrong, good or bad or ugly, standard-compliant or not, etc. because that does not matter in any way there - it is a religious matter for these people in believing in M$FT. No, I do not like it either but the majority of people obviously have no problem with it. Yes, I reply inline and delete full-quotes (if I happen to answer them). Yes, I mark all of these I'm, not in my office until mails as spam (especially if I get more than one inclusive-or they go over a mailing list) because that *is* spam as in unsolicited bulk email. Just plain rejecting mails simply kills the communication (as it kills the business relation) so that won't you get that far. Any better idea than being a PITA and flagging it as spam to get in the long run people to think about it? Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ 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] X-Auto-Response-Suppress header
On Don, 2012-05-17 at 16:02 -0700, kd6...@yahoo.com wrote: --- On Thu, 5/17/12, Kris Deugau kdeu...@vianet.ca wrote: ...All that said Your system, your policy. In that case, why have standards at all if the results from non-compliant software will be accepted anyway? Rejection of What misses here is the be liberal what you accept, ... sentence. But nowadays adhering to that implies lots of spam. non-standard data (including messages) should give sufficient motivation to fix broken software. The problem is that M$FT has to fix it and the the vast majority of users can't even belief (or do not want to think) that M$FT has bad tools/apps/ (if only that they are too lazy to get used to something else). And the pressure gets back Beliefs like yours are the problem. Policies like mine cause the solution. Perhaps it is more annoying if you add these rules to SpamAssassin and score spam points for it. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ 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] Remove existing tag from Subject:
On Mon, 2010-12-06 at 12:24 -0500, Jason Bertoch wrote: Does anyone have filter code they're willing to share that removes any existing *SPAM* tag in the Subject: header? I occasionally get customers that reply back-and-forth several times to a FP, leaving the tag in place each time, then finally report to me that the reply is a FP. In many cases, the cause of the FP has already been fixed so each reply is no longer considered spam, but the tag is still in place. Removing any - People shouldn't use the subject line for for (automatic) filtering but some headers fields. - The tag is usually at the beginning of the subject. So having Re: or similar in front should actually tell the user something. - And if people (and MUAs) would actually thread their mailboxes by default, it would be obvious (IMHO) that the tag is just copied from the first mail in the thread. Short answer: There is no clean technical solution to a (pure) human problem. The problems range from starting to remove too much too early (on real spams) up to changing completely different subjects who just happen to have the spam marker in it (OK, the risk might be quite low, but it's there). existing tag prior to processing with SA will reduce confusion on the recipient's end, and save me a fair amount of leg work on the FP report. I realize that Subject: tagging is outdated, but it's what my customers already have rules for in their mail clients. Changing this habit is in the works, but it's also a slow process. But the only real solution ... Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ 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] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible patch)
On Mit, 2010-02-03 at 12:32 -0800, - wrote: [...] Using the latter-above code, $2 is the IPv4, and if $1 is anything ACK, for real world use the ( must be annotated so that $1 always is the IPv4 address (or it's empty). other than ::, then the address was not machine generated and it's likely that the message was manually tampered with (and thus spam). Even if that´s the case, it shouldn't cause the software to fail or do the wrong thing[0]. Apart from my believe into inet_ntop(3)/inet_pton(3) (similar to the resident maintainer), I stumbled over too much buggy/broken software and future changes to rely on text in standards or this string always comes out from $FUNCTION which is per definition correct. Mainly because the last sentence really needs at least a now to be correct and God knows what´s put in next year. As for some real experiments: inet_pton(3) on my F-12 glibc-2.11.1 actually accepts both of :::1.2.3.4 and :::1234:5678 and inet_ntop(3) produces always the :::1.2.3.4 version. For normal/pure IPv6 addresses, inet_pton(3) also accepts both as long as the dotted quad is at the end and inet_ntop(3) produces always the pure IPv6 notation (is there a special name for it?). So just finding a . in the string doesn't qualify for the above IPv4 mapping. So the compromise version seems perfect (without looking at more source). Bernd [0]: Exploits are also made of this. -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ 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] [Patch] relay_is_* not ipv6 friendly (IPv4 Compatible patch)
On Mit, 2010-02-03 at 07:01 -0500, David F. Skoll wrote: Bernd Petrovitsch wrote: Perhaps reason enough to simply use Net::IP. What, from C? :) Oops, sorry, I had the impression it´s in the perl part. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ 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] [Patch] relay_is_* not ipv6 friendly
Hi! On Mon, 2010-02-01 at 21:26 +0100, Michiel Brandenburg wrote: [...] I recently noticed the relay_is_* functions within mimdefang.pl do not playing nice with ipv6 addresses. This patch fixes it. Not that a lot of mail is running ipv6 over here but there is always hope :) # taken from Net::IP, and converted to use no external, and handle no padding Hmm, any special reason for not using Net::IP directly? Or did I miss something? Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ 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] [Patch] relay_is_* not ipv6 friendly
On Die, 2010-02-02 at 13:09 +0100, Michiel Brandenburg wrote: On 2-2-2010 11:34, Bernd Petrovitsch wrote: # taken from Net::IP, and converted to use no external, and handle no padding Hmm, any special reason for not using Net::IP directly? Or did I miss something? That could be done without a problem but I did not want to bloat mimedefang.pl anymore than strictly needed. I have checked all modules that are used by default and none seem to need Net::IP so to add another dependency just to reverse some addresses was pointless. On a side note Net::IP is not installed per default (at least on my debian machines) so adding another package there .. . Well, I don't think that the default packages of some Linux distribution (even if it's Debian - which is not the whole world) should decide if one either copies the code (and bugs) or uses the lib/module. Apart from that RHEL5/CentOS-5 (and thus Fedora since F6) have it in the core repo (if I interpret the output from `rpm -qi perl-Net-IP` correctly. But I activate/use usually also the kbsingh, epel, rpmfusion and rpmforge repos - if only for CPAN modules). It would be good to use some more functions from Net::IP notably tests to see what is ipv6 / ipv4 cause all beat /:/ and /\./ :) That could be the other to use it in the core MD code too. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ 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] stream_by_recipient beginner
On Die, 2009-09-29 at 13:33 -0500, Cliff Hayes wrote:
Hello,
I am attempting to use stream_by_recipient.
I followed the instructions in the man page and added the following:
sub filter_begin {
if (stream_by_recipient()) {
return;
}
...
Now I get this in the maillog:
Sep 29 10:35:35 sadev mimedefang.pl[11193]: n8TFZZYj011357: filter_begin set
TerminateAndDiscard flag.
Sep 29 10:35:35 sadev mimedefang[11208]: n8TFZZYj011357: Discarding because
filter instructed us to
Sep 29 10:35:35 sadev mimedefang[11208]: n8TFZZYj011357: Filter time is
139ms
Sep 29 10:35:35 sadev sendmail[11357]: n8TFZZYj011357: Milter: data, discard
Sep 29 10:35:35 sadev sendmail[11357]: n8TFZZYj011357: discarded
If there's more to it than that, is there a walkthrough somewhere on the
Internet you could hook me up with to help me out?
No, that looks normal.
And that discarded mail should appear than multiple times each with
exactly one recipient.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
___
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] stream_by_recipient beginner
On Die, 2009-09-29 at 16:09 -0500, Cliff Hayes wrote: How does using stream_by_recipient compare with using filter_recipient? If there is more than 1 recipient, stream_by_recipient() plain simply resubmits that mail for each recipient separately (via `sendmail` - IIRC you can find that function in mimedefang,pl). And (usually) these mails go through the whole mail checking process again (as if the original sender sent them that way). And after that, the original mail is discarded (where all these log messages come from). [ Fullquote deleted ] Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ___ 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] Firewalls and Mimedefang
On Die, 2009-09-15 at 14:46 -0500, Cliff Hayes wrote: [...] Now I have to deal with the jerks. I started out running with no firewall The jerks are usually bots looking for some default installations. (not comfortable with that) and have the typical ssh probes. I didn't want The simple solution: - Block port 22 via /etc/hosts.deny and /etc/hosts.allow for all networks except the ones where you really come from - and/or make sshd listen on some other port (and use this other above for that) That's of course not the best solution. Better to figure out the really needed ports and just open them up (and only to the necessary networks). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ___ 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] Message header madness
On Fri, 2009-07-31 at 01:35 -0700, - wrote: [...] Usenet, there are people who use Reply-To specifying a mailbox under the reserved .invalid TLD and other values like example.com. If this is their only violation, their messages won't Are you really sure? It's usually the other way around: You put an invalid email address (or one from a spam trap) into the From: and the real (and read) one into the Reply-To:. The reason is that the From: addresses can be seen with the (quite cheap) list of all postings in a group, the Reply-To: only if you get the whole posting. Caveat emptor: Rules from the SMTP world may not apply to the NNTP world. be marked as spammy -- but I stand by my view that a positive value (toward spaminess) should still be assigned when it is identical to the From header value. Feel free to do it but I don't think it makes any sense to punish people for setting the default value into an optional field. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ___ 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
[Mimedefang] Freezing/hanging MIMEDefang 2.56
Does anyone else experience a freezing mimedefang-multiplexor parent process with up to 200 child processes? This happens on Linux Debian/Sarge if we try to stress-test the installation. Is there a known maximum number of child processes so that it works? /var/spool/MIMEDefang is on a tmpfs. EMB_PERL is enabled. We also use Spam-Assassin with bayes_auto_learn (with the default DBM backend) but disabled the occasitional --sync (and do it once in the night). But since the parent process just manges the children, this should IMHO not matter. There is not almost no swapping activity during the test (which is pretty short since the freeze occurs within a few minutes). The mimedefang-multiplexor process hangs in a futex(2) SysCall - so it seems to be some locking problem. AFAICS (reading mimedefang-multiplexor.c and friends) there is no explicit synchronization/locking in mimedefang-multiplexor which may use futex(2) below. But what I found was in activateSlave() around line 2313: snip sigemptyset(sigs); sigprocmask(SIG_BLOCK, sigs, NULL); snip Reading the manual pages and unless I'm missing something, this is basically a no-op. So either this should have been sigprocmask(SIG_SETMASK, ...) (and enables thus all signals) or the two lines can be deleted completely. Any hints or ideas where to look into? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ___ 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
