Re: A little OT: SPF

[Scott Kitterman]

On Tue, 16 Dec 2008 22:14:26 +0200 Tolga  wrote:
>Hello,
>
>For an e-mail not to fall into spam category, the sourcing server has to 
>have SPF record I think, or so I've been told. How do I check whether it 
>has a SPF record or not?
>
Oh dear, no.

You might want to reject mail that fails SPF checks, but not reject mail 
due to lack of an SPF record.  There are  multiple policy server 
implementation for checking SPF results.  You can find a couple at 
http://www.openspf.org/Software.

Scott K

Re: rate limit outgoing mails with mailman

[Scott Kitterman]

On Fri, 2 Jan 2009 10:40:45 -0500 ja...@monsterjam.org wrote:
>> The following requires Postfix 2.5 or later:
>> 
>> /etc/postfix/main.cf:
>> # Deliver all mail via the "smtp" transport in master.cf.
>> # Use [] to suppress MX lookup.
>> relayhost = [mail.example.com]
>> default_transport = smtp
>> smtp_destination_rate_delay = 30
>> 
>> This will deliver one message every 30 seconds.
>> 
>>  Wietse
>
>aah heck, I lied to you..
>I have  postfix 2.4.5-3ubuntu1.3 installed   :(
>
>Is there a way to accomplish the same thing for this version or should I 
compile the new one?
>I couldnt find postfix 2.5 for Ubuntu 7.10 
>

Look in gutsy-backports or upgrade to 8.04.  Also note that the release you 
are using will be unsupported in another 3 months, so upgrading is likely 
your best bet.

Scott K

Re: [OFF] SPF

[Scott Kitterman]

On Mon, 26 Jan 2009 09:47:35 -0200 Márcio Luciano Donada 
 wrote:
>Hi list,
>I am using debian etch and postfix and then using the
>/usr/lib/postfix/policyd, but with the high traffic of e-mails in recent
>days I have had problems even had to disable it. I wonder what you are
>used to check the SPF on servers?
>
For Etch there aren't any good solutions in Debian proper (that I know of).  In 
backports.org there is a backport of a reasonably recent version of 
postfix-policyd-spf-python that I can recommend (I'm upstream and the Debian 
maintainer, so not unbiased).

Scott K

Re: Creating database maps with postmap

[Scott Kitterman]

On Wed, 11 Mar 2009 14:51:02 -0600 Chris Cameron  wrote:
>On Wed, Mar 11, 2009 at 1:54 PM, Brian Evans - Postfix List
> wrote:
>> Chris Cameron wrote:
>>> I'm using spf-milter-python, which uses an access map for refining the
>>> SPF policy.
>>>
>>> The file is formated as:
>>>
>>> SPF-Fail:     REJECT
>>>
>>
>> If the lookup key you want is 'SPF-Fail' then do not put a colon.
>> Colons are normally only used in alias lookups with Postfix
>> In General, access maps will not use them.
>>
>> Brian
>>
>Fair enough. However the documents for spf-milter-python state that I
>could also do:
>
>SPF-Neutral:aol.comREJECT
>SPF-Softfail:aol.com   REJECT
>
>
>Would that still be valid considering "SPF-Softfail:aol.com" could be
>seen as just one string?
>
>
>Thank you for your help,
>
>Chris

All the documentation for spf-milter-python is written by a Sendmail admin.  If 
you (sorry, I've been busy and just skimming the list - so this is to all of 
you discussing this) have suggestions for the documentation for Postfix users, 
please let me know and I'll get them forwarded upstream (I've packaged this for 
Debian/Ubuntu, but am not the author).

On a related note, with Postfix this is very easy to do (and much better 
documented) with the postfix-policyd-spf-python policy server.  Apologies if 
you've already been down this road.

Scott K

Re: Ubuntu, dynamicmaps?

[Scott Kitterman]

On Wed, 11 Mar 2009 16:40:26 -0500 KLaM Postmaster  
wrote:
>I am thinking of switching to Ubuntu 8.10 LTS server, however when I
>look at the Postfix configuration it seems somewhat odd.
>I don't want to start a flame war, but I would like to hear what people
>think about things like "dynamicmaps" and other oddities of the Ubuntu
>Postfix configuration.
>
The design decision in the Debian/Ubuntu Postfix packages the most often 
causes commentary here is to enable chroot by default.  Personally, I like 
it, but it does add some complexity and add to the number of people needing 
help.

How to accomplish most things you need to do with the chroot is reasonably 
well covered in the Ubuntu documentation.  There are also distro specific 
support resources that can help.

We are shipping (and I don't recall which release it arrived in, it may 
just be in the development release) a script to automate removing the 
chroot for people that don't want it.

Scott K

Re: Export User

[Scott Kitterman]

