Re: Attachment policy
> Those sound like perfectly legitimate emails so working to classify them > as decent emails would be our goal. Was there anything malicious snuck in > there? > No, they were all just very basic PDF documents, mostly from gmail accounts, but also from another dozen or different providers. Some looked to be pasted from Google Translate from their native language to English, and a few were in languages other than English. Some were tagged because of the DKIM/DMARC bug, lol. Okay, I'll train them as ham and hope it can later discern these from malicious emails with PDF attachments. Please keep us updated on the progress of the ExtractText plugin. Thanks, Alex
Re: Attachment policy
On 6/27/22 2:50 PM, Alex wrote: Hi, Hi, I'm looking for input from people on how they handle attachments, and people using email as a file transfer service. My opinion is that you shouldn't rely on using email as a file transfer service until /after/ you've tested that it works. One of our users must have posted to a job site recently, soliciting resumes from people internationally. This resulted in 100+ emails from random people who had never emailed this user before, many of which had no subject and no body, just a PDF attachment. Some had the "Sent by my iPhone" signatures, but that's about it. Virtually all of them were tagged as spam due to bayes. >wince< Any recommendations? There wasn't otherwise anything wrong with the attachments - they were all legitimate resumes from legitimate sources. *nod* Should they be blocked? I don't think so. By your own description, these seem like perfectly legitimate email. Admittedly the content was a little questionably formatted. Should I retrain bayes to not consider these spam? I'm now training bayes with them as ham, but it will take a lot to offset these. Same with emails that only contain images. I don't know what the /technical/ solution to this particular use case is. However these messages /sound/ legitimate to me. Should an email with only an image attachment with no subject and no body but sent from a legitimate source and otherwise not dangerous be considered spam? These don't sound like spam to me. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Attachment policy
Those sound like perfectly legitimate emails so working to classify them as decent emails would be our goal. Was there anything malicious snuck in there? We are using extract text and have been making improvements to it. False positives especially with the beneficiary and financial rules is something to be noted and worked on as well. HTH, KAM On Mon, Jun 27, 2022, 16:50 Alex wrote: > Hi, > I'm looking for input from people on how they handle attachments, and > people using email as a file transfer service. One of our users must have > posted to a job site recently, soliciting resumes from people > internationally. This resulted in 100+ emails from random people who had > never emailed this user before, many of which had no subject and no body, > just a PDF attachment. Some had the "Sent by my iPhone" signatures, but > that's about it. Virtually all of them were tagged as spam due to bayes. > > Any recommendations? There wasn't otherwise anything wrong with the > attachments - they were all legitimate resumes from legitimate sources. > Should they be blocked? Should I retrain bayes to not consider these spam? > I'm now training bayes with them as ham, but it will take a lot to > offset these. Same with emails that only contain images. Should an email > with only an image attachment with no subject and no body but sent from a > legitimate source and otherwise not dangerous be considered spam? > > Many also hit DCC, presumably because of the empty body. Is it possible to > train DCC with one of these to be ignored that would then apply to all > similar messages? I've generated a signature of an empty email before, but > unsure how much variation is allowed before it's no longer considered the > same signature. > > Somewhat related, is the ExtractText plugin useful anymore? I had to > disable it altogether because of the money rules and people emailing their > credit card statements, and even though they talk about money, it's not > malicious. > > >
Attachment policy
Hi, I'm looking for input from people on how they handle attachments, and people using email as a file transfer service. One of our users must have posted to a job site recently, soliciting resumes from people internationally. This resulted in 100+ emails from random people who had never emailed this user before, many of which had no subject and no body, just a PDF attachment. Some had the "Sent by my iPhone" signatures, but that's about it. Virtually all of them were tagged as spam due to bayes. Any recommendations? There wasn't otherwise anything wrong with the attachments - they were all legitimate resumes from legitimate sources. Should they be blocked? Should I retrain bayes to not consider these spam? I'm now training bayes with them as ham, but it will take a lot to offset these. Same with emails that only contain images. Should an email with only an image attachment with no subject and no body but sent from a legitimate source and otherwise not dangerous be considered spam? Many also hit DCC, presumably because of the empty body. Is it possible to train DCC with one of these to be ignored that would then apply to all similar messages? I've generated a signature of an empty email before, but unsure how much variation is allowed before it's no longer considered the same signature. Somewhat related, is the ExtractText plugin useful anymore? I had to disable it altogether because of the money rules and people emailing their credit card statements, and even though they talk about money, it's not malicious.
Re: attachment policy?
Barton L. Phillips a écrit : > Of course under Windows a .pl may well be linked to perl and therefore > be executable without having to do a chmod (which of course Windows > doesn't understand). However, in general I have no problem with either > in-lining or attaching script code. > I don't see much benefit in "linking" .pl to perl, as this means you double click and the script runs (I am not talking about email here, but of general windows use). In many cases, perl scripts need arguments. so running them by double click is at least useless, and at worst harmful. I rather link .pl to an editor! if you need to run a perl script via double click, a .bat (or a perl script with a specific extension linked to perl if you prefer) would allow you to specify command line arguments. > Executables, on the other hand are a different story. For one, I and, I > expect others, have software running (like mimedefang) that will reject > attached executables. If one really needs to post an executable it > would, IMHO, be better to do so via a web page. > yes. I would include .vbs, even if these are scripts. There is a minimal list of extensions that have nothing to do in email (who needs a .pif nowadays? and in the rare cases it is needed, it can be sent using a different method or different "encoding"). now, as the .wmf story showed, you can't trust the extension. you still need to look at the magic header. This is fortunately feasible with mimedefang, amavisd-new, renattach, ripmime, ... etc. > As I use Linux I don't have much of a problem with attached .exe or .com > files etc. I NEVER read my mail on any of my Windows machines, and I > restrict my web browsing to only very well trusted sites and then only > when I can't use Linux or Firefox because the sites are so Windows only > designed. > The problem is mostly with outlook (even if it can be configured to not auto run executables, it had vulnerabilities that made it run some actions without the user "opening" the mail!).
Re: attachment policy?
Of course under Windows a .pl may well be linked to perl and therefore be executable without having to do a chmod (which of course Windows doesn't understand). However, in general I have no problem with either in-lining or attaching script code. Executables, on the other hand are a different story. For one, I and, I expect others, have software running (like mimedefang) that will reject attached executables. If one really needs to post an executable it would, IMHO, be better to do so via a web page. As I use Linux I don't have much of a problem with attached .exe or .com files etc. I NEVER read my mail on any of my Windows machines, and I restrict my web browsing to only very well trusted sites and then only when I can't use Linux or Firefox because the sites are so Windows only designed. Christopher X. Candreva wrote: On Fri, 24 Feb 2006, Theo Van Dinter wrote: On Thu, Feb 23, 2006 at 04:14:05PM -0800, OpenMacNews wrote: i'm noticing, e.g., *.pl scripts as attachments ... rather than links to posts at code-paste sites. I don't think we have a policy about it specifically. Generally speaking though, it's good netiquette to do as you said: put your large attachments Sorry. I was thinking of it as a code example, not a program. The script in question was 29 lines totaling 376 bytes. I was going to in-line it into the e-mail, to show how short it was, and made an attachment at the last minute, probably thinking it would be easier to look at . I tend to think of text attachments as just sections of an e-mail, and don't think of perl files as executables, since they aren't until you chmod them. Now, please don't tell me there is some mail program that will automatically run a file because it ends in .pl, or begins with #! line ! -Chris == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/ -- Barton L. Phillips Applied Technology Resources, Inc. Tel: (818)652-9850 Web: http://www.applitec.com
Re: attachment policy?
OpenMacNews wrote: > > i hear your point(s). AND i'm well aware of how many attachments are > sent to this list ... don't need to search the archives. > > hence my point/question. > > a potentially-executable attachment ESPECIALLY from a spam/virus-centric > list is not something i'm terribly thrilled about. I've never seen an attachment on this list that was executable except a perl script. I can't speak for the clamav list. That said, if you're only concerned about potentially-executable attachments, why don't you just filter/trash/whatever those? Trashing entire mails that contain attachments, simply because they contain attachments, seems a lot like throwing the baby out with the bathwater. There's really nice tools out there that allow you to filter by regex of the filename, so you can block by extension, or will use the "file" utility to attempt to determine the real type. Say for example.. MailScanner, but there's a half-dozen other tools that do this. MailScanner can even rip off the attachments while letting the main body of the message go, replacing the ripped attachment with a text-file notice about why.
Re: attachment policy?
OpenMacNews a écrit : > sending attachments to lists wins nothing that can't be readily replaced > with post-sites, costs bandwidth/cpu @ the server, runs counter to > 'typical' list rules/netiquette around the web. there is one thing that attachments win: self contained archives. It may be frustrating to search the archive, to find the solution, but it refers to an external site, to go there, but the page is no more available... > > but, i'm clearly in the minority here, so i guess y'all should feel free > to send whatever you like to the list :-) > I don't remember sending an attachment. and in the perl case, I can just copy/paste and "inline" it. But many people prefer them as attachments to do a "Save As" quickly. for forwarded spam/ham, attachments are necessary (if included in mail) as some MUAs break normal text. but again, I differentiate between safe attachments and unsafe ones. There is no reason to send a .pif or .vbs (though I've seen this)... etc. but a .txt/.pl/.sh/.diff, ... etc are ok unless your MUA executes them automatically (which then means an unsafe configuration anyway).
Re: attachment policy?
> bounce? aheh? bounce to whom? if you bounce to the list, you'll be > unsubscribed. if you bounce to the original sender, you'll get block > listed, may be even bombed, hated, and your photos will be sent to fox > news :). > i said discard/bounce ... i bounce to people i consider friendly, to let them know i'm not accepting attachments. assuming i've config'd my server(s) correctly, i don't bounce to this list. i discard the messages out of hand. > up so far, I didn't see a .vbs or a .pif. calling a .pl or an rfc822 > attachment a risk is at least an over statement. It's just text. I know > of no MUA that will execute a .pl or an rfc822 attachment! > > you can discard it. but please no bounce. sending attachments to lists wins nothing that can't be readily replaced with post-sites, costs bandwidth/cpu @ the server, runs counter to 'typical' list rules/netiquette around the web. but, i'm clearly in the minority here, so i guess y'all should feel free to send whatever you like to the list :-) > Anyway, by subscribing to an open mailing list, you accept that you'll > get mail from that list. LIST mail, yes. attachments, no. but, you're absolutely right -- i can unsubscribe. -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6
Re: attachment policy?
OpenMacNews a écrit : > Matt Kettler wrote: > >>OpenMacNews wrote: >> >>>hi theo, >>> >>> >>> On Thu, Feb 23, 2006 at 04:14:05PM -0800, OpenMacNews wrote: >question: what's this list's policy for sending attachments to the list ? > >i'm noticing, e.g., *.pl scripts as attachments ... rather than links to >posts at code-paste sites. > I don't think we have a policy about it specifically. Generally speaking though, it's good netiquette to do as you said: put your large attachments up on a website somewhere and send a link to it instead of sending that attachment to everyone. >>> >>>thx for the clarify. >>> >>>if there's *any* list(s) that i'd, personally, rather NOT see sending >>>out attachments, it' *spamassassin* & *clamav*. >>> >>>any chance of getting attachments simply blocked here? or at least >>>discussed? >>> >> >>Personally.. If there's any list I *DO* want people sending attachments >>it is this list. >> >>I would VERY strongly oppose any measure to block attachments on this list. >> >>There are only two reasonable ways to post sample spams for general list >>analysis. >> >>1) put them on a website and post a link... best for large spam, but not >>everyone has this option. >>2) post them as an attachment. >> >>In-line quote of spam posted to the list is generally not acceptable, as >>the sending MUA modifies the content and this inhibits useful analysis. >> >>Search the list archives for how many times people have had to be told >>to re-post with the full spam as an attachment instead of an inline >>quote in the body. >> >> > > > i hear your point(s). AND i'm well aware of how many attachments are > sent to this list ... don't need to search the archives. > > hence my point/question. > > a potentially-executable attachment ESPECIALLY from a spam/virus-centric > list is not something i'm terribly thrilled about. especially to a USER > list ... otoh, if the DEVs want to receive/analyse, then, imho, please > feel free to "share amongst yourselves" :-) > > bottom line? i don't trust attachments from this list. yes, i know, > that's my choice. > > in the end, i'll simply continue to discard/bounce messages with > attachments. bounce? aheh? bounce to whom? if you bounce to the list, you'll be unsubscribed. if you bounce to the original sender, you'll get block listed, may be even bombed, hated, and your photos will be sent to fox news :). up so far, I didn't see a .vbs or a .pif. calling a .pl or an rfc822 attachment a risk is at least an over statement. It's just text. I know of no MUA that will execute a .pl or an rfc822 attachment! Anyway, by subscribing to an open mailing list, you accept that you'll get mail from that list. you can discard it. but please no bounce.
Re: attachment policy?
On Fri, 24 Feb 2006, Theo Van Dinter wrote: > On Thu, Feb 23, 2006 at 04:14:05PM -0800, OpenMacNews wrote: > > i'm noticing, e.g., *.pl scripts as attachments ... rather than links to > > posts at code-paste sites. > > I don't think we have a policy about it specifically. Generally speaking > though, it's good netiquette to do as you said: put your large attachments Sorry. I was thinking of it as a code example, not a program. The script in question was 29 lines totaling 376 bytes. I was going to in-line it into the e-mail, to show how short it was, and made an attachment at the last minute, probably thinking it would be easier to look at . I tend to think of text attachments as just sections of an e-mail, and don't think of perl files as executables, since they aren't until you chmod them. Now, please don't tell me there is some mail program that will automatically run a file because it ends in .pl, or begins with #! line ! -Chris == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Re: attachment policy?
Matt Kettler wrote: > OpenMacNews wrote: >> hi theo, >> >> >>> On Thu, Feb 23, 2006 at 04:14:05PM -0800, OpenMacNews wrote: >>> question: what's this list's policy for sending attachments to the list ? i'm noticing, e.g., *.pl scripts as attachments ... rather than links to posts at code-paste sites. >>> I don't think we have a policy about it specifically. Generally speaking >>> though, it's good netiquette to do as you said: put your large attachments >>> up on a website somewhere and send a link to it instead of sending that >>> attachment to everyone. >>> >> thx for the clarify. >> >> if there's *any* list(s) that i'd, personally, rather NOT see sending >> out attachments, it' *spamassassin* & *clamav*. >> >> any chance of getting attachments simply blocked here? or at least >> discussed? >> > Personally.. If there's any list I *DO* want people sending attachments > it is this list. > > I would VERY strongly oppose any measure to block attachments on this list. > > There are only two reasonable ways to post sample spams for general list > analysis. > > 1) put them on a website and post a link... best for large spam, but not > everyone has this option. > 2) post them as an attachment. > > In-line quote of spam posted to the list is generally not acceptable, as > the sending MUA modifies the content and this inhibits useful analysis. > > Search the list archives for how many times people have had to be told > to re-post with the full spam as an attachment instead of an inline > quote in the body. > > i hear your point(s). AND i'm well aware of how many attachments are sent to this list ... don't need to search the archives. hence my point/question. a potentially-executable attachment ESPECIALLY from a spam/virus-centric list is not something i'm terribly thrilled about. especially to a USER list ... otoh, if the DEVs want to receive/analyse, then, imho, please feel free to "share amongst yourselves" :-) bottom line? i don't trust attachments from this list. yes, i know, that's my choice. in the end, i'll simply continue to discard/bounce messages with attachments. just my $0.02, but i think it's unfortunate that there's no choice in the matter ... as for: > but not everyone has this option i can only assume that means not everyone can post an EXECUTABLE file -- which, again, i'd propose should NOT be sent to the LIST in the 1st place ... cuz there are simply scads of code-paste sites that are free, can be used anonymously, and are accessible to any/all with a browser. it's done ALL THE TIME on #irc, e.g. -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6
Re: attachment policy?
OpenMacNews wrote: > hi theo, > > >> On Thu, Feb 23, 2006 at 04:14:05PM -0800, OpenMacNews wrote: >> >>> question: what's this list's policy for sending attachments to the list ? >>> >>> i'm noticing, e.g., *.pl scripts as attachments ... rather than links to >>> posts at code-paste sites. >>> >> I don't think we have a policy about it specifically. Generally speaking >> though, it's good netiquette to do as you said: put your large attachments >> up on a website somewhere and send a link to it instead of sending that >> attachment to everyone. >> > > thx for the clarify. > > if there's *any* list(s) that i'd, personally, rather NOT see sending > out attachments, it' *spamassassin* & *clamav*. > > any chance of getting attachments simply blocked here? or at least > discussed? > Personally.. If there's any list I *DO* want people sending attachments it is this list. I would VERY strongly oppose any measure to block attachments on this list. There are only two reasonable ways to post sample spams for general list analysis. 1) put them on a website and post a link... best for large spam, but not everyone has this option. 2) post them as an attachment. In-line quote of spam posted to the list is generally not acceptable, as the sending MUA modifies the content and this inhibits useful analysis. Search the list archives for how many times people have had to be told to re-post with the full spam as an attachment instead of an inline quote in the body.
Re: attachment policy?
hi theo, > On Thu, Feb 23, 2006 at 04:14:05PM -0800, OpenMacNews wrote: >> question: what's this list's policy for sending attachments to the list ? >> >> i'm noticing, e.g., *.pl scripts as attachments ... rather than links to >> posts at code-paste sites. > > I don't think we have a policy about it specifically. Generally speaking > though, it's good netiquette to do as you said: put your large attachments > up on a website somewhere and send a link to it instead of sending that > attachment to everyone. thx for the clarify. if there's *any* list(s) that i'd, personally, rather NOT see sending out attachments, it' *spamassassin* & *clamav*. any chance of getting attachments simply blocked here? or at least discussed? thx! richard -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6
Re: attachment policy?
On Thu, Feb 23, 2006 at 04:14:05PM -0800, OpenMacNews wrote: > question: what's this list's policy for sending attachments to the list ? > > i'm noticing, e.g., *.pl scripts as attachments ... rather than links to > posts at code-paste sites. I don't think we have a policy about it specifically. Generally speaking though, it's good netiquette to do as you said: put your large attachments up on a website somewhere and send a link to it instead of sending that attachment to everyone. -- Randomly Generated Tagline: Leela: And nappster says illegal copies never hurt anybody. pgppUdPuPZBaG.pgp Description: PGP signature
attachment policy?
hi all, question: what's this list's policy for sending attachments to the list ? i'm noticing, e.g., *.pl scripts as attachments ... rather than links to posts at code-paste sites. iiuc, in general attachments are 'bad form', but given that the list-mgr is NOT apparently blocking them , it thought i'd ask ... thanks! richard -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments
