You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by David Nelson <ja...@david-nelson.com> on 2004/05/22 04:50:26 UTC

AttachmentFileNameIs or Matcher in general param size limit?

Hello,

I have a list of approx. 60 dangerous email attachment file extensions (i.e.
*.exe, *.cmd, *.scr).  I tried using the AttachmentFileNameIs matcher to bounce
the messages back to the sender.  If I put all 60 in one Matcher declaration,
nothing gets filtered - all of the mail comes through.  I ended up breaking it
up into 6 mailets with 10 extensions each and everything works fine.  

Did I discover a bug?  Is there a limit on the param length for Matchers?   

Please note there was nothing magical about my decision to go with 10 on each
Matcher declaration other than my finding that 1 worked and 60 didn't.  I was
short on time and figured 10 was a conservative number.  This is JAMES 2.2.0RC3
running on RedHat 7.3.

Thanks!
David N.

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by "Noel J. Bergman" <no...@devtech.com>.
> You guys mind if I ask what you mean by an in-protocol processor?

Look in the archives for discussion of "SMTP ACL."

	--- Noel

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by David Nelson <ja...@david-nelson.com>.
You guys mind if I ask what you mean by an in-protocol processor?  


Quoting Vincenzo Gianferrari Pini <vi...@praxis.it>:

> My approach is the following:
> 
> I have my antivirus on the server (McAfee) updated every day at about 7 PM
> Pacific time (4 AM my time), to let the AV manufacturer insert any last
> minute update. 
> 
> For every incoming mail:
> 1. Do an anti- virus check.
> 2. If a virus is found the email is ghosted without a bounce for the reasons
> you said.
> 3. If no virus is found, do the attachment check as a "second line" defense.
> 4. If a "dangerous" attachment is found, bounce with no attachment and a very
> clear message asking the sender to rename the attachments by hand, and
> ghost.
> 5. If no dangerous attachment is found, deliver.
> 
> This way, I risk to bounce to a spoofed MAIL FROM only in the rare case that
> the email is infected by a virus *so new* that my antivirus has not yet been
> updated, and the window is less than 24 hours.
> 
> A problem occurs with .zip attachments. Before the arrival of the Netsky
> virus in February, I was simply accepting zip attachments, but as the
> "success" of this virus comes from sending zip attachments containing
> infected executables I decided to block all zips, bouncing a notification to
> the sender, storing them in a special repository and notifying the recipient
> about what has happened. But many users did complain, so I had to add a
> special zip management for special users that asked to receive such messages
> in any case, forwarding them the original message as an attachment to a
> special "frightening" notification.
> A much better behaviour for zips would be to check if there are executables
> *inside* the zip and behave like in step 3 above. This requires a smarter
> AttachmentFileNameIs behaviour.
> 
> I plan to build some kind of  "integrated SecurityCheck" mailet that does
> (optionally) the antivirus check and the attachment check and an attachment
> check inside any zip all in one time, offloading the attachments only once to
> disk. The result will be a "severity code" in a message attribute that will
> be checked later on by one or more HasMailAttributeWithValue entries (or a
> new CompareNumericAttributeValue matcher). Another advantage of this approach
> would be that a mailet is much easier to parameterize than a matcher.
> 
> What do you think?
> 
> An in-protocol processor would also be great, and not in conflict with what
> said above.
> 
> Vincenzo
> 
> > -----Original Message-----
> > From: Noel J. Bergman [mailto:noel@devtech.com]
> > Sent: domenica 23 maggio 2004 2.37
> > To: James Users List
> > Subject: RE: AttachmentFileNameIs or Matcher in general param size
> > limit?
> > 
> > 
> > FYI, the newly current trend is to NOT issue an anti-virus bounce.  Far
> too
> > high a percentage of spoofed MAIL FROM addresses.  However, in the case of
> > legitimate content being blocked by filename, you would fail to deliver
> and
> > fail to notify.  I find that troubling (and probably interpretable as an
> RFC
> > violation).  The addition of in-protocol processors should allow rejection
> > to the sending without the problem of bouncing to spoofed senders.
> > 
> > 	--- Noel
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-user-help@james.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
> 
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by David Nelson <ja...@david-nelson.com>.
Quoting Vincenzo Gianferrari Pini <vi...@praxis.it>:

