Re: Mail from own host is recognized as spam
On Feb 15, 2016, at 7:51 AM, Catscrash wrote: > I have a problem with mail being marked as SPAM, although being > transmitted between virtual domains on the same hosts. Why are you sending mail between local domains to amavis? -- I WILL NOT PLEDGE ALLEGIANCE TO BART Bart chalkboard Ep. 7F09
Multiple Amavis::Custom hooks.
Hello All, I am developing a plugin for amavis that can do some additional tasks such as adding additional disclaimers to the emails based on contents, adding some per-user preferences to the emails. I understand that the Amavis::Custom module can be used for this purpose. Question: If I install my hook, would it overwrite any existing hooks that the user may have previously defined? I want both (my hook and user's preinstalled hook) to work together? Any help is appreciated. Please also redirect me to the right mailing list if this is not the right one. -- Thanks and Regards, Ashish Behl.
Re: Upcoming Release: feature Request
On Feb 15, 2016, at 1:53 PM, A. Schulze wrote: > Feature Request: Amavisd-new should recognise A-R header and use/trust them. > Assumption: the A-R header aren't present in an incoming message but really > added by a local milter. How would amavis know if the headers were added by the local server or faked by the spammer? -- 'We'll all be killed.' 'Think of it as the lesser of two evils.' 'What's the other one?' Vimes drew his sword. 'Me.' --Jingo
Re: Upcoming Release: feature Request
* @lbutlr : > On Feb 15, 2016, at 1:53 PM, A. Schulze wrote: > > Feature Request: Amavisd-new should recognise A-R header and use/trust them. > > Assumption: the A-R header aren't present in an incoming message but really > > added by a local milter. > > How would amavis know if the headers were added by the local server or faked > by the spammer? One could remove any existing headers, add ones own and then trust them. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Upcoming Release: feature Request
On Feb 16, 2016, at 3:31 AM, Patrick Ben Koetter wrote: > * @lbutlr : >> On Feb 15, 2016, at 1:53 PM, A. Schulze wrote: >>> Feature Request: Amavisd-new should recognise A-R header and use/trust them. >>> Assumption: the A-R header aren't present in an incoming message but really >>> added by a local milter. >> >> How would amavis know if the headers were added by the local server or faked >> by the spammer? > > One could remove any existing headers, add ones own and then trust them. How does amavis know if you removed the spammer headers and added your own? -- 'Charity ain't giving people what you wants to give, it's giving people what they need to get.'
Re: Mail from own host is recognized as spam
Am 16.02.2016 um 11:01 schrieb @lbutlr: > On Feb 15, 2016, at 7:51 AM, Catscrash wrote: >> I have a problem with mail being marked as SPAM, although being >> transmitted between virtual domains on the same hosts. > Why are you sending mail between local domains to amavis? > ok, sure. Good Point. I added my own Domains to the whitelist, so as long as no one starts faking them I'm good. Although if one has a really large infrastructe, one might not trust every virtual domain on the host and might want to have amavis check the mails anyway... so I still would like to know why this happened...
Re: Upcoming Release: feature Request
@lbutlr: How does amavis know if you removed the spammer headers and added your own? It has to trust the administrator does a good job :-) Each A-R header include an AuthServID (a hostname generating the A-R header) Any A-R header consumer must know these "TrustedAuthServIDs" and trust these are generated localy. Andreas
amavis -> clamav: Scan mail or only parts?
Does amavis clamav to scan the mail (header + body) or only parts of it? I specified @keep_decoded_original_maps on a Debian 2.10.1 install to "retain full original message for virus checking" like this: @keep_decoded_original_maps = (new_RE( qr'^MAIL$', # retain full original message for virus checking (can be slow) qr'^MAIL-UNDECIPHERABLE$', # recheck full mail if it contains undecipherables qr'^(ASCII(?! cpio)|text|uuencoded|xxencoded|binhex)'i, )); >From this I would suspect amavis to tell clamav to scan the whole mail, which I assume to be stored in $tempdir/email.txt. But I don't see that, when I look at the communication that takes place between amavis and clamav. >From what I read from the recorded tcpdump session (see below) amavis tells clamd to - CONTSCAN /var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/parts/p004 - CONTSCAN /var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/parts/p002 There's no CONTSCAN /var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/email.txt (allthough it would work as I tested manually). Did I miss something? Is my assumption amavis will let clamav scan the complete message, wrong? Thanks p@rick 13:51:34.667566 IP localhost.localdomain.60081 > localhost.localdomain.3310: Flags [S], seq 4241060098, win 43690, options [mss 65495,sackOK,TS val 2109639026 ecr 0,nop,wscale 7], length 0 E..<.p@.@.DI..q..0. }..r 13:51:34.667588 IP localhost.localdomain.3310 > localhost.localdomain.60081: Flags [S.], seq 3782527681, ack 4241060099, win 43690, options [mss 65495,sackOK,TS val 2109639026 ecr 2109639026,nop,wscale 7], length 0 E..<..@.@.<..tq..0. }..r}..r 13:51:34.667601 IP localhost.localdomain.60081 > localhost.localdomain.3310: Flags [.], ack 1, win 342, options [nop,nop,TS val 2109639026 ecr 2109639026], length 0 E..4.q@.@.DP..q..t.V.(. }..r}..r 13:51:34.668699 IP localhost.localdomain.60081 > localhost.localdomain.3310: Flags [P.], seq 1:74, ack 1, win 342, options [nop,nop,TS val 2109639026 ecr 2109639026], length 73 E..}.r@.@.D...q..t.V.q. }..r}..rCONTSCAN /var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/parts 13:51:34.668729 IP localhost.localdomain.3310 > localhost.localdomain.60081: Flags [.], ack 74, win 342, options [nop,nop,TS val 2109639026 ecr 2109639026], length 0 E..4C.@.@tqL...V.(. }..r}..r 13:51:34.671151 IP localhost.localdomain.3310 > localhost.localdomain.60081: Flags [P.], seq 1:98, ack 74, win 342, options [nop,nop,TS val 2109639027 ecr 2109639026], length 97 E...C.@.@tqL...V... }..s}..r/var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/parts/p004: VirusDB: FOUND 13:51:34.671176 IP localhost.localdomain.60081 > localhost.localdomain.3310: Flags [.], ack 98, win 342, options [nop,nop,TS val 2109639027 ecr 2109639027], length 0 E..4.s@.@.DN..qL.t.#...V.(. }..s}..s 13:51:34.671608 IP localhost.localdomain.3310 > localhost.localdomain.60081: Flags [P.], seq 98:195, ack 74, win 342, options [nop,nop,TS val 2109639027 ecr 2109639027], length 97 E...C.@.@t.#..qL...V... }..s}..s/var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/parts/p002: VirusDB: FOUND 13:51:34.671624 IP localhost.localdomain.60081 > localhost.localdomain.3310: Flags [.], ack 195, win 342, options [nop,nop,TS val 2109639027 ecr 2109639027], length 0 E..4.t@.@.DM..qL.t.V.(. }..s}..s 13:51:34.671743 IP localhost.localdomain.3310 > localhost.localdomain.60081: Flags [F.], seq 195, ack 74, win 342, options [nop,nop,TS val 2109639027 ecr 2109639027], length 0 E..4C.@.@tqL...V.(. }..s}..s 13:51:34.671917 IP localhost.localdomain.60081 > localhost.localdomain.3310: Flags [F.], seq 74, ack 196, win 342, options [nop,nop,TS val 2109639027 ecr 2109639027], length 0 E..4.u@.@.DL..qL.t.V.(. }..s}..s 13:51:34.671938 IP localhost.localdomain.3310 > localhost.localdomain.60081: Flags [.], ack 75, win 342, options [nop,nop,TS val 2109639027 ecr 2109639027], length 0 E..4C.@.@tqM...V.(. }..s}..s -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
CLOSED: Re: amavis -> clamav: Scan mail or only parts?
Answering my own question: The last part (here: p004) contains the message in full. It was sent as first part to be inspected. p@rick * Patrick Ben Koetter : > Does amavis clamav to scan the mail (header + body) or only parts of it? > > I specified @keep_decoded_original_maps on a Debian 2.10.1 install to "retain > full original message for virus checking" like this: > > @keep_decoded_original_maps = (new_RE( > qr'^MAIL$', # retain full original message for virus checking (can be > slow) > qr'^MAIL-UNDECIPHERABLE$', # recheck full mail if it contains > undecipherables > qr'^(ASCII(?! cpio)|text|uuencoded|xxencoded|binhex)'i, > )); > > From this I would suspect amavis to tell clamav to scan the whole mail, which > I assume to be stored in $tempdir/email.txt. But I don't see that, when I look > at the communication that takes place between amavis and clamav. > > From what I read from the recorded tcpdump session (see below) amavis tells > clamd to > > - CONTSCAN > /var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/parts/p004 > - CONTSCAN > /var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/parts/p002 > > There's no CONTSCAN > /var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/email.txt (allthough > it would work as I tested manually). > > Did I miss something? Is my assumption amavis will let clamav scan the > complete message, wrong? > > Thanks > > p@rick > > > > > 13:51:34.667566 IP localhost.localdomain.60081 > localhost.localdomain.3310: > Flags [S], seq 4241060098, win 43690, options [mss 65495,sackOK,TS val > 2109639026 ecr 0,nop,wscale 7], length 0 > E..<.p@.@.DI..q..0. > }..r > 13:51:34.667588 IP localhost.localdomain.3310 > localhost.localdomain.60081: > Flags [S.], seq 3782527681, ack 4241060099, win 43690, options [mss > 65495,sackOK,TS val 2109639026 ecr 2109639026,nop,wscale 7], length 0 > E..<..@.@.<..tq..0. > }..r}..r > 13:51:34.667601 IP localhost.localdomain.60081 > localhost.localdomain.3310: > Flags [.], ack 1, win 342, options [nop,nop,TS val 2109639026 ecr > 2109639026], length 0 > E..4.q@.@.DP..q..t.V.(. > }..r}..r > 13:51:34.668699 IP localhost.localdomain.60081 > localhost.localdomain.3310: > Flags [P.], seq 1:74, ack 1, win 342, options [nop,nop,TS val 2109639026 ecr > 2109639026], length 73 > E..}.r@.@.D...q..t.V.q. > }..r}..rCONTSCAN > /var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/parts > > 13:51:34.668729 IP localhost.localdomain.3310 > localhost.localdomain.60081: > Flags [.], ack 74, win 342, options [nop,nop,TS val 2109639026 ecr > 2109639026], length 0 > E..4C.@.@tqL...V.(. > }..r}..r > 13:51:34.671151 IP localhost.localdomain.3310 > localhost.localdomain.60081: > Flags [P.], seq 1:98, ack 74, win 342, options [nop,nop,TS val 2109639027 ecr > 2109639026], length 97 > E...C.@.@tqL...V... > }..s}..r/var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/parts/p004: > VirusDB: FOUND > > 13:51:34.671176 IP localhost.localdomain.60081 > localhost.localdomain.3310: > Flags [.], ack 98, win 342, options [nop,nop,TS val 2109639027 ecr > 2109639027], length 0 > E..4.s@.@.DN..qL.t.#...V.(. > }..s}..s > 13:51:34.671608 IP localhost.localdomain.3310 > localhost.localdomain.60081: > Flags [P.], seq 98:195, ack 74, win 342, options [nop,nop,TS val 2109639027 > ecr 2109639027], length 97 > E...C.@.@t.#..qL...V... > }..s}..s/var/lib/amavis/tmp/amavis-20160216T131521-08377-MZJAqZlB/parts/p002: > VirusDB: FOUND > > 13:51:34.671624 IP localhost.localdomain.60081 > localhost.localdomain.3310: > Flags [.], ack 195, win 342, options [nop,nop,TS val 2109639027 ecr > 2109639027], length 0 > E..4.t@.@.DM..qL.t.V.(. > }..s}..s > 13:51:34.671743 IP localhost.localdomain.3310 > localhost.localdomain.60081: > Flags [F.], seq 195, ack 74, win 342, options [nop,nop,TS val 2109639027 ecr > 2109639027], length 0 > E..4C.@.@tqL...V.(. > }..s}..s > 13:51:34.671917 IP localhost.localdomain.60081 > localhost.localdomain.3310: > Flags [F.], seq 74, ack 196, win 342, options [nop,nop,TS val 2109639027 ecr > 2109639027], length 0 > E..4.u@.@.DL..qL.t.V.(. > }..s}..s > 13:51:34.671938 IP localhost.localdomain.3310 > localhost.localdomain.60081: > Flags [.], ack 75, win 342, options [nop,nop,TS val 2109639027 ecr > 2109639027], length 0 > E..4C.@.@tqM...V.(. > }..s}..s > > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 > Franziskanerstraße 15, 81669 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > Aufsichtsratsvorsitzender: Florian Kirstein > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesell
Re: Upcoming Release: feature Request
@lbutlr: How does amavis know if you removed the spammer headers and added your own? Andreas Schulze wrote: It has to trust the administrator does a good job :-) Each A-R header include an AuthServID (a hostname generating the A-R header) Any A-R header consumer must know these "TrustedAuthServIDs" and trust these are generated localy. AuthServID by itself is not good enough, such header field must also belong to a set of trusted fields. SpamAssassin solves the problem of determining which header fields can be trusted by settings trusted_networks / internal_networks / msa_networks. Mark
amavis av_scan randomly skips av_scanners
Hi together, I am facing a strange behaviour and am searching for a solution. I have configured four av_scanners: 1 a small pl script that searches for some headers in the mailfiles 2 another pl script that searches for vba code. 3 sophos savscan 4 clamd All work well and give clean/infected state back. But sometimes (maybe when there are more messages at the same time) amavis just skips some of the scanners without any note. In the logfile at level 5 I only see which scanners are used (run) but no note about the others! What I do see, that the first two seem to be skipped and the other two - maybe not. Sophos and clamd also are in the backup list so this may be, why they are not skipped? But would that give a note, if the backup list is used? Any ideas what is happening here? thanks, martin
Re: Upcoming Release: feature Request
* Mark Martinec : > >@lbutlr: > >>How does amavis know if you removed the spammer headers and > >>added your own? > > Andreas Schulze wrote: > >It has to trust the administrator does a good job :-) > > > >Each A-R header include an AuthServID (a hostname generating the > >A-R header) > >Any A-R header consumer must know these "TrustedAuthServIDs" and trust > >these are generated localy. > > AuthServID by itself is not good enough, such header field must also > belong to a set of trusted fields. SpamAssassin solves the problem > of determining which header fields can be trusted by settings > trusted_networks / internal_networks / msa_networks. How would you do that in a MILTER setup? p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
