amavis-user — Open Discussion about AMaViS

[AMaViS-user] NOTICE: TRANSFERRING THE amavis-user MAILING LIST

[Mark M. <Mar...@ij...>]

ANNOUNCEMENT
Members of the mailing list amavis-user @ SF, please read!

The last week's one day outage of the amavis-user mailing list at
the SourceForge reminded me that there were similar events in the past,
but more importantly that I dislike the advertisement which SourceForge
mailing list appends to each message, and that the mailing list is not
transparent, i.e. by changing passed messages the original sender's
DKIM signatures are broken.

I had a standing offer by Christian Bricart, the owner of the domain
amavis.org, to re-purpose this domain to service the amavisd-new project.
On December 2008 all the developers and main contributors of different
branches of AMaViS (AMaViS shell script, amavis-perl, Amavis 0.3.*,
amavisd(-snapshot), AMaViS-ng, and me) agreed with Christian's proposal
and stated they do not intend to continue working on stale branches.
In Christian's own words:

> Dear current and former developers within the AMaViS project,
> if anyone has objections, I'd like to declare amavisd-new "the one and
> only" branch and let all other branches officially die and r.i.p.
> I'll come to an arrangement with Mark in private about his Site moving in
> at amavis.org (@Mark: if you like, of course ;-) ).
> 
> So it would be like in the early ages of Netscape/Mozilla who stated:
> "It's spelled Netscape, but it's pronounced Mozilla..".
>               ^^^^^^^^                      ^^^^^^^^
>             (amavisd-new)                   (AMaViS)
> Please raise your hands for comments (or retreat into silence forever ;-))

Btw, my preferred spelling nowadays is Amavis (instead of AMaViS) when
referring generally to the whole project. I use 'amavisd' when referring
to the actual amavisd-new daemon, and 'amavisd-new' when referring to
my branch of Amavis, but I'll need to learn calling it just the 'Amavis'.


The other offer which I'm accepting now, is by Patrick Ben Koetter and
Ralf Hildebrandt (the authors of "The Book of Postfix"), and the offer is
to move the ama...@li... mailing list to their site,
where amavis.org will be hosted together with de.postfix.org . The move
is being coordinated with Christian Bricart and Rainer Link, moderators
of the amavis-user @ SF mailing list.

The plan is to subscribe all current mailing list members to the new list,
then restrict/close postings to the old list and unsubscribe members from
the old list.

Old list name:
  ama...@li...

New list name:
  ama...@am...  (note the change: user -> users !)

List-Id: <amavis-users.amavis.org>
List-Archive: <http://lists.amavis.org/pipermail/amavis-users>
List-Post: <mailto:ama...@am...>
List-Help: <mailto:ama...@am...?subject=help>
List-Archive: <http://lists.amavis.org/pipermail/amavis-users>
List-Subscribe:
  <http://lists.amavis.org/cgi-bin/mailman/listinfo/amavis-users>,
  <mailto:ama...@am...?subject=subscribe>
List-Unsubscribe:
  <http://lists.amavis.org/cgi-bin/mailman/options/amavis-users>, 
  <mailto:ama...@am...?subject=unsubscribe>

All mail coming from the mailing new list will be signed by a DKIM
signature of a domain amavis.org. If you'd like to whitelist all
valid mail from this mailing list using SpamAssassin 3.3.0 or later,
please add the following to your local.cf, assuming the DKIM plugin
is enabled:
  whitelist_from_dkim  *@*  amavis.org

The main change that needs cooperation from members is to start
posting to the new e-mail address, and stop posting to the old address.

The transition will occur later today, estimated between
16:00 UTC and 17:00 UTC  (17h CET, 11h EST, 8h PST).

I'll adapt the information of the web page later on.

Thanks you all for your interest in the Amavis project,
and I appologize for any inconvenience that may have been
caused by this move.

  Mark

[AMaViS-user] MIMEHEADER - Amavisd-new erorrs

[kibirango m. <kib...@gm...>]

Hullo Amavisd-Users

When I send email I get a “Passed Bad header”  in my logs . I have
configured amavisd such that all incoming emails with bad header are
passed without checking for spam. I want them to pass but I also want
them to be checked for spam.
Logs Errors:
WARN: MIME::Parser error: unexpected end of header
header: X-Amavis-Alert: BAD HEADER SECTION, MIME error: error:
unexpected end of\n\theader\n
Passed BAD-HEADER, <sender email > -> <recipient email>, mail_id:
vlsNbcKWq+P8, Hits: -, size: 19, queued_as: 537868E9, 48291 ms
 I am using amavisd-new 2.6.4 and spamassasin 3.3.1
Please can someone  out there help with a solution to the  errors below?

1.	MIME::Parser error,
2.	X-Amavis-Alert: BAD HEADER SECTION, MIME error.

Thanks,

Moses

Re: [AMaViS-user] Custom Log Template Question

[Mark M. <Mar...@ij...>]

> Yes, it is an unstructured header field, header section must not include
> any characters with code above 256

s/256/127/

  Mark

Re: [AMaViS-user] Custom Log Template Question

[Mark M. <Mar...@ij...>]

Clay,

> But, given the example from my original email, am I thinking correctly
> that the subject with it's ascii representation of the "registered sign"
> not fall under RFC 2822 specifications for an unstructured header field
> using US-ASCII? Shouldn't this then have been MIME encoded to meet
> specifications?

Yes, it is an unstructured header field, header section must not include
any characters with code above 256, and yes, the Subject should have
been encoded according to RFC 2047.

> I'm not sure it's safe to discard these messages. Although I am going to
> look through those that are showing this type of behavior and determine
> how many may be legitimate messages.

It is not unusual that some older or misconfigured mail clients would
put a non-encoded text into Subject or into display name or elsewhere,
especially in countries using ISO Latin character sets with diacritics,
or cyrillic - so despite violating the rules, in most cases it is not safe
to discard such messages. It is not even a good spam sign. It's better
to educate sender of such otherwise legitimate mail.

  Mark

Re: [AMaViS-user] amavisd-nanny question

[Christian R. <c+a...@ro...>]

> > Is running amavisd-nanny -c 1 >/dev/null
> > from cron every hour (or so) sufficient to ensure that?
> 
> I guess so, although I'm not doing this myself.
> It can't hurt to put its output to a log file to be able
> to investigate past events if need occurs. And if
> a need for killing a child process arises more often
> than once in a blue moon, it needs to be investigated.
> 
>   Mark

@hourly date >> /var/log/mail/amavisd-nanny.log ; amavisd-nanny -c 1
>/dev/null 2>> /var/log/mail/amavisd-nanny.log

Something like this?

Maybe sounds strange, what for is this? I have done this now, but do not
understand the meaning :)

Christian
-- 
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com

Re: [AMaViS-user] amavisd-nanny question

[Mark M. <Mar...@ij...>]

Ralf,
 
> Is running amavisd-nanny -c 1 >/dev/null
> from cron every hour (or so) sufficient to ensure that?

I guess so, although I'm not doing this myself.
It can't hurt to put its output to a log file to be able
to investigate past events if need occurs. And if
a need for killing a child process arises more often
than once in a blue moon, it needs to be investigated.

  Mark

Re: [AMaViS-user] DKIM signing

[Mark M. <Mar...@ij...>]

Matthias,

> > The cleanest way to differentiate mail submitted from inside
> > from inbound mail is to provide a dedicated mailer (MSA) for
> > mail submission, which accepts only authenticated mail or mail
> > from internal networks. All mail from such MSA can then be
> > passed to amavisd on a dedicated TCP port, where a policy bank
> > can set the originating flag to 1.
 
> you were right. I had to introduce a policy bank which uses the
> originating flag:
> 
> # policy bank to have mails DKIM signed
> $policy_bank{'ORIGINATING'} = {
>    # indicates client is ours, allows signing
>    originating => 1,
>    # force MTA to convert mail to 7-bit before DKIM signing
>    # to avoid later conversions which could destroy signature:
>    smtpd_discard_ehlo_keywords => ['8BITMIME'],
>    # forward to a smtpd service providing DKIM signing service
>    # (if using a signing milter instead of signing by amavisd):
>    forward_method => 'smtp:[127.0.0.1]:10025',
> };
> 
> # Use ORIGINATING policy to enable DKIM signing
> $interface_policy{'10024'} = 'ORIGINATING';
> 
> So far it seems to work. Is there anything wrong with this solution?