> My approach is the following:
> 
> I have my antivirus on the server (McAfee) updated every day at about 7 PM
> Pacific time (4 AM my time), to let the AV manufacturer insert any last
> minute update. 
> 
> For every incoming mail:
> 1. Do an anti- virus check.
> 2. If a virus is found the email is ghosted without a bounce for the reasons
> you said.
> 3. If no virus is found, do the attachment check as a "second line" defense.
> 4. If a "dangerous" attachment is found, bounce with no attachment and a very
> clear message asking the sender to rename the attachments by hand, and
> ghost.
> 5. If no dangerous attachment is found, deliver.
> 
> This way, I risk to bounce to a spoofed MAIL FROM only in the rare case that
> the email is infected by a virus *so new* that my antivirus has not yet been
> updated, and the window is less than 24 hours.
> 
> A problem occurs with .zip attachments. Before the arrival of the Netsky
> virus in February, I was simply accepting zip attachments, but as the
> "success" of this virus comes from sending zip attachments containing
> infected executables I decided to block all zips, bouncing a notification to
> the sender, storing them in a special repository and notifying the recipient
> about what has happened. But many users did complain, so I had to add a
> special zip management for special users that asked to receive such messages
> in any case, forwarding them the original message as an attachment to a
> special "frightening" notification.
> A much better behaviour for zips would be to check if there are executables
> *inside* the zip and behave like in step 3 above. This requires a smarter
> AttachmentFileNameIs behaviour.
> 
> I plan to build some kind of  "integrated SecurityCheck" mailet that does
> (optionally) the antivirus check and the attachment check and an attachment
> check inside any zip all in one time, offloading the attachments only once to
> disk. The result will be a "severity code" in a message attribute that will
> be checked later on by one or more HasMailAttributeWithValue entries (or a
> new CompareNumericAttributeValue matcher). Another advantage of this approach
> would be that a mailet is much easier to parameterize than a matcher.
> 
> What do you think?
> 
> An in-protocol processor would also be great, and not in conflict with what
> said above.
> 
> Vincenzo
> 
> > -----Original Message-----
> > From: Noel J. Bergman [mailto:noel@devtech.com]
> > Sent: domenica 23 maggio 2004 2.37
> > To: James Users List
> > Subject: RE: AttachmentFileNameIs or Matcher in general param size
> > limit?
> > 
> > 
> > FYI, the newly current trend is to NOT issue an anti-virus bounce.  Far
> too
> > high a percentage of spoofed MAIL FROM addresses.  However, in the case of
> > legitimate content being blocked by filename, you would fail to deliver
> and
> > fail to notify.  I find that troubling (and probably interpretable as an
> RFC
> > violation).  The addition of in-protocol processors should allow rejection
> > to the sending without the problem of bouncing to spoofed senders.
> > 
> > 	--- Noel
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-user-help@james.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
> 
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


Re: AttachmentFileNameIs or Matcher in general param size limit?

Posted by Lane Sharman <la...@opendoors.com>.
Most email administrators prefer to blackhole viruses and known spam 
because of the high cost of intervention, inspection and the low-return 
of value about the source of same.

-Lane

Serge Knystautas wrote:

> Vincenzo Gianferrari Pini wrote:
>
>> 2. If a virus is found the email is ghosted without a bounce for the 
>> reasons you said.
>
>
> I've created a separate address to send bounces for mesages like this 
> (e.g., bounce-admin@lokitech.com instead of postmaster@lokitech.com). 
> Also, I was thinking that these bounces in the first place could be 
> put in a separate remote delivery spool that are retried fewer times.  
> Any idas on how to make this easier to do is appreciated.
>

-- 
Lane Sharman
Providing Private and SPAM-Free Email
http://www.opendoors.com
858-755-2868




---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


Re: AttachmentFileNameIs or Matcher in general param size limit?

Posted by Serge Knystautas <se...@lokitech.com>.
Vincenzo Gianferrari Pini wrote:
>>Vincenzo Gianferrari Pini wrote:
>>
>>>2. If a virus is found the email is ghosted without a bounce for the reasons you said.
>>
>>I've created a separate address to send bounces for mesages like this 
>>(e.g., bounce-admin@lokitech.com instead of postmaster@lokitech.com). 
>>Also, I was thinking that these bounces in the first place could be put 
>>in a separate remote delivery spool that are retried fewer times.  Any 
>>idas on how to make this easier to do is appreciated.
> 
> Why are you bouncing back? The only reason would be (as we all were doing in the past) to politely notify an innocent original sender that he is infected, but nowadays the sender address is almost always randomly fake, so I would be just adding traffic and confusion to the Internet. In fact some percentage of the infected messages received by my production server consists of bounces made by antivirus running on other MTAs, and many messages are similar bounces not infected because the bounce stripped the infected attachment.

