headers
Philip Prindeville | 1 Mar 2008 01:02

Re: Testing for port #/TLS in filter_relay

David F. Skoll wrote:
> Philip Prindeville wrote:
>
>> Ok, so...  let's step back a moment.  What's the barrier to passing
>> Sendmail Macros to mimedefang at the relayok time?
>
> The barrier is MIMEDefang's architecture.  It passes macros in the 
> COMMANDS
> file and that file does not exist until MAIL FROM.  Fixing this
> is a major change that is unlikely to happen.

What about adding extra parameters to relayok and/or filter_relay()?  
mfconnect() has all the state it needs to pass the port # to MXRelayOK().

The arguments could be added on to the end, so existing scripts would 
continue to work.

If I send a patch to do it this way, what's the chance of it being accepted?

-Philip
Permalink | Reply | 12 comments |
headers
David F. Skoll | 1 Mar 2008 01:22
Favicon

Re: Testing for port #/TLS in filter_relay

Philip Prindeville wrote:

> What about adding extra parameters to relayok and/or filter_relay()?  

I don't like that.  We need to keep the commands between the C and Perl
code fairly short.

> If I send a patch to do it this way, what's the chance of it being 
> accepted?

Very low, unless a few other people on the list want the feature badly
enough to ask for it.  I honestly don't think the changes are worth
it; you can do everything you need at the MAIL FROM stage.

Regards,

David.
Permalink | Reply | 10 comments |
headers
Kelson | 1 Mar 2008 01:51
Favicon

Re: Testing for port #/TLS in filter_relay

Philip Prindeville wrote:
> What about adding extra parameters to relayok and/or filter_relay()?  
> mfconnect() has all the state it needs to pass the port # to MXRelayOK().

Sorry if I missed something earlier in the thread, but is there a reason 
that what you're doing can't/shouldn't be done in filter_sender?

I seem to recall that this was where most people originally did MD-based 
relay tests, before filter_relay was added.  And as far as efficiency 
goes, it's pretty much the same as running sendmail with delay_checks 
turned on.

--

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>
Permalink | Reply | 0 comments |
headers
Philip Prindeville | 1 Mar 2008 03:10

Re: Testing for port #/TLS in filter_relay

David F. Skoll wrote:
> > If I send a patch to do it this way, what's the chance of it being 
> accepted?
>
> Very low, unless a few other people on the list want the feature badly
> enough to ask for it.  I honestly don't think the changes are worth
> it; you can do everything you need at the MAIL FROM stage.

By the time that MAIL FROM: is seen, fork()'s have happened, etc. and 
it's a bit late to avoid the overhead that could be otherwise be avoided 
by balking at the connection early on.

-Philip
Permalink | Reply | 9 comments |
headers
David F. Skoll | 1 Mar 2008 03:15
Favicon

Re: Testing for port #/TLS in filter_relay

Philip Prindeville wrote:

> By the time that MAIL FROM: is seen, fork()'s have happened, etc.

???

The fork() happens right after the connection is accepted, even before
filter_relay.

> and it's a bit late to avoid the overhead that could be otherwise be avoided 
> by balking at the connection early on.

The difference is very minor, certainly not worth loading more complexity
into MIMEDefang.  If saving that bit of overhead actually makes a difference,
then you shouldn't be running MIMEDefang at all, because MIMEDefang is
not exactly lightweight.

Regards,

David.
Permalink | Reply | 8 comments |
headers
Vladimír Solnický | 3 Mar 2008 08:21
Picon

When the fork happens [Re: Testing for port #/TLS in filter_relay]

29. 2. 2008 napsal(a) David F. Skoll na téma ,Re: [Mimedefang] Testing for...:

> Philip Prindeville wrote:
>
>> By the time that MAIL FROM: is seen, fork()'s have happened, etc.
>
> ???
>
> The fork() happens right after the connection is accepted, even before
> filter_relay.

IMHO there were two forks in sendmail, one as you say after accepting the 
connection and the second in the MAIL FROM stage (I looked at it four 
years ago, thus the past tense; I do not know the current situation). The 
second fork could be avoided if the client used ESMTP and the ONEX 
command. As I said I do not know if it is the same now but IMHO it has not 
changed since then.

Regards,

Vladimír
--

-- 
Vladimír Solnický (Vladimir Solnicky in ASCII)
Píši pouze za sebe / Speaking for myself only ...
Permalink | Reply | 2 comments |
headers
Jan-Pieter Cornet | 3 Mar 2008 10:03
Picon
Picon
Favicon

Re: re_match in filter_begin

On Fri, Feb 29, 2008 at 06:33:48PM -0500, Kevin A. McGrail wrote:
> Follow-up on my earlier code.  I think if I want to trick MD into thinking 
> I have a different scanner temporarily, I need to do this.  It's untested 
> but I definitely didn't have it right before.
> 
>      if (re_match($entity, '\.docx?') && 1 == 2) {
>        $Features{'Virus:NAI_temp'} = $Features{'Virus:NAI'};
>        $Features{'Virus:NAI'} = undef;
>        $Features{'Virus:CLAMAV'} = '/usr/local/clamav/bin/clamscan';
>        undef  <at> VirusScannerMessageRoutines;
>        undef  <at> VirusScannerEntityRoutines;
>        $VirusScannerRoutinesInitialized = 0;
>        initialize_virus_scanner_routines();
> 
> ...
> 
>        $Features{'Virus:NAI'} = $Features{'Virus:NAI_temp'};
>        $Features{'Virus:CLAMAV'} = undef;
>        undef  <at> VirusScannerMessageRoutines;
>        undef  <at> VirusScannerEntityRoutines;
>        $VirusScannerRoutinesInitialized = 0;
>        initialize_virus_scanner_routines();
>      }
>    }

Why don't you simply use both scanners all the time? Performance
issues? Afraid of false positives?

We're currently using 3 virus scanners, and virus scanning doesn't
take much resources, when compared to spamassassin. Plus, it's clear
(Continue reading)

Permalink | Reply | 502 comments |
headers
David F. Skoll | 3 Mar 2008 14:56
Favicon

Re: When the fork happens [Re: Testing for port #/TLS in filter_relay]

Vladimír Solnický wrote:

> IMHO there were two forks in sendmail, one as you say after accepting 
> the connection and the second in the MAIL FROM stage (I looked at it 
> four years ago, thus the past tense; I do not know the current 
> situation). The second fork could be avoided if the client used ESMTP 
> and the ONEX command. As I said I do not know if it is the same now but 
> IMHO it has not changed since then.

Reading the source code, I do not see an additional fork() after MAIL FROM.
Could you show me where it happens?

I also traced an instance of Sendmail and did not see a fork after MAIL.
It only forked after the final "." because of the "background" delivery
mode.

Regards,

David.
Permalink | Reply | 1 comment |
headers
vs-ml | 3 Mar 2008 19:31
Picon

Re: When the fork happens [Re: Testing for port #/TLS in filter_relay]

3. 3. 2008 napsal(a) David F. Skoll na téma ,Re: When the fork happens [Re:...:

> Vladimír Solnický wrote:
>
>> IMHO there were two forks in sendmail, one as you say after accepting the 
>> connection and the second in the MAIL FROM stage (I looked at it four years 
>> ago, thus the past tense; I do not know the current situation). The second 
>> fork could be avoided if the client used ESMTP and the ONEX command. As I 
>> said I do not know if it is the same now but IMHO it has not changed since 
>> then.
>
> Reading the source code, I do not see an additional fork() after MAIL FROM.
> Could you show me where it happens?

No, I did not see it in the source code, I made observations on amount of 
sendmail processes (and their status lines in ps) in an unsed e-mail 
environment.

> I also traced an instance of Sendmail and did not see a fork after MAIL.
> It only forked after the final "." because of the "background" delivery
> mode.

Then I think they moved the fork to a much more logical place (as this is 
the time you need the fork, not before, and till this point the message 
can be refused--content analysis, oversize, etc.--making the fork a waste 
of resources).

Sorry for not checking if the old observation still applies with the more 
recent versions of sendmail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philip Prindeville | 4 Mar 2008 03:04

Re: Testing for port #/TLS in filter_relay

David F. Skoll wrote:
> Philip Prindeville wrote:
>
>> By the time that MAIL FROM: is seen, fork()'s have happened, etc.
>
> ???
>
> The fork() happens right after the connection is accepted, even before
> filter_relay.

Okay, I'll try to explain this in a different way.

I have a fairly low default Client connection rate specified on my mail 
server, because it also does other work (NFS, web service, CUPS 
spooling, FTP server, etc).

If I have to wait until I see the MAIL FROM, then that's a connection 
that is held open potentially for as long as my read-timeout is 
(currently 15 minutes), and someone could DoS attack me by sending me a 
bunch of connections but never advancing the state on them.

If, on the other hand, I drop the connection as soon as it arrives, then 
the window by which they could deny other clients from delivering mail 
is severely restricted to the RTT's of the attacker's connection times 3 
or four.  Clearly, that's better than 15 minutes.

-Philip
Permalink | Reply | 4 comments |

Gmane