On Fri, 13 Mar 2009 12:40:37 -0400 Jorey Bump  wrote:
>Sasa wrote, at 03/13/2009 11:35 AM:
>
>> On current mail server I have:
>> 
>> [r...@mail ~]# file /etc/sasldb2
>> /etc/sasldb2: Berkeley DB (Hash, version 8, native byte-order)
>> 
>> on new mail server I have:
>> 
>> [r...@mail ~]# file /etc/sasldb2
>> /etc/sasldb2: Berkeley DB (Hash, version 9, native byte-order)
>> 
>> ..the version is different, this is can be a problem ?
>
>Unfortunately, it might. But Berkeley DB provides decent tools for
>dumping databases, so you should be able to easily dump the contents on
>the old machine then load them on the new one. I use gdbm for sasldb2,
>however, so you'll need to do some research or ask on the appropriate
>list. I think db_dump and db_load will do the trick, but I'm not aware
>of the steps. Also keep in mind that it's possible to have multiple
>versions of Berkely DB installed, so watch out for possible conflicts.
>
If this is an upgrade to DB 4.6/4.7 from 4.3/4.4/4.5 (I'm pretty sure it 
is) then the on disk format changes only affected databases with 
transaction support (which doesn't affect sasldb).  Make backups, etc., but 
you should still be able to just copy the file over.

Scott K

Re: Postfix denies relays when sending from Eudora

[Scott Kitterman]

On Thu, 26 Mar 2009 13:48:01 -0700 Asai  wrote:
>LuKreme wrote:
>> On 26-Mar-2009, at 13:57, Asai wrote:
>>> My apologies, I hope this is of assistance.
>>
>> LOGS of the eudora user tring to send to gmail.
>>
>>
>> And don't top-post.
>>
>>
> From /var/log/maillog, one example of the problem:
>
>Mar 26 11:58:18 triata postfix/smtpd[25357]: NOQUEUE: reject: RCPT from 
>unknown[63.229.177.226]: 554 5.7.1 : Relay access 
>denied; from= to= 
>proto=ESMTP helo=
>

Did you expect this client to use SMTP Auth?  If so, you might check and 
see if your server is offering LOGIN.  I have a vague recollection of at 
least some Eudora versions not using PLAIN and needing LOGIN.

Scott K

Re: Postfix.org SPF

[Scott Kitterman]

On Sunday, July 04, 2010 10:51:32 pm junkyardma...@verizon.net wrote:
> Yahoo has ulterior motives?  They wish to push their domain keys.
> 
> Others probably likewise have ulterior motives.
> 
> Do you also oppose SPF, and if so what is your motives?
> 
Please stop.  This is offtopic for this list and not helpful in any case.  Some 
people like and use SPF and some people don't.  Rejecting or discarding mail 
due simply to a lack of and SPF record is idiotic and domain owners are 
completely free to publish a record or not.

Consult Google if you want to know my views on SPF (they aren't hard to find).  
If you want to discuss SPF, there is an spf-discuss mailing list where such 
discussions are on topic (see http://www.openspf.org/Forums for details).

Scott K

Re: distribution issues with Postfix

[Scott Kitterman]

On Wednesday, July 07, 2010 14:42:29 Phil Howard wrote:
 
> Ubuntu works reasonably OK with everything else I've used on it.
> Problem exist with Postfix on it.  They've said to address it with
> Postfix.  I personally think the specific problems are more of how
> Ubuntu handles Postfix poorly.  One issue (which may be part of the
> problem) is the Postfix package in Ubuntu being an older one.

No.  It really doesn't.  If you don't understand how to use your distro 
package management system, you should seek help in a distro specific venue.


Scott K

OFFLIST - Re: distribution issues with Postfix

[Scott Kitterman]

On Wednesday, July 07, 2010 15:13:00 Phil Howard wrote:
> On Wed, Jul 7, 2010 at 15:00, Scott Kitterman  wrote:
> > On Wednesday, July 07, 2010 14:42:29 Phil Howard wrote:
> >> Ubuntu works reasonably OK with everything else I've used on it.
> >> Problem exist with Postfix on it.  They've said to address it with
> >> Postfix.  I personally think the specific problems are more of how
> >> Ubuntu handles Postfix poorly.  One issue (which may be part of the
> >> problem) is the Postfix package in Ubuntu being an older one.
> > 
> > No.  It really doesn't.  If you don't understand how to use your distro
> > package management system, you should seek help in a distro specific
> > venue.
> 
> BTDT.  They say it's not a distro specific issue.  I don't know if I
> agree with them or not.  But I am considering abandoning that distro.
> If Postfix people's experience was that the distro does not have such
> issues with Postfix, then it might be worthwhile pursuing that issue
> with them (the distro people) further.  Quite possibly it is the
> person who makes the Postfix package not doing thing right with
> respect to either Postfix and/or Ubuntu.
> 
> But I might also seek another distro.  It has already been said here
> that I should run the latest version of Postfix.  That would be
> compiling from source since the latest is not packaged in the distro.
> In general, that's not a problem.  But it is to a certain degree a
> problem in some distros (and why this is, certainly is not a Postfix
> issue ... I have experienced the problem with other than Postfix).
> I'm just saying that so you know why I'm also looking away from Ubuntu
> (please do not assume I am asking you to fix those Ubuntu issues).
> 
> How about simply, which distro various Postfix users are running?

Who is "They" and what exactly is the issue?

In addition to running a number of mail servers with Postfix on Ubuntu, I'm 
also an Ubuntu developer and I can look into it.

Scott K

Re: distribution issues with Postfix

[Scott Kitterman]

On Wednesday, July 07, 2010 15:14:08 Gary Chambers wrote:
> > No.  Clearly not the case.  Ubuntu is an example which interferes with
> > Postfix.  I'm trying to determine if others are more or less so.  I
> > suspect at least some surely must be less so.
> 
> Why not simply avoid whatever hassles you're encountering with your
> distribution's version of the software and compile your own?  I'd like
> PostgreSQL support in Ubuntu Server 10.04 LTS, but I didn't come to
> the list to ask for it.
> 
Just so the archives have the correct information about this:

sudo apt-get install postfix-pgsql

is all that's needed for PostgreSQL support in Ubuntu Server 10.04 LTS.

Scott K

Re: OFFLIST (or not) - Re: distribution issues with Postfix

[Scott Kitterman]

On Wednesday, July 07, 2010 15:22:22 Scott Kitterman wrote:
> On Wednesday, July 07, 2010 15:13:00 Phil Howard wrote:
> > On Wed, Jul 7, 2010 at 15:00, Scott Kitterman  
wrote:
> > > On Wednesday, July 07, 2010 14:42:29 Phil Howard wrote:
> > >> Ubuntu works reasonably OK with everything else I've used on it.
> > >> Problem exist with Postfix on it.  They've said to address it with
> > >> Postfix.  I personally think the specific problems are more of how
> > >> Ubuntu handles Postfix poorly.  One issue (which may be part of the
> > >> problem) is the Postfix package in Ubuntu being an older one.
> > > 
> > > No.  It really doesn't.  If you don't understand how to use your distro
> > > package management system, you should seek help in a distro specific
> > > venue.
> > 
> > BTDT.  They say it's not a distro specific issue.  I don't know if I
> > agree with them or not.  But I am considering abandoning that distro.
> > If Postfix people's experience was that the distro does not have such
> > issues with Postfix, then it might be worthwhile pursuing that issue
> > with them (the distro people) further.  Quite possibly it is the
> > person who makes the Postfix package not doing thing right with
> > respect to either Postfix and/or Ubuntu.
> > 
> > But I might also seek another distro.  It has already been said here
> > that I should run the latest version of Postfix.  That would be
> > compiling from source since the latest is not packaged in the distro.
> > In general, that's not a problem.  But it is to a certain degree a
> > problem in some distros (and why this is, certainly is not a Postfix
> > issue ... I have experienced the problem with other than Postfix).
> > I'm just saying that so you know why I'm also looking away from Ubuntu
> > (please do not assume I am asking you to fix those Ubuntu issues).
> > 
> > How about simply, which distro various Postfix users are running?
> 
> Who is "They" and what exactly is the issue?
> 
> In addition to running a number of mail servers with Postfix on Ubuntu, I'm
> also an Ubuntu developer and I can look into it.
> 
> Scott K

My apologies.  I intended that to be sent offlist.

Scott K

Re: SPF Not Pass None - patch policyd-spf

[Scott Kitterman]

On Friday, August 06, 2010 10:35:45 pm junkyardma...@verizon.net wrote:
> patch policyd-spf (0.8.0) to support rejection of no SPF record.

This is off topic for postfix-users.  Please file a bug with the patch and we 
can 
discuss it in an appropriate venue:

https://bugs.launchpad.net/pypolicyd-spf/+filebug

Scott K

Re: need help with forged To and From

[Scott Kitterman]

"donovan jeffrey j"  wrote:

>
>On Aug 8, 2010, at 2:16 PM,  
> wrote:
>
>> http://www.openspf.org/
>> 
>
>thanks for the reply,
>since this is not postfix related. I have to go off list. but before I go
>
>i get a little confused when reading the SPF docs. It seems to easy.
>from what i understand I can add a TXT line in my dns config,
>@IN TXT "v=spf1 a:example.com -all"
>
>or 
>
>example.com.   10800   IN  TXT "v=spf1 a:host.example.com -all"
>
>
>do i apply this for the whole domain or just what hosts I authorize to send 
>mail.
>Do i need to apply a record for my MX server ?
>
>The only systems that should be sending mail with my domain are two SMTP 
>relays.; smtp1 and smtp2 respectively.
>-j

See http://www.openspf.org/Forums for information on how to subscribe to the 
spf-help mailing list. The question is on topic there. 

Scott K

Re: couple of doubts about postfix milters

[Scott Kitterman]

"Jose-Marcio Martins da Cruz"  wrote:

>Noel Jones wrote:
>> On 11/9/2010 8:39 AM, Lima Union wrote:
>
>> 
>> clamav-milter operates on the message data, so all postfix 
>> smtpd_*_restrictions -- which operate on the envelope -- will get a 
>> chance to reject mail before the data is transmitted.
>> 
>> sid-milter operates on the envelope.  It will probably run before 
>> smtpd_recipient_restrictions, but that's not such a big deal since
>it's 
>> a fairly lightweight process (minimal CPU, but it does trigger a DNS 
>> lookup).
>
>
>Not sure. The MTA sequentially calls each milter at each SMTP step.
>
>See :
>
>   https://www.milter.org/developers/overview#ControlFlow
>
>So, e.g., for each recipient, postfix will call each milter one after
>the other.
>
>However, I don't know if postfix checks smtpd_recipient_restrictions
>before 
>calling milters or after. I suppose before, but I'm not sure. Wietse
>???
>
>José-Marcio
>
>
>> 
>> Now that I've had more coffee and can think better, this modifies the
>
>> answer I gave earlier -- even though you can't specify sid-miler > 
>> greylist > clamav-milter, that's how it will effectively run.
>> 
>> 
On a related note, I think sid-milter does Sender ID normally and that needs 
the body of the message as it doesn't operate on the envelope.

Scott K

Re: Ubuntu/Debian Postfix 2.8.x repository

[Scott Kitterman]

"Patrick Ben Koetter"  wrote:

>* Mark Alan :
>> > > Do you know any reliable Debian/Ubuntu repositories for the
>> > > newest Postfix 2.8?
>> > 
>> > http://debian.incertum.net/
>> 
>> Thank you, but the emphasis in my question was in 'reliable'.
>> 
>> A quick diff between the 2.8 sources and patches at
>> http://debian.incertum.net/ and the originals at
>> http://www.postfix.org/download.html
>> showed significant differences that are not Debian related.
>> 
>> As such and for now http://debian.incertum.net/ must be seen as its
>> latin name implies incertum (=uncertain, irregular, unreliable)
>
>Have you asked what the changes are for?
>
>I do know Stefan Förster, the guy who runs incertum.net, personally and
>I
>consider him to be a highly responsible and trustfull person, who acts
>very
>reliable.
>
>If there are "significant differences that are not Debian related"
>Stefan
>certainly has had reasons to add them.

Now that Debian Squeeze is released we should have updated Postfix packages in 
Debian Unstable (and Ubuntu) soon.  If there are worthwhile improvements in 
these other packages, I'd be interested to hear about them so we can improve 
the packages in the distro archives.

Scott K

Re: Postfix stable release 2.8.1 available

[Scott Kitterman]

On Wednesday, February 23, 2011 09:02:09 am Christian Roessner wrote:
> Hi,
> 
> > Postfix stable release 2.8.1 is available. This release fixes one
> > "signal 11" bug with SMTP server debug logging, and cleans up some
> > code and documentation.
> 
> Ubuntu packages done.
> 
> https://launchpad.net/~christian-roessner-net/+archive/ppa
> 
> - I dropped HP-UX patches from Debain, as they are useless in Ubuntu
> - I dropped chroot environment, as discussed lately on this list

What to do about chrooting by default is a conversation we should have at the 
distro level.  I know it's a long standing disagreement between upstream and 
the Debian/Ubuntu maintainer, but this isn't the place to resolve it.

Scott K

Re: Postfix stable release 2.8.1 available

[Scott Kitterman]

On Wednesday, February 23, 2011 09:33:35 am Christian Roessner wrote:
> Hi,
> 
> > > - I dropped HP-UX patches from Debain, as they are useless in Ubuntu
> > > - I dropped chroot environment, as discussed lately on this list
> > 
> > What to do about chrooting by default is a conversation we should have at
> > the distro level.  I know it's a long standing disagreement between
> > upstream and the Debian/Ubuntu maintainer, but this isn't the place to
> > resolve it.
> 
> Excuse me, but you took different packages for Ubuntu and my PPA is a
> backport or even does not exist in current Ubuntu releases.
> 
> Removing chroot does even not hurt anybody, because existing
> configurations won't be touched by the distro and newly installed
> instances do not have disadvantages.
> 
> I have not modified the init script, so people still can do chrooting
> and the init script will work as always.

I didn't take anything.  The primary maintainer of the package uploaded 2.8.0 
much as he always does.  As I said before, this isn't the place to discuss it.  
This is my last comment on this thread.

Scott K

Re: Whitelisting secondary MX for spf check

[Scott Kitterman]

On Mon, 14 Sep 2009 19:18:36 +0200 bsd  wrote:
>Hello,
>
>I am using two postfix server and quite often some misconfigured mail  
>server are sending mail to the backup MX instead of the primary.
>Both server have postfix implemented using the 'classic' conf:
>
>in main.cf
>
>> smtpd_recipient_restrictions =
>>permit_mynetworks,
>>permit_sasl_authenticated,
>>check_recipient_access hash:/usr/local/etc/postfix/access
>>reject_unauth_destination,
>>reject_invalid_hostname,
>>reject_unknown_sender_domain,
>># SPF implementation
>>check_policy_service unix:private/policy
>># Greylisting implementation
>>check_policy_service inet:127.0.0.1:10023
>
>and in master.cf :
>
>> # SPF policy implementation /usr/ports/mail/postfix-policyd-spf
>> policy  unix  -   n   n   -   -   spawn
>>   user=nobody argv=/usr/local/sbin/postfix-policyd-spf
>>
>
>
>The problem is that I sometimes have (quite often in fact) rejected  
>mail because they are using spf and the mail is transfered from my  
>backup MX to my master server and my server is considering that second  
>server as the issuer.
>
>Is there any option that I can activate on master.cf or main.cf to  
>avoid that… my initial reading and googling have not been very  
>successful.
>
Not exactly the question you asked, but if you are using one of the policy 
servers from http://www.openspf.org/Software , both provide their own mechanism 
for bypassing SPF checks for specific relays (like secondary MX).

The Python implementation provides this in a proper config file.  The Perl 
implementation is much more primative and you have to edit the actual 
executable script (patches welcome).  In either case, the documentation shipped 
with the packages should explain how to do it.

Scott K

Re: OT: need some advice as to distro

[Scott Kitterman]

On Tue, 01 Dec 2009 09:39:06 -0500 John Peach  wrote:
>On Tue, 01 Dec 2009 16:30:36 +0200
>Eero Volotinen  wrote:
>
>> 
>> > Centos 5.4 - while it looks like a good choice, there has been some
>> > political infighting going on recently which makes us a little
>> > nervous about its future. In addition we have found that a number
>> > of the core packages we wish to use are out of date (postfix,
>> > dovecot, amavisd-new among them).
>> 
>> Centos 5.x is my selection. You can also use packages from epel and 
>> dag's rpm repositories.
>
>It suffers from Red Hat's liking for sendmail. The postfix package is
>aeons old. I would go with Ubuntu (probably 9.04 which is a long-term
>support version).

It's actually 8.04 that's LTS.  The next release (10.04) will be also LTS 
(5 years).

I am in favor of Ubuntu Server for Postfix related uses. Postfix is the 
standard MTA, so it's use is well documented, pretty much everything you 
might want to add on to Postfix is packaged so there's no need to hunt down 
external repositories, and it benifits both from Debian's strong package 
management system and well maintained Postfix package.

Scott K

Re: Policy Daemon in python

[Scott Kitterman]

On Friday, March 25, 2011 05:35:01 pm Gary Smith wrote:
> Does anyone have a simple policy daemon written in Python they would be
> willing to share? I was looking at policy but that's overkill and it might
> require some tweaking just to support my tiny requirements.
> 
> Gary Smith

Sure.

https://launchpad.net/pypolicyd-spf

Scott K

Re: Silly question but I can't figure it out / postscreen implementation / mail transport unavailable

[Scott Kitterman]

On Tuesday, May 03, 2011 01:36:50 PM Bailey, Damian S. wrote:
> Hey all,
> 
> 
> 
> I just updated by backup mail gateway (Postfix/Clam/SA/Amavis) to 2.8 to
> use postscreen.
> 

You may be suffering from this bug:

https://bugs.launchpad.net/bugs/764096

a duplicate report:

https://bugs.launchpad.net/bugs/769514

has some workarounds that have helped some people.  This should be fixed 
shortly.

Scott K

Re: Silly question but I can't figure it out / postscreen implementation / mail transport unavailable

[Scott Kitterman]

On Tuesday, May 03, 2011 02:14:40 PM Bailey, Damian S. wrote:
 
> > -Original Message-
> > From: owner-postfix-us...@postfix.org
> > [mailto:owner-postfix-us...@postfix.org] On Behalf Of Scott Kitterman
> > Sent: Tuesday, May 03, 2011 2:00 PM
> > To: postfix-users@postfix.org
> > Subject: Re: Silly question but I can't figure it out / postscreen
> > implementation / mail transport unavailable
> > 
> > On Tuesday, May 03, 2011 01:36:50 PM Bailey, Damian S. wrote:
> > > Hey all,
> > > 
> > > 
> > > I just updated by backup mail gateway (Postfix/Clam/SA/Amavis) to 2.8 to
> > > use postscreen.
> > 
> > You may be suffering from this bug:
> > 
> > https://bugs.launchpad.net/bugs/764096
> > 
> > a duplicate report:
> >  
> > https://bugs.launchpad.net/bugs/769514
> > 
> > has some workarounds that have helped some people.  This should be fixed 
> > shortly.
> > 
> > Scott K

> Scott,
> 
> Thanks, but I don't think this is my issue.  (Thought the bugs are good
> to know!)
> 
> My mail just isn't being relayed to my email server.  I am running
> Ubuntu, though it's 10.04.2 LTS

No, it wouldn't be that bug then.  It only applies to 11.04.  Sorry for the 
distraction.

Scott K

Trivial typo fix for MULTI_INSTANCE_README.html

[Scott Kitterman]

I noticed this one while reading the document on postfix.org.

Scott K

--- MULTI_INSTANCE_README.html.orig	2011-06-08 22:53:34.647880630 -0400
+++ MULTI_INSTANCE_README.html	2011-06-08 22:54:01.103880784 -0400
@@ -420,7 +420,7 @@
 
 
   Lines 1-2: With "authorized_submit_users = root", the
-superuser can test the postix-out instance with "postmulti -i
+superuser can test the postfix-out instance with "postmulti -i
 postfix-out -x sendmail -bv recipient...", but otherwise local
 submission remains disabled.  
 

Re: Issues with clamav-milter on Postfix

[Scott Kitterman]

On Sunday, June 12, 2011 09:46:41 PM Janantha Marasinghe wrote:
> Hi All,
> 
> I have installed clamav-milter on my postfix 2.7 which is running on
> ubuntu 10.04 server LTS. I have configured the config file where the
> socket is the clamav-milter.ctl but when postfix gets an e-mail it gives
> the warning the directory or file doesn't exist. has anyone got the
> clamav-milter working? a lot less documentation available on the net
> regarding it. thanks

Unless you've changed it, your postfix is running in a chroot.  You either need 
to take it out of the chroot or make the socket available iinside the chroot.  
The easiest way to do this is use a TCP socket (as mentioned in one of the 
other replies in this thread).

Scott K

Re: Milter does not process from postfix 2.7.1-1 (Debian Squeeze)

[Scott Kitterman]

On Wednesday, June 15, 2011 10:43:40 AM J4K wrote:
> Hi there,
> 
> Spamass-milter has stopped processing messages from Postfix.  I have
> tested the milter socket and it works. To test that it worked  I used :-
> http://www.itg.uiuc.edu/itg_software/milter_watch/  and Spamass-milter
> rejected the spammy messages.
> The spam threshold on the spam milter is 11, and it seems that any
> message is getting through.  However, the backend SpamAssassin is
> correctly tagging the messages as spam.
> 
> My objective of mailing this list is to either rule out Postfix config
> problems or not.
> 
> Now I think I know that the milter is functioning, I would like someone
> to check my config to ensure that is it correct.  If some one has the
> time:-
> 
> # postconf -n | grep milter
> milter_default_action = tempfail
> non_smtpd_milters = unix:/dkim-filter/dkim-filter.sock
> smtpd_milters = unix:/clamav/clamav-milter.ctl,
> unix:/spamass/spamass.sock, unix:/dkim-filter/dkim-filter.sock

Debian ships postfix running in a chroot by default.  You either need to change 
master.cf to have it not run in the chroot or arrange to have both these 
sockets available within the chroot.  This is (IME) generally easier to manage 
with TCP sockets than with Unix sockets.

Scott K

Re: Problem with DNS lookup when chrooted

[Scott Kitterman]

On Wednesday, August 10, 2011 05:16:50 PM Stan Hoeppner wrote:
> On 8/10/2011 3:07 PM, ricardus1867 wrote:
> > I'm running Ubuntu 10.04 and I installed Postfix 2.8.4 from Christian
> > Roessner's PPA.
> 
> I just went through the Debian 6.x Postfix 2.7.1 init script, and I'm
> sorry to say that it appears multi instance support was never added.
> Christian's init script is likely the Debian init script.  You may want
> to diff them to confirm.
> 
> A working multi instance patch was submitted via the Debian bug
> reporting system to the package maintainer (I linked it previously
> IIRC), Lamont Jones, _4 years ago_, in July 2007.  It was apparently
> never accepted, and no independent alternative was created.
> 
> Lamont replied once, in Feb 2008, over 6 months after the bug report and
> patch were submitted, simply saying he wanted to "wait for upstream".
> That is the first and last entry in the bug report from the maintainer.
> 
> Thus, I would assume, as long as he's the maintainer, multi instance
> support will never be added to the Debian init script.
> 
> No reason for never implementing multi instance in Debian was given.
> Maybe this was discussed elsewhere and I'm simply unaware of it.

I've discussed it with Lamont in the last few months.  He is aware of it and 
planning on updating the Debian package, but it hasn't quite made the top of 
the TODO list yet.

Scott K

Re: Cert auth failure - untrusted issuer - after postfix upgrade

[Scott Kitterman]

On Saturday, August 20, 2011 02:55:28 PM Georg Sauthoff wrote:
...
> But the script copies the certificates to a wrong location - in my case to:
> 
> /var/spool/postfix/etc/postfix/certs/etc/postfix/certs/
> 
> Correct location would be:
> 
> /var/spool/postfix/etc/postfix/certs/
> 
> After moving the certificates to the right location, everything works as
> expected.
> 
> I can reproduce this issue executing:
> 
> # /etc/init.d/postfix restart
> 
> (which again creates the wrong directory structure)

There are open bug reports for this in Debian and Ubuntu.  I expect this will 
be fixed in the next uploads to each distro.

Scott K

Re: Why does 'help' not work at smtp prompt?

[Scott Kitterman]

On Thursday, October 06, 2011 12:06:41 AM Miles Fidelman wrote:
> Viktor Dukhovni wrote:
> > On Wed, Oct 05, 2011 at 05:28:40PM -0400, Homer Wilson Smith wrote:
> >>  Running Postfix 2.8.2
> >>  
> >>  When I telnet smtp0.lightlink.com 25, and type 'help',
> >> 
> >> it says unknown command.
> >> 
> >>  Thanks in advance for pointers to RTFM.
> >>  
> >>  Homer Smith
> >>  Lightlink Internet
> > 
> > For help with SMTP commands, see:
> > http://tools.ietf.org/html/rfc5321
> > 
> > For help with Postfix:
> > http://www.postfix.org/documentation.html
> > 
> > The Postfix SMTP server does not implement the legacy Sendmail SMTP
> > help interface, this feature is obsolete.
> 
> Last time I looked (just now), RFC5321 stated:
> 
> "SMTP servers SHOULD support HELP without arguments and MAY support it
> with arguments."
> 
> Not implemented, yes, and Postfix properly responds with a 502 response
> code.  Arguably not all that useful when implemented (e.g., as by
> Sendmail).  But neither  "legacy" nor "obsolete" would seem to apply.
> 
> Is this reply nitpicky, and/or pedantic?  Probably.

5321 also says:

"4.1.1.8. HELP (HELP)


   This command causes the server to send helpful information to the
   client.  ..."

It sounds like you got some helpful information, so one might even argue that 
telling you HELP is not implemented is an implementation of HELP.

Scott K

Re: Using Postfix to check and verify SPF

[Scott Kitterman]

On 10/26/2011 10:17 AM, Simon Brereton wrote:
...

So my obvious question to the list is - Can I get amavis to explicity
add a header with the SPF validity, and if not, can I do this with
policyd?  And if not, and I must install postfix-policyd-spf-python
or postfix-policyd-spf-perl which do you recommend and why?


There is an amavis user list that you should consult for amavis support.

postfix-policyd-spf-perl is very simple and is, IMO, not suitable for 
anything other than hobby installs.  postfix-policyd-spf-python is well 
documented, supports a wide variety of configurations for different uses 
and is much more complete.


I'm the last one to do any work on the Perl implementation and the 
developer of the Python implementation.  Unless you are severely 
allergic to Python and prepared to read/modify Perl source, I'd use the 
Python one.  It is available as a distribution package in many distros.


Scott K

Re: Using Postfix to check and verify SPF

[Scott Kitterman]

On 10/26/2011 10:44 AM, Simon Brereton wrote:

On 26 October 2011 10:27, Scott Kitterman  wrote:

On 10/26/2011 10:17 AM, Simon Brereton wrote:
...


So my obvious question to the list is - Can I get amavis to explicity
add a header with the SPF validity, and if not, can I do this with
policyd?  And if not, and I must install postfix-policyd-spf-python
or postfix-policyd-spf-perl which do you recommend and why?

...

postfix-policyd-spf-perl is very simple and is, IMO, not suitable for
anything other than hobby installs.  postfix-policyd-spf-python is well
documented, supports a wide variety of configurations for different uses and
is much more complete.

I'm the last one to do any work on the Perl implementation and the developer
of the Python implementation.  Unless you are severely allergic to Python
and prepared to read/modify Perl source, I'd use the Python one.  It is
available as a distribution package in many distros.


Thanks for the advice.  Curiously for a "hobby installs" package it
has more howtos and documentation on Google.  I'm not adverse to
python, but I'd still like reassurance that two policy filters is the
way to go..  For my edification, where would you put it in my
restrictions?


I'm not sure I understand the rationale behind your current setup well 
enough to make a specific recommendation. I think the documentation 
shipped with both policy servers should give sufficient guidance.


The Perl implementation was done several years before the Python one and 
was, for many years, shipped with Postfix, so it's not surprising that 
it would show up that way.  If it works for you as is, it's fine, but it 
is missing a lot of options supported in the new Python implementation 
(grab the source and read the documentation for details).


Scott K

Re: www.open-spf.org server down ddomain name renewal

[Scott Kitterman]

On 11/03/2011 08:53 AM, David Southwell wrote:

Hi

Just trying to look at www.open-spf.org for some info about a problem and
found their server is down. Godaddy says the domain name has not been
renewed!!


openspf.org (and open-spf.org - they are the same) is down and we're 
working on getting a new server in place.  It's a volunteer project and 
doesn't have as much redundancy as one would like.


In the meantime, since I see you're using an SPF policy server, I'd 
recommend consulting the documentation I provide with it as it should 
cover integration with postfix.


If you have an SPF protocol question, you can ask it on the spf-help 
mailing list:


https://www.listbox.com/subscribe/ and use spf-help for the list name.

Scott K

Re: openspf.org

[Scott Kitterman]

On 11/16/2011 01:01 PM, David Mehler wrote:
> Hello,
> 
> I'm trying to get spf going on my arch postfix server. I'm wanting to
> get perl-policyd-spf going and am atempting to download the needed
> source. The issue is openspf.org appears down, anyone know why or if
> there's an alternative download available?

You should look at openspf.net for now, but also the source for this can
be found at:

https://launchpad.net/postfix-policyd-spf-perl

There is a significantly more capable alternative available at:

https://launchpad.net/pypolicyd-spf

I'd recommend the latter unless you are somehow allergic to Python.

Scott K

Re: Question with Postfix and SPF

[Scott Kitterman]

On Thursday, March 08, 2012 12:44:55 PM Marcelo Vieira wrote:
> Hello,
> 
> I have a question related with Postfix and SPF.
> 
> I have a server configured to check SPF MTA. Two domains uses that MTA.
> 
> When I receive an e-mail from outside (gmail / hotmail etc ...) the
> verification of
> SPF is ok. When sending an e-mail from a domain that exists in the MTA to
> another, the SPF isnt checked, nor any information is written on logs.
> 
> E-mails exchanged between different domains on the same MTA should have
> their SPF checked?

You should probably take this up on an SPF related list.  See 
http://www.openspf.org/Forums for information on how to subscribe to the spf-
help mailing list.

Scott K

Re: OT: spf2.0 (was Re: mx bind ip)

[Scott Kitterman]

Reindl Harald  wrote:

>
>
>Am 10.03.2012 02:08, schrieb Nick Edwards:
>>> thelounge.net.  86400   IN  SPF "v=spf1
>ip4:91.118.73.15
>>> ip4:91.118.73.20 ip4:91.118.73.17
>>> ip4:91.118.73.6 ip4:91.118.73.32 ip4:91.118.73.38 ip4:91.118.73.30
>>> ip4:91.118.73.1 ip4:89.207.144.27 -all"
>>>
>>> thelounge.net.  86400   IN  TXT "v=spf1
>ip4:91.118.73.15
>>> ip4:91.118.73.20 ip4:91.118.73.17
>>> ip4:91.118.73.6 ip4:91.118.73.32 ip4:91.118.73.38 ip4:91.118.73.30
>>> ip4:91.118.73.1 ip4:89.207.144.27 -all"
>> 
>> yes but I also include  'mx' and I never use 'a' or ptr, they are
>> IMHO too wide, BTW, I hope you also use spf2.0 settings as well,
>makes
>> it easier to get higher confidence level in sending to
>> hotmail/live.com :->
>
>no because i did not notice about spf2.0 until now
>and do not find anything about it on openspf.org
>http://www.openspf.org/SPF_Record_Syntax
>
>have you some good documentation/examples
>since i am the developer of our admin-backends
>it should be easy to integrate any record-types
>
I wouldn't worry too much about it.  You won't find anything about it on 
openspf.org because it's is a Microsoft variant that has virtually no support 
in the open source world. There's an IETF working group in progress to move 
SPF, the openspf.org kind, onto its standards track (SPFbis). One probable 
outcome of this work is to deprecate the Microsoft variant.

Scott K

Re: New default settings for "submission" service?

[Scott Kitterman]

On Tuesday, March 13, 2012 07:46:09 PM Robert Schetterer wrote:
> Am 13.03.2012 17:37, schrieb Patrick Ben Koetter:
> > * Patrick Ben Koetter :
> >> * Wietse Venema :
> >>> Different sites have different needs, and perhaps it is an idea to
> >>> provide *multiple* submission service examples in master.cf, all
> >>> commented out of course. The first could be the recommended one:
> >>> not allowing plaintext sessions is good as a general rule. The
> >>> second example could allow plaintext sessions (level = may) but
> >>> allow plaintext passwords only over encrypted sessions.
> > 
> > Here are two examples we all seem to agree on. They differ in TLS
> > (optional/mandatory) and the SASL mechanisms they allow depending on the
> > TLS context.
> > 
> > Additionally, both examples have SMTP session filters that check for
> > syntactic deliverability (MSA job) and add required headers if they are
> > missing.
> > 
> > Filters and fixing headers is a change I'd propose, but nobody seems to
> > have commented on yet. Agreed by everyone?
> > 
> > As a safety net I would change smtpd_client_restrictions into
> > smtpd_recipient_restrictions. This will give a client sufficient time to
> > authenticate and permit_sasl_authenticated will work even if an admin
> > changed the defaults for smtpd_delay_reject. It also makes it possible
> > to filter for reject_non_fqdn_recipient, which the RFC I quoted says to
> > be a MSA job.
> > 
> > 
> > # submission example 1: Optional TLS with SASL methods safe to use over
> > an # unencrypted network
> > #submission inet n   -   -   -   -   smtpd
> > #  -o smtpd_tls_security_level=may
> > #  -o smtpd_sasl_auth_enable=yes
> > #  -o smtpd_sasl_security_options=noplaintext,noanonymous
> > #  -o smtpd_tls_sasl_security_options=noanonymous
> > #  -o always_add_missing_headers=yes
> > #  -o
> > smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_rec
> > ipient,permit_sasl_authenticated,reject #  -o
> > milter_macro_daemon_name=ORIGINATING
> > 
> > 
> > # submission example 2: Mandatory TLS and SASL only over an encrypted
> > network #submission inet n   -   -   -   -   smtpd
> > #  -o smtpd_tls_security_level=enforce
> > #  -o smtpd_sasl_auth_enable=yes
> > #  -o smtpd_tls_auth_only=yes
> > #  -o always_add_missing_headers=yes
> > #  -o
> > smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_rec
> > ipient,permit_sasl_authenticated,reject #  -o
> > milter_macro_daemon_name=ORIGINATING
> 
> Hi Patrick,
> 
> always_add_missing_headers (default: no)
> 
> Always add (Resent-) From:, To:, Date: or Message-ID: headers when
> not present. Postfix 2.6 and later add these headers only when clients
> match the local_header_rewrite_clients parameter setting. Earlier
> Postfix versions always add these headers; this may break DKIM
> signatures that cover non-existent headers.
> 
> are you sure that your example is safe with i.e dkim ?

The MSA should be doing the signing, not the MUA, so it should be.

Scott K

Re: Linux.3 in makedefs & Ubuntu12

[Scott Kitterman]

Quanah Gibson-Mount  wrote:

>I'm testing the ubuntu12 64-bit beta, and had to make the following
>change 
>to makedefs under the Linux.3 category.  Just FYI:
>
>--- postfix-2.9.1.2z/makedefs.orig  2012-01-17 17:19:48.0
>-0800
>+++ postfix-2.9.1.2z/makedefs   2012-03-28 16:43:26.154076634 -0700
>@@ -367,7 +373,7 @@
> SYSLIBS="-ldb"
> for name in nsl resolv
> do
>-for lib in /usr/lib64 /lib64 /usr/lib /lib
>+for lib in /usr/lib64 /lib64 /usr/lib /lib 
>/usr/lib/x86_64-linux-gnu /lib/x86_64-linux-gnu
> do
>test -e $lib/lib$name.a -o -e $lib/lib$name.so && {
>SYSLIBS="$SYSLIBS -l$name"
>
>
>
>Apparently, Ubuntu/Debian put some of the libraries in an architecture 
>specific directory now (x86_64-linux-gnu).  I hit this for libnsl.

wiki.debian.org/Multiarch

Scott K

Re: Postfix missing AUTH?

[Scott Kitterman]

On Thursday, April 05, 2012 02:27:05 PM Mike Jones! wrote:
> I've been following the postfix documentation, but still get no AUTH
> from the daemon.

What documentation specifically have you been following?

Scott K

Re: Postfix missing AUTH?

[Scott Kitterman]

On Thursday, April 05, 2012 02:32:32 PM Mike Jones! wrote:
> On Thu, Apr 5, 2012 at 2:29 PM, Scott Kitterman  
wrote:
> > What documentation specifically have you been following?
> > 
> > Scott K
> 
> Primarily http://www.postfix.org/SASL_README.html#server_dovecot and
> http://www.postfix.org/SASL_README.html#server_sasl_enable

Since your using Debian, there's some additional information here that is 
relevant:

/usr/share/doc/postfix/README.Debian

You can also find Debian specific guidance on this at:

http://wiki.debian.org/PostfixAndSASL

Scott K

Re: Ubuntu Precise packaged 2.9.1 & SSL 1.0.1

[Scott Kitterman]

On Tuesday, June 26, 2012 11:04:16 AM Daniel L. Miller wrote:
> After a recent Ubuntu server upgrade, the packaged versions of Postfix -
> using Ubuntu's "Precise" version, as well as the "security", "updates",
> and "backports" repositories - Postfix's TLS is broken with the known
> SSL version issue:
> 
> warning: TLS library problem: 4425:error:1408F10B:SSL
> routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:340:
> 
> I've tried a couple different main.cf settings, including:
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
> 
> but the only option that has given me temporary functionality is:
> smtpd_tls_security_level=none
> 
> Is there a way I can restore TLS functionality via configuration? Or is
> an updated Postfix, possibly a self-compiled version, my only option?

I have it on my TODO list to do the testing to get the package updated to 
2.9.3 on Ubuntu 12.04, but haven't gotten to it yet.  Since you're interested, 
I went ahead and uploaded the package for test to my PPA at 
https://launchpad.net/~kitterman/+archive/ppa - It won't be compiled there yet 
since I just uploaded it, but it should be available later today or tomorrow.

Scott K

Re: Postfix with Mailman and DKIM signing

[Scott Kitterman]

On Friday, June 29, 2012 06:18:03 PM Andrew Hodgson wrote:
> Hi,
> 
> I currently use a Mailman and Exim4 setup on Debian with Exim running
> the DKIM signing for outgoing mails.  I have VERP set on in some
> lists, and on the lists doing VERP I am getting a very slow delivery
> time (around 10 minutes for 800 subscribers).  If I don't use VERP the
> delivery time increases.
> 
> On the Mailman-users list someone suggested Postfix may be a better
> bet for this type of delivery, I have been looking into this over the
> past few days and I can get the initial Postfix set up on a test VM,
> but want to know the best way of doing DKIM in Postfix?
> 
> Any suggestions greatfully received.

There's more than one way to do it.  The most common these days seems to be 
the opendkim milter.  See opendkim.org for details.  They also have their own 
mailing list where you can ask questions about setup if you have them.

Scott K

Re: Can't get auxprop/sasldb SMTP auth working

[Scott Kitterman]

On Saturday, July 21, 2012 12:34:31 AM Rich Carreiro wrote:
...
Snipping heavily to make it easier to follow.

> However, I am trying to migrate this over to an
> Ubuntu 12.04LTS system running Postfix 2.9.3
> and I just cannot get it to work. I'm doing everything
> the same, but postfix gives authentication failures
> every time.
> 
> It's not the /etc/sasldb2 file.  I've tried bringing
> over the file from the old system and that doesn't work.
> I've created a new file using
> 
> saslpasswd2 -c -u mail.mydomain.com authusername
> 
> and that doesn't work, though it *WILL* work on the old system
> if I copy it to the old system, which is how I know there's
> nothing wrong with the file.

Sometimes Berkeley DB changes it's on disk format.  Cyrus SASL in the 
Debian/Ubuntu packages (I don't recall if it's upstream or a patch) has code 
to upgrade from one format to another, so it's not guaranteed that you can 
copy sasldb files between versions of cyrus-sasl2 that were built with 
different 
DB versions.  I don't know of any incompatibilities, but it's something to be 
careful of.  You've excluded this by trying a new sasldb, but I thought it'd 
be worth mentioning.
 
> Likewise, I know postfix is seeing the smtpd.conf file.
> If I add more mechanisms to the mech_list line of the file,
> I see those extra mechanisms being advertised when I connect
> to the smtpd daemon.  And when I remove them they go away
> again.  So /etc/postfix/sasl/smtpd.conf is clearly
> getting used.

This seems to conflict with what saslfinger shows.

> I am testing both by using an actual mail client and by
> manually talking to the server after generating a token with this:
> 
> perl -MMIME::Base64 -e 'print
> encode_base64("\000authusername\000thePassword");'
> 
> then:
> 
> openssl s_client -quiet -starttls smtp -connect the.newsystem.com:587
> 
> 250 DSN
> EHLO example.com
> 250-the.newsystem.com
> 250-PIPELINING
> 250-SIZE 20971520
> 250-ETRN
> 250-AUTH PLAIN
> 250-AUTH=PLAIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> AUTH PLAIN theBase64EncodedToken
> 535 5.7.8 Error: authentication failed: authentication failure

This exact process works on my Ubuntu 12.04 box.  Did you copy the sasldb into 
the chroot (/var/spool/postfix/etc/sasldb2)?

> But if I instead connect to the.oldsystem.com:587 and do the
> same thing, I get:
> 
> 235 2.7.0 Authentication successful
> 
> The output of saslfinger on the new machine is:

... 
Mine is very similar.  Differences:

> smtpd_sasl_path = smtpd

smtpd_sasl_path =

> -- content of /etc/postfix/sasl/smtpd.conf --
> pwcheck_method: auxprop
> auxprop_plugin: sasldb
> mech_list: PLAIN

-- content of /etc/postfix/sasl/smtpd.conf --
#Global parameters
log_level: 2
pwcheck_method: auxprop
#saslauthd parameters
mech_list: PLAIN LOGIN
#auxiliary plugin parameters:
auxprop_plugin: sasldb

> -- content of /etc/postfix/sasl/smtpd.conf --
> pwcheck_method: auxprop
> auxprop_plugin: sasldb
> mech_list: PLAIN

-- content of /etc/postfix/sasl/smtpd.conf --
#Global parameters
log_level: 2
pwcheck_method: auxprop
#saslauthd parameters
mech_list: PLAIN LOGIN
#auxiliary plugin parameters:
auxprop_plugin: sasldb

...
>   -o smtpd_tls_security_level=encrypt

smtpd_tls_security_level =

(also no milter on submission)
> [snipping the rest of the services]
> 
> -- mechanisms on localhost --
> 
> -- end of saslfinger output --

-- mechanisms on localhost --
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN

Scott K

Re: configuration of mailman with postfix

[Scott Kitterman]

On Wednesday, July 25, 2012 02:36:40 PM Robert Schetterer wrote:
> Am 25.07.2012 14:30, schrieb Eric Smith:
> > Hi
> > 
> > I have the following versions mailman 1:2.1.14-3 on postfix 2.9.1-5 and
> > Ubuntu 12.04 LTS
> > 
> > My installation is for lists on virtual domains
> > NOT foobar.fruitcom.com
> > but complete virtual domains, in  this example
> > foobar.com
> > 
> > When I configure with the following instructions such as this one:
> > http://free-electrons.com/blog/mailman-howto-ubuntu-10-04/
> > 
> > Postfix reports a warning:
> > warning: /etc/postfix/main.cf: unused parameter:
> > mailman_destination_recipient_limit=1
> > 
> > Mails sent to one of the list commit...@foobar.com give the following
> > error: <"|/var/lib/mailman/mail/mailman post committee"@fruitcom.com>
> > (expanded from
> > 
> > ): unknown user: "|/var/lib/mailman/mail/mailman
> > post committee"> 
> > Is there a suggestion to address this particular issue which I
> > think is the expansion to `committee"@fruitcom.com' ,
> > alternatively, are there other complete configure instructions that might
> > work?
> > 
> > Thanks.
> 
> looks to me ,like you miss mailman in the transport table
> 
> 
> look
> 
> https://help.ubuntu.com/community/Mailman
> 
> ---snip
> Associate the domain lists.example.com to the mailman transport with the
> transport map. Edit the file /etc/postfix/transport:
> 
> lists.example.com  mailman:
> ---snipend
> 
> then mailman_destination_recipient_limit=1 should work unless there
> arent any more failures
> 
> 
> http://www.postfix.org/postconf.5.html#transport_destination_recipient_limit
> 
> -snip
> transport_destination_recipient_limit (default:
> $default_destination_recipient_limit)
> 
> A transport-specific override for the
> default_destination_recipient_limit parameter value, where transport is
> the master.cf name of the message delivery transport.
> 
> Note: some transport_destination_recipient_limit parameters will not
> show up in "postconf" command output before Postfix version 2.9. This
> limitation applies to many parameters whose name is a combination of a
> master.cf service name and a built-in suffix (in this case:
> "_destination_recipient_limit").
> --snipend

Additionally, I would strongly recommend re-enabling the precise-updates 
pocket and installing the updated packages.  I know you've disabled them 
because you didn't report having postfix 2.9.3.  Not directly related to this 
issue, but you'll be happier with it in the long run.

Scott K

Re: configuration of mailman with postfix

[Scott Kitterman]

On Wednesday, July 25, 2012 08:55:52 PM Eric Smith wrote:
> Thanks Robert (Scott)
> 
> I have upgraded, checked and followed the Ubuntu docs.
> transport in master.cf corrected (I had a typo that gave the
> error with the user expansion), now it is like this;
> 
> [root@pepper ~] $ grep -A1 mailman  /etc/postfix/master.cf
> mailman   unix  -   n   n   -   -   pipe
>  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
>  ${nexthop} ${user}
> 
> $ mutt fres...@fresher2.nl -stest sudo sh -c "find /var/log/ -mmin -1; grep fresher  /var/log/mail.log|tail
> -1" /var/log/syslog
> /var/log/mail.log
> /var/log/auth.log
> Jul 25 20:45:53 localhost postfix/local[10429]: 70E4329020F: \
> to=<|/var/lib/mailman/mail/mailman post fres...@fruitcom.com>, \
> orig_to=, relay=local, delay=0.17, \
> delays=0.11/0/0/0.06, dsn=5.1.1, status=bounced (unknown user: \
> "|/var/lib/mailman/mail/mailman post fresher")
> 
> FWIW:
> [eric@pepper ~] $ echo $HOSTNAME
> pepper.fruitcom.com
> 
> (Tooth enamel wearing a bit thin)
> 
> Any ideas where I could look?

I've never used mailman, so I don't know for sure about this, but I note 
you're using "user=list" in the flags for the mailman service, but I see 
"/var/lib/mailman/mail/mailman post fresher" in the logs.  Is fresher a valid 
address in your domain?

Scott K

Re: spf configuration how to

[Scott Kitterman]

On Thursday, September 27, 2012 12:51:32 AM Feel Zhou wrote:
> Hello, My friend
> 
> how can I set SPF ( not greylist ) in postfix and DNS Server
> 
> which Document I need to read ?
> 
> Thanks for your time
> 
> TOM

For postfix, I would recommend downloading https://launchpad.net/pypolicyd-spf/ 
and looking at the included documentation (but there is more than one way to 
do it).  For publishing SPF records in DNS, openspf.org is a good resource.

Scott K

Re: Issues with address not listed for hostname

[Scott Kitterman]

On Thursday, October 11, 2012 07:46:22 PM Reindl Harald wrote:
> Am 11.10.2012 19:39, schrieb staticsafe:
> > That has fixed the issue. Thanks for all the help. I do find it a bit
> > weird that the Debian postfix maintainer decided to leave that turned on
> > in the default master.cf that ships with the squeeze package.
> make a bugreport!
> 
> Wietse has blamed him many times here the last years

Don't bother.  It's not going to change.

A bug report explaining what didn't work when chroot'ed would be useful.

Scott K

Re: Issues with address not listed for hostname

[Scott Kitterman]

On Thursday, October 11, 2012 01:58:31 PM Wietse Venema wrote:
> Scott Kitterman:
> > On Thursday, October 11, 2012 07:46:22 PM Reindl Harald wrote:
> > > Am 11.10.2012 19:39, schrieb staticsafe:
> > > > That has fixed the issue. Thanks for all the help. I do find it a bit
> > > > weird that the Debian postfix maintainer decided to leave that turned
> > > > on
> > > > in the default master.cf that ships with the squeeze package.
> > > 
> > > make a bugreport!
> > > 
> > > Wietse has blamed him many times here the last years
> > 
> > Don't bother.  It's not going to change.
> 
> What if I change the built-in default (as opposed to the configured
> default as distributed from postfix.org source code mirrors)?

Lamont would have to answer that.  He and I had discussed this in general 
terms several times and I know he has a strong opinion on the appropriate 
default.  I can't speak for him on this point though.

Scott K

Re: clamsmtp or clamav-milter for antivirus with postfix 2.9?

[Scott Kitterman]

On Friday, October 12, 2012 12:38:28 PM David Mehler wrote:
> Hello,
> 
> This might be off topic, but I was wondering I am using Postfix 2.9.x
> and am wanting to integrate antivirus capabilities. What are the
> differences between clamsmtp and clamav-milter? I'm wondering which
> one would be better for an antivirus setup?

In situations where I was only doing anti-virus and not anti-spam, I've used 
clamsmtp for years with no issues.  It hasn't had a release in awhile, but 
only because it does what it was designed to do and the author decided not to 
try to make it into a swiss army knife.  I know in Debian/Ubuntu clamav-milter 
doesn't have a lot of users and does not get heavily tested.  I don't know 
generally though and have never used it.

In situation where you are doing both A/V and A/S, then I would integrate 
clamav with postfix using amavisd-new.

Scott K

Re: Postfix problems after year of flawless functioning

[Scott Kitterman]

On Tuesday, November 20, 2012 11:07:20 PM Jumping Mouse wrote:
> Hello all my postfix smpt server started acting strangely after a year of
> flawless functioning. 
> 
> I am getting these messages in my mailqueue:
> 
> host 127.0.0.1[127.0.0.1] said: 451 4.5.0 From MTA([127.0.0.1]:10025) during
> fwd-connect (Negative greeting: at (eval 87) line 442,  line 6215.):
> id=12736-02-2 (in reply to end of DATA command)
> 
> I am using amavis for email filtering as well as postgrey
> 
> Postfix version 2.5.1  Ubuntu Server 8.04 LTS
> 
> 
> also when I try to start postfix /etc/init.d/postfix start  I get:
> 
> 
> 
>  * Stopping Postfix Mail Transport Agent postfixpostfix/postfix-script:
> fatal: usage: postfix start (or stop, reload, abort, flush, check,
> set-permissions, upgrade-configuration) [fail]
> 
> 
> 
> But I can start postfix through the postfix webmin module.  
> 
> 
> I have tried removing and reinstalling postfix, amavis and postgrey with no
> luck. 
> 
> I have made no changes to configurations. Just run normal updates.  
> 
> I searched the internet for a solution but no luck.  does anybody have an
> idea about what could be the issue?

Webmin ships it's own postfix configuration files and expects those to be used 
instead of the ones shipped with postfix.  I have seen it before that webmin 
not only didn't use the shipped config files, but it also clobbered them.

I would try to purge postfix (sudo apt-get purge postfix) and then reinstall 
it.  
That will cause dpkg to no longer track that config files have been removed by 
an agent outside the packaging system and reinstall them.

Scott K

Re: [OT] Non-interactive Debian (aptitude) install

[Scott Kitterman]

On Friday, November 23, 2012 07:55:57 PM Glenn Park wrote:
> Hello,
> 
> When I install Postfix using aptitude on a fresh Debian system, an
> interactive GUI comes up asking me how it wants me to configure
> postfix.  I'd like to suppress this interface and make it default to
> "No configuration" (I am automating the installation and have my own
> configuration files, thank you).  However I can find nothing
> documented that allows me to do this.  Can anyone help?

There are some assumptions built into the way the postfix packaging interact 
with debconf that make this a risky thing to do.  See (Debian and Ubuntu are 
the same in this regard):

https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1027061

Scott K

Re: [OT] Non-interactive Debian (aptitude) install

[Scott Kitterman]

On Friday, November 23, 2012 09:29:08 PM Glenn Park wrote:
> On Fri, Nov 23, 2012 at 8:43 PM, Scott Kitterman  
wrote:
> > On Friday, November 23, 2012 07:55:57 PM Glenn Park wrote:
> >> Hello,
> >> 
> >> When I install Postfix using aptitude on a fresh Debian system, an
> >> interactive GUI comes up asking me how it wants me to configure
> >> postfix.  I'd like to suppress this interface and make it default to
> >> "No configuration" (I am automating the installation and have my own
> >> configuration files, thank you).  However I can find nothing
> >> documented that allows me to do this.  Can anyone help?
> > 
> > There are some assumptions built into the way the postfix packaging
> > interact with debconf that make this a risky thing to do.  See (Debian
> > and Ubuntu are the same in this regard):
> > 
> > https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1027061
> 
> Pardon my lack of understanding here (I did read that whole
> conversation), but I'm a little hazy on what the problem is.  What's
> the difference between giving a "No Configuration" answer ahead of
> time/by default and doing it with the GUI that is presented?  But are
> you saying that it's impossible to suppress anyway?
> 
> Rather, you seem to be suggesting that upon update, we may see our
> configuration changed out from under us?  We are not using puppet or
> anything like that.  Config is by hand.

Yes.  The postfix package is designed to be configured by the debconf (Debian 
Configuration) system.  If, in the internal status of the debconf system, 
postfix is marked as "No configuration" via there being no status entry, so 
there's currently no way to distinguish between "desired configuration is 'No 
configuration'" and "Don't do anything, something else will handle it."

I have not had time to research this issue.  I expect it's reasonably 
tractable to fix, but I don't know when I'll be able to get to it.

What I usually do is pick "Internet site" and then modify things from there.  
If you do that once, even if you copy your config files over the provided ones, 
you won't have to worry about your changes getting reverted.

Scott K

Re: [OT] Non-interactive Debian (aptitude) install

[Scott Kitterman]

On Friday, November 23, 2012 11:05:42 PM Glenn Park wrote:
> On Fri, Nov 23, 2012 at 10:02 PM, Scott Kitterman  
wrote:
> > On Friday, November 23, 2012 09:29:08 PM Glenn Park wrote:
> >> On Fri, Nov 23, 2012 at 8:43 PM, Scott Kitterman 
> > 
> > wrote:
> >> > On Friday, November 23, 2012 07:55:57 PM Glenn Park wrote:
> >> >> Hello,
> >> >> 
> >> >> When I install Postfix using aptitude on a fresh Debian system, an
> >> >> interactive GUI comes up asking me how it wants me to configure
> >> >> postfix.  I'd like to suppress this interface and make it default to
> >> >> "No configuration" (I am automating the installation and have my own
> >> >> configuration files, thank you).  However I can find nothing
> >> >> documented that allows me to do this.  Can anyone help?
> >> > 
> >> > There are some assumptions built into the way the postfix packaging
> >> > interact with debconf that make this a risky thing to do.  See (Debian
> >> > and Ubuntu are the same in this regard):
> >> > 
> >> > https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1027061
> >> 
> >> Pardon my lack of understanding here (I did read that whole
> >> conversation), but I'm a little hazy on what the problem is.  What's
> >> the difference between giving a "No Configuration" answer ahead of
> >> time/by default and doing it with the GUI that is presented?  But are
> >> you saying that it's impossible to suppress anyway?
> >> 
> >> Rather, you seem to be suggesting that upon update, we may see our
> >> configuration changed out from under us?  We are not using puppet or
> >> anything like that.  Config is by hand.
> > 
> > Yes.  The postfix package is designed to be configured by the debconf
> > (Debian Configuration) system.  If, in the internal status of the debconf
> > system, postfix is marked as "No configuration" via there being no status
> > entry, so there's currently no way to distinguish between "desired
> > configuration is 'No configuration'" and "Don't do anything, something
> > else will handle it."
> > 
> > I have not had time to research this issue.  I expect it's reasonably
> > tractable to fix, but I don't know when I'll be able to get to it.
> > 
> > What I usually do is pick "Internet site" and then modify things from
> > there. If you do that once, even if you copy your config files over the
> > provided ones, you won't have to worry about your changes getting
> > reverted.
> 
> Woa, wait, so even if I choose "No configuration" in the GUI, my
> config may be overwritten?
> 
> If I have to choose "Internet site" in order to be able to put my own
> config files in place (and not have them overwritten), that's fine.
> But my question is how I can do that unattended?

I believe you can do this using preseeding.  Preseeding is discussed in the 
context of a new system installation here: 
http://wiki.debian.org/DebianInstaller/Preseed

Scott K

Re: Ubuntu Upgrade broke my TLS

[Scott Kitterman]

On Wednesday, December 12, 2012 07:05:51 PM Tony Nelson wrote:
> I just upgraded my Ubuntu server from 10.04 to 12.04 which upgraded Postfix
> to 2.9.1-4.  The postfix server sits behind my firewall, in front of my
> corporate Exchange servers.
> 
> After the upgrade I found that my exchange servers would/could no longer
> send mail.  I got the following error:
> 
> Dec 12 18:48:41 mail postfix/smtpd[3093]: lost connection after EHLO from
> NY-HUBT02.WIN.STARPOINT.COM[192.168.43.
> 19]
> 
> A bit of googling pointed me to TLS issues.  After trying several things, I
> commented out my TLS configuration parameters, and sure enough all of the
> mail flowed out of my Exchange servers, so the problem is definitely TLS
> related.

Re-enable package updates (they are enabled by default).  If you had them 
enabled, you would have postfix 2.9.3-2~12.04.4.  IIRC, there were changes in 
postfix 2.9.2 or 3 to integrate better with openssl 1.0.1, which Ubuntu 12.04 
also ships.

Scott K

Re: Ubuntu Upgrade broke my TLS

[Scott Kitterman]

On Thursday, December 13, 2012 03:05:12 PM Benny Pedersen wrote:
> Tony Nelson skrev den 13-12-2012 02:04:
> > It appears that my upgrade didn't go so well.  After running apt-get
> > update/upgrade I ended up upgrading some 250+ packages, including
> > Postfix.  I now have 2.9.3-2~12.04.4 as you suggested and TLS has
> > started working again.
> 
> thanks for using opensource that are precompiled :=)
> 
> with freebsd/gentoo this problem would not exists

Thanks for spread FUD about other FOSS projects.  If the OP had left his 
system in the default configuration and installed all available updates, the 
problem would not have existed.

Being on FreeBSD or Gentoo wouldn't help if the system isn't kept up to date.

Scott K

Re: clamd with clamsmtp vs mailscanner

[Scott Kitterman]

On Thursday, January 31, 2013 06:33:45 AM Noel Jones wrote:
> On 1/31/2013 5:59 AM, Muhammad Yousuf Khan wrote:
> > i wanted to have an experienced suggestion from Pros. i have been
> > going through from different steps deploying clamav and spamassassin,
> > one is "mailscanner" and seccond one is "clamd with clamsmtp"
> > in your expert opinion which one is the right track to choose. like
> > which one is efficient in perspective of hardware utilization /
> > resources utilization , complexity and more appropriate approach
> > towards stable deployment.
> > 
> > Thanks
> 
> Neither.  If you only want to do virus scanning, use the
> clamav-milter included with clamav.
> 
> Mailscanner is "not recommended" for use with postfix.  clamsmtp is
> more complicated than using the bundled clamav-milter.
> 
> clamav-milter integrates easily with postfix, is reliable, and has
> fewer third-party dependencies compared to the other choices.

What third party dependency does clamsmtp require that isn't also required by 
clamav-milter?

Scott K

Re: clamd with clamsmtp vs mailscanner

[Scott Kitterman]

On Thursday, January 31, 2013 03:29:31 PM John Allen wrote:
> On 31/01/2013 6:59 AM, Muhammad Yousuf Khan wrote:
> > i wanted to have an experienced suggestion from Pros. i have been
> > going through from different steps deploying clamav and spamassassin,
> > one is "mailscanner" and seccond one is "clamd with clamsmtp"
> > in your expert opinion which one is the right track to choose. like
> > which one is efficient in perspective of hardware utilization /
> > resources utilization , complexity and more appropriate approach
> > towards stable deployment.
> > 
> > Thanks
> 
> Why not use Amavis-new as the mail scanner. It will handle the hand off
> to spamassassin and clamav and the return of scanned mail to postfix and
> there are several very good "How to"s on setting it up.

Personally, I use clamsmtp for virus scanning only and amavisd-new if the 
requirement is for both virus and spam scanning.  They all have their 
advantages.

It also depends a bit on what O/S distribution you're using.  In 
Debian/Ubuntu, none of the people who maintain clamav use the milter so it 
gets very light testing at the distribution level.

Scott K

Re: patch: mitigate CRIME attack

[Scott Kitterman]

Andreas Schiermeier  wrote:

>I'm confident our auditors will understand and accept the
>argumentation.
>The finding comes from an automated scan.
>
>It's good to know 2.11 will include the ability to disable compression.
>
>Maybe I'll inform Ubuntu package maintainers about my patch, in case
>there is rising demand for jumping through "stupid hoops" :-).

Discussing that or how to document working around the "issue" would be useful. 
It would be a good topic to discuss on ubuntu-ser...@lists.ubuntu.com.

Scott K

Re: Is it time for 2.x.y -> x.y?

[Scott Kitterman]

On Friday, May 31, 2013 04:56:11 PM Wietse Venema wrote:
> After the confusion that Postfix 2.10 is not Postfix 2.1, maybe it
> is time to change the release numbering scheme.
> 
> We could to the Linux thing where 2.mumble was followed by 3.mumble.
> 
> or we could do it like Sun. After releasing Solaris 2.0 .. 2.6,
> they changed the numbering scheme with Solaris 7 which was released
> way back in 1998. Nowadays, many software distributions change the
> major release number frequently, if not every time.
> 
> If we were to change the release numbering scheme like this with
> Postfix then we would immediately be free from the pain of getting
> sites to adopt Postfix 3.0, because they would no longer expect the
> pain of transitioning from Python 2->3, from perl 5->6 and the like.
> The next Postfix release would be 11.0, so 3.x would never happen.

>From a packaging perspective, as long as the version number always goes up, it 
doesn't matter.  I don't see any reason to change though (for reasons others 
have mentioned that I won't bother repeating).

Scott K

Re: External connection to Postfix problem

[Scott Kitterman]

On Thursday, June 20, 2013 10:19:25 AM Gary Brinker wrote:
>  Because of a hardware failure on an old installation of a postfix gateway I
> took the opportunity to install an up to date version on an Ubuntu server.
> I am not too far into the configuration but am having a basic problem with
> accessing it from external sites. I think I can eliminate the usual DNS and
> router configurations as it did work correctly with the old system. The
> issue is that I can telnet into it internally with no problem but cannot
> reach it externally. I hooked up wireshark and if I'm interpreting it
> correctly I do find the initial SYN come in but no connection is
> established. My reading suggests that I may have an ownership or
> permissions problem, but I'm not finding success in isolating the issue.
> Can anyone point out specifically what I should be looking at to diagnose
> and correct this so I can get on to the meat of the configuration. Thanks
> for any suggestions.

I think it's stunningly unlikely that you are having an issue related to 
upstream Postfix issues.  I would recommend using an Ubuntu server specific 
venue to try and fix the problem.  One would be:

https://lists.ubuntu.com/mailman/listinfo/ubuntu-server

Scott K

Re: Mail server, what else?

[Scott Kitterman]

On Friday, July 12, 2013 05:22:27 PM LuKreme wrote:
> On 12 Jul 2013, at 17:15 , J Gao  wrote:
> > I could use 2.10 but I thought this will be "safe" for CentOS 6.
> 
> It might just be me, but I don't consider any software that is no longer
> supported to be safe, especially not something as critically important as
> an MTA.

Distributors are often placed in the position of needing to support older 
releases than are supported by upstream.  So no longer supported by upstream 
isn't the same as no longer supported.  Personally, I don't get the 
RHEL/CentOS preference for ancient software, but that doesn't mean it's unsafe 
to use.  The most important thing is knowing to go talk to your distributor if 
you have a problem in these cases because it's outside the window of what the 
upstream is paying attention to.

Scott K

Re: Setting up SPF in Postfix for sending

[Scott Kitterman]

b...@bitrate.net wrote:
>On Aug 16, 2013, at 01.56, Rob Tanner  wrote:
>
>> What is it, besides adding the correct the DNS TXT records
>
>as there is a formal dns rr type for spf defined in rfc4408, you'll of
>course want to include that as well.

I wouldn't bother. It has only very limited deployment and is proposed for 
removal in the revision to RFC 4408 that is about to enter IETF last call.

The is, however,  unrelated to postfix.  Either spf-discuss or spf-help would 
be appropriate. See www.openspf.org/Forums for information about these lists. 

Scott K

Re: Setting up SPF in Postfix for sending

[Scott Kitterman]

On Saturday, August 17, 2013 12:16:03 Hans Spaans wrote:
> Scott Kitterman schreef op 2013-08-16 21:06:
> > b...@bitrate.net wrote:
> >> On Aug 16, 2013, at 01.56, Rob Tanner  wrote:
> >>> What is it, besides adding the correct the DNS TXT records
> >> 
> >> as there is a formal dns rr type for spf defined in rfc4408, you'll of
> >> course want to include that as well.
> > 
> > I wouldn't bother. It has only very limited deployment and is proposed
> > for removal in the revision to RFC 4408 that is about to enter IETF
> > last call.
> 
> You may want to check thread "9.3.3 - SPF record checks" from May 30
> 2013 on the bind-users mailinglist.

He's wrong about what most SPF libraries do.  Most don't query for the RR type 
at all, but we'll see how the IETF last call works out.  It is a matter of 
some controversy.

Thanks,

Scott K

Re: Authentication issues

[Scott Kitterman]

On Friday, August 23, 2013 15:38:38 David Hulsebus wrote:
> I apologize in advance for the long post.  I started working for a small ISP
> with around 3000 mailboxes and inherited a Postfix server that I've been
> auditing. It's based on Ubuntu 8.04 LTS, Postfix 2.51, and runs Courier for
> pop and imap authentication. It has encrypted passwords in a MySQL
> database.

That release has been out of security support for a third of a year.  
Upgrading to a supported release should be on your TODO list (pretty high up, 
IMO).

Ubuntu (due to it's Debian heritage) ships  Postfix in a chroot by default.  
Make sure you have either taken it out of the chroot or that your changes are 
visible inside the chroot.  

Scott K

Re: need to purge clamav from postfix configuration

[Scott Kitterman]

On Saturday, September 21, 2013 03:34:57 David Benfell wrote:
> Hi all,
> 
> As near as I can tell debian's clamav is just broken. It keeps whining
> about clamd.ctl and nothing I can find on the web fixes it.

You didn't post your original configuration, so I don't know what your original 
problem was.  If you're using a Unix socket and having a Debian specific 
problem, it's probably a matter of the socket not being available in the 
chroot that postfix, on Debian, uses by default.  Assuming this was your 
original problem, there are three ways to solve it:

1.  Make the socket available in the chroot (/var/spool/postfix/).
2.  Take postfix out of the chroot.
3.  Using TCP sockets instead.

I use the Debian clamav packages every day.  I also maintain them for the 
distro.  If you are having problems, I encourage you to file bugs in the Debian 
BTS.  I do look at them and try to solve them.

Scott K

Re: need to purge clamav from postfix configuration

[Scott Kitterman]

On Saturday, September 21, 2013 17:34:35 li...@rhsoft.net wrote:
> Am 21.09.2013 17:25, schrieb DTNX Postmaster:
> > +1 on using Debian ClamAV packages without any problems. We use the
> > milter package to integrate it with Postfix, using unix sockets.
> > 
> > The problem people generally run into with unix sockets is one of
> > permissions. The milter socket needs to be stored inside the Postfix
> > chroot, and be writable by both Postfix and the milter daemon
> 
> which leaves the question open why the Debian postfix-maintainer
> insists in the *non upstream* chroot-default after years of most
> problems reported here are caused by it?

That's a question best asked on a Debian specific channel.  Personally, I don't 
have any problems with it, it works fine for me.

Scott K

Re: need to purge clamav from postfix configuration

[Scott Kitterman]

On Saturday, September 21, 2013 09:02:05 David Benfell wrote:
> On 09/21/2013 07:36 AM, Scott Kitterman wrote:
> > On Saturday, September 21, 2013 03:34:57 David Benfell wrote:
> >> Hi all,
> >> 
> >> As near as I can tell debian's clamav is just broken. It keeps
> >> whining about clamd.ctl and nothing I can find on the web fixes
> >> it.
> > 
> > You didn't post your original configuration, so I don't know what
> > your original problem was.  If you're using a Unix socket and
> > having a Debian specific problem, it's probably a matter of the
> > socket not being available in the chroot that postfix, on Debian,
> > uses by default.  Assuming this was your original problem, there
> > are three ways to solve it:
> > 
> > 1.  Make the socket available in the chroot (/var/spool/postfix/).
> > 2.  Take postfix out of the chroot. 3.  Using TCP sockets instead.
> 
> The lines I had taken out in main.cf, based on something I found on
> the web, are:
> 
> #content_filter = scan:127.0.0.1:10026
> #receive_override_options = no_address_mappings

What had you configured to listen on port 10026?  Personally, I use clamsmtp 
and amavisd-new (depending on if I'm just doing virus scanning or also doing 
content scanning for spam, etc.)

> And out of master.cf are:
> 
> #127.0.0.1:10025 inet  n -   n   -   16  smtpd
>#-o content_filter=
>#-o
> receive_override_options=no_unknown_recipient_checks,no_header_body_checks
>#-o smtpd_helo_restrictions=
>#-o smtpd_client_restrictions=
>#-o smtpd_sender_restrictions=
>#-o smtpd_recipient_restrictions=permit_mynetworks,reject
>#-o mynetworks_style=host
>#-o smtpd_authorized_xforward_hosts=127.0.0.0/8
> 
> I think of the three choices you offer, I would prefer to take postfix
> out of the chroot. Postfix's configuration is already far more
> complicated than I can even begin to make any sense of, the
> configuration, copied over from a hosed Arch installation (thanks
> systemd upgrade), was not written for it (looking at
> https://we.riseup.net/debian/authenticated-smtp it appears the
> question becomes what else do I need to do to kill the chroot), and I
> would prefer to move in the direction of simplicity.

The upstream master.cf is shipped in /usr/share/postfix (it's master.cf.dist).  
You can check it to verify which services should be removed from the chroot.

> > I use the Debian clamav packages every day.  I also maintain them
> > for the distro.  If you are having problems, I encourage you to
> > file bugs in the Debian BTS.  I do look at them and try to solve
> > them.
> 
> If this were back in the 1970s or early 1980s, when I was a
> programmer, I might be able to discern what is and is not a bug. The
> world has moved quite a ways since then, often leaving me in a state
> of fury, because what everybody else thinks is correct behavior I see
> as absolutely broken. (And systemd on Arch is not the example I would
> choose here: it may be a good idea but it's just not stable yet, it
> obscures far too much, and it's a mistake for me to rely on it.)
> There's no reconciling those worldviews. I can't tell a bug from
> design behavior these days. I just want it to work so I can go back to
> focusing on my Ph.D. program which is *not* technology related.

I think this is likely a configuration issue and not a bug in any case.

Scott K

Re: need to purge clamav from postfix configuration

[Scott Kitterman]

On Saturday, September 21, 2013 23:50:00 DTNX Postmaster wrote:
> On Sep 21, 2013, at 21:29, David Benfell  wrote:
> > At least within postfix, there is a very nice command to just fix the
> > permissions. (Did Wietse get tired of seeing that particular problem?)
> > I have no idea what they should be for clamd.ctl because, as near as I
> > can tell, it isn't a permanent file, so I can't even see it in the
> > emergency backup I did from a rescue system after the Arch upgrade
> > hosed my server (which is remote, by the way).
> 
> This is the socket, and it is or should be created by the ClamAV daemon
> on startup. Check your ClamAV configuration for details, on Debian the
> config files are in '/etc/clamav' by default. If there is no entry
> specifying the location, check the ClamAV docs for the default
> location, which is probably somewhere in '/var/run' or similar.

On Debian (and Ubuntu), as root (or using sudo depending on your system 
configuration) run dpkg-reconfigure clamav-base.  It will, among other things, 
ask you if you want a Unix socket or a TCP socket and what port to listen on.  
This is documented at the top of /etc/clamav/clamd.conf

Scott K

Re: postfix 2.7.1 debian - does not query DNS

[Scott Kitterman]

On Monday, November 11, 2013 20:41:05 Hans Spaans wrote:
> Stan Hoeppner schreef op 2013-11-09 04:22:
> > On 11/8/2013 4:05 AM, li...@rhsoft.net wrote:
> >> there are only rare situations where a chrooted postfix
> >> makes sense and so they should not making a problematic
> >> default which gains nothing on 999 out of 1000 setups
> > 
> > The reason for chrooting Postfix is due to a Debian policy established
> > lng ago, and it is not Postfix specific.  IIRC there's a class of
> > services that all get chrooted in Debian, but for the life of me I
> > can't
> > seem to find the policy doc that explains this.  So far I can't find it
> > in the Debian Policy Manual
> > 
> > http://www.debian.org/doc/debian-policy/
> > 
> > Not sure where it is, but the chroot policy is described somewhere.
> > Debian is pretty good WRT documentation.  Good at making it easy to
> > find
> > is another matter...
> 
> As far as I know it was only under consideration long ago (around the
> time when Solaris Containers where introduced it became a topic again if
> I'm not mistaken) and it is an advisory for building packages on a
> developer machine. Postfix is still one of the few services doing it and
> I still wonder why as it makes things complex to a point where admins
> start playing with ln, chmod and cp to get things working. Reading
> bugreport 151692[1], seeing all the chroot bugreports and taking the
> request from the SELinux Debian Developers into account it makes me
> wonder a lot who is going to end this. Wietse or Debian Technical
> Committee.
> 
> Hans
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=151692

This is increasingly off topic for postfix-users.  I'd suggest taking this up 
in 
a Debian specific forum.  Personally, I run postfix in a chroot everywhere, so 
I 
don't understand the fuss.  There are occasional problems and they get fixed.

The Debian maintainer has a different view than the upstream developer on 
default configuration is not at all an unusual thing to happen, but it needs to 
be addressed in the distro, not here.

Scott K

Re: can someone explain this SPF fail to me

[Scott Kitterman]

Kris Deugau  wrote:
>jeffrey j donovan wrote:
>> Greetings,
>> 
>> Can someone explain this error to me, I have never seen this one
>before. I tested my spf records and they seem fine. 
>> 
 : host mail.ncem-pa.org[204.186.202.37] said:
>554
5.7.1 : Recipient address rejected: Failed
>SPF
check; beth.k12.pa.us, Redundant applicable 'v=spf1' sender
>policies found
(in reply to RCPT TO command)
 Reporting-MTA: dns; smtp5.beth.k12.pa.us
>> 
>> in this , it looks like the user recipient address is incorrect or
>something along those lines.
>> I do have two spf records, one for my relays and one for google.
>
>I'm not completely clear on what you mean by "one for my relays and one
>for google", but you have two SPF records published publicly.  Don't Do
>That.  (I don't think it's strictly a violation of the spec, but
>clearly
>the recipient is being picky.)

It is an error. The recipient is choosing to reject based on an error condition 
that is specified in RFC 4408 (and still in the not quite released 4408bis).

Scott K

Postfix Architecture Overview

[Scott Kitterman]

I thought there might be people here that would find this of interest:

http://liquidat.wordpress.com/2014/02/25/postfix-architecture-overview/

Scott K

Re: DKIM, DMARC, Original-Authentication-Results

[Scott Kitterman]

On April 10, 2014 7:24:54 PM EDT, LuKreme  wrote:
>
>On 10 Apr 2014, at 17:01 , Viktor Dukhovni 
>wrote:
>
>> On Fri, Apr 11, 2014 at 12:57:54AM +0200, li...@rhsoft.net wrote:
>> 
 That said, I thought DKIM ignored everything after the signature
 delimiter, so if the lists attach the footer *properly* it
>shouldn?t
 be an issue
>> 
>> No, the DKIM spec makes no allowance for signature delimiters.  If
>> the body is modified beyond adding removing whitespace (with relaxed
>> canonicalization) the DKIM check fails.
>
>That seems like a bug in the implementation of DKIM.

It was a deliberate design choice. The signature wouldn't mean much if adding 
arbitrary text to the message didn't invalidate the signature. It would open 
the protocol up to replay attacks. 

There is a virtually unused L tag to embed the length of signed content into 
the signature, but its use is strongly disrecommended.

>>> the subject also don't matter in case of signed messages
>>> it is a HEADER and headers are added at every hop
>> 
>> DKIM also signs message headers.
>
>Certain headers, not all of them.

Yes, but subject is generally signed (I don't recall seeing a case where it 
wasn't).

Scott K

Re: Reverse DNS Lookup

[Scott Kitterman]

On Tuesday, April 22, 2014 18:36:08 Erwan David wrote:
> Le 22/04/2014 18:29, Tim Smith a écrit :
> > Just trying to get my head round the error and understand what is
> > actually happening.
> > 
> > So to summarize, the delivery.mailspampropection.com domain has 81 A
> > records which, when queried won't fit into a UDP packet which explains
> > why Postfix correctly says it can't resolve the hostname.
> > 
> > Is there some kind of fix I can employ here for this particular
> > server? Would entries in the /etc/hosts file work? I assume that if I
> > have "multi on", I can put an entry in for each A record?
> 
> In that case DNS should switch to TCP or use EDNS, both MUST be
> available in a modern installation, because DNS answers become larger
> with new features (IPv6 addresses, DNSSEC, etc.)

Yes, but all it takes is one firewall that blocks TCP port 53 and the TCP 
fallback fails.  Even on the modern internet you have to try to fit in a UDP 
packet if you want reliable service.

Scott K

Re: SSL LDAP maps cause SEGV in cleanup

[Scott Kitterman]

On May 24, 2014 1:14:13 AM EDT, Viktor Dukhovni  
wrote:
>On Fri, May 23, 2014 at 10:06:28PM +, Viktor Dukhovni wrote:
>
>> On Fri, May 23, 2014 at 03:27:54PM -0500, Jeff Larsen wrote:
>> 
>> > > Others may not be able to reproduce your problem.  Ideally you'd
>help
>> > > the community by identifying the call sequence (stack trace from
>debugger
>> > > attached to faulting cleanup process).
>> > 
>> > The trace is here: http://pastebin.com/Lt9gb6jV
>> 
>> This is a syscall trace, not a stack trace, but it is still
>informative.
>> 
>> Your OpenLDAP library is linked with GnuTLS, not OpenSSL, and it
>> is GnuTLS that is segfaulting when it is unable to open /etc/passwd.
>> Either getpwuid() in libc breaks in this case, or GnuTLS is not
>> checking return values properly in some way.
>
>The problem appears to have been accidentally fixed in GnuTLS 3.3.0
>which postdates the release in Ubuntu 14.04.  The broken code is
>now dead code inside while (0) { ... problem code ... }.
>
>The reason for the while (0) was to reduce the GnuTLS stack footprint,
>not to fix the problem, so the problematic code is still there, but it
>is now dead code:
>
>gnutls/lib/system.c:
>
>   while(0) {
>   struct passwd *pwd;
>   struct passwd _pwd;
>   char tmp[512];
>
>   getpwuid_r(getuid(), &_pwd, tmp, sizeof(tmp), &pwd);
>   if (pwd != NULL) {
>   snprintf(path, max_size, "%s/" CONFIG_PATH, 
> pwd->pw_dir);
>   } else {
>   path[0] = 0;
>   }
>   }
>
>The code should be checking the return value of getpwuid_r, not
>whether it set pwd to zero or not (and the pointer should have been
>initialized).  One can hope this dead code will either be removed
>or fixed (or in any case never revived, nor copied by anyone else).
>
>Ubuntu has the version without the while (0) { ... } guard.

If someone can provide a reduced test case to reproduce the bug and validate 
it's fixed, I can probably get this fixed in Ubuntu 14.04 as a post-release 
update.

Probably best to contact me off list since it's not really a postfix issue. 
Ubuntu-devel-discuss would be the appropriate Ubuntu list to continue this.  
Private mail is fine too.

Scott K

Re: Before rushing into writing my own policy daemon for postfix, what are the options?

[Scott Kitterman]

On Monday, June 16, 2014 00:53:14 Eliezer Croitoru wrote:
> On 06/15/2014 11:11 PM, li...@rhsoft.net wrote:
> > what you describe is*the minimum*  requirement of a sane MTA
> > you must not allow senders you would not accept incoming messages
> > and no - there are no exceptions for whatever user
> 
> I am not sure you understand it but there is little doubt we are talking
> about the same thing or not.
> The postix server is allowing for now to relay any email by from any
> email if the user is locally authenticated.
> Others are just blocked.
> A local user can send as itself... and as otherusern...@google.com.
> Other servers might not like it and will enforce SPF the same way this
> server uses it.
> I want to force only on authenticated users (since there are other
> automated systems that rely on the service) a rule that will force them
> to only use the local domains in the "From:" header of the mail body.
> For now I enforce rate limiting and other means of enforcement on the
> service usage to prevent and detect abnormal usage and abuse of the
> local network SMTP relay service.(which works so good that people who
> abuse it are stuck in one sec to more then 24 hours no matter if they
> scream shout or anything else...)
> 
> For now the users and authenticate and send a mail as "u...@google.com"
> or "u...@hotmail.com" since the SPF rules of these providers allow a
> SOFT SPF enforcement.
> I would like to harden the service one level up and not allow this
> unless strictly allowed by the admin of the service not related to SPF.

If I understand what you're after, reject_authenticated_sender_login_mismatch 
may well do exactly what you want.

Scott K

Re: Individual smtpd_tls_ask_ccert?

[Scott Kitterman]

On July 29, 2014 7:15:04 PM EDT, BlueStar88  wrote:
>
>Am 29.07.2014 um 19:40 schrieb Viktor Dukhovni:
>> On Tue, Jul 29, 2014 at 07:24:41PM +0200, BlueStar88 wrote:
>>
>>> First we should extend DNS using another MX-like entry, to be able
>to
>>> define authoritative MTA client nodes for a specific domain, so we
>have
>>> something to stick on.
>> This was abandoned in favour of SPF, DKIM and DMARC.
>>
>> http://tools.ietf.org/html/draft-crocker-csv-csa-00
>> It was an anti-spam measure, and has no direct bearing on TLS client
>> authentication.
>
>That RFC is from 2005 and was considered for anti-spam, as you've said.
>But does that mean, it is buried forever?
>If we have a new - and quite serious - purpose here (having mutual TLS
>security in mind), it should be revived to support that.
>
>If there's another way, I'm fine with that. But we have to improve here
>by any means, to keep up with the ongoing arms race.
>Having neat things like DNSSEC and DANE to backup up TLS security
>doesn't make much sense, if only one party/peer of each connection can
>uphold a certain security level.

CSV doesn't really offer more than an SPF check on the HELO identity.  It's 
dead. 

Scott K

Re: client hostname resolution

[Scott Kitterman]

On Tuesday, August 26, 2014 00:04:31 Martin Vegter wrote:
> > On 08/25/2014 11:28 PM, Wietse Venema wrote:
> >> Do I ned to change any settings in postfix, so that client IPs are
> >> resolved into hostnames?
> > 
> > You need the correct DNS server in /etc/resolv.conf.
> > 
> > You must not have "disable_dns_lookups=yes" in main.cf or master.cf.
> > 
> > You must not have "smtpd_peername_lookup=no" in main.cf or master.cf.
> > 
> > You may also need to turn off chroot per instructions in
> > http://www.postfix.org/DEBUG_README.html#no_chroot
> 
> I have turned off chroot for smtp and now it works.
> But that is not an optimal solution. I would like to keep chrooted smtp.
> 
> Is there any way to make it work even in chroot? I see, Postfix has all
> the necesary files in /var/spool/postfix/etc:
> 
> $ ls /var/spool/postfix/etc
> hosts  localtime  nsswitch.conf  resolv.conf  services
> 
> and the config options you mentioned are OK as well:
> 
> disable_dns_lookups=no
> smtpd_peername_lookup=yes

Since, as mentioned downthread, this is more related to distribution packaging 
than upstream postfix, it would probably be better to take this up in a Debian 
specific user forum.

Scott K

Re: RELEASE: Postwhite 0.1.0

[Scott Kitterman]

On Thursday 24 July 2008 12:37, Sven Schwyn wrote:
> Hi
>
> I've just released the first version of Postwhite, a policy server for
> Postfix which implements whitelisting. These per-recipient whitelists
> are entirely managed by use of emails.
>
> http://www.bitcetera.com/products/postwhite
>
> Here's a real-life example of what Postwhite does:
>
> Arthur‘s main email address [EMAIL PROTECTED] is great for everyday use,
> but he doesn‘t want to pollute it by using it for mailing lists,
> websites, online shopping and such. Postwhite to the rescue! Arthur
> creates a virtual email address [EMAIL PROTECTED] which is delivered
> to the same mailbox.
>
> Initially, all incoming emails will be rejected, so when Arthur
> decides to join the Betelgeuse mailing list (digest), his whitelist
> has to learn about this. Arthur sends an empty email to
> [EMAIL PROTECTED] which puts Postwhite into learning mode for a
> limited period of
> time. In learning mode, Postwhite allows and delivers any incoming
> mails, yet it delivers a followup notification message along with it.
> When the first email from the Betelgeuse mailing list comes in, Arthur
> simply replies to the corresponding notification message thus adding
> Betelgeuse to the whitelist.
>
You appear to have missed the next step where spammers scrape Arthur's list 
mail address from the mailing list archives and use it as the Mail From 
address in spam they send to him.

Scott K

Re: RELEASE: Postwhite 0.1.0

[Scott Kitterman]

On Fri, 25 Jul 2008 20:28:45 +1000 Daniel Black 
<[EMAIL PROTECTED]> wrote:
>On Fri, 25 Jul 2008 06:32:13 am Scott Kitterman wrote:
>> You appear to have missed the next step where spammers scrape Arthur's 
list
>> mail address from the mailing list archives and use it as the Mail From
>> address in spam they send to him.
>>
>> Scott K
>
>Just need to make sure the list owner has deployed SPF and DKIM before 
>then :-)
>
My first thought when I read that was 'or' not 'and'.  My second was, 'Not 
really'. 

Based on the example, he's whitelisting based on Rcpt To. In my counter 
example the local domain is being used in both Mail From and Rcpt To, so 
the only domain's SPF that might enter into this is his own.  SPF can be 
used to reject such messages, but there are other ways to do it for your 
own domains.

The policy service does not have access to the message body, so no DKIM 
either.

A domain level whitelist function based on SPF Pass or good DKIM signatures 
would potentially be useful (no way to do the latter in a policy server in 
any case), but that doesn't seem to be what's on offer here.

Scott K

Re: Connection timed out

[Scott Kitterman]

On Tue, 29 Jul 2008 14:59:25 +0100 Evan Ingram <[EMAIL PROTECTED]> 
wrote:
>On Tue, 2008-07-29 at 15:46 +0200, mouss wrote:
>> some sites drop traffic from residential blocks, which could explain why 
>> you cannot connect.
>
>
>Hmmm That would make sense. But what about the other machines I have
>here being able to connect to the problem mail servers via telnet etc
>but my mail server cannot? :/
>
>
These restrictions are generally limited to port 25.  Are you able to 
telnet from other machines on port 25?

Scott K

Re: postfix-policyd-spf

[Scott Kitterman]

On Wednesday 20 August 2008 11:30, LuKreme wrote:
> I installed postfix-policyd-spf (postfix-policyd-spf-1.0.1_2 via
> portinstall) and added the following to master.cf and main.cf:
>
> main.cf Added
> check_policy_service unix:private/policy
>
> (this is immediately after reject_unauth_destination)
>
> master.cf Added
>   policy  unix  -   n   n   -   -   spawn
> user=nobody argv=/usr/local/sbin/postfix-policyd-spf
>
> Now it occurs to me that I should have rebuilt postfix with SPF
> support in it, so I've disabled the lines in main/master until I get
> some comments...

There is no need to patch Postfix for this and patching Postfix won't help.  
As long as you have the correct Perl SPF library installed it should work.

Scott K

Re: postfix-policyd-spf

[Scott Kitterman]

On Wednesday 20 August 2008 22:27, LuKreme wrote:
> On 20-Aug-2008, at 09:42, mouss wrote:
> > LuKreme wrote:
> >> I installed postfix-policyd-spf (postfix-policyd-spf-1.0.1_2 via
> >> portinstall) and added the following to master.cf and main.cf:
> >> main.cf Added
> >> check_policy_service unix:private/policy
> >> (this is immediately after reject_unauth_destination)
> >> master.cf Added
> >> policy  unix  -   n   n   -   -   spawn
> >>   user=nobody argv=/usr/local/sbin/postfix-policyd-spf
> >> Now it occurs to me that I should have rebuilt postfix with SPF
> >> support in it, so I've disabled the lines in main/master until I
> >> get some comments...
> >
> > there is no "spf support in postfix".
>
> Hmmm. in the config screen for the postfix port there is the line:
>
>   │ [ ] SPF  SPF support
>
> Erm... at least that was in postfix22, not sure if it's in 2.5.x

There was an unofficial patch that was the only way to do it for Postfix 2.0 
(before the policy service existed).  While that might possibly made sense in 
2003, there's no need for it for a long time.  The SPF project removed 
references to the patches from it's web site years ago.

If the BSD ports packager is including it, then they really ought to update 
their package.  Use a policy server or a milter.  There are several to choose 
from.

http://www.openspf.org/Implementations

Scott K

Re: Postfix TLS and M$ Outlook Express

[Scott Kitterman]

On Wednesday 20 August 2008 20:01, Michael wrote:
> Has anyone else here found incompatibilities between these two?
>
> My TLS implementation works fine sending from KDE Kmail, but I can't use
> Outlook Express' secure option.

Depending on the version of OE involved (I believe the current version finally 
support TLS) you'll need to enable SMTPS on port 465 to support OE via SSL.

Scott K

Re: Postfix TLS and M$ Outlook Express

[Scott Kitterman]

On Fri, 22 Aug 2008 02:39:47 +1200 "Michael Hallager" 
<[EMAIL PROTECTED]> wrote:
>
>- Original Message - 
>From: "Brian Evans - Postfix List" <[EMAIL PROTECTED]>
>To: 
>Sent: Friday, August 22, 2008 1:50 AM
>Subject: Re: Postfix TLS and M$ Outlook Express
>> Michael wrote:
>>> On Fri, 22 Aug 2008 01:07:12 Dave wrote:
>>>
 Hello,
 When i used outlook express and tls it worked fine. There's sasl issues
 with OE, if your using sasl i do have a fix for those i'll have to 
look 
 in
 my main.cf, but it's an issue.
 Dave.

>>>
>>> SASL works for me with OE.
>
>I get the following error message, regardless of whether secure passwd 
auth 
>is set or not-
>
>Your server has unexpectedly terminated the connection. Possible causes 
for 
>this include server problems, network problems, or a long period of 
>inactivity. Account: 'mail.nettrust.net.nz', Server: 
'mail.nettrust.net.nz', 
>Protocol: SMTP, Port: 25, Secure(SSL): Yes, Error Number: 0x800CCC0F

Note the port number (25).  More than one person has suggested you need to 
set up smtps on port 465.  You do.

>For some unknown reason POP3 also fails as well with SSL selected.
>
>Both work fine with TLS set under KDE Kmail.
>
Kmail does TLS on port 25 just fine.

>>>
>>> It's TLS that is failing. I will come back to the list with more info 
>>> like
>>> error messages etc.
>>>
>>
>> Please review the DEBUG_README.
>> Particularly http://www.postfix.org/DEBUG_README.html#sniffer for your 
>> case.
>>
>> Also read http://www.postfix.org/DEBUG_README.html#mail.
>>
Note that the Postfix logs will likely be more useful than the error 
messages you've posted so far.  I suggest another read of the DEBUG_README.

Scott K

Re: Enable SMTP Authentication

[Scott Kitterman]

On Fri, 22 Aug 2008 20:27:57 +0200 mouss <[EMAIL PROTECTED]> wrote:
...
>once dovecot is configured, read
>   http://www.postfix.org/SASL_README.html
>to setup postfix. Make sure your postfix was built with dovecot (sasl) 
>support (so don't use an "ancient" postfix).
>
I don't recall if the Feisty Postfix was built with support for Dovecot 
SASL or not.  Postfix 2.5.4 is available in the community supported 
feisty-backports repository if you need it.

Scott K

Re: SPF Checking

[Scott Kitterman]

On Tue, 26 Aug 2008 12:16:00 -0400 "Raymond Jette" <[EMAIL PROTECTED]> 
wrote:
>Good afternoon,
>
>I am using Postfix with postfix-policyd-spf-python for SPF. This is
>rejecting mail from the HELO verb. According to RFC 4008:
>
> 
>
>   The "HELO" identity derives from either the SMTP HELO or EHLO command
>
>   (see [RFC2821]).  These commands supply the SMTP client (sending
>   host) for the SMTP session.  Note that requirements for the domain
>   presented in the EHLO or HELO command are not always clear to the
>   sending party, and SPF clients must be prepared for the "HELO"
>   identity to be malformed or an IP address literal.  At the time of
>   this writing, many legitimate E-Mails are delivered with invalid HELO
>   domains.
 
The policy server is designed with this in mind.  Broken HELO names will 
not cause it to reject mail.  If it is, it's a bug and I'd appreciate 
evidence in the form of logs so I can fix it.

>Is there a way to disable SPF checking in the HELO part of a message?

Yes.

>Also, is there a way to bypass spf for a given host or domain?

Yes.

See the man pages installed with the package for details.

If you need more help, the spf-help mailing list is probably more 
appropriate.  See http://www.openspf.org/Forums for information on how to 
subscribe.

Scott K

Re: libspf2 Vulnerability [from another list...]

[Scott Kitterman]

On Tue, 21 Oct 2008 23:59:00 -0400 Victor Duchovni 
<[EMAIL PROTECTED]> wrote:
>
>All libspf2 users should read this post by Dan Kaminsky, and upgrade  
>libspf2 to 1.2.8 as soon as possible:
>
>http://www.doxpara.com/?p=1263
>
FWIW, the Ubuntu libspf2 packages for all releases have been patched to 
correct the buffer overflow mentioned in the article and 1.2.8 will be 
included in the next release.  There is also a patched version for Debian 
Lenny published and one for Etch is imminent.

Scott K

Re: [OFF] SPF

[Scott Kitterman]

On Tue, 04 Nov 2008 14:56:10 -0200 Márcio Luciano Donada <[EMAIL PROTECTED]> 
wrote:
>Hi,
>
>I am now using the policyd as shown below:
>
>main.cf
># SPF
>spfpolicy_time_limit = 3600
>smtpd_recipient_restrictions = ...
>check_policy_service unix: private / spfpolicy
>...
>
>master.cf
>#SPF
>spfpolicy unix - nn - - spawn
>user = nobody argv = /usr/lib/postfix/policyd
>
>
>now the message below is due to the SPF spfpolicy_time_limit:
>
>warning: problem talking to server private/spfpolicy: Connection timed
>
>But the problem is that I am still in the logs
>"server configuration problem"
>
>When disable the rules of SPF of postfix, I have no further message
>"server configuration problem"
>
>Some ideas.

I'm not sure what version you have, but your setup does not line up with the 
upstream recommendations.  I'm out of the office and don't have the docs, but 
if you get the latest version at http://www.openspf.org/Software and check, 
that may help.

Scott K

Re: [OT] postmaster@ for customers' domains?

[Scott Kitterman]

On Fri, 07 Nov 2008 20:58:25 -0600 "Gerald V. Livingston II" 
<[EMAIL PROTECTED]> wrote:
>Martin Strand wrote:
>> We're an email service provider hosting ~3000 domains. Customers can
>> delegate their domains to our nameservers and administer email
>> accounts with a web interface.
>> 
>> I figured it would be a good idea to reserve the postmaster@ and
>> abuse@ addresses for hosted domains and forward them to our own
>> postmaster account.
>> 
>> Now one of these customers wants to create a [EMAIL PROTECTED]
>> account and use it for his personal email... I just want to ask what
>> you guys think about this policy, am I just being silly when
>> reserving these addresses in the customer's own domain? Should I drop
>> that restriction and leave their domains alone?
>> 
>> Thanks, Martin
>
>You need to tell the user to read RFC 2821 and get over it. "postmaster" 
>is not for personal mail.
>
>Any system that includes an SMTP server supporting mail relaying or
>delivery MUST support the reserved mailbox "postmaster" as a case-
>insensitive local name.  This postmaster address is not strictly
>necessary if the server always returns 554 on connection opening (as
>described in section 3.1).  The requirement to accept mail for
>postmaster implies that RCPT commands which specify a mailbox for
>postmaster at any of the domains for which the SMTP server provides
>mail service, as well as the special case of "RCPT TO:"
>(with no domain specification), MUST be supported.
>
>As noted above, if the domain doesn't reserve the postmaster address 
>then it must return a 554 for every incoming connection and *NOT* accept 
>*ANY* mail for *ANY* address on the domain (eg. a smtp server intended 
>for use only on a private WAN could accept mail for its member cidr 
>ranges but must 554 all mail from outside unless postmaster is reserved 
>and working for its intended purpose).
>

Well yes, but whose domain is it?  

The domain owner is responsible for monitoring these addresses.  If the 
domain owner chooses to delegate that responsibility to their domain host 
chooses to host and the domain host chooses to offer that service, I think 
it's perfectly appropriate.  I think its reasonable for a domain host 
insist that these addresses exist and be deliverable.  OTOH, if a provider 
prevented me from controlling these addresses in my domains so I could 
monitor postmaster/abuse, I'd definitely be cancelling my account.

If you choose to continue this policy it should be clearly explained in 
your terms of service.

Scott K

Re: policy daemon to greylist on SPF failure?

[Scott Kitterman]

On Wed, 19 Nov 2008 13:44:48 -0500 (EST) Justin Piszcz 
<[EMAIL PROTECTED]> wrote:
>Was curious if there were any daemons out there that currently did this, 
or if 
>I should just modify the main spf checking script that openspf.org 
provides?
>
I think tumgreyspf will do this. Alternatively, you could do this with 
restrction classes and a separate policy server for greylisting.  The 
Python policy server on openspf.org can be set up to do the SPF part pretty 
easily and there is a README on integration with Postfix restriction 
classes.

Scott K

Re: postfix error shown in mail.log

[Scott Kitterman]

On July 26, 2021 8:59:00 AM UTC, Vincent Lefevre  wrote:
>On 2021-07-24 09:29:04 +1000, raf wrote:
>> On Fri, Jul 23, 2021 at 04:13:00PM +0200, Jean-François Bachelet 
>>  wrote:
>> 
>> > Hello ^^)
>> > 
>> > I found that error in mail.log, at each start postfix issue that error :
>> > 
>> > 'Jul 23 15:36:57 discovery postfix/postfix-script[1170]: warning: symlink
>> > leaves directory: /etc/postfix/./makedefs.out'
>> > 
>> > is that warning harmless or not ?
>> > 
>> > Jeff
>> 
>> I'm pretty sure that that file is put there as part of
>> the debian package (even though it doesn't show up in
>> dpkg-query -L postfix). I had it too.
>
>It is not part of the Debian package, but installed by the
>postfix.postinst script:
>
># we want it out of /etc to not be a conffile, but users might expect it there
># so leave a symlink at the expected place in /etc
>if [ -f "/usr/share/postfix/makedefs.out" ]; then
>if [ ! -e "/etc/postfix/makedefs.out" ]; then
>ln -s /usr/share/postfix/makedefs.out /etc/postfix/makedefs.out
>fi
>fi
>
>If I understand correctly, it is a normal file in postfix
>(it is listed in the postfix 3.6.1 tarball in conf/postfix-files:
>"$meta_directory/makedefs.out:f:root:-:644"), but Debian chose
>to move it into /usr/share/postfix and added a symlink to this
>file. The probable reason is that this file is not a configuration
>file and should not be modified.
>

Close.  

The Debian package management system tracks system induced changes in /etc and 
notifies users about them during package upgrade.  Before I moved the file to 
/usr/share/postfix, there were alerts during package upgrade every time if 
makedefs.out changed (i.e. every time).

I agree with the warning since permissions in the target directory might be 
inappropriate.  In this case I've checked it before I put the symlink in place 
and it's fine.

There are a limited number of options:

1. Don't install makedefs.out, which means the standard postfix installation is 
incomplete (this is what Debian used to do).

2.  Put it in /etc, which means the admin gets notified about changes in the 
file on package upgrade (which made no one happy).

3.  Put it elsewhere and provide a symlink, which means the warning.

4.  Put it elsewhere and patch away the warning.

None of those are ideal.

Scott K 

Re: postfix error shown in mail.log

[Scott Kitterman]

On July 28, 2021 2:58:21 PM UTC, Viktor Dukhovni  
wrote:
>If the postfix-files file does not reflect the content delivered by
>the package, you would typically see errors running "postfix check".
>Either the package should deliver all the files expected upstream,
>or the "postfix-files" file should be updated to match the package
>content.
>

I think it matches.  Last year I went through and checked.  I'll check it again.

Scott K

Re: will this break DMARC?

[Scott Kitterman]

On August 13, 2021 12:05:44 PM UTC, post...@ptld.com wrote:
>Raf,
>Im confused by this, i thought as long as either dkim or spf passes then 
>dmarc passes. But i still see dmarc fails.
>
>   Envelope-From: dovecot-boun...@dovecot.org
>   Header From: some...@netcourrier.com
>
>   DKIM: bad signature data
>   DMARC: SPF(mailfrom): dovecot.org pass
>   DMARC: netcourrier.com fail
>
>Shouldn't dmarc pass with the good SPF?

It has to pass and align.  Mail from domain and From domain aren't aligned.

Scott K

Re: heads up: dkimpy-milter signing breaks w/ python 3.10 (e.g., @ fedora 45 -> 35 upgrade)

[Scott Kitterman]

On November 2, 2021 8:18:54 PM UTC, PGNet Dev  wrote:
>
>i've reported the bug here,
>
>  python 3.10 incompat, exec FAILs @ "SystemError: PY_SSIZE_T_CLEAN macro must 
> be defined for '#' formats"
>   https://bugs.launchpad.net/dkimpy-milter/+bug/1949520
>
>fwiw, python 3.9 still works as expected
>
>now to poke at it ...
>

Thanks.  From the error message, that looks like something from the Python C 
API, so it's almost certainly in the pymilter Python binding for libmilter, not 
in dkimpy-milter itself.

Scott K

PCRE2 Support

[Scott Kitterman]

The original PCRE library that Postfix uses is no longer maintained:

https://pcre.org/

It's been replaced by PCRE2, which has a notably different API, so Postfix PCRE 
support would need porting.  I've looked and it's beyond my limited skills.  
Is there any chance of getting this updated for Postfix 3.7?

PCRE2 was released 6 years ago, so I would imagine support is reasonably 
widespread.

Scott K

Re: PCRE2 Support

[Scott Kitterman]

On November 21, 2021 10:50:24 PM UTC, Wietse Venema  
wrote:
>Wietse Venema:
>> Scott Kitterman:
>> > The original PCRE library that Postfix uses is no longer maintained:
>> > 
>> > https://pcre.org/
>> > 
>> > It's been replaced by PCRE2, which has a notably different API, so Postfix 
>> > PCRE 
>> > support would need porting.  I've looked and it's beyond my limited 
>> > skills.  
>> > Is there any chance of getting this updated for Postfix 3.7?
>> > 
>> > PCRE2 was released 6 years ago, so I would imagine support is reasonably 
>> > widespread.
>> 
>> Thanks for the reminder. Now is the time to start planning
>> the annual stable release.
>
>I have an implementation based on PCRE2 that passes the existing
>Postfix tests for PCRE (which are ASCII based), without triggering
>complaints from Valgrind. I'll release this code first in Postfix
>3.7. After that we can discuss if it makes sense to merge this
>change back into earlier stable Postfix versions.
>
>One visible difference is that the obscure 'X' pattern flag is no
>longer supported, because the underlying PCRE_EXTRA feature no
>longer exists in the PCRE2 library. Postfix ignores the flag and
>logs a warning.
>
>There may be other visible differences in the way that the PCRE2
>library handles malformed UTF8, or content that happens to be using
>a different 8-bit encoding.
>
>I updated the PCRE auto-detection code in the makedefs script. It
>will try to use PCRE2, and if that is not installed, it will try
>to use PCRE. If we merge this back into earlier stable Postfix
>versions, then maybe PCRE should be the default, because breaking
>changes in a stable release are unwelcome.
>
>   Wietse

Great news, thanks.  For Debian's purposes we won't need support for PCRE2 
before 3.7.  I don't know about anyone else.

Scott K

Re: mail-to-script messages id and from lines

[Scott Kitterman]

On Tuesday, November 23, 2021 6:16:43 PM EST Wietse Venema wrote:
> J?rgen Weber:
> > From webe...@host.my.tld  Sun Nov 21 19:11:19 2021
> > Return-Path: 
> > X-Original-To: maild@my.virtual
> > Delivered-To: ma...@host.my.tld
> > Received: by host.my.tld (Postfix, from userid 1001)
> > id D3DFD783; Sun, 21 Nov 2021 19:11:19 +0100 (CET)
> 
> The "id" line should start with tab or space. That's how
> Postfix creates the line.
> 
> > To: maild@my.virtual
> > Subject: s1
> > Message-Id: <20211121181119.d3dfd...@host.my.tld>
> > Date: Sun, 21 Nov 2021 19:11:19 +0100 (CET)
> > From: J?rgen Weber 
> 
> Non-ASCII header text should be encoded with RFC 2o47.
> 
> > Can you prevent Postfix from adding these lines?
> 
> Use egrep.
> 
> If Python's email.Parser can't handle non-ASCII headers, then you
> should not use it for real email management.

It can.  It has trouble with non-UTF-8 if you use the string type internally.  
You have to use byte strings and not everyone does.  I think it's generally 
fine, but there are foot guns to watch out for.

Scott K

Re: Newbie question - main.cf.proto

[Scott Kitterman]

On December 6, 2021 8:18:11 PM UTC, Herndon Elliott  
wrote:
>I am just getting started with trying to install postifx and get it running
>on a single Ubuntu 18.04 server.  The documentation talks at length about
>changes to be made in "/etc/postfix/main.cf" file, but there is no such
>file in my install.  I have a main.cf.proto, but no main.cf  The only
>mention I can find the documentation of these files is " multi-instance
>template files "
>
>So am I supposed to rename (or better yet, copy) main.cf.proto as main.cf
>before making the changes to it??
>
>The installation instructions certainly could be a bit more explicit about
>this for a beginner

When you installed the package you selected "No configuration", so it's not 
particularly surprising you have no configuration.  Use dpkg-reconfigure 
postfix and pick a different option for configuration and you will have a 
main.cf.  Internet Site is probably the most useful for a starting place.

Scott K

Re: what's best guess record for SPF

[Scott Kitterman]

On December 10, 2021 4:32:50 AM UTC, raf  wrote:
>On Tue, Dec 07, 2021 at 07:55:54PM +0800, Piper H  wrote:
>
>> I sent an email from my t-online.de account to gmail.
>> Gmail shows SPF pass by best guessing:
>> 
>> Received-SPF: pass (google.com: best guess record for domain of
>> x...@t-online.de designates 194.25.134.18 as permitted sender)
>> client-ip=194.25.134.18;
>> 
>> And t-online.de has no SPF setup for which you can check from their domain.
>> So what's the best guess record by google?
>> 
>> Thanks in advance.
>> Piper
>
>Just guessing of course, but it's probably the fact that
>the host name of 194.25.134.18 is mailout04.t-online.de
>whose parent domain (t-online.de) matches sender domain.
>They might also accept the sender domain's MX hosts, regardless
>of their domain name.
>
>cheers,
>raf

Pyspf still has the original best guess record hidden in the code from when it 
was first written in 2004:

https://github.com/sdgathman/pyspf/blob/0858adb6cf529e696a42318b7938e0b9e8a86c1c/spf.py#L245

No one should be using this anymore, but some still do.  It's relatively safe 
to use for finding pass results, but should never be used in any negative way.  
It's also, formally, not an SPF result because it's not part of the RFC 
4408/7208 definition of SPF.

Pyspf is the only first generation SPF library that's still maintained, so it's 
got some very old pre-IETF bits laying around still.

Scott K

Re: postconf outputs 2 bounce_notice_recipient lines

[Scott Kitterman]

On Monday, November 15, 2021 9:03:32 AM EST  wrote:
> Vincent Lefevre:
> > Under Debian, after the postfix upgrade from 3.5.6 to 3.5.13,
> > postconf now outputs duplicate bounce_notice_recipient lines:
> > 
> > zira:~> postconf | grep '^bounce_notice_recipient'
> > bounce_notice_recipient = postmaster
> > bounce_notice_recipient = postmaster
> > 
> > Can you reproduce this?
> 
> Yes. It was introduced with postfix-3.3-patch19, postfix-3.4-patch22,
> postfix-3.5-patch12, and postfix-3.6-patch02.
> 
> 20210708
> 
> Bugfix (introduced: 1999): the Postfix SMTP server was
> sending all session transcripts to the error_notice_recipient,
> instead of sending transcripts of bounced mail to the
> bounce_notice_recipient. File: smtpd/smtpd_chat.c.
> 
> The above replaced error_notice_recipient with bounce_notice_recipient,
> but did not update the default setting. The fix for the fix is
> below.
> 
>   Wietse
> 
> 2025
> 
>   Bugfix (introduced: 20210708): duplicate bounce_notice_recipient
>   entries in postconf output. The fix to send SMTP session
>   transcripts to bounce_notice_recipient was incomplete.
>   Reported by Vincent Lefevre. File: smtpd/smtpd.c.
> 
> The same fix applies to postfix-3.3.19, postfix-3.4.22, postfix-3.5.12,
> postfix-3.6.2, and later.
> 
> --- /var/tmp/postfix/src/smtpd/smtpd.c2021-07-24 18:20:43.0 
> -0400
> +++ src/smtpd/smtpd.c 2021-11-15 08:42:43.088958256 -0500
> @@ -6419,7 +6419,7 @@
>   VAR_EOD_CHECKS, DEF_EOD_CHECKS, &var_eod_checks, 0, 0,
>   VAR_MAPS_RBL_DOMAINS, DEF_MAPS_RBL_DOMAINS, &var_maps_rbl_domains, 0, 0,
>   VAR_RBL_REPLY_MAPS, DEF_RBL_REPLY_MAPS, &var_rbl_reply_maps, 0, 0,
> - VAR_BOUNCE_RCPT, DEF_ERROR_RCPT, &var_bounce_rcpt, 1, 0,
> + VAR_BOUNCE_RCPT, DEF_BOUNCE_RCPT, &var_bounce_rcpt, 1, 0,
>   VAR_ERROR_RCPT, DEF_ERROR_RCPT, &var_error_rcpt, 1, 0,
>   VAR_REST_CLASSES, DEF_REST_CLASSES, &var_rest_classes, 0, 0,
>   VAR_CANONICAL_MAPS, DEF_CANONICAL_MAPS, &var_canonical_maps, 0, 0,

I was just reviewing the 3.7 development changelog and didn't see 2025 
listed.  Is this fix still planned?

Scott K

Re: postconf outputs 2 bounce_notice_recipient lines

[Scott Kitterman]

On December 22, 2021 2:34:22 AM UTC, Wietse Venema  wrote:
>Scott Kitterman:
>> On Monday, November 15, 2021 9:03:32 AM EST  wrote:
>> > Vincent Lefevre:
>> > > Under Debian, after the postfix upgrade from 3.5.6 to 3.5.13,
>> > > postconf now outputs duplicate bounce_notice_recipient lines:
>> > > 
>> > > zira:~> postconf | grep '^bounce_notice_recipient'
>> > > bounce_notice_recipient = postmaster
>> > > bounce_notice_recipient = postmaster
>> > > 
>> > > Can you reproduce this?
>> > 
>> > Yes. It was introduced with postfix-3.3-patch19, postfix-3.4-patch22,
>> > postfix-3.5-patch12, and postfix-3.6-patch02.
>> > 
>> > 20210708
>> > 
>> > Bugfix (introduced: 1999): the Postfix SMTP server was
>> > sending all session transcripts to the error_notice_recipient,
>> > instead of sending transcripts of bounced mail to the
>> > bounce_notice_recipient. File: smtpd/smtpd_chat.c.
>> > 
>> > The above replaced error_notice_recipient with bounce_notice_recipient,
>> > but did not update the default setting. The fix for the fix is
>> > below.
>> > 
>> >Wietse
>> > 
>> > 2025
>> > 
>> >Bugfix (introduced: 20210708): duplicate bounce_notice_recipient
>> >entries in postconf output. The fix to send SMTP session
>> >transcripts to bounce_notice_recipient was incomplete.
>> >Reported by Vincent Lefevre. File: smtpd/smtpd.c.
>> > 
>> > The same fix applies to postfix-3.3.19, postfix-3.4.22, postfix-3.5.12,
>> > postfix-3.6.2, and later.
>> > 
>> > --- /var/tmp/postfix/src/smtpd/smtpd.c 2021-07-24 18:20:43.0 
>> > -0400
>> > +++ src/smtpd/smtpd.c  2021-11-15 08:42:43.088958256 -0500
>> > @@ -6419,7 +6419,7 @@
>> >VAR_EOD_CHECKS, DEF_EOD_CHECKS, &var_eod_checks, 0, 0,
>> >VAR_MAPS_RBL_DOMAINS, DEF_MAPS_RBL_DOMAINS, &var_maps_rbl_domains, 0, 0,
>> >VAR_RBL_REPLY_MAPS, DEF_RBL_REPLY_MAPS, &var_rbl_reply_maps, 0, 0,
>> > -  VAR_BOUNCE_RCPT, DEF_ERROR_RCPT, &var_bounce_rcpt, 1, 0,
>> > +  VAR_BOUNCE_RCPT, DEF_BOUNCE_RCPT, &var_bounce_rcpt, 1, 0,
>> >VAR_ERROR_RCPT, DEF_ERROR_RCPT, &var_error_rcpt, 1, 0,
>> >VAR_REST_CLASSES, DEF_REST_CLASSES, &var_rest_classes, 0, 0,
>> >VAR_CANONICAL_MAPS, DEF_CANONICAL_MAPS, &var_canonical_maps, 0, 0,
>> 
>> I was just reviewing the 3.7 development changelog and didn't see 2025 
>> listed.  Is this fix still planned?
>
>The fix is in the 3.7 code, but I forgot to update the HISTORY file.
>It is also planned for the next stable releases, together with the
>fix below.
>
>These are low-priority fixes, so expect to see these early January.
>
>   Wietse
>
>20211216
>
>   Bugfix (introduced: Postfix 3.0): the proxymap daemon did not
>   automatically authorize proxied maps inside pipemap (example:
>   pipemap:{proxy:maptype:mapname, ...}) or inside unionmap. Problem
>   reported by Mirko Vogt. Files: proxymap/proxymap.c.

Thanks.  Certainly no rush.  I only wanted to make sure it wasn't forgotten.

Any chance of the glibc-2.34 fix being in there too?  We haven't switched, so 
not a rush directly for Debian, but some of our downstreams have, so it would 
be nice to see.

Scott K