Yes, although this was meant as a general bounce strategy so would 
include "invalid account" and other such bounce conditions.

> Moreover, many MTAs do not follow the rules when they receive a "NULL RETURN-PATH" (<>): so, suppose that you receive an infected message from fakeuser@realdomain.com; if you bounce back to him, you may in many cases receive a second bounce from postmaster@realdomain.com saying that fakeuser is unknown, adding confusion to confusion.

Right, that's why I use the bounce-admin@lokitech.com when sending <>, 
so then I can automatically bit-bucket anything to there.

> The current trend, as Noel said, is to ghost those infected emails, risking in a very few cases to not help someone that is infected :-(

Agreed, although I would really prefer to have throttling, so the first 
time an IP address or sending address does something, I notify them, and 
THEN stop giving them notices (and eventually just block them altogether).

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Serge,

> Vincenzo Gianferrari Pini wrote:
> > 2. If a virus is found the email is ghosted without a bounce for the reasons you said.
> 
> I've created a separate address to send bounces for mesages like this 
> (e.g., bounce-admin@lokitech.com instead of postmaster@lokitech.com). 
> Also, I was thinking that these bounces in the first place could be put 
> in a separate remote delivery spool that are retried fewer times.  Any 
> idas on how to make this easier to do is appreciated.

Why are you bouncing back? The only reason would be (as we all were doing in the past) to politely notify an innocent original sender that he is infected, but nowadays the sender address is almost always randomly fake, so I would be just adding traffic and confusion to the Internet. In fact some percentage of the infected messages received by my production server consists of bounces made by antivirus running on other MTAs, and many messages are similar bounces not infected because the bounce stripped the infected attachment.

Moreover, many MTAs do not follow the rules when they receive a "NULL RETURN-PATH" (<>): so, suppose that you receive an infected message from fakeuser@realdomain.com; if you bounce back to him, you may in many cases receive a second bounce from postmaster@realdomain.com saying that fakeuser is unknown, adding confusion to confusion.

The current trend, as Noel said, is to ghost those infected emails, risking in a very few cases to not help someone that is infected :-(

Vincenzo


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


Re: AttachmentFileNameIs or Matcher in general param size limit?

Posted by Serge Knystautas <se...@lokitech.com>.
Vincenzo Gianferrari Pini wrote:
> 2. If a virus is found the email is ghosted without a bounce for the reasons you said.

I've created a separate address to send bounces for mesages like this 
(e.g., bounce-admin@lokitech.com instead of postmaster@lokitech.com). 
Also, I was thinking that these bounces in the first place could be put 
in a separate remote delivery spool that are retried fewer times.  Any 
idas on how to make this easier to do is appreciated.

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Noel,

> Your approach seems reasonable because you're not bouncing most virii, you
> are trying to just bounce potentially legitimate attachments to let the
> sender know that they aren't permitted to send them.
> 
> I'm wondering if one could consider accepting such attachments if the
> message is signed.  Check for a trusted CA (exclude self-signed) or defer
> that to the MUA.
> 
> Personally, I would not accept it, signed or not, if I weren't expecting
> such an e-mail from a trusted person.  Depending on their security settings,
> a new worm might be able to use their key if it infected their client
> system.  I would not accept an executable unless I had prior expectation of
> a specific message (and I have a *very* short list from whom I would accept
> a binary).
I totally agree with you, I block those attachments and will never accept them, legitimate or not, unless I am somehow expecting them from people I trust (in the appropriate sense). But obviously I have to notify the sender of it. But as at that point I have already filtered out 99.9% or more of the viruses with the antivirus, the probability that I'm bouncing back to a fake MAIL FROM, increasing traffic and confusion, is very low.

> 
> Generically speaking, it might be interesting if I could give someone an "I
> am expecting this message"-token that they could use to send a message that
> would otherwise be filtered.
If the sender sends the binary attachment renamed, changing the extension to something that is explicitely described in the main text of the message, explaining *as a human being that I personally recognize* what it is all about, and the sender is one of the few ones I trust and can expect to receive a binary in that time and context, then I accept the attachment *manually*. Here the rename recognizable as *not automatic" is crucial for me. My bounce messages are lengthy and try to explain everything to the sender and suggest this manual approach.

Vincenzo


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by "Noel J. Bergman" <no...@devtech.com>.
Vincenzo,

Your approach seems reasonable because you're not bouncing most virii, you
are trying to just bounce potentially legitimate attachments to let the
sender know that they aren't permitted to send them.

I'm wondering if one could consider accepting such attachments if the
message is signed.  Check for a trusted CA (exclude self-signed) or defer
that to the MUA.

Personally, I would not accept it, signed or not, if I weren't expecting
such an e-mail from a trusted person.  Depending on their security settings,
a new worm might be able to use their key if it infected their client
system.  I would not accept an executable unless I had prior expectation of
a specific message (and I have a *very* short list from whom I would accept
a binary).

Generically speaking, it might be interesting if I could give someone an "I
am expecting this message"-token that they could use to send a message that
would otherwise be filtered.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
My approach is the following:

I have my antivirus on the server (McAfee) updated every day at about 7 PM Pacific time (4 AM my time), to let the AV manufacturer insert any last minute update. 

For every incoming mail:
1. Do an anti- virus check.
2. If a virus is found the email is ghosted without a bounce for the reasons you said.
3. If no virus is found, do the attachment check as a "second line" defense.
4. If a "dangerous" attachment is found, bounce with no attachment and a very clear message asking the sender to rename the attachments by hand, and ghost.
5. If no dangerous attachment is found, deliver.

This way, I risk to bounce to a spoofed MAIL FROM only in the rare case that the email is infected by a virus *so new* that my antivirus has not yet been updated, and the window is less than 24 hours.

A problem occurs with .zip attachments. Before the arrival of the Netsky virus in February, I was simply accepting zip attachments, but as the "success" of this virus comes from sending zip attachments containing infected executables I decided to block all zips, bouncing a notification to the sender, storing them in a special repository and notifying the recipient about what has happened. But many users did complain, so I had to add a special zip management for special users that asked to receive such messages in any case, forwarding them the original message as an attachment to a special "frightening" notification.
A much better behaviour for zips would be to check if there are executables *inside* the zip and behave like in step 3 above. This requires a smarter AttachmentFileNameIs behaviour.

I plan to build some kind of  "integrated SecurityCheck" mailet that does (optionally) the antivirus check and the attachment check and an attachment check inside any zip all in one time, offloading the attachments only once to disk. The result will be a "severity code" in a message attribute that will be checked later on by one or more HasMailAttributeWithValue entries (or a new CompareNumericAttributeValue matcher). Another advantage of this approach would be that a mailet is much easier to parameterize than a matcher.

What do you think?

An in-protocol processor would also be great, and not in conflict with what said above.

Vincenzo

> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: domenica 23 maggio 2004 2.37
> To: James Users List
> Subject: RE: AttachmentFileNameIs or Matcher in general param size
> limit?
> 
> 
> FYI, the newly current trend is to NOT issue an anti-virus bounce.  Far too
> high a percentage of spoofed MAIL FROM addresses.  However, in the case of
> legitimate content being blocked by filename, you would fail to deliver and
> fail to notify.  I find that troubling (and probably interpretable as an RFC
> violation).  The addition of in-protocol processors should allow rejection
> to the sending without the problem of bouncing to spoofed senders.
> 
> 	--- Noel
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by "Noel J. Bergman" <no...@devtech.com>.
FYI, the newly current trend is to NOT issue an anti-virus bounce.  Far too
high a percentage of spoofed MAIL FROM addresses.  However, in the case of
legitimate content being blocked by filename, you would fail to deliver and
fail to notify.  I find that troubling (and probably interpretable as an RFC
violation).  The addition of in-protocol processors should allow rejection
to the sending without the problem of bouncing to spoofed senders.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by David Nelson <ja...@david-nelson.com>.
I thought it was... I did just paste in the line directly from your email and it
works fine now.  I must have had something out of whack.

Boy do I feel silly....  sorry about that!

Thanks for your help!
David

Quoting Vincenzo Gianferrari Pini <vi...@praxis.it>:

> I've tried with your list using (RC3), and the matcher did work for me:
> 
> <mailet
>
match="AttachmentFileNameIs=*.htm,*.html,*.exe,*.com,*.cmd,*.bat,*.pif,*.scr,*.sct,*.lnk,*.dll,*.ocx,*.doc,*.dot,*.xls,*.xlw,*.xlt,*.ppt,*.pot,*.rtf,*.vb,*.vbs,*.vbe,*.hta,*.pl,*.pm,*.shb,*.shs,*.hlp,*.chm,*.eml,*.wsc,*.wsf,*.wsh,*.ade,*.adp,*.js,*.jse,*.mda,*.mdb,*.mde,*.mdw,*.msi,*.msp,*.reg,*.asd,*.asf,*.asx,*.cil,*.cpl,*.pps,*.wma,*.wmv,*.wms,*.wmz,*.wmd,*.vcf,*.nws,*.wsz,*.url,*},*.dat"
> class="Bounce" onMatchException="noMatch">
> 
> Are you sure that your list was really like that?
> 
> Vincenzo
> 
> > -----Original Message-----
> > From: David Nelson [mailto:james.rocks@david-nelson.com]
> > Sent: sabato 22 maggio 2004 14.52
> > To: James Users List
> > Subject: RE: AttachmentFileNameIs or Matcher in general param size
> > limit?
> > 
> > 
> > Here's mine....  I realize it's a little "extreme" right now.  I may trim
> it
> > down some in the future.  The *} is not a typo but an attempt to block a
> "CLSID
> > exploit".
> > 
> > I know it's off topic for the current thread, but since I'm writing you...
> If I
> > upgrade to RC4, can I use the same config.xml I currently have for RC3?
> > 
> > Regards,
> > David
> > 
> > <mailet
> >
>
match="AttachmentFileNameIs=*.htm,*.html,*.exe,*.com,*.cmd,*.bat,*.pif,*.scr,*.sct,*.lnk"
> > onMatchException="noMatch" class="Bounce">
> >  <notice>550 Mail apparently from your email address contained an unsafe
> > attachment, mail rejected.  Please note that if you did not send this mail,
> then
> > someone (a VIRUS perhaps which may or may not be on YOUR computer) is
> pretending
> > to be you and forging mail with your email address.</notice>
> >  <attachment>none</attachment>
> >  <prefix>[REJECTED] </prefix>
> >  <passThrough>false</passThrough>
> > </mailet>
> >  
> > <mailet
> >
>
match="AttachmentFileNameIs=*.dll,*.ocx,*.doc,*.dot,*.xls,*.xlw,*.xlt,*.ppt,*.pot,*.rtf"
> > onMatchException="noMatch" class="Bounce">
> >  <notice>550 Mail apparently from your email address contained an unsafe
> > attachment, mail rejected.  Please note that if you did not send this mail,
> then
> > someone (a VIRUS perhaps which may or may not be on YOUR computer) is
> pretending
> > to be you and forging mail with your email address.</notice>
> >  <attachment>none</attachment>
> >  <prefix>[REJECTED] </prefix>
> >  <passThrough>false</passThrough>
> > </mailet>
> >  
> > <mailet
> >
>
match="AttachmentFileNameIs=*.vb,*.vbs,*.vbe,*.hta,*.pl,*.pm,*.shb,*.shs,*.hlp,*.chm"
> > onMatchException="noMatch" class="Bounce">
> >  <notice>550 Mail apparently from your email address contained an unsafe
> > attachment, mail rejected.  Please note that if you did not send this mail,
> then
> > someone (a VIRUS perhaps which may or may not be on YOUR computer) is
> pretending
> > to be you and forging mail with your email address.</notice>
> >  <attachment>none</attachment>
> >  <prefix>[REJECTED] </prefix>
> >  <passThrough>false</passThrough>
> > </mailet>
> >  
> > <mailet
> >
>
match="AttachmentFileNameIs=*.eml,*.wsc,*.wsf,*.wsh,*.ade,*.adp,*.js,*.jse,*.mda,*.mdb"
> > onMatchException="noMatch" class="Bounce">
> >  <notice>550 Mail apparently from your email address contained an unsafe
> > attachment, mail rejected.  Please note that if you did not send this mail,
> then
> > someone (a VIRUS perhaps which may or may not be on YOUR computer) is
> pretending
> > to be you and forging mail with your email address.</notice>
> >  <attachment>none</attachment>
> >  <prefix>[REJECTED] </prefix>
> >  <passThrough>false</passThrough>
> > </mailet>
> >  
> > <mailet
> >
>
match="AttachmentFileNameIs=*.mde,*.mdw,*.msi,*.msp,*.reg,*.asd,*.asf,*.asx,*.cil,*.cpl"
> > onMatchException="noMatch" class="Bounce">
> >  <notice>550 Mail apparently from your email address contained an unsafe
> > attachment, mail rejected.  Please note that if you did not send this mail,
> then
> > someone (a VIRUS perhaps which may or may not be on YOUR computer) is
> pretending
> > to be you and forging mail with your email address.</notice>
> >  <attachment>none</attachment>
> >  <prefix>[REJECTED] </prefix>
> >  <passThrough>false</passThrough>
> > </mailet>
> >  
> > <mailet
> >
>
match="AttachmentFileNameIs=*.pps,*.wma,*.wmv,*.wms,*.wmz,*.wmd,*.vcf,*.nws,*.wsz,*.url,*},*.dat"
> > onMatchException="noMatch" class="Bounce">
> >  <notice>550 Mail apparently from your email address contained an unsafe
> > attachment, mail rejected.  Please note that if you did not send this mail,
> then
> > someone (a VIRUS perhaps which may or may not be on YOUR computer) is
> pretending
> > to be you and forging mail with your email address.</notice>
> >  <attachment>none</attachment>
> >  <prefix>[REJECTED] </prefix>
> >  <passThrough>false</passThrough>
> > </mailet>
> >  
> >  
> > 
> > Quoting "Noel J. Bergman" <no...@devtech.com>:
> > 
> > > David,
> > > 
> > > I'd like to see your list.  Mine is:
> > > 
> > >   <mailet
> > >
> match="AttachmentFileNameIs=*.bat,*.com,*.dll,*.exe,*.lnk,*.pif,*.scr,*.vbe,
> > > *.vbs,*.wsh"
> > >           onMatchException="noMatch" class="Bounce">
> > >     <notice>550 Rejected - Banned type of attachment.  Please contact
> > > intended recipient.</notice>
> > >     <attachment>none</attachment>
> > >     <passThrough>false</passThrough>
> > >   </mailet>
> > > 
> > > Coincidentally, that is 10.  I'm not aware of a limitation, but you
> could
> > > modify the init() method to log the parameter and setup, just to check.
> > > 
> > > 	--- Noel
> > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> > > For additional commands, e-mail: server-user-help@james.apache.org
> > > 
> > > 
> > 
> > 
> > 
> > 
> > -------------------------------------------------
> > This mail sent through IMP: http://horde.org/imp/
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-user-help@james.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
> 
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
I've tried with your list using (RC3), and the matcher did work for me:

<mailet match="AttachmentFileNameIs=*.htm,*.html,*.exe,*.com,*.cmd,*.bat,*.pif,*.scr,*.sct,*.lnk,*.dll,*.ocx,*.doc,*.dot,*.xls,*.xlw,*.xlt,*.ppt,*.pot,*.rtf,*.vb,*.vbs,*.vbe,*.hta,*.pl,*.pm,*.shb,*.shs,*.hlp,*.chm,*.eml,*.wsc,*.wsf,*.wsh,*.ade,*.adp,*.js,*.jse,*.mda,*.mdb,*.mde,*.mdw,*.msi,*.msp,*.reg,*.asd,*.asf,*.asx,*.cil,*.cpl,*.pps,*.wma,*.wmv,*.wms,*.wmz,*.wmd,*.vcf,*.nws,*.wsz,*.url,*},*.dat" class="Bounce" onMatchException="noMatch">

Are you sure that your list was really like that?

Vincenzo

> -----Original Message-----
> From: David Nelson [mailto:james.rocks@david-nelson.com]
> Sent: sabato 22 maggio 2004 14.52
> To: James Users List
> Subject: RE: AttachmentFileNameIs or Matcher in general param size
> limit?
> 
> 
> Here's mine....  I realize it's a little "extreme" right now.  I may trim it
> down some in the future.  The *} is not a typo but an attempt to block a "CLSID
> exploit".
> 
> I know it's off topic for the current thread, but since I'm writing you... If I
> upgrade to RC4, can I use the same config.xml I currently have for RC3?
> 
> Regards,
> David
> 
> <mailet
> match="AttachmentFileNameIs=*.htm,*.html,*.exe,*.com,*.cmd,*.bat,*.pif,*.scr,*.sct,*.lnk"
> onMatchException="noMatch" class="Bounce">
>  <notice>550 Mail apparently from your email address contained an unsafe
> attachment, mail rejected.  Please note that if you did not send this mail, then
> someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
> to be you and forging mail with your email address.</notice>
>  <attachment>none</attachment>
>  <prefix>[REJECTED] </prefix>
>  <passThrough>false</passThrough>
> </mailet>
>  
> <mailet
> match="AttachmentFileNameIs=*.dll,*.ocx,*.doc,*.dot,*.xls,*.xlw,*.xlt,*.ppt,*.pot,*.rtf"
> onMatchException="noMatch" class="Bounce">
>  <notice>550 Mail apparently from your email address contained an unsafe
> attachment, mail rejected.  Please note that if you did not send this mail, then
> someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
> to be you and forging mail with your email address.</notice>
>  <attachment>none</attachment>
>  <prefix>[REJECTED] </prefix>
>  <passThrough>false</passThrough>
> </mailet>
>  
> <mailet
> match="AttachmentFileNameIs=*.vb,*.vbs,*.vbe,*.hta,*.pl,*.pm,*.shb,*.shs,*.hlp,*.chm"
> onMatchException="noMatch" class="Bounce">
>  <notice>550 Mail apparently from your email address contained an unsafe
> attachment, mail rejected.  Please note that if you did not send this mail, then
> someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
> to be you and forging mail with your email address.</notice>
>  <attachment>none</attachment>
>  <prefix>[REJECTED] </prefix>
>  <passThrough>false</passThrough>
> </mailet>
>  
> <mailet
> match="AttachmentFileNameIs=*.eml,*.wsc,*.wsf,*.wsh,*.ade,*.adp,*.js,*.jse,*.mda,*.mdb"
> onMatchException="noMatch" class="Bounce">
>  <notice>550 Mail apparently from your email address contained an unsafe
> attachment, mail rejected.  Please note that if you did not send this mail, then
> someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
> to be you and forging mail with your email address.</notice>
>  <attachment>none</attachment>
>  <prefix>[REJECTED] </prefix>
>  <passThrough>false</passThrough>
> </mailet>
>  
> <mailet
> match="AttachmentFileNameIs=*.mde,*.mdw,*.msi,*.msp,*.reg,*.asd,*.asf,*.asx,*.cil,*.cpl"
> onMatchException="noMatch" class="Bounce">
>  <notice>550 Mail apparently from your email address contained an unsafe
> attachment, mail rejected.  Please note that if you did not send this mail, then
> someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
> to be you and forging mail with your email address.</notice>
>  <attachment>none</attachment>
>  <prefix>[REJECTED] </prefix>
>  <passThrough>false</passThrough>
> </mailet>
>  
> <mailet
> match="AttachmentFileNameIs=*.pps,*.wma,*.wmv,*.wms,*.wmz,*.wmd,*.vcf,*.nws,*.wsz,*.url,*},*.dat"
> onMatchException="noMatch" class="Bounce">
>  <notice>550 Mail apparently from your email address contained an unsafe
> attachment, mail rejected.  Please note that if you did not send this mail, then
> someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
> to be you and forging mail with your email address.</notice>
>  <attachment>none</attachment>
>  <prefix>[REJECTED] </prefix>
>  <passThrough>false</passThrough>
> </mailet>
>  
>  
> 
> Quoting "Noel J. Bergman" <no...@devtech.com>:
> 
> > David,
> > 
> > I'd like to see your list.  Mine is:
> > 
> >   <mailet
> > match="AttachmentFileNameIs=*.bat,*.com,*.dll,*.exe,*.lnk,*.pif,*.scr,*.vbe,
> > *.vbs,*.wsh"
> >           onMatchException="noMatch" class="Bounce">
> >     <notice>550 Rejected - Banned type of attachment.  Please contact
> > intended recipient.</notice>
> >     <attachment>none</attachment>
> >     <passThrough>false</passThrough>
> >   </mailet>
> > 
> > Coincidentally, that is 10.  I'm not aware of a limitation, but you could
> > modify the init() method to log the parameter and setup, just to check.
> > 
> > 	--- Noel
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-user-help@james.apache.org
> > 
> > 
> 
> 
> 
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by David Nelson <ja...@david-nelson.com>.
Here's mine....  I realize it's a little "extreme" right now.  I may trim it
down some in the future.  The *} is not a typo but an attempt to block a "CLSID
exploit".