Yes, that's what I had in mind. If you tested it and it works with
your MTA setup, than this is it. I just wasn't sure / don't know how
you are interfacing sendmail with amavisd, which can influence
a choice of solutions.

  Mark

Re: [AMaViS-user] Mutiple recipients postfix/amavis

[Sébastien A. <sav...@al...>]

Fine it's looks like great with postfix and amavis new version.
We'll try before lmtp feeder solution before updating our version.

Thanks you very much.

Sébastien AVELINE sav...@al... <mailto:sav...@al...>
Service Exploitation
Alinto // email and more
15 quai Tilsitt - 69002 Lyon (France)
Tel. : +33(0)4 78 38 73 62 - Fax : +33(0)4 26 68 91 68
Site web : www.alinto.com <http://www.alinto.com>
Blog : www.demainlemail.com <http://www.demainlemail.com>
Suivez Alinto sur Twitter <http://twitter.com/alinto_news> & Facebook 
<http://www.facebook.com/group.php?v=wall&gid=314333826838>

Le 02/03/2011 12:43, Mark Martinec a écrit :
> Sébastien,
>
>> The original mail is from stat@xxx to nbenhadid@xxx, mduriez@xxx and
>> dgueraud@xxx.
>>
>> When postfix transmit it to amavis we have those lines
>> postfix/smtp[4439]: C7A527414E: to=<mduriez@xxx>,
>> relay=127.0.0.1[127.0.0.1]:10050, delay=8.8, delays=6.1/0/0/2.7,
>> dsn=2.0.0, status=sent (250 2.0.0 Ok, id=04231-04, from
>> MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 1433874162)
>> postfix/smtp[4439]: C7A527414E: to=<dgueraud@xxx>,
>> relay=127.0.0.1[127.0.0.1]:10050, delay=8.8, delays=6.1/0/0/2.7,
>> dsn=2.0.0, status=sent (250 2.0.0 Ok, id=04231-04, from
>> MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 1433874162)
>> postfix/smtp[4439]: C7A527414E: to=<nbenhadid@xxx>,
>> relay=127.0.0.1[127.0.0.1]:10050, delay=8.8, delays=6.1/0/0/2.7,
>> dsn=2.0.0, status=sent (250 2.0.0 Ok, id=04231-04, from
>> MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 1433874162)
>> postfix/qmgr[364]: C7A527414E: removed
>>
>> So postfix queued three mails whith the same id 1433874162.
>>
>> Now when amavis looks at these mails :
>>
>> amavis[4231]: (04231-04) Passed CLEAN, SCAN-OUTMAIL [YY.YYY.YYY.YY]
>> YY.YYY.YYY.YY]<stats@xxx>  ->
>> <mduriez@xxx>,<dgueraud@xxx>,<nbenhadid@xxx>, Message-ID:
>> <011b01cbd821$4075e660$c161b320$@fr>, mail_id: yzSTUfSdJ2wI, Hits: -1,
>> size: 265980, queued_as: 1433874162/4867674151, 2716 ms
>>
>> Amavis give them two different queue ids 1433874162 and 4867674151.
>>
>> So when looking for mail 4867674151 we can't get back to the original
>> queue id C7A527414E.
>> [...]
>>
>> But we really need to be able to get back from the id after amavis to
>> the id before because we want to trace whole mail process from entering
>> to postfix, pass through amavisd and postfix reinjection.
>> What's the solution please ?
> If you need correct per-recipient responses, the solution is
> to use LMTP instead of SMTP to feed mail from Postfix to amavisd.
>
> On the amavisd side there are no changes required. On the Postfix
> side change the 'amavisfeed' entry (or whatever you call it in
> a content_filter setting), replacing 'smtp' with 'lmtp' throughout,
> e.g. in a service program name, as well as in all its options.
>
>
> Btw, starting with amavisd-new-2.7.0-pre13 and Postfix 2.8.0,
> it became even more comfortable to associate a Postfix queue ID
> on each side of a content filter
>
> RELEASE_NOTES:
>
> - added a client-side and server-side support for the IDENT attribute of
>    a Postfix XFORWARD smtp command (available since Postfix version 2.8.0).
>    The attribute allows passing of a local message identifier (MTA queue id)
>    downstream from a front-end MTA to a post-queue content filter and back
>    to a back-end MTA. Amavisd makes this information available through an
>    existing macro %Q (which was previously non-empty only in milter setups),
>    and as such the information appears in the log when using a default amavisd
>    log template. This information is also passed back to a re-entry MTA if
>    it announces a support for this attribute (enabled on a back-end smtpd
>    service with an option smtpd_authorized_xforward_hosts), so the log entries
>    are now easier to correlate:
>
>    back-end MTA:
>      postfix/smtpd[72995]: 553261D1CB0: client=localhost[::1],
>        orig_queue_id=2F5971D1CA3, orig_client=...
>
>    post-queue content filter:
>      amavis[20341]: (20341-15) Passed CLEAN ...
>        Queue-ID: 2F5971D1CA3, queued_as: 553261D1CB0
>
>    front-end MTA:
>      postfix/lmtp[73130]: 2F5971D1CA3: ... relay=127.0.0.1[127.0.0.1]:10024,
>        status=sent (250 2.0.0 from MTA(smtp:[::1]:10025):
>                     250 2.0.0 Ok: queued as 553261D1CB0)
>
>
> Mark
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> AMaViS-user mailing list
> AMa...@li...
> https://lists.sourceforge.net/lists/listinfo/amavis-user
>   Please visit http://www.ijs.si/software/amavisd/ regularly
>   For administrativa requests please send email to rainer at openantivirus dot org

Re: [AMaViS-user] DKIM signing

[Matthias H. <ha...@id...>]

> My guess is that the $originating flag is not set for mail
> coming from inside, so amavisd thinks this is an inbound mail,
> which is not to be signed.
> ...
> The cleanest way to differentiate mail submitted from inside
> from inbound mail is to provide a dedicated mailer (MSA) for
> mail submission, which accepts only authenticated mail or mail
> from internal networks. All mail from such MSA can then be
> passed to amavisd on a dedicated TCP port, where a policy bank
> can set the originating flag to 1.
>
> ...
>
>  Mark



Hi Mark,

you were right. I had to introduce a policy bank which uses the  
originating flag:

# policy bank to have mails DKIM signed
$policy_bank{'ORIGINATING'} = {
   # indicates client is ours, allows signing
   originating => 1,
   # force MTA to convert mail to 7-bit before DKIM signing
   # to avoid later conversions which could destroy signature:
   smtpd_discard_ehlo_keywords => ['8BITMIME'],
   # forward to a smtpd service providing DKIM signing service
   # (if using a signing milter instead of signing by amavisd):
   forward_method => 'smtp:[127.0.0.1]:10025',
};

# Use ORIGINATING policy to enable DKIM signing
$interface_policy{'10024'} = 'ORIGINATING';

So far it seems to work. Is there anything wrong with this solution?

Regards
Matthias

Re: [AMaViS-user] amavisd-nanny Problem

[Ralf H. <Ral...@ch...>]

* Ralf Hildebrandt <Ral...@ch...>:
> mail:~# amavisd-nanny
> process-id task-id     elapsed in    elapsed-bar (dots indicate idle)
>            or state   idle or busy
> Program version 5.1 doesn't match environment version 4.8
> BDB no env: DB_VERSION_MISMATCH: Database environment version mismatch No such file or directory at /usr/sbin/amavisd-nanny line 142.
> exited
> 
> What am I doing wrong? It's probably a BerkeleyDB thing, but how do I
> fix that?

I fixed that by restarting amavisd-new (WTF?)
-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ral...@ch... | http://www.charite.de
	    

Re: [AMaViS-user] amavisd-nanny question

[Andreas S. <and...@da...>]

Ralf,

> Is running amavisd-nanny -c 1 >/dev/null
> from cron every hour (or so) sufficient to ensure that?
I do so ...

-- 
Andreas Schulze
Internetdienste | P252

DATEV eG
90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196
E-Mail info @datev.de | Internet www.datev.de
Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70
Vorstand
Prof. Dieter Kempf (Vorsitzender)
Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender)
Dipl.-Kfm. Michael Leistenschneider
Jörg Rabe v. Pappenheim
Dipl.-Vw. Eckhard Schwarzer
Vorsitzender des Aufsichtsrates: Reinhard Verholen

