Re: [Mimedefang] How to change envelope sender?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.05.2013 00:47, schrieb Richard Laager: How are you getting on the Spamcop block list? It has been some time since I last had a problem with Spamcop and I don't remember what the reason for the listing was in that specific case. Generally the most frequent causes for blacklistings of our mailservers are: - - abuse by the previous owner of our IPv4 address range (Our current /24 range was assigned to us only three years ago, obviously too short for some RBL operators to notice.) - - misclassification of our IPv4 address range as dial-up - - false claims about missing or incorrect DNS or whois entries - - undisclosed reasons (We have evidence but we won't show it.) Any of these disqualifies a blacklist, of course, at least if there is no quick and easy way to get it corrected. Occasionally we also get blacklisted because a user account was bruteforced and abused for spamming. That's easily corrected, and respectable blacklists quickly delist afterwards, so it's more of a nuisance than a problem. But again, I haven't had a problem with Spamcop for some time so I currently don't recommend against using it. Are you doing any outbound filtering? No. German law doesn't allow that. Even inbound filtering is legally tricky. IANAL. I think that virus scanning is acceptable, but some lawyers even challenge that, claiming that the virus scanner gains knowledge of the mail content, thereby violating the constitutional right to privacy of correspondence. T. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGKL28ACgkQ780oymN0g8OG3ACfePbNVhv20b/e5r4N9eMxb2u/ CV8AniUXZx1vPO84gQoVoSwYQ5JAmG5d =Kx+U -END PGP SIGNATURE- ___ 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] How to change envelope sender?
Am 06.05.2013 20:29, schrieb kd6...@yahoo.com: I agree that spaminess and source authentication are separate issues, but most recipients don't want forged messages either, spam or not. Most recipients do not expect or even want the mail system to try doing source authenticaton, much less to reject mail messages if it fails. Ym2c, T. signature.asc Description: OpenPGP digital signature ___ 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] How to change envelope sender?
Am 06.05.2013 09:13, schrieb Benoit Panizzon: Backscatter OTOH is a nuisance, which should be minimized of course, but cannot be completely avoided. Blacklisting because of backscatter would be a Bad Idea (TM) which I thankfully never encountered so far, but if someone did that it would certainly be their own fault if they blocked legitimate mail as a result. In my experience, misguided measures like that tend to get lifted very quickly if senders and (intended) recipients of blocked mails are informed in no unclear words who's responsible for the communication failure. Well, there are such blacklists I can tell you as a tech at an ISP. [...] We had even the case where one single email was sent over our infrastructure to a 'special' spamcop.net spamtrap causing immediate blacklisting of our main outbound server. And spamcop.net is widely used. There are all kinds of misguided blacklists. So far, the following procedure has served me well for these cases: 1. Try to contact the blacklist's operators and get the listing removed. If that fails: 2. Try to contact the administrator of the mailserver using the blacklist and ask him or her to stop using that blacklist on grounds that it lists servers (such as mine) without justification and refuses to remove such listings. If that fails: 3. Explain to the sender and recipient of the blocked mail exactly why it was blocked, who is responsible for it, and who refused to do something about it. Step 3 usually results in a complaint by someone paying for a service to the one providing that service, and thereby in a belated success of either step 1 or step 2. Specifically, I have convinced more than one mail server administrator to stop using Spamcop because it blocked legitimate mail to paying customers of theirs. As Spamcop itself insists: it's never the responsibility of the blacklist operators if a mail is blocked, but always the responsibility of the mailserver administrator who decided to use that blacklist. signature.asc Description: OpenPGP digital signature ___ 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] How to change envelope sender?
Am 03.05.2013 um 08:18 schrieb Benoit Panizzon benoit.paniz...@imp.ch: Well, what's worse? - Backscatter? (and getting your server in blacklists because of that). - Sender not knowing his email got not forwarded (but the one forwarding his address can check upon that). I do consider backscatter the more serious problem. I strongly disagree. Notifying the sender of delivery problems is an essential and nonnegotiable element of E-mail. IOW dropping a mail without notifying the server is Bad. Full stop. Backscatter OTOH is a nuisance, which should be minimized of course, but cannot be completely avoided. Blacklisting because of backscatter would be a Bad Idea (TM) which I thankfully never encountered so far, but if someone did that it would certainly be their own fault if they blocked legitimate mail as a result. In my experience, misguided measures like that tend to get lifted very quickly if senders and (intended) recipients of blocked mails are informed in no unclear words who's responsible for the communication failure. Jm2c Tilman ___ 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] md_check_against_smtp_server and md_graphdefang_log
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 25.03.2013 19:51, schrieb David F. Skoll: my ($retval, $code, $dsn, $text) = md_check_against_smtp_server($sender, $recip, localhost, 192.168.1.10); Why four result elements? The manpage says md_check_against_smtp_server returns only two. Thanks, Tilman -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFcZjAACgkQ780oymN0g8OVFQCg494i+BEcJO2XcOKru7vK+JmB /aQAniYKv5StPoNONnd2NSsLTOuGd1qu =L36K -END PGP SIGNATURE- ___ 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] md_check_against_smtp_server and md_graphdefang_log
Am 27.03.2013 01:43, schrieb James Curtis:
I made the modification to /etc/sysconfig/mimedefang (still not sure why this
is referred to as 'running with the -t option')
MX_RECIPIENT_CHECK=yes
That sysconfig setting tells the init script to start MIMEdefang
with the -t option. Running with the -t option is low-level
speak, running with MX_RECIPIENT_CHECK enabled would be the
corresponding high-level expression.
-Code
sub filter_recipient
{
my($recip, $sender, $ip, $host, $first, $helo, $rcpt_mailer, $rcpt_host,
$rcpt_addr) = @_;
return md_check_against_smtp_server($sender, $recip, localhost,
192.168.1.10);
}
Code-
I now get the following response before the data phase that rejects the user!
550 5.1.1 t...@testdomain.com... User unknown
-
Yea! It's working
Good.
I tried changing the code as suggested below:
--Code-
sub filter_recipient
{
my ($retval, $code, $dsn, $text) = md_check_against_smtp_server($sender,
$recip, localhost, 192.168.1.10);
# if ($retval eq Reject) {
# md_graphdefang_log('notauser', $recip, $sender);
# return action_discard
#}
#else{
# md_graphdefang_log('valid', $retval, $code);
# }
}
-Code--
I told you not to remove the first line
my($recip, $sender, ...) = @_;
Without that line, the $sender and $recip variables will not be set,
so your md_check_against_smtp_server call will try to check an empty
address.
I also told you to compare $retval to REJECT in all capitals in
your if statement because that's what md_check_against_smtp_server
will return. As it stands, the comparison will never be true so
the else branch will always be run.
And finally I told you to insert a return statement before the
closing brace. The code above will return an empty result, which
the caller doesn't expect.
Btw, return action_discard is not appropriate in filter_recipient
either. It should be something like return('REJECT', 'You lose!');.
Having tried with the remarked statement and having it fail, I remarked it
back to just ther ecommended line and it still fails all email address',
whether valid or not valid with this response:
501 5.5.4 Invalid Address
And quite rightly so. The empty address is indeed invalid as a
recipient. :-)
In sum, try something like this: (Sorry for the line wraps.)
-Code
sub filter_recipient
{
my($recip, $sender, $ip, $host, $first, $helo, $rcpt_mailer,
$rcpt_host, $rcpt_addr) = @_;
my($retval, $code, $dsn, $text) =
md_check_against_smtp_server($sender, $recip, localhost, 192.168.1.10);
if ($retval eq REJECT) {
md_graphdefang_log('notauser', $recip, $sender);
return ('REJECT', 'go away');
}
else {
md_graphdefang_log('valid', $retval, $code);
return ('CONTINUE', 'ok');
}
}
Code-
HTH
T.
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
signature.asc
Description: OpenPGP digital signature
___
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] md_check_against_smtp_server and md_graphdefang_log
Am 27.03.2013 15:59, schrieb Matt Garretson: # man mimedefang-filter [...] md_graphdefang_log($event, $v1, $v2) [...] Note that md_graphdefang_log should not be used in filter_relay, filter_sender or filter_recipient. The global variables it relies on are not valid in that context. [...] OMG *blush* Although I checked the manpage several times in the course of this thread I never noticed that paragraph. Well, you live and learn. Thanks, Matt, for pointing that out. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ 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] md_check_against_smtp_server and md_graphdefang_log
Am 26.03.2013 um 04:35 schrieb kd6...@yahoo.com: If it were to be limited to servers under one's control and enforced as such, the routine would have to obtain the recipient's MX-RRset internally and test all higher priority MTAs; thus it would not need the remote host address parameter. It would determine which host in the MX-RRset it is running on based on the macro variables passed in via the milter interface. That would exclude a lot of useful and legitimate applications. Hint: Not every mail server has an MX RR pointing to it. ___ 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] md_check_against_smtp_server and md_graphdefang_log
Am 26.03.2013 05:25, schrieb James Curtis: From what I have read of the documentation (man mimedefang-filter, Rejecting Unknown Users Early section), the md_check_against_smtp_server is meant to verify that the email address someone is sending to actually exists on the server they are trying to send to (through the filter server that is running mimedefang). To the best of my knowledge it doesn't check the sender to make sure that the sender exists on the domain that the sending email address. md_check_against_smtp_server is a generic function for testing whether a given mail server will accept a given mail address. If you pass it the recipient address and destination server, it will test that the destination server is prepared to accept mail for that recipient address. This is the intended use. But you can just as well pass it the sender address and sending server, and it will dutifully check whether the sending server would accept mail to the sender address, no matter how inadvisable such a test would be. FILTERING BY RECIPIENT You can define a function called filter_recipient in your filter. This lets you reject messages to certain recipients, rather than waiting until the whole message has been sent. Note that for this check to take place, you must use the -t flag with mimedefang. Can someone verify that modifying the /etc/rc.d/init.d/mimedefang script daemon $PROGDIR/$prog-multiplexor -p /var/spool/MIMEDefang/$prog-multiplexor.pid -t \ OR daemon $PROGDIR/$prog-multiplexor -t -p /var/spool/MIMEDefang/$prog-multiplexor.pid \ OR am I misunderstanding what it means to run it with the -t option. Normally you shouldn't need to modify the init script directly. Most versions read a configuration file where you can adjust common settings such as this. The location of that configuration file varies for operating systems (you don't seem to have mentioned yours yet) and, in the case of Linux, distributions. In my case (CentOS) the configuration file is /etc/sysconfig/mimedefang, containing, among others, these lines: # If yes, turn on the multiplexor recipient checking function MX_RECIPIENT_CHECK=yes HTH T. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ 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] md_check_against_smtp_server and md_graphdefang_log
Am 26.03.2013 11:23, schrieb James Curtis:
Now just one more thing. I want to md_graphdefang_log if it is an unknown
user. Here is what I have put together
based on the other entries in this post. I'm sure I'm missing something
because it doesn't work. Please advise for this
last piece of the puzzle. Obviously I wouldn't log all valid, its for
testing purposes, what am I missing?
--code
sub filter_recipient
{
my ($retval, $code, $dsn, $text) = md_check_against_smtp_server($sender,
$recip, localhost, 192.168.1.10);
# my($recip, $sender, $ip, $host, $first, $helo, $rcpt_mailer,
$rcpt_host, $rcpt_addr) = @_;
This line is needed and should be the very first line of the
subroutine. Don't comment it out, and don't insert anything
before it. Just change the return in the line below into
my ($retval, $code, $dsn, $text) = .
# return md_check_against_smtp_server($sender, $recip, mail.hml.com,
192.168.1.10);
if ($retval eq Reject) {
According to the manpage $retval will be REJECT, not Reject
in the reject case, so you should compare against the string
in all capitals.
md_graphdefang_log('notauser', $recip, $sender);
}else{
md_graphdefang_log('valid', $retval, $code);
}
Here you are missing a return statement to pass the result of
md_check_against_smtp_server to the caller of filter_recipient.
Ie. insert
return ($retval, $code);
before the closing brace.
}
--code---
HTH
T.
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
signature.asc
Description: OpenPGP digital signature
___
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] md_check_against_smtp_server and md_graphdefang_log
Am 25.03.2013 23:08, schrieb Kees Theunissen: On Mon, 25 Mar 2013, David F. Skoll wrote: my ($retval, $code, $dsn, $text) = md_check_against_smtp_server($sender, $recip, localhost, 192.168.1.10); Shouldn't that be: my ($retval, $text, $code, $dsn) = md_check_against_smtp_server($sender, $recip, localhost, 192.168.1.10); Why four variables? My man mimedefang-filter says: The return value is always a two-element array. If the RCPT TO: command succeeds, the return value is (CONTINUE, OK). If the RCPT fails with a permanent failure, the return value is (REJECT, $msg), where $msg is the message from the SMTP server. Any temporary failures, connec- tion errors, etc. result in a return value of (TEMPFAIL, $msg). -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ 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] md_check_against_smtp_server and md_graphdefang_log
Am Di, 26.03.2013, 19:33, kd6...@yahoo.com schrieb: On Tue, 3/26/13, Tilman Schmidt t.schm...@phoenixsoftware.de wrote: Am 26.03.2013 um 04:35 schrieb kd6...@yahoo.com: If it were to be limited to servers under one's control and enforced as such, the routine would have to obtain the recipient's MX-RRset internally and test all higher priority MTAs; thus it would not need the remote host address parameter. It would determine which host in the MX-RRset it is running on based on the macro variables passed in via the milter interface. That would exclude a lot of useful and legitimate applications. Hint: Not every mail server has an MX RR pointing to it. 1) I don't consider sender callbacks useful. Nor do I. That's not what I was talking about. 2) If this is to be used by secondary MXs to test the primary, there will be MX records present in the DNS for that domain/hostname label. Neither is this. 3) Forwarding services shouldn't be randomly probing the ultimate destinations. I agree. Such things should be done systematically, not randomly. :-) Alright, I'll spell it out for you. Here's the scenario: - You have a so-called groupware server on your internal network, let's say Microsoft Exchange or Lotus Notes. - Quite sensibly you do not want to expose the SMTP port of that server directly to the Internet. - So you put a *nix relay server in your DMZ which accepts mail from the outside and forwards it to your groupware server. - The internal server does not appear in the public DNS at all. - The relay server has a mailertable entry pointing to the groupware server. - The relay server runs MIMEdefang to do all sorts of checks on incoming mail before accepting responsibility for forwarding it. - One of these checks should be whether the recipient address actually exists. - The easiest and most reliable way for that is to ask the groupware server. - The easiest way for that is SMTP call-ahead aka md_check_against_smtp_server. Now I'm sure you'll find a nit to pick with that approach, but to me it's quite sensible and time proven, and it would not work if md_check_against_smtp_server insisted in checking only against servers with published MX RRs. ___ 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] md_check_against_smtp_server and md_graphdefang_log
Am 26.03.2013 19:53, schrieb kd6...@yahoo.com: Extended codes: 5.1.1 - No such destination mailbox. 5.1.3 - Bad destination mailbox syntax (should have been checked by the current relay MTA but wasn't) 5.1.4 - Destination mailbox ambiguous (matches multiple possibilities) 5.2.1 - Destination mailbox (valid but) disabled 5.2.2 - Destination mailbox full (also may be tempfailed) 5.2.3 - Message too big (if the SIZE parameter is used with MAIL FROM) 5.3.1 - Mail system full (usually disk storage full) 5.3.4 - Message too big (systemwide limit, as opposed to a per user limit) and these which have nothing to do with the recipient: 5.1.7 - Bad sending mailbox syntax 5.1.8 - Bad sending mailbox's system address 5.7.1 - Spam or other similar refusal (mailboxes otherwise valid) etc Only the first two indicate a no valid user, but all of these (and probably others) can occur during such a test. Can you 100% guarantee that these other error reasons will never occur between your primary and secondaries? I don't think so Welcome to real life, where there are no 100% guarantees, ever. In fact, there isn't even a 100% guarantee that a mailserver will return an extended code at all, let alone one that correspond to the actual reason for the rejection. signature.asc Description: OpenPGP digital signature ___ 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] md_check_against_smtp_server and md_graphdefang_log
Am 26.03.2013 23:24, schrieb kd6...@yahoo.com: --- On Tue, 3/26/13, t...@phoenixsoftware.de t...@phoenixsoftware.de wrote: ... - The easiest way for that is SMTP call-ahead aka md_check_against_smtp_server. A much better way is to access the user database directly. That's what LDAP is for, but it can be done with other database types too. Sure, in a perfect world that would be the way to go. Unfortunately, real life tends to get into the way of such theoretically better solutions. You did notice my mentioning of the 'M' and 'N' words, I trust? (Microsoft and Notes, that is.) With properly set up LDAP servers, one may even choose to make a subset of the information available to sending servers so they can check before even attempting to connect to yours. I'll try to remember your advice should I ever come across a properly set up LDAP server. Several MTA programs (e.g. sendmail) have had LDAP query ability built in for more than a decade. Ever tried to make that work against a Microsoft Exchange or Lotus Notes server? I did, and ruefully returned to SMTP call-ahead. Technically within SMTP, the proper way for a secondary to check with a primary for valid users would not be by faking a mail transaction but by using the VRFY or EXPN commands Technically, yes. But again, reality gets in the way of technically proper solutions and forces you to make do with actually working ones instead. signature.asc Description: OpenPGP digital signature ___ 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] md_check_against_smtp_server and md_graphdefang_log
Am 24.03.2013 15:28, schrieb James Curtis:
md_graphdefang_log('spamhaus', $hits, $RelayAddr);
[...]
# the reject works, but graphdefang log shows the Subject instead of Relay
address
[...]
Mar 24 09:44:06 monitor mimedefang.pl[15805]:
MDLOG,r2ODhv3a027039,spamhaus,,31.16.181.217,c20195935f81d7e31...@reass.co.uk,sandseatra...@mydomain.com,Huge
83%25 discount for sandseatravel
You are reading this wrong. Quoting the manpage for mimedefang-filter:
md_graphdefang_log($event, $v1, $v2)
Logs an event with up to two optional additional parameters.
The log message has a specific format useful for graphing
tools; the message looks like this:
MDLOG,msgid,event,v1,v2,sender,recipient,subj
So your log entry contains:
- the fixed string MDLOG,
-- just as promised by the manpage
- msgid = r2ODhv3a027039,
-- a plausible message ID
- event = spamhaus,
-- as you specified
- v1 = empty,
-- unsurprisingly, as you passed $hits which is never set in your filter
- v2 = 31.16.181.217,
-- a plausible relay IP address
- sender = c20195935f81d7e31...@reass.co.uk,
- recipient = sandseatra...@mydomain.com,
- subj = Huge 83%25 discount for sandseatravel
-- all quite plausible
To me that looks like everything's working fine.
I guess I need a mimedefang-filter and Perl for dummies book.
Is there a place I can find such a document?
I seem to remember a book Perl for Dummies actually exists.
The best approximation to mimedefang-filter for Dummies is
probably this mailinglist. :-)
How do I know what outputs a command will produce when called so I can base
an if rule against it?
The mimedefang-filter manpage would be the canonical source for that.
I just now realized that the unknown user reports are because I had to enable
the recipient filter on the internal server, so that explains why the bounces
are going out.
Yes, that makes more sense.
But I really want it to check before sending so it doesn't accept, instead of
bounce.
Sure, that's the way it can and should be done. Bounces are to
be avoided whenever possible.
I'm doing something similar on a mail server serving several
domains, some local and some relayed. My filter_recipient just
contains, for each relayed domain:
if ($recipient =~ /[@.]relayeddoma\.in?$/i) {
return md_check_against_smtp_server($sender, $recipient, $helo,
'mail.relayeddoma.in');
}
ie. it just passes on the result of md_check_against_smtp_server
without even looking at it. This works for me because (a)
md_check_against_smtp_server's return value is designed to be a
valid return value for filter_recipient, and (b) I don't need to
do any further checks or actions on relayed mails in
filter_recipient after md_check_against_smtp_server.
If do you need to do more in filter_recipient after
md_check_against_smtp_server has returned OK you'll have
to assign its result to a variable and check it with
appropriate if statements. But I'd recommend against that.
SpamAssassin and virus checking belong in filter_end, and
additional logging doesn't add anything useful IMHO.
So if you relay *all* mails to internal private address,
your filter_recipient could in fact be as simple as:
sub filter_recipient
{
my($recip, $sender, $ip, $host, $first, $helo, $rcpt_mailer,
$rcpt_host, $rcpt_addr) = @_;
return md_check_against_smtp_server($sender, $recip,
filter serverexternal DNS name, internal private address);
}
HTH
T.
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
signature.asc
Description: OpenPGP digital signature
___
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] Slightly OT: SpamAssassin freemail check data
Am 25.03.2013 04:42, schrieb Ben Kamen: Where does the freemail filters for SA get it's list of email addy's? I'm looking at the FreeMail.pm -- and I'm not perl coherent enough to have it jump out at me. I'm just wondering if it's downloaded and/or also comes from a locally scanned db (through sa learn).. The way I understand it, it does neither of the two. You have to specify them all yourself in the config file as described in the initial comment of FreeMail.pm: ### Supported .cf clauses: # # freemail_domains domain ... # #List of domains to be used in checks. # HTH T. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ 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] md_check_against_smtp_server and md_graphdefang_log
Am 25.03.2013 20:54, schrieb James Curtis:
your filter_recipient could in fact be as simple as:
sub filter_recipient
{
my($recip, $sender, $ip, $host, $first, $helo, $rcpt_mailer,
$rcpt_host, $rcpt_addr) = @_;
return md_check_against_smtp_server($sender, $recip,
filter serverexternal DNS name, internal private address);
}
OK, so I tried this simple strip of code, just to get it to reject unknown
users without logging. It still doesn't seem to be working.
That doesn't match what I am observing. With my very similar
setup I get log entries for all rejections. So whatever it is
that rejects unknown users in your setup, I'm pretty sure it
isn't that filter_recipient function.
What exactly do you mean by reject unknown users without
logging, anyway? What happens when a server attempts to
deliver a mail message for an unknown user? What response
does the sending server get? What does your server log?
Nothing at all? That would be very odd. In my experience,
Sendmail always logs at least the connection attempt.
Please show an actual log excerpt.
Should it be in a separate section of the code, it's own section of code. I
have tried adding it to filter_begin, filter_end, and as it's own section of
code directly after the } after all of the filter_begin.
filter_recipient is a filter function of its own. It should
not be stuffed inside one of the other filter functions.
One other thing I forgot: MIMEdefang must actually be told
that you want it to run a filter_recipient function, by
starting it with the -t option. If you don't give that option
it'll just ignore any filter_recipient function you might
have in your filter script. Bit me more than once, that one.
Could location be part of the equation that I'm missing?
Well, of course where you place code makes all the difference.
In programming, where you place a piece of code determines
when it is run.
If you are unsure how all of this hangs together, perhaps it
would be best to post your mimedefang-filter script in its
entirety so knowledgeable people can have a look at it.
HTH
T.
signature.asc
Description: OpenPGP digital signature
___
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] md_check_against_smtp_server and md_graphdefang_log
Am 23.03.2013 05:49, schrieb kd6...@yahoo.com: --- On Fri, 3/22/13, James Curtis jameswcur...@hotmail.com wrote: I don't have any sendmail configuration that checks for bad users. If you're using the default provided rulesets, you do have a configuration that checks for bad users. Sendmail default rulesets only check for bad _local_ users. The OP was inquiring about SMTP call-ahead. Sendmail does not have a default ruleset for that. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ 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] md_check_against_smtp_server and md_graphdefang_log
Am 23.03.2013 01:43, schrieb James Curtis:
# yea, I know that the DNSBL is more effecient in sendmail, but I want to
know how many blocked for what user by blacklist.
if ($result = (relay_is_blacklisted($RelayAddr, zen.spamhaus.org))) {
md_graphdefang_log('spamhaus', $hits, $RelayAddr);
return action_bounce(reject: mail from ($RelayHostname ||
$RelayAddr) rejected due to http://www.spamhaus.org/zen;);
# the reject works, but graphdefang log shows the Subject instead of
Relay address
That's strange. Please show an example log entry.
sub filter_recipient
{
my($recip, $sender, $ip, $host, $first, $helo, $rcpt_mailer,
$rcpt_host, $rcpt_addr) = @_;
md_check_against_smtp_server($sender, $recip, filter
serverexternal DNS name, internal private address);
md_graphdefang_log('notuser', $recip, $sender);
# graphdefang log doesn't log entry as 'notuser', eventually logs it as
spam, or mail_in depending on score because of code that follows.
return action_discard();
}
This cannot work. You call md_check_against_smtp_server but never
check the result. md_graphdefang_log and action_discard are called
unconditionally. If this code was what your MIMEdefang actually
runs, all messages would be logged with 'notuser' and discarded.
So there must be something else wrong.
Perhaps your MIMEdefang is not using the filter script you think
it does. Perhaps filter_recipient is redefined later. Perhaps it's
a simple copy/paste error or your sanitizing.
HTH
T.
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
signature.asc
Description: OpenPGP digital signature
___
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] Email injection and the android 'email' app
Am 06.03.2013 05:37, schrieb Richard Laager: As a result of this thread, we discussed and tested this in-house (on just one phone). I believe we did get a notification that the message didn't send, so that's good. What I thought when I first read this thread. Users will ignore notifications and swear afterwards that there was none. System ate my mail after clicking away a pop-up window saying Unknown recipient. That aside, is Android behaving any differently than Thunderbird, or many other mail clients? Getting a 5xx status code from the outgoing mail server seems to pop up a dialog and then leave the message in the outbox on the ones we tested. Thunderbird leaves the message composition window open in that case, which is arguably a clearer sign that the message wasn't sent. This leads to inconsistent behavior between local and remote destinations. I don't think it's inconsistent. Processes can fail at different stages, and people are (or should be) used to that. Specifically, mail transmission can fail at different stages, and notifications will differ depending on that. The popup right after clicking Send is just one more variant. So if you want consistency, accepting all recipients for authenticated senders (and then later generating bounces) seems to be the only option. IMHO that would be a very bad solution, reducing the usability of the server for the majority of users because of the (forgive me) stupidity of a few. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ 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] Disable filter on smtp-auth
Am 27.01.2013 21:09, schrieb Wesley M.A:
I just enable saslauthd on this mail server.
But when clients send emails using our MTA, their message are filtered
and so they are like [SPAM]
Is there a way to disable this filter only for SMTP Auth ?
Sure. More than one, actually. My (rather simplistic) approach is this:
I simply amended the standard filter_end section
# Spam checks if SpamAssassin is installed
if ($Features{SpamAssassin}) {
if (-s ./INPUTMSG 100*1024) {
to
# Spam checks if SpamAssassin is installed
if ($Features{SpamAssassin}) {
if (defined($SendmailMacros{auth_type})) {
# Don't scan messages from authenticated senders.
md_graphdefang_log('auth');
}
elsif (-s ./INPUTMSG 100*1024) {
So messages are not SpamAssassin scanned if auth_type is defined,
which it is if the sender has authenticated through SMTP AUTH.
This has proved good enough for me.
HTH
Tilman
___
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] DNSWL
Dear all,
my mimedefang-filter script contains the following in its
filter_end function to run SpamAssassin on mails not originating
locally:
# Spam checks if SpamAssassin is installed
if ($Features{SpamAssassin}) {
if ($RelayAddr =~ /^10\.0\./) {
# Don't scan messages from local net
md_graphdefang_log('locl');
}
elsif (defined($SendmailMacros{auth_type})) {
# Don't scan messages from authenticated senders.
md_graphdefang_log('auth');
}
elsif (-s ./INPUTMSG 100*1024) {
# Only scan messages smaller than 100kB.
my($hits, $req, $names, $report) = spam_assassin_check();
if ($hits = $req) {
...yadda...
}
}
}
I would like to extend that so that the SpamAssassin call is
skipped for hosts which are ranked medium or high on the DNSWL,
as recommended on http://www.dnswl.org/tech. Alas, that page
does not offer a MIMEDefang recipe.
Google found a discussion on this list in December 2007 under
the subject dnswl and relay_is_blacklisted() in Mimedefang
sub_filter_relay that appears relevant, but I'm not sure how
to apply that to my case.
Could someone share a code snippet?
aTdHvAaNnKcSe,
Tilman
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
___
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] DNSWL
Am 30.10.2012 15:01, schrieb Steffen Kaiser:
something like this - untested
Thanks, but that doesn't quite work:
elsif(defined($dnswl = relay_is_blacklisted($RelayAddr,
'list.dnswl.org')) $dnswl =~ /\A127\.\0\.\d+\.[23]\z/) {
The pattern in the second term never seems to match.
If I remove it (thereby just checking for any DNSWL listing
no matter which rank), this ...
# Don't scan messages when whitelisted in DNSWL
md_graphdefang_log('dnswl ' . $dnswl);
prints things like
Oct 30 15:39:17 posthamster mimedefang.pl[9941]: q9UEdCWO010111:
MDLOG,q9UEdCWO010111,dnswl
%7F%00%05%00,,,alf...@s437660197.onlinehome.us,t.schm...@phoenixsoftware.de,=?iso-8859-1?Q?Kann_ich_einzahlen_10.000.000%2C00_WOHLT=C4TIGKEITSFONDS_=A3?=
=?iso-8859-1?Q?_in_Ihrem_Konto=3F?=
which (apart from being an example of obvious spam from a DNSWL
listed site :-) seems to show that relay_is_blacklisted(),
un-Perl-like, returns its result not as a string, but in some
sort of packed binary format. Any idea how to unpack that?
Thanks,
Tilman
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
___
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] DNSWL
Am 30.10.2012 15:59, schrieb David F. Skoll:
First of all, from the mimedefang-filter man page:
Note that the relay_is_blacklisted functions are deprecated
and may be removed in a future release. Instead, you should
use the module Net::DNSBL::Client from CPAN.
Thanks. Given that relay_is_blacklisted_multi appears to fall
under the deprectated verdict as well, and despite previous
bad experience with using CPAN on an RPM based Linux distribution,
I gave the Net::DNSBL::Client module a try. This is what I came up
with:
# Spam checks if SpamAssassin is installed
if ($Features{SpamAssassin}) {
if ($RelayAddr =~ /^10\.0\./) {
# Don't scan messages from local net
md_graphdefang_log('locl');
}
elsif (defined($SendmailMacros{auth_type})) {
# Don't scan messages from authenticated senders.
md_graphdefang_log('auth');
}
elsif (-s ./INPUTMSG 100*1024) {
# Only scan messages smaller than 100kB.
use Net::DNSBL::Client;
my $c = Net::DNSBL::Client-new({ timeout = 3 });
$c-query_ip($RelayAddr,
[ { domain = 'list.dnswl.org',
type = 'mask', data = '0.0.0.254' } ]);
my $answers = $c-get_answers();
if (@$answers) {
md_graphdefang_log('dnswl');
}
else {
my($hits, $req, $names, $report) = spam_assassin_check();
if ($hits = $req) {
...yadda...
}
}
}
}
Does that look about right? It seems to work fine so far, anyway.
Pity I couldn't avoid the extra level of braces, though.
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
___
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] DNSWL
Am 30.10.2012 19:26, schrieb kd6...@yahoo.com: It's your system, but I would consider exempting mail from local users from the scan as a POOR design. Apparently, you believe that your local users will never have their accounts hacked or infected with a mail-sending virus. I would not make such an assumption. That's a valid concern. In this specific case, however, it does not apply. All I do if SpamAssassin arrives at a score above the threshold (the ...yadda... part) is adding an X-Spam-Score header. Everything else (moving it to a spam folder or even deleting it) happens in the recipient's mail agent, and thus under the recipient's responsibility. It would make little sense IMHO to do that for mail which originated within the organization. Virus scanning is of course applied to every mail, whether originating locally or remotely. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany ___ 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] wanted: mimedefang-filter recipe for configurable SMTP call-ahead
One of my mail servers is serving a few relay domains in addition
to its local ones. So its mimedefang-filter script has a few
entries of the form:
if ($recipient =~ /[@.]example\.com?$/i) {
return md_check_against_smtp_server($sender, $recipient, $helo,
'mail.example.com');
}
As the number of entries is growing, I would like to move the
actual list of domains and servers to a configuration file and
have mimedefang-filter read that. In fact, Sendmail's mailertable
file has all the information already, so a separate configuration
file might not even be necessary and mimedefang-filter could be
tied to mailertable.db.
Unfortunately my Perl-fu is not quite up to the task. But I
imagine I'm not the first one to want something like that.
If someone has already done it, would you share your
solution?
aTdHvAaNnKcSe
Tilman
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
signature.asc
Description: OpenPGP digital signature
___
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] The .local TLD
Am 19.08.2012 20:30, schrieb kd6...@yahoo.com: --- On Sat, 8/18/12, David F. Skoll d...@roaringpenguin.com wrote: ... Sure, x.y.z.10.in-addr.arpa probably does hit the root name servers pretty often. If that were true, then explain the AS112 name servers. Isn't that obvious? The former is the raison d'être of the latter. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ 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] The .local TLD
Am 17.08.2012 21:35, schrieb David F. Skoll: RFC 1918 addresses don't typically leak out onto the Internet, so JFTR: Yes, they do. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany ___ 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] Mail Admin Question
Am 17.08.2012 11:29, schrieb Nathan Findley: Is it generally accepted as being ok to directly contact the other servers email administrator in order to try to resolve an undelivered email? Of course. I am finding myself being berated by the other systems admin for my unconventional methods in trying to resolve the matter because I sent him an email asking him to look into the connection reset by mail message. I am a total newbie in this arena. That's far from unconventional. He should be grateful you notified him of a potential problem. Regards, Tilman -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ 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] sanity Check: MD - SpamAssassing checks ~/.spamassassin/user_prefs
Am 01.08.2012 21:56, schrieb Ben Kamen: On 2012-08-01 7:22 AM, David F. Skoll wrote: On Wed, 01 Aug 2012 01:23:33 -0500 Ben Kamen bka...@benjammin.net wrote: But I don't see any place explicitly calling out ~dest_user/.spamassassin/userprefs in any form (still looking) You won't see that because it's impossible. MIMEDefang is a milter; it has no idea whether or not an SMTP recipient is local, remote, an alias, etc. Ok, so since SA runs under MD and MD doesn't know about local users... I follow. Perhaps it could be taught, though. I guess you could add some Perl code to the mimedefang-filter script to - check the domain part of destination addresses whether it is delivered locally (eg. by looking it up in local-host-names) - if so, look up the local part in aliases and/or virtusertable to find if it is delivered to a local shell user - if found, look in that user's home directory for a .spamassassin/userprefs file - if it exists, use it. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany ___ 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] sanity Check: MD - SpamAssassing checks ~/.spamassassin/user_prefs
Am 02.08.2012 19:13, schrieb Kevin A. McGrail: On 8/2/2012 12:00 PM, Tilman Schmidt wrote: Perhaps it could be taught, though. I guess you could add some Perl code to the mimedefang-filter script to - check the domain part of destination addresses whether it is delivered locally (eg. by looking it up in local-host-names) - if so, look up the local part in aliases and/or virtusertable to find if it is delivered to a local shell user - if found, look in that user's home directory for a .spamassassin/userprefs file - if it exists, use it. Or just shell out and run sendmail -bv [email address] That has its own challenges: - You'll have to arrange for sendmail -bv to be run as root even though MIMEdefang itself runs as the unprivileged defang user. - You'll have to parse sendmail -bv's output, possibly including multiple lines. Regards, Tilman ___ 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] Quick Question
Am 13.06.2012 08:19, schrieb kd6...@yahoo.com: --- On Tue, 6/12/12, Nathan Findley nat...@zenlok.com wrote: When I restart mimedefang (or perhaps for other reasons), I sometimes find a folder(s) remaining in the MIMEdefang spool directory. Is there a way to continue to re-process this mail? Or is sendmail sending a proper try again/bounce message to the sender? I am just concerned about proper delivery of all mail through my system. Doesn't your mail syslog tell you? Ah, a classical non-answer. @kd6lvw: Even though, in every individual case, the sendmail log will indeed tell you what it did to the mail, there is still value in posing the general question. @Nathan: Sendmail will indeed take care of making sure that every mail message is either delivered or properly bounced. (Except if your rules tell it otherwise of course.) Specifically, if MIMEdefang dies while processing a mail, Sendmail notices and signals an error to the sending server, which will then (if it is a properly working mail server) either retry or bounce. HTH Tilman -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ 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] Start Mimedefang with options
Am 11.06.2012 10:47, schrieb Prabin Acharya: Im using CentOS 6 /etc/sysconfig/mimedefang offers many ways to influence which options MIMEdefang is started with. If what you want to achieve doesn't have a specific variable there you can always use MD_EXTRA. HTH T. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ 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] filter_sender, authenticated or smtp (port 25) Connections
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 18.02.2012 06:57, schrieb Jobst Schmalenbach:
I have a mailserver that staff on mobile devices can use for sending email on
behalf of our domain.
This is done using port 465, ssl and authentication.
Is there any reason why you don't use the Mail Submission port 587 which
has been designated specifically for that purpose?
Reason: I used to have this nice thing in filter_sender that did not allow
people sending emails when the FROM address was from our domain, killing a
fair amount of spam and viruses. Now when they connect using 465 and
authentication I have no way finding out whether they come through 465 or 25,
well at least to my current knowledge.
Is there any way I can find out in mimedefang whether a connection is made as
authenticated users or coming through the standard smtp (25) port??
I don't think you can find out on which port the connection was made,
but you can easily check whether it was authenticated. For example, I am
using
if (defined($SendmailMacros{auth_type})) {
to avoid running SpamAssassin on messages submitted by my customers.
(Not because of the server load it generates, but because my customers
tend to be miffed if my server marks their messages as spam. ;-)
HTH
T.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAk8/wSYACgkQ780oymN0g8PK5QCfbrhCs9owRvJQzYwaDvxppNd/
9igAoOsYhuGfX5C50cFvoebuVgod2BhK
=l5Cu
-END PGP SIGNATURE-
___
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] Simplifying installations re: $Features{}
Am 17.11.2011 06:59, schrieb Philip Prindeville:
On 11/16/11 2:07 AM, Tilman Schmidt wrote:
$Features{'Virus:CLAMD'} = '/usr/sbin/clamd';
$Features{'Virus:CLAMAV'} = '/usr/bin/clamscan';
Works great.
For what it's worth, I think most of the $Feature{} tests just care about
true/false...
The scan methods that start a new process for every scan (like
'Virus:CLAMAV') use the $Feature{} value to find the executable.
Those that contact a daemon through a socket (like 'Virus:CLAMD') have
the daemon's executable in their $Feature{} entry just by convention,
and do indeed just use it as a boolean. They have a separate variable
(like $ClamdSock) for the socket address if necessary.
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
___
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] Simplifying installations re: $Features{}
Am 16.11.2011 02:31, schrieb Philip Prindeville:
On 11/15/11 2:46 PM, David F. Skoll wrote:
The point of the ./configure script is to search all those weird and
wonderful
paths at build time.
Well, right. But the build target isn't always the same as the run-target.
Especially for RPM-based builds.
Correct. So it's reasonable to default to not installed.
[...] putting explicit
$Features{...} assignments in your filter so you know exactly what you're
getting.
Yes, there's that... except that I don't like to modify scripts themselves in
/usr/bin... since that's a program and not configuration data.
You shouldn't. The assignments should go into the filter script. I had
the same situation with CentOS and put this in mimedefang-filter:
#***
# Configure Virus Scanners
#***
$ClamdSock = /var/run/clamav/clamd.sock;
$Features{'Virus:CLAMD'} = '/usr/sbin/clamd';
$Features{'Virus:CLAMAV'} = '/usr/bin/clamscan';
Works great.
HTH
Tilman
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
___
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] Mailman Footer in MS Outlook Link
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 24.10.2011 19:33, schrieb wbr...@e1b.org: servings...@gmail.com wrote on 10/24/2011 12:23:14 PM: By the way, the footer now is not an attachment but the unsubscribe link in the footer is not clickable. _I wonder if there is a solution for the link?_ This is likely to be a feature/function of your mail client to take URLs and turn them into clickable links. You may have it turned off for security or other reasons, or your client doesn't support it. Note the subject of this thread. It does state the mail client in question. So it's not a question of likeliness, but of catering for the quirks of that particular (unfortunately quite popular) mail client. Confidentiality Notice: This electronic message and any attachments may contain confidential [...] *sigh* T. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk6l2cUACgkQ780oymN0g8NJjgCgvaPlBr75YcOM+p2K3jbFL9XB 3s8AoI3Z/ijehrMbnzC8gqveBOurxFCA =EDPd -END PGP SIGNATURE- ___ 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] From Specific Address's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 21.10.2011 14:27, schrieb Aaron Enders:
Can mimedefang be used to inspect the from address and if it matches a
specific From *@example.com address forward a copy to another mailbox?
Sure. The envelope from address is available in the $sender
variable. Forwarding a copy can be achieved with the
add_recipient() function.
If so any examples would be appreciated.
- From the top of my hat, untested, YMMV, you get the idea...:
if ($sender =~ /\@example\.com/) {
add_recipient('interception-serv...@cia.example.org');
}
This causes BCC style forwarding. If you want CC style, add a
CC: header to the mail itself via action_add_header().
HTH
T.
- --
Tilman Schmidt
Abteilungsleiter Technik
-
Phoenix Software GmbH Tel. +49 228 97199 0
Geschäftsführer: W. Grießl Fax +49 228 97199 99
Adolf-Hombitzer-Str. 12 www.phoenixsoftware.de
53227 Bonn, GermanyAmtsgericht Bonn HRB 2934
-
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6hd5gACgkQ780oymN0g8MVTACgmQs9QIJUPCiKN2XRA+g6ZSUi
IXUAoMZyWhTR5NfFT/sbxJdnznrAKEpH
=me3y
-END PGP SIGNATURE-
___
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] greylist implemenation
Am Fr, 26.03.2010, 11:59 schrieb Marcus: http://hcpnet.free.fr/milter-greylist/ May be OT, but any experiences with this filter? Works fine here on two servers. Reasonably easy to set up, and no problems so far. HTH Tilman ___ 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] Email 101
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2010-03-16 20:19 schrieb -: Page 2: 3. RFCs are available in plain-text format. They are easy to read online on any type of computer. Add: They may be available in additional formats (e.g. HTML). Please don't. It would just clutter the text without adding anything substantial. 3.2.2 TCP isn't working around IP's unreliability. It's working around IP's failure to guarentee reliability and ordering of received data. The former isn't wrong or misleading, and the latter is much longer and harder to comprehend, so I'd vote for the short and sweet version. 4.2: Isn't host depreciated? Use dig instead. No. nslookup is deprecated. host is the designated successor. dig is nice as a troubleshooting tool or if you want to see the gory details, but it produces much too verbose output for the purpose at hand. Page 9 example: You should not use local parts that have special meanings. Replace devnull with something else. Can't see why. devnull is a perfectly fine local part. In fact, I do have an E-mail correspondent whose mail address is devn...@ 6.1.2 - Received header. You should NOT include examples of syntactically invalid received headers. I disagree. Real-life Received headers are very frequently not syntactically valid, and the mail gets through, anyway. It does a much better service to the reader to show him or her what to expect when looking at the headers of an actual E-mail message, than to explain what these headers should have looked like if software authors had for once adhered to the standards. HTH Tilman - -- Tilman Schmidt Abteilungsleiter Technik - Phoenix Software GmbH Tel. +49 228 97199 0 Geschäftsführer: W. Grießl Fax +49 228 97199 99 Adolf-Hombitzer-Str. 12 www.phoenixsoftware.de 53227 Bonn, GermanyAmtsgericht Bonn HRB 2934 - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkugqVMACgkQ780oymN0g8Mo/gCghpJzcmAqNPIAUWKQVr1xYlhx +eIAn1lO2gqn/mlVQthbscL6ZhA+CV/8 =teif -END PGP SIGNATURE- ___ 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] blocking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2010-02-26 10:40 schrieb Salem, Hadi (Hadi)** CTR **: I would like mailter to block .exe mention in the msg body. How?? That depends largely on what exactly you mean by mention (and to some extend on what you mean by block.) Do you want to block any mail containing the string .exe anywhere in its text? (Not a good idea IMHO, it would for example block both your question and my answer.) Do you want to block any mail containing an actual attachment with a file name ending on .exe? Do you want to block any mail containing an URL for downloading an .exe? Do you want to explicitly reject the blocked mail when it's coming in? Do you want to silently delete it? Do you want to put it into some sort of quarantine? Do you want to pass it on but remove the .exe mention? - -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuHob8ACgkQ780oymN0g8MFnQCdFJXj+3mDrSabLPGZK8Eq0O8z V6IAnRSXQ5DJSabqXNukVCVixzGoStgs =uKB0 -END PGP SIGNATURE- ___ 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] MIMEDefang 2.68 panic: top_env problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2010-02-25 10:55 schrieb -: Even if you choose not to upgrade perl itself (to version 5.10.1), you should really run: perl -MCPAN -e upgrade Don't do that if Perl was installed as an RPM package. (Which I suspect in the case of the OP, given his uname output.) Otherwise you risk ending up with a completely broken Perl after the next RPM update. HTH Tilman -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuGe7sACgkQ780oymN0g8MY5wCgnmXvQNIMisGZbGmHYP7q9a7x z+UAni0FCSoLhhb5xeFW8D7Aj9ntGn6A =DFJ2 -END PGP SIGNATURE- ___ 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] OT: Choice of desktop OS (was Re: watch-mimedefang)
Am 13.02.2010 00:54 schrieb David F. Skoll: I must confess, I've never understood people who administer Linux servers, yet don't run a Linux desktop. Heck, run Linux in VMWare if you must, but at least use proper desktop tools to administer a Linux server. From personal experience I can recommend doing it the other way around: run Windows in VirtualBox on a Linux desktop. ___ 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] how can i change the required score in spamassassin in a mimedefang script?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2010-02-02 18:21 schrieb ml ml: What i am trying to do now is to get the required spamassassin score per domain. Here is my code: http://pastebin.com/m690faaa2 (ok, this is a terrible proof-of-concept code, but it does its job so far for testing) It look, that's its actually working, although the spam report keeps talking about the required default score of 5, which is definitely not being used. What do you expect? SpamAssassin has no way of knowing the required score value you are retrieving from LDAP in MIMEDefang. More precisely, the required score value is configured in SpamAssassin (specifically, /etc/mail/sa-mimedefang.cf) and reported back to MIMEDefang in the 2nd element of the result vector. By the time you replace $req by the value retrieved from LDAP, SpamAssassin has already done its work and written the report. So either you devise a way of passing your LDAP value into SpamAssassin for inclusion in the report, or you generate your own report in MIMEDefang. HTH Tilman - -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktpPkwACgkQ780oymN0g8NBZgCePJh3t76QX4V4W4jGGEB8eY2D uH8AoIEpN9j0gFHwQTxO8deVFZUFwfnp =Ko4Y -END PGP SIGNATURE- ___ 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] Reap: slave 37 (pid 15371) exited due to signal 14 (SLAVE DIED UNEXPECTEDLY)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2010-02-03 09:17 schrieb Casper Kristiansson:
Why do the multiplexor give the above error within this code ??
eval{
$SIG{INT}=sub{$grey_insert-cancel};
alarm 10;
Looks like you are catching the wrong signal. You set $SIG{INT} but
alarm is emitting SIGALRM.
HTH
Tilman
- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktpP+gACgkQ780oymN0g8Oc7wCg0PST2gExD6rXyjR9qgFq0Qur
mukAn3Is8gjm/nsOQ/449JvHAKaFtnM7
=RTjt
-END PGP SIGNATURE-
___
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] auto reply / vacation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2010-02-02 08:39 schrieb ml ml: Hi, On Tue, Feb 2, 2010 at 1:12 AM, - kd6...@yahoo.com wrote: --- On Mon, 2/1/10, ml ml mliebher...@googlemail.com wrote: has anyone got some hints for me how to write a auto reply / vacation script? Or is there already such a project out ... Yes: DON'T. There are enough problems with existing autoresponders out there. well, there is the feature request which needs to be done. So there is no way around it. In my experience, there is almost always a way around unreasonable feature requests, although it typically involves hurdles such as actually talking to the requestors. What problems exactly, how can they be avoided? Firstly, using an autoresponder very rarely serves any useful purpose. In many cases it actually harms, for example by leaking internal information (such as the existence of the mail address, the real name of its owner, or the reason and/or duration of his or her absence), creates false expectations (will reply promptly after my return :-) and/or annoys the recipient (why is no one filling in?). Secondly, autoresponders frequently respond to mails they shouldn't, such as mailing lists, newsletters, SPAM, do not reply mails, machine generated notification mails, DSNs, mails from other autoresponders ... Reliably avoiding that is very hard. Thirdly, autoresponders may send their autoresponse to the wrong recipient. It's of course not always obvious who the correct recipient of an autoresponse should be or how to determine that algorithmically. Fourthly, the autoresponse is often useless to the recipient. I regularly receive automatic I have received your mail and will reply to it promptly messages which don't give me any clue to which mail they might refer to, and from mailboxes to which I never consciously sent a mail. And fifthly (does that word exist?), autoresponders interact badly with another nuisance feature request, legal disclaimers. The autoresponder emits a canned message that doesn't give a clue to whom it might be addressed and what it might referred to, and the attached disclaimer then asks the recipient to delete all copies of the message if he or she is not the intended recipient. What kind of impression will the recipient of such a message get about the legal and technical competence of the organization that was responsible for the emission of such an incoherent piece of mail? HTH Tilman - -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktn+F4ACgkQ780oymN0g8PSmwCdG8BYaJWS5DOiiP8AaFROlro4 YAoAnigJTJDvpJNQ6yZEYYx1eAuVW8tG =O91t -END PGP SIGNATURE- ___ 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] FW: Mimedefang and Anti-virus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, sorry for the late reply. Been out of the office for most of the last two weeks. Am 2010-01-20 23:22 schrieb Cliff Hayes: The list rejected my reply too ... so sending directly to you. I'll try CCing the list again. Perhaps it'll change it's mind. :-) don't know what mimedefang expects. If it's like spamassassin, I know that mimedefang does not use the spamassassin daemon, so I don't need to run spamd. If it's the same for clamav, then I need clamav and not the scanner daemon. At least on my servers, MIMEDefang uses the scanner daemon (clamd) via the socket configured in $ClamdSock. (/var/spool/MIMEDefang/clamd.sock by default.) Actually, perusing the Perl source in /usr/bin/mimedefang.pl I see that it seems to support both ways. Ie. if the ClamAV daemon is not available it will call clamscan directly. However I would recommend against it from a performance point of view. HTH Tilman - -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktoLB4ACgkQ780oymN0g8O9uwCgi8cSTxeWZtWBjn838jMUvHio nwEAn0d27jyh++of45c1dr8bTBPEIR7G =z7Ie -END PGP SIGNATURE- ___ 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] configuring mimedefang-filter to reject during smtp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2010-01-18 01:44 schrieb Tony:
Can anyone provide a mimedefang-filter example that shows the correct
syntax to reject during smtp? [...] In the mimedefang-filter file I see
entries to change the header and do this and that but all I'm intetested
in is rejecting during smtp. Thanks for any advice.
The key is the action_bounce method. As an example, here's a patch hunk
for mimedefang-filter to reject messages with suspicious characters in
headers during the SMTP dialogue instead of dropping them (beware of
line wraps):
@@ -118,7 +130,9 @@
md_graphdefang_log('suspicious_chars');
# action_quarantine_entire_message(Message quarantined because of
suspicious characters in headers);
# Do NOT allow message to reach recipient(s)
- - return action_discard();
+ # Don't discard; bounce as per #ss9.5
+ # return action_discard();
+ return action_bounce(Message rejected; illegal characters in message
(per RFC 2821, 2822));
}
# Copy original message into work directory as an mbox file for
HTH
T.
- --
Tilman Schmidt
Phoenix Software GmbH
Adolf-Hombitzer-Str. 12
53227 Bonn, Germany
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktVdBMACgkQ780oymN0g8MllQCgzrDAtTBLkNaYVICDoP9B8ta/
6dYAnA/IzSfOqTydZevZsrZ6ff+VAN7i
=OvgS
-END PGP SIGNATURE-
___
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] Mimedefang and Anti-virus
Am 19.01.2010 16:38 schrieb Cliff Hayes: I did a yum search clamav and got the following. What does mimedefang require? From a machine currently running MIMEDefang ClamAV: [...@mailgate ~]$ rpm -qa *clam* clamav-0.95.3-1.el5.rf clamav-db-0.95.3-1.el5.rf clamd-0.95.3-1.el5.rf Note the last one (clamd) which is essential but which your search didn't catch. IIRC yum install clamd was enough to pull in all the others as dependencies. HTH T. ___ 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] Sendmail::Milter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2009-11-23 21:38 schrieb -: I too limit connections to one, and one per 5 minutes. Should remotes violate that, they get two warnings (ICMP admin-prohibited), and if they're too eager, they fall into my TCP TARPIT. I wonder. Do you have any data on how typical mail server software reacts to that sort of policy? What does, for example, a Sendmail or Exchange server in default configuration do if it tries to deliver two mails to a destination server, the first one succeeds, and the second one fails with administratively prohibited? - -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLC5nn780oymN0g8MRAvw8AKDL2jaNqj37dBtX1YugqaFoe7XiVACgks4j r+wM1qwEWp8B66WWdAn4sR8= =cQ3R -END PGP SIGNATURE- ___ 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] mimedefang fails to start upon reboot
Am 09.11.2009 20:15 schrieb -: In general, I don't see why anybody should care about any bug that doesn't exist with the most current release of ALL involved software packages. Only when it occurs with the current releases is it a problem (that hasn't been fixed). You don't run production servers, do you? SCNR T. ___ 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] SNARE spam detection
Kenneth Porter schrieb: Just saw this on Slashdot: http://www.technologyreview.com/communications/23086/page1/ That article is so full of misinformation and patently wrong statements it's really not worth discussing. 2) They look at how many open ports are on the sender. (Few ports indicates a bot-controlled zombie spammer.) The sentence you refer to claims that Bots [...] tend to keep open the [SMTP] port which is absurd. I've yet to find a Spambot that actually accepts incoming SMTP connections. Both operations look potentially expensive, The article also claims that information could be gleaned from a single packet of data which is equally absurd. and port-scanning the sender means all our legitimate senders will soon see regular port scans. Well, everybody on the Internet is seeing regular port scans anyway. The real issue is that users of that wonderful new spam detection technique will quickly find themselves on those legitimate senders' IP blacklists, together with all those bots which in their spare time between distributing spam try a bit of portscanning to recruit more members for their botnet. T. ___ 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] Overlong line in RESULTS file and sendmail confMAX_HEADERS_LENGTH
Roberto Ullfig schrieb: Feb 16 13:56:28 clientmq-3 mimedefang[19145]: n1GJt7KB012211: Overlong line in RESULTS file - 25940 chars (max 8191) confMAX_HEADERS_LENGTH MaxHeadersLength [32768] Maximum length of the sum of all headers. It would seem that sendmail and mimedefang are at odds here. Sendmail allows 32K headers but mimedefang only allows 8K headers. Is that what I'm seeing? Am I understanding this right? If so, wouldn't it make sense to reduce sendmail's confMAX_HEADERS_LENGTH to 8191? The way we have things setup I'd much rather have the message get rejected by sendmail instead of mimedefang. These are different things. MIMEdefang limits the length of a single header line, while Sendmail limits the length of the entire header. Setting confMAX_HEADERS_LENGTH to 8191 would reliably limit the length of each individual header line to 8191, too, of course, but it would be a rather drastic way of achieving that. :-) HTH -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany ___ 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