I know it's off topic for the current thread, but since I'm writing you... If I
upgrade to RC4, can I use the same config.xml I currently have for RC3?

Regards,
David

<mailet
match="AttachmentFileNameIs=*.htm,*.html,*.exe,*.com,*.cmd,*.bat,*.pif,*.scr,*.sct,*.lnk"
onMatchException="noMatch" class="Bounce">
 <notice>550 Mail apparently from your email address contained an unsafe
attachment, mail rejected.  Please note that if you did not send this mail, then
someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
to be you and forging mail with your email address.</notice>
 <attachment>none</attachment>
 <prefix>[REJECTED] </prefix>
 <passThrough>false</passThrough>
</mailet>
 
<mailet
match="AttachmentFileNameIs=*.dll,*.ocx,*.doc,*.dot,*.xls,*.xlw,*.xlt,*.ppt,*.pot,*.rtf"
onMatchException="noMatch" class="Bounce">
 <notice>550 Mail apparently from your email address contained an unsafe
attachment, mail rejected.  Please note that if you did not send this mail, then
someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
to be you and forging mail with your email address.</notice>
 <attachment>none</attachment>
 <prefix>[REJECTED] </prefix>
 <passThrough>false</passThrough>
</mailet>
 
<mailet
match="AttachmentFileNameIs=*.vb,*.vbs,*.vbe,*.hta,*.pl,*.pm,*.shb,*.shs,*.hlp,*.chm"
onMatchException="noMatch" class="Bounce">
 <notice>550 Mail apparently from your email address contained an unsafe