Re: [AMaViS-user] bad-header

[Mark M. <Mar...@ij...>]

P,

> We're using amavisd-new 2.6.4 on Debian Squeeze to call a mail filter.
> Although $final_bad_header_destiny is set to D_PASS mail with bad
> headers is still quarantined.
> In a previous version 2.4.2 we used the setting
> $bad_header_quarantine_method = undef;
> Is this still valid in 2.6.4? Or how can we prevent mail with bad
> headers from being quarantined?

Yes, setting $bad_header_quarantine_method to undef should still
be able to disable quarantining of bad header mail under 2.6.4,
assuming there are no other more serious reasons for quarantining
and that $clean_quarantine_method and $archive_quarantine_method
are left at their default undef value. Are you seing otherwise?
Btw, setting  $bad_header_quarantine_to = undef  would achieve
the same effect.

  Mark

Re: [AMaViS-user] Better default for $localhost_name?

[Mark M. <Mar...@ij...>]

Rob, Patrick,

> > RFC 2006 <http://tools.ietf.org/rfc/rfc2606.txt> indicates you are right.
> > I need to do some testing. Maybe I jumped to the wrong conclusion why
> > specifying "localhost" only causes problems.
> 
> reject_non_fqdn_helo_hostname will catch a bare 'localhost' since it has
> no '.', but 'localhost.' doesn't work either, since the implementation
> specifically checks for '.' within the string.  So it'll cause problems
> here either way, but...
>   [...]
> I'd say that's a mistake, and not one amavisd-new should be trying
> particularly hard to avoid.  On my systems, I reject any HELO coming from
> the outside that looks like localhost, the box's own addresses or domain
> names, the RFC 2606 reserved names, and a handful of common pseudo-TLDs,
> including '.localdomain'.  But it's perfectly fine to use 'localhost' over
> the loopback:

Well, so far the 'localhost' seems to have caused least surprises.
Initially the default was to use $myhostname, but that caused Postfix
to complain about mail looping. I agree that 'localhost.' may indeed
be a little bit better choice - but in the absence of 'search' or
'domain' in /etc/resolv.conf (at the MTA host) they are both the same.
Not sure if it is worth changing the defult, considering that the
reject_non_fqdn_helo_hostname will reject either.

  Mark

Re: [AMaViS-user] Better default for $localhost_name?

[Rob F. <rw...@lo...>]

On Thu, 3 Mar 2011, Patrick Ben Koetter wrote:

> RFC 2006 <http://tools.ietf.org/rfc/rfc2606.txt> indicates you are right. I
> need to do some testing. Maybe I jumped to the wrong conclusion why specifying
> "localhost" only causes problems.

reject_non_fqdn_helo_hostname will catch a bare 'localhost' since it has 
no '.', but 'localhost.' doesn't work either, since the implementation 
specifically checks for '.' within the string.  So it'll cause problems 
here either way, but...

> Some simply set it globally and don't disable it or change the policy on
> reinjection port.

I'd say that's a mistake, and not one amavisd-new should be trying 
particularly hard to avoid.  On my systems, I reject any HELO coming from 
the outside that looks like localhost, the box's own addresses or domain 
names, the RFC 2606 reserved names, and a handful of common pseudo-TLDs, 
including '.localdomain'.  But it's perfectly fine to use 'localhost' over 
the loopback:

Received: from localhost (localhost [127.0.0.1])
     by jupiter.loonybin.net (Postfix) with ESMTP id 3032BA2813F
     for <rw...@lo...>; Wed,  2 Mar 2011 18:15:15 -0500 (EST)

-Rob

Re: [AMaViS-user] Better default for $localhost_name?

[Patrick B. K. <p...@st...>]

* Rob Foehl <rw...@lo...>:
> On Wed, 2 Mar 2011, Patrick Ben Koetter wrote:
> 
> > Shouldn't $localhost_name be a (RFC compliant) FQDN hostname like
> > 'localhost.localdomain' by default?
> >
> > Currently it defaults to 'localhost', which IIRC is not a FQDN.
> 
> 'localhost.' is an FQDN, and one that is actually correct, as opposed to 
> the non-standard .localdomain convention that has caused more trouble than 
> it has ever solved.  Please don't encourage further confusion. :)

