Re: [Mimedefang] Poll: Who uses the "filter_tick" and "map" functionality of MIMEDefang? (-X and -N options to mimedefang-multiplexor)
I used to use filter_tick to basically do keep-alives on the tcp connection from the milter to a database or ldap server. This, I hoped, would solve the problem of the remote server silently closing the connection down because of inactivity. I found that it was more appropriate to instead - Keep track of approx last time the connection was used. - And if the last time it was used was larger than some threshold = I would first issue a noop or other low cost operation = If the noop failed, I would reestablish the connection = If the noop succeeded, I would merely continue So I no longer need the filter_tick function. (Nor do I use the '-N sock_map' feature.) Thanks for asking, -Original Message- From: MIMEDefang [mailto:mimedefang-boun...@lists.roaringpenguin.com] On Behalf Of Dianne Skoll Sent: Wednesday, April 27, 2016 1:24 PM To: mimedefang@lists.roaringpenguin.com Subject: [Mimedefang] Poll: Who uses the "filter_tick" and "map" functionality of MIMEDefang? (-X and -N options to mimedefang-multiplexor) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, all, I'm looking at stripping out unused features from MIMEDefang. 1) Does anyone use the "-X n" feature that calls a function called filter_tick every "n" seconds? If not... I'd like to nuke. 2) Does anyone use the "-N map_sock" feature that provides a SOCKETMAP to Sendmail 8.13+? If not... again, I'd like to nuke. Regards, Dianne. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iD8DBQFXIPWrwYQuKhJvQuARAkEQAKCDy2/7dw57wIxclFGbb4nXW5Y5jwCfTX2A BlFemB45ZVrCz/l980YzsiA= =D0FR -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 ___ 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] helo callback
> Check the Sendmail source. It seems to me that the version I checked > (8.14.5) lets the HELO go by successfully even if the milter says not to. Yep. 8.14.9 still has the bug that I see first referenced back in 2004. The routine in sendmail/srvrstmp.c where I suspect the bug resides is a small 2800 lines long. I'll be happy to see what I can accomplish. Dale Moore ___ 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] Net::DNS referral section for a Domain?
Instead of using the $reply->answer
Use the $reply->authority section.
use Net::DNS;
my $res = Net::DNS::Resolver->new() ||
die "No Resolver\n";
my $reply = $res->query('pccc .com') ||
die "No Reply\n";
my $authority = $reply->authority ||
die "No Authority\n";
foreach my $rr ( $reply->authority) {
( $rr->type eq 'NS' ) || next;
print $rr->nsdname , "\n";
}
-Original Message-
From: mimedefang-boun...@lists.roaringpenguin.com
[mailto:mimedefang-boun...@lists.roaringpenguin.com] On Behalf Of Kevin A.
McGrail
Sent: Thursday, November 13, 2014 5:44 PM
To: mimedefang@lists.roaringpenguin.com
Subject: [Mimedefang] Net::DNS referral section for a Domain?
Trying to do some checks on spam by nameservers but I can't figure out how to
find the referral nameservers for a domain from the
root servers.
For example, this snippet is NOT what I need, I don't think:
use Net::DNS;
my $res = Net::DNS::Resolver->new;
my $reply = $res->query("pccc.com", "NS");
if ($reply) {
foreach $rr (grep { $_->type eq 'NS' } $reply->answer) {
print $rr->nsdname, "\n";
}
}
else {
warn "query failed: ", $res->errorstring, "\n";
}
This snippet gets the SOA records which don't have to agree with whois, for
example:
ns3.pccc.com
ns.2rad.net
ns.pccc.com
ns2.pccc.com
But perhaps it's because our system will check and the servers are
authoritative.
What we want is the equivalent of a dig +trace referral record which would be:
;; Received 486 bytes from 198.41.0.4#53(a.root-servers.net) in 9 ms
pccc.com. 172800 IN NS ns.pccc.com.
pccc.com. 172800 IN NS ns2.pccc.com.
pccc.com. 172800 IN NS ns3.pccc.com.
Any thoughts on how to do that programmatically with Net::DNS?
Regards,
KAM
___
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
___
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] helo callback
Perhaps someone can explain this behavior..
Below is what happens in chronological order.
Client: connect to server (sendmail 8.14.9)
Mimedefang filter_relay: return('CONTINUE');
Server: 220 somehost.cs.cmu.edu ESMTP Sendmail 8.14.9/8.14.9; Fri, 7 Nov 2014
12:56
Client: Helo naughtywords
Mimedefang filter_helo: return('REJECT', 'I do not like naughtywords');
Server: 220 somehost.cs.cmu.edu Hello someclient.cs.cmu.edu [128.2.x.x],
pleased to meet you
Client: Mail From:
Mimedefang filter_sender: return('CONTINUE');
Server: 554 5.7.1 I do not like naughtywords
Note how the mimedefang filter_helo does not affect the SMTP response
immediately,
but is instead delayed until after the sender has been specified.
I would have instead expected it to happen immediately.
Details: Sendmail 8.14.9 Solaris 10 (and linux has same behaivor)
Sendmail is not configured with delay_checks.
Mimedefang version 2.75 .
Explanations appreciated.
Dale Moore
___
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] delay on relay problems
Short Version:
Mimedefang 2.75 doesn't implement delay on filter_relay routine.
I think that is a bug. Where do I submit patches?
Long Version:
I'm trying to run a small experiment to delay on relay connect
Under special circumstances, and I'm having some problems.
It appears that the perl filter_relay routine
Returns an 5 element list
( code, message, code, dsn, delay)
Of course many of these can be undef.
In examining the source code, and milter specifications,
A few things captivate me.
The first thing is that we cant call smfi_setreply
from connect callback. Ok. That is a limit, but
the delay is not implemented in the smfi callbacks,
it is instead implemented by the mimedefang process.
The mimedefang sources carefully pass the list
( message, code, dsn, delay)
Back through
- from the mimedefang-filter
- through the intermediary multiplexor and its communication buffers
- and into mfconnect routine mimedefang.c
In the mfconnect routine the code reads
if (doRelayCheck) {
char buf2[SMALLBUF];
int n = MXRelayOK(MultiplexorSocketName, buf2, data->hostip,
data->hostname, data->hostport, data->myip,
data->daemon_port);
if (n == MD_REJECT) {
/* Can't call smfi_setreply from connect callback */
/* set_dsn(ctx, buf2, 5); */
cleanup(ctx);
DEBUG_EXIT("mfconnect", "SMFIS_REJECT");
return SMFIS_REJECT;
}
if (n <= MD_TEMPFAIL) { ... }
if (n == MD_ACCEPT_AND_NO_MORE_FILTERING) {
/* Can't call smfi_setreply from connect callback */
/* set_dsn(ctx, buf2, 2); */
cleanup(ctx);
DEBUG_EXIT("mfconnect", "SMFIS_ACCEPT");
return SMFIS_ACCEPT;
}
if (n == MD_DISCARD) { ... }
}
DEBUG_EXIT("mfconnect", "SMFIS_CONTINUE");
return SMFIS_CONTINUE;
}
The set_dsn routine is responsible for
- decoding the arguments from the multiplexor
- implementing the delay
- calling smfi_set_reply but only when the third parameter is 4 or 5.
If you'll examine the code above you'll see
- that we don't explicty check for MD_CONTINUE
- that filter routine always avoids calling set_dsn, even when num param is
not 4 or 5
I believe that it is a bug that the 2.75 version of mimedefang
does not implement the delay on filter_relay , especially on 'CONTINUE'.
I sincerely hope that you agree.
I will have some patches I would like to submit.
Where should I submit them?
Dale Moore
___
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 count recipients in filter_recipient
My mistake. Thanks for pointing this out. Dale Moore -Original Message- From: mimedefang-boun...@lists.roaringpenguin.com [mailto:mimedefang-boun...@lists.roaringpenguin.com] On Behalf Of kd6...@yahoo.com Sent: Tuesday, April 16, 2013 2:32 PM To: mimedefang@lists.roaringpenguin.com Subject: Re: [Mimedefang] How to count recipients in filter_recipient --- On Tue, 4/16/13, Dale Moore wrote: > In this case, we merely main::delete_recipient($recipient_A); > then main::action_accept() for the rest of the recipients. > > You cant tempfail individual recipients once you peek at the message > and see that it is spam. By the time you see the message, you've already > accepted the recipients. > > Different mimedefang-milter processes might handle the same message. > One milter process could handle the relay while a different one handles > the sender. In fact, different processes could handle different recipients > of the same message. This makes persistent variables like $rcpt_count > difficult to implement. Look at how the Recipients array is defined during filter_recipient: "[A]fter calling read_commands_file within filter_recipient, the current recipient under consideration is in the final position of the array, at $Recipients[-1], while any previous (and accepted) recipients are at the beginning of the array, that is, in @Recipients[0 .. $#Recipients-1]." At the array lists only accepted recipients, one can easily reject or tempfail any future recipient that has a different spam policy than the first recipient (and only the first need be checked, since one checked for differences with the other elements as the array was built -- one recipient at a time). ___ 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 ___ 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 count recipients in filter_recipient
In this case, we merely
main::delete_recipient($recipient_A);
then
main::action_accept()
for the rest of the recipients.
You cant tempfail individual recipients once you peek at the message
and see that it is spam. By the time you see the message, you've already
accepted the recipients.
Different mimedefang-milter processes might handle the same message.
One milter process could handle the relay while a different one handles
the sender. In fact, different processes could handle different recipients
of the same message. This makes persistent variables like $rcpt_count
difficult to implement.
Dale Moore
Carnegie Mellon University
-Original Message-
From: mimedefang-boun...@lists.roaringpenguin.com
[mailto:mimedefang-boun...@lists.roaringpenguin.com] On Behalf Of Benoit
Panizzon
Sent: Tuesday, April 16, 2013 5:52 AM
To: mimedefang@lists.roaringpenguin.com
Subject: [Mimedefang] How to count recipients in filter_recipient
Hello
The situation:
Recipients have different SpamAssassin Settings:
Recipeint A => "NO FILTERING";
Recipient B => "REJECT SPAM";
Now an email arrives
mail from:
rcpt to:
rcpt to:
Now if this is an email that will be handled as spam, we have the problem,
that Recipeint A does want to receive that email and Recipient B want us to
reject it during SMTP Handshake.
We could:
Accept the Email and deliver it only to Recipient A.
Problem: If it was a false positive, that sender does not know it was not
delivered to Recipient B. His Maillog will tell him it was successfully
delivered. => NoGo.
We could:
Reject that email: Recipient A will complain that we filtered the email even
though his settings tell us not to do so. = NoGo.
Solution:
We only accept those recipients which have identical anti-spam settings and
tempfail the others, forcing the sending MTA to resent them in a separate
session. So we can then handle that session according the users settings.
sub filter_sender {
$rcpt_count = 0;
return ('CONTINUE',"ok");
}
sub filter_recipient {
if ($rcpt_count eq 0) {
my $filterrule = &getspamsettings($recipient);
} else {
$rcpt_count++;
return ('TEMPFAIL', "Too many Recipients") if ($rcpt_count > 50);
return ('TEMPFAIL', "Different Spam Setting, please resend separately")
if
($filterrule != &getspamsettings($recipient));
}
return ('CONTINUE',"ok");
}
Well, this is the basic idea. Please ignore the syntax errors :-), I just
started with the $rcpt_count in my code. Unfortunately filter_sender and
filter_recipient calls are carried to different filter processes. So the
counter is not reset.
Is there a way to define some sort of over-global variable that is consistent
for one SMTP session between all of the mimedefang processes?
Kind regards
Benoit Panizzon
--
I m p r o W a r e A G-
__
Zurlindenstrasse 29 Tel +41 61 826 93 07
CH-4133 PrattelnFax +41 61 826 93 02
Schweiz Web http://www.imp.ch
__
___
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
___
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
> Those aren't big numbers and it shouldn't bother your server much even > if they were orders of magnitude higher... Why not just ignore it? > Or do you want to improve the user's experience by getting a DNS in their > inbox > where they might see it - which is what would happen if the server where they > submit > didn't know the user list? Exactly right. Looking back over my logs, this was only a couple of droids A few months ago. Now I must do this several times a month. Perhaps the result of a minor email education blitz. The load on the server is very low, but getting higher. But from the user experience standpoint it is a total failure. The users don't check their 'Outbox' on their android. They don't know why the email didn't get through. They didn't get any notification as to why their email didn't go through. They thought that they sent it. They are sure that they sent it. And the intended recipient sure didn't receive it. It does the right thing for other especially off-site email addresses. From the users perspective our system lost their email again. This application works for hundreds or thousands of other sites and it doesn't work for our system.From their perspective, our setup is just plain broken. Dale Moore -- Les Mikesell lesmikes...@gmail.com ___ 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 ___ 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
> I would take a scorched-earth approach. I would immediately lock the > account of any user from whom I observed such behaviour and refuse to unlock > it until the user replaces the email app with a non-broken version. With that approach, I'm not sure that it is the earth that would end up being scorched. ___ 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] Email injection and the android 'email' app
I am a recent mailing list subscriber.
I am a longtime user of mimedefang.
I'd like to discuss email injection, which is not specifically a mimedefang
issue, but I will use mimedefang to implement what I'm discussing.
I have had the philosophy that it is better to reject an email via
SMTP protocol (550 5.1.1 No Such user here) instead of accepting an
email then later sending a Delivery Status Notification (DSN) that an email
could not be delivered.
That philosophy of early rejection is independent of
- whether the client had authenticated or not, and/or
- whether the email was for the local site or not.
This philosophy reduces network traffic, reduces mis-directed
DSN blowback (faked envelope mail from), and is just a cleaner
way of doing things.
A most curious behavior that I'm seeing is with the Android email app.
When an android user, using the default 'email' app,
attempts to send email to u...@this.site.example.com but the
user mistypes the email address as nosuchu...@this.site.example.com
the SMTP server for my domain (this.site.example.com) will respond with
550 5.1.1 No Such mailbox here
It responds with failure because the smtp server knows the local
domain this.site.example.com very well because it is the local domain.
And it knows all of the email addresses within that domain.
And it knows that nosuchu...@this.site.example.com is not valid.
It only makes sense to me to reject this email at this point.
The android 'email' app, will NOT take this 'permanent' failure as definitive,
and instead try again shortly to resend the email. The email remains the
the app's 'Outbox' . I currently have dozens of remote android client
that connect to my smtp server that regularly attempt to send their
same mis-addressed email dozens of times a day for weeks on end.
My guess is that this email client application wants my SMTP server to
always accept the email and send a DSN upon discovery of a problem.
We currently have several per account email settings stored in our
ldap directory that my mimedefang milters reference. These settings include
- Spam scoring thresholds
- greylisting settings
we are considering one that would do the following
- get the authenticated user id ($main::SendmailMacros{auth_authen})
- retrieve their LDAP bouce settings
- Use this bounce setting to decide whether to bounce or send a DSN.
Another option to attempt to solve this problem, is if my milters see this
behavior more times than some configurable threshold (say 10 times from
the same IP/envelope from/rcpt to/) is to
- adjust the servers behaviour by accepting the email and
- send a DSN that the email was probably mis-addressed.
That would cause the apps nagging to eventually stop, but at the expense
of a non-immediate feedback to the app user that he or she cant type.
Another option is some combination of the above.
Currently, to deal with this problem, I'm
- manually scanning the logs picking out such behavior
- personally notifying the users that their email isnt going out and why
- helping them put their droid in airplane mode
- helping them remove the offending message from their 'Outbox'
- helping them put their droid out of airplane mode
If your opinion is that the android app is wrong, I'll agree. But it is
becoming
so pervasive, we must find a better way of accomodating this email client app.
There are too many android users. We cant try to convince them that they should
use a different email app or adjust their settings for composing or reading
email.
I might as well hold back the tide as ask them to change their behavior.
I myself am an android app user.
Your ideas are appreciated. You can send your ideas to me directly and I will
summarize in a week. Or you can send them to this list.
Dale Moore
___
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