attachment, mail rejected.  Please note that if you did not send this mail, then
someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
to be you and forging mail with your email address.</notice>
 <attachment>none</attachment>
 <prefix>[REJECTED] </prefix>
 <passThrough>false</passThrough>
</mailet>
 
<mailet
match="AttachmentFileNameIs=*.eml,*.wsc,*.wsf,*.wsh,*.ade,*.adp,*.js,*.jse,*.mda,*.mdb"
onMatchException="noMatch" class="Bounce">
 <notice>550 Mail apparently from your email address contained an unsafe
attachment, mail rejected.  Please note that if you did not send this mail, then
someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
to be you and forging mail with your email address.</notice>
 <attachment>none</attachment>
 <prefix>[REJECTED] </prefix>
 <passThrough>false</passThrough>
</mailet>
 
<mailet
match="AttachmentFileNameIs=*.mde,*.mdw,*.msi,*.msp,*.reg,*.asd,*.asf,*.asx,*.cil,*.cpl"
onMatchException="noMatch" class="Bounce">
 <notice>550 Mail apparently from your email address contained an unsafe
attachment, mail rejected.  Please note that if you did not send this mail, then
someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
to be you and forging mail with your email address.</notice>
 <attachment>none</attachment>
 <prefix>[REJECTED] </prefix>
 <passThrough>false</passThrough>