RFC 2006 <http://tools.ietf.org/rfc/rfc2606.txt> indicates you are right. I
need to do some testing. Maybe I jumped to the wrong conclusion why specifying
"localhost" only causes problems.


> > I'm asking because the non-FQDN $localhost_name makes Postfix reject amavis
> > when reject_non_fqdn_helo_hostname is enabled.
> 
> What's the use case for running that on a content filter reinjection port?

Some simply set it globally and don't disable it or change the policy on
reinjection port.

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>

Re: [AMaViS-user] Better default for $localhost_name?

[Rob F. <rw...@lo...>]

On Wed, 2 Mar 2011, Patrick Ben Koetter wrote:

> Shouldn't $localhost_name be a (RFC compliant) FQDN hostname like
> 'localhost.localdomain' by default?
>
> Currently it defaults to 'localhost', which IIRC is not a FQDN.

'localhost.' is an FQDN, and one that is actually correct, as opposed to 
the non-standard .localdomain convention that has caused more trouble than 
it has ever solved.  Please don't encourage further confusion. :)

> I'm asking because the non-FQDN $localhost_name makes Postfix reject amavis
> when reject_non_fqdn_helo_hostname is enabled.

What's the use case for running that on a content filter reinjection port?

-Rob

Re: [AMaViS-user] Better default for $localhost_name?

[Patrick B. K. <p...@st...>]

* Michael Scheidell <mic...@se...>:
> On 3/2/11 7:45 AM, Patrick Ben Koetter wrote:
> >   makes Postfix reject amavis
> > when reject_non_fqdn_helo_hostname is enabled.
> >
> not if allow mynets is before the tests.

Agreed, but why write an exception if you can get it right in the first.

p@rick


-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>

Re: [AMaViS-user] amavisd-nanny Problem

[Quanah Gibson-M. <qu...@zi...>]

--On Wednesday, March 02, 2011 11:55 AM +0100 Ralf Hildebrandt 
<Ral...@ch...> wrote:

> mail:~# amavisd-nanny
> process-id task-id     elapsed in    elapsed-bar (dots indicate idle)
>            or state   idle or busy
> Program version 5.1 doesn't match environment version 4.8
> BDB no env: DB_VERSION_MISMATCH: Database environment version mismatch No
> such file or directory at /usr/sbin/amavisd-nanny line 142. exited
>
> What am I doing wrong? It's probably a BerkeleyDB thing, but how do I
> fix that?

The BDB database was created with BDB 4.8.  Amavis is using a perl module 
linked against BDB 5.1.  You need to upgrade the BDB database to 5.1, or 
rebuild your BDB perl module against 4.8.

--Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Re: [AMaViS-user] Better default for $localhost_name?

[Michael S. <mic...@se...>]

On 3/2/11 7:45 AM, Patrick Ben Koetter wrote:
>   makes Postfix reject amavis
> when reject_non_fqdn_helo_hostname is enabled.
>
not if allow mynets is before the tests.



-- 
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
ISN: 1259*1300
 >*| *SECNAP Network Security Corporation

    * Certified SNORT Integrator
    * 2008-9 Hot Company Award Winner, World Executive Alliance
    * Five-Star Partner Program 2009, VARBusiness
    * Best in Email Security,2010: Network Products Guide
    * King of Spam Filters, SC Magazine 2008

______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r). 
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________  

Re: [AMaViS-user] What does SMTP DATA in TIMING refer to?

[Andreas S. <and...@da...>]

Am 02.03.2011 09:25 schrieb Patrick Ben Koetter:
> I'm trying to locate a bottleneck in a mailsystem. The TIMING in amavis logging shows ...

some weeks ago I posted a little helpersript. For me it's usefull to know
which steps take most of the time.

$ grep TIMINGS /var/log/mail | amavisd-timings 

Maybe it helps ...

Andreas

-- 
Andreas Schulze
Internetdienste | P252