</mailet>
 
<mailet
match="AttachmentFileNameIs=*.pps,*.wma,*.wmv,*.wms,*.wmz,*.wmd,*.vcf,*.nws,*.wsz,*.url,*},*.dat"
onMatchException="noMatch" class="Bounce">
 <notice>550 Mail apparently from your email address contained an unsafe
attachment, mail rejected.  Please note that if you did not send this mail, then
someone (a VIRUS perhaps which may or may not be on YOUR computer) is pretending
to be you and forging mail with your email address.</notice>
 <attachment>none</attachment>
 <prefix>[REJECTED] </prefix>
 <passThrough>false</passThrough>
</mailet>
 
 

Quoting "Noel J. Bergman" <no...@devtech.com>:

> David,
> 
> I'd like to see your list.  Mine is:
> 
>   <mailet
> match="AttachmentFileNameIs=*.bat,*.com,*.dll,*.exe,*.lnk,*.pif,*.scr,*.vbe,
> *.vbs,*.wsh"
>           onMatchException="noMatch" class="Bounce">
>     <notice>550 Rejected - Banned type of attachment.  Please contact
> intended recipient.</notice>
>     <attachment>none</attachment>
>     <passThrough>false</passThrough>
>   </mailet>
> 
> Coincidentally, that is 10.  I'm not aware of a limitation, but you could
> modify the init() method to log the parameter and setup, just to check.
> 
> 	--- Noel
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
> 
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


RE: AttachmentFileNameIs or Matcher in general param size limit?

Posted by "Noel J. Bergman" <no...@devtech.com>.
David,

I'd like to see your list.  Mine is:

  <mailet
match="AttachmentFileNameIs=*.bat,*.com,*.dll,*.exe,*.lnk,*.pif,*.scr,*.vbe,
*.vbs,*.wsh"
          onMatchException="noMatch" class="Bounce">
    <notice>550 Rejected - Banned type of attachment.  Please contact
intended recipient.</notice>
    <attachment>none</attachment>
    <passThrough>false</passThrough>
  </mailet>

Coincidentally, that is 10.  I'm not aware of a limitation, but you could
modify the init() method to log the parameter and setup, just to check.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org