DATEV eG
90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196
E-Mail info @datev.de | Internet www.datev.de
Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70
Vorstand
Prof. Dieter Kempf (Vorsitzender)
Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender)
Dipl.-Kfm. Michael Leistenschneider
Jörg Rabe v. Pappenheim
Dipl.-Vw. Eckhard Schwarzer
Vorsitzender des Aufsichtsrates: Reinhard Verholen

[AMaViS-user] bad-header

[polloxx <po...@gm...>]

Dear,

We're using amavisd-new 2.6.4 on Debian Squeeze to call a mail filter.
Although $final_bad_header_destiny is set to D_PASS mail with bad
headers is still quarantined.
In a previous version 2.4.2 we used the setting
$bad_header_quarantine_method = undef;
Is this still valid in 2.6.4? Or how can we prevent mail with bad
headers from being quarantined?

Thx,
P.

Re: [AMaViS-user] What does SMTP DATA in TIMING refer to?

[Mark M. <Mar...@ij...>]

Patrick,

> I'm trying to locate a bottleneck in a mailsystem. The TIMING in amavis
> logging shows that amavis spends most time with "SMTP DATA":
> 
> Mar  2 08:37:20 mail amavis[12218]: (12218-03) TIMING [total 4034 ms] -
> SMTP greeting: 0 (0%)0, SMTP EHLO: 0 (0%)0, SMTP pre-MAIL: 0 (0%)0, SMTP
> pre-DATA-flush: 24 (1%)1, SMTP DATA: 3882 (96%)97, ...

> Mar  2 08:37:41 mail
> amavis[12416]: (12416-05) TIMING [total 7679 ms] - SMTP greeting: 4 (0%)0,
> SMTP EHLO: 0 (0%)0, SMTP pre-MAIL: 0 (0%)0, SMTP pre-DATA-flush: 0 (0%)0,
> SMTP DATA: 7275 (95%)95, ...

> What does SMTP DATA refer to? The system uses amavis archive method to copy
> messages. Could it be related to that?

The "SMTP DATA" timing section refers to an actual transfer of mail contents
(header section + body) from MTA to amavisd.  In my benchmarking  of 2.7.0
I measured the following transfer rates on our regular mailer (AMD Opteron
2376, 8 CPUs - not the very latest and greatest but still fine):

RELEASE_NOTES:

- rewritten a code section on receiving SMTP/LMTP DATA, replacing perl
  line-by-line reads & processing by reading & processing 32 kB chunks
  of data at a time; as a result, data transfer rate has been increased
  by a factor of about 3.9 for plain text session, and by a factor of 11
  for encrypted (TLS) session.

  Measured data rates of an SMTP DATA transfer between Postfix and amavisd
  on a loopback interface:

  No TLS (no session encryption):
  . amavisd receiving, old code:  8.3 MiB/s
  . amavisd receiving, new code: 32.3 MiB/s
  . amavisd sending:             18   MiB/s

  With TLS (encrypted session, AES256-SHA):
  . amavisd receiving, old code:  1.0 MiB/s
  . amavisd receiving, new code: 11.2 MiB/s
  . amavisd sending:              4.3 MiB/s


So the question is: what is the size of these messages? Calculate the
transfer rate for larger messages. If you get much different results
from mine, there must be something wrong there. Are both the
MTA and amavisd on the same host? Are they communicating over
an inet socket? On a loopback interface? Are you using TLS? Is there
any milter involved? Any unusual MTU settings on the interface?

  Mark

[AMaViS-user] Better default for $localhost_name?

[Patrick B. K. <p...@st...>]

Shouldn't $localhost_name be a (RFC compliant) FQDN hostname like
'localhost.localdomain' by default?

Currently it defaults to 'localhost', which IIRC is not a FQDN.

I'm asking because the non-FQDN $localhost_name makes Postfix reject amavis
when reject_non_fqdn_helo_hostname is enabled.

p@rick

-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstraße 15      Telefon +49 89 3090 4664
81669 München              Telefax +49 89 3090 4666

Amtsgericht München        Partnerschaftsregister PR 563

[AMaViS-user] amavisd-nanny question

[Ralf H. <Ral...@ch...>]

I've seen that amavisd-nanny will kill children that are lingering
around and not reporting back to the DB.

Is running
amavisd-nanny -c 1 >/dev/null

from cron every hour (or so) sufficient to ensure that?

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ral...@ch... | http://www.charite.de
	    

Re: [AMaViS-user] Mutiple recipients postfix/amavis

[Mark M. <Mar...@ij...>]

Sébastien,

> The original mail is from stat@xxx to nbenhadid@xxx, mduriez@xxx and
> dgueraud@xxx.
> 
> When postfix transmit it to amavis we have those lines
> postfix/smtp[4439]: C7A527414E: to=<mduriez@xxx>,
> relay=127.0.0.1[127.0.0.1]:10050, delay=8.8, delays=6.1/0/0/2.7,
> dsn=2.0.0, status=sent (250 2.0.0 Ok, id=04231-04, from
> MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 1433874162)
> postfix/smtp[4439]: C7A527414E: to=<dgueraud@xxx>,
> relay=127.0.0.1[127.0.0.1]:10050, delay=8.8, delays=6.1/0/0/2.7,
> dsn=2.0.0, status=sent (250 2.0.0 Ok, id=04231-04, from
> MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 1433874162)
> postfix/smtp[4439]: C7A527414E: to=<nbenhadid@xxx>,
> relay=127.0.0.1[127.0.0.1]:10050, delay=8.8, delays=6.1/0/0/2.7,
> dsn=2.0.0, status=sent (250 2.0.0 Ok, id=04231-04, from
> MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 1433874162)
> postfix/qmgr[364]: C7A527414E: removed
> 
> So postfix queued three mails whith the same id 1433874162.
> 
> Now when amavis looks at these mails :
> 
> amavis[4231]: (04231-04) Passed CLEAN, SCAN-OUTMAIL [YY.YYY.YYY.YY]
> YY.YYY.YYY.YY] <stats@xxx> ->
> <mduriez@xxx>,<dgueraud@xxx>,<nbenhadid@xxx>, Message-ID:
> <011b01cbd821$4075e660$c161b320$@fr>, mail_id: yzSTUfSdJ2wI, Hits: -1,
> size: 265980, queued_as: 1433874162/4867674151, 2716 ms
> 
> Amavis give them two different queue ids 1433874162 and 4867674151.
> 
> So when looking for mail 4867674151 we can't get back to the original
> queue id C7A527414E.
> [...]
> 
> But we really need to be able to get back from the id after amavis to
> the id before because we want to trace whole mail process from entering
> to postfix, pass through amavisd and postfix reinjection.
> What's the solution please ?

If you need correct per-recipient responses, the solution is
to use LMTP instead of SMTP to feed mail from Postfix to amavisd.

On the amavisd side there are no changes required. On the Postfix
side change the 'amavisfeed' entry (or whatever you call it in
a content_filter setting), replacing 'smtp' with 'lmtp' throughout,
e.g. in a service program name, as well as in all its options.


Btw, starting with amavisd-new-2.7.0-pre13 and Postfix 2.8.0,
it became even more comfortable to associate a Postfix queue ID
on each side of a content filter

RELEASE_NOTES:

- added a client-side and server-side support for the IDENT attribute of
  a Postfix XFORWARD smtp command (available since Postfix version 2.8.0).
  The attribute allows passing of a local message identifier (MTA queue id)
  downstream from a front-end MTA to a post-queue content filter and back
  to a back-end MTA. Amavisd makes this information available through an
  existing macro %Q (which was previously non-empty only in milter setups),
  and as such the information appears in the log when using a default amavisd
  log template. This information is also passed back to a re-entry MTA if
  it announces a support for this attribute (enabled on a back-end smtpd
  service with an option smtpd_authorized_xforward_hosts), so the log entries
  are now easier to correlate:

  back-end MTA:
    postfix/smtpd[72995]: 553261D1CB0: client=localhost[::1],
      orig_queue_id=2F5971D1CA3, orig_client=...

  post-queue content filter:
    amavis[20341]: (20341-15) Passed CLEAN ...
      Queue-ID: 2F5971D1CA3, queued_as: 553261D1CB0

  front-end MTA:
    postfix/lmtp[73130]: 2F5971D1CA3: ... relay=127.0.0.1[127.0.0.1]:10024,
      status=sent (250 2.0.0 from MTA(smtp:[::1]:10025):
                   250 2.0.0 Ok: queued as 553261D1CB0)


Mark