Question: 451 4.3.5 Server configuration problem (in reply to RCPT TO command))

[Simon Loewenthal/NL/Tele2]

   
Hi,

I have a seen a few of these messages popping up in the mail.log
over the past weeks. Would someone tell me whether this is a
configuration problem with my server, or a remote site?  The 451 error
has appeared from a couple of sites, hence I wonder if the problem lies
with my site.  In the case of the example below, the message is delivered.

Best regards,
Simon.


Version:
postfix 2.7.1-1+squeeze1

# grep 91545817DA mail.log.1
Sep 12 17:52:19 logout postfix/smtpd[28483]: 91545817DA:
client=unknown[62.11.22.33], sasl_method=PLAIN,
sasl_username=scrubbed_u...@example.com
Sep 12 17:52:19 logout postfix/cleanup[28473]: 91545817DA: replace:
header Received: from [127.0.0.1] (unknown [62.11.22.33])??(using TLSv1
with cipher DHE-RSA-AES256-SHA (256/256 bits))??(No client certificate
requested)??by example.com (Postfix) with ESMTPSA id 91545817DA from
unknown[62.11.22.33]; from=
to= proto=ESMTP helo=<[127.0.0.1]>: Received:
from [127.0.0.1] (localhost [127.0.0.1]) by localhost
Sep 12 17:52:19 logout postfix/cleanup[28473]: 91545817DA:
message-id=<4e6e2ad2.8010...@example.com>
Sep 12 17:52:21 logout postfix/qmgr[12672]: 91545817DA:
from=, size=31400, nrcpt=1 (queue active)
Sep 12 17:52:21 logout postfix/smtp[28488]: 91545817DA:
to=,
relay=mail.gigahost.dk[89.186.169.167]:25, delay=1.9,
delays=1.5/0.01/0.2/0.21, dsn=4.2.0, status=deferred (host
mail.gigahost.dk[89.186.169.167] said: 450 4.2.0
: Recipient address rejected: Greylisted, see
http://postgrey.schweikert.ch/help/soekris.eu.html (in reply to RCPT TO
command))
Sep 12 17:58:52 logout postfix/qmgr[12672]: 91545817DA:
from=, size=31400, nrcpt=1 (queue active)
Sep 12 17:58:54 logout postfix/smtp[28509]: 91545817DA:
to=,
relay=mail.gigahost.dk[89.186.169.167]:25, delay=394,
delays=393/0.02/0.12/1, dsn=4.3.5, status=deferred (host
mail.gigahost.dk[89.186.169.167] said: 451 4.3.5 Server configuration
problem (in reply to RCPT TO command))
Sep 12 18:08:52 logout postfix/qmgr[12672]: 91545817DA:
from=, size=31400, nrcpt=1 (queue active)
Sep 12 18:08:53 logout postfix/smtp[28548]: 91545817DA:
to=,
relay=mail.gigahost.dk[89.186.169.167]:25, delay=994,
delays=993/0.02/0.12/0.21, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
as 1CEE44E2943C)
Sep 12 18:08:53 logout postfix/qmgr[12672]: 91545817DA: removed



# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
body_checks = regexp:/etc/postfix/body_checks.regexp
bounce_template_file = /etc/postfix/bounce.cf
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks
inet_interfaces = all
mailbox_size_limit = 0
message_size_limit = 2048
milter_connect_macros = j {daemon_name} v {client_addr} _
milter_default_action = tempfail
mime_header_checks = regexp:/etc/postfix/mime_header_checks
mydestination =
myhostname = example.com
mynetworks = mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters = unix:/dkim-filter/dkim-filter.sock
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_helo_timeout = 60s
smtp_mail_timeout = 60s
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 50
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname,
reject_unlisted_recipient, reject_unlisted_sender,
regexp:/etc/postfix/helo.regexp, permit
smtpd_milters =
unix:/clamav/clamav-milter.ctl,unix:/spamass/spamass.sock,unix:/dkim-filter/dkim-filter.sock
smtpd_recipient_restrictions =
permit_mynetworks,permit_sasl_authenticated, reject_unauth_destination,
check_recipient_access cidr:/etc/postfix/whitelist,
reject_non_fqdn_sender, reject_rbl_client
hostkarma.junkemailfilter.com=127.0.0.2, reject_rbl_client
sbl-xbl.spamhaus.org
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_tls_CAfile = scrubbed
smtpd_tls_cert_file = scrubbed
smtpd_tls_key_file = scrubbed
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/transport
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
virtual_alias_maps = proxy:mysql:/etc/postfix/sql/scrubbed.cf,
proxy:mysql:/etc/postfix/sql/scrubbed.cf,
proxy:mysql:/etc/postfix/sql/scrubbed.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql/scrubbed.cf
virtual_mailbox_maps = mysql:/etc/postfix/sql/scrubbed.cf
virtual_transport = dovecot-spamass

Re: Question: 451 4.3.5 Server configuration problem (in reply to RCPT TO command))

[Reindl Harald]

Am 13.09.2011 10:54, schrieb Simon Loewenthal/NL/Tele2:

> I have a seen a few of these messages popping up in the mail.log
> over the past weeks. Would someone tell me whether this is a
> configuration problem with my server, or a remote site?  The 451 error
> has appeared from a couple of sites, hence I wonder if the problem lies
> with my site.  In the case of the example below, the message is delivered.
> 
> relay=mail.gigahost.dk[89.186.169.167]:25, delay=394,
> delays=393/0.02/0.12/1, dsn=4.3.5, status=deferred (host
> mail.gigahost.dk[89.186.169.167] said: 451 4.3.5 Server configuration
> problem (in reply to RCPT TO command))

if you get from a remote host "said: 451 4.3.5 Server configuration problem"
this message says clearly that the remite host has a configuration problem
and this has nothing to do with you




signature.asc
Description: OpenPGP digital signature

Re: Question: 451 4.3.5 Server configuration problem (in reply to RCPT TO command))

[Wietse Venema]

Simon Loewenthal/NL/Tele2:
>
> Hi,
> 
> I have a seen a few of these messages popping up in the mail.log
> over the past weeks. Would someone tell me whether this is a
> configuration problem with my server, or a remote site?  The 451 error
> has appeared from a couple of sites, hence I wonder if the problem lies
> with my site.  In the case of the example below, the message is delivered.

SMTP is a client-server protocol. 

When sending mail, Postfix is the SMTP client.

When receiving mail, Postfix is the SMTP server.

When the SMTP server replies with "server configuration error" then
the SMTP server has a problem.

Wietse

Re: Question: 451 4.3.5 Server configuration problem (in reply to RCPT TO command))

[Simon Loewenthal/NL/Tele2]

On 09/13/2011 02:11 PM, Wietse Venema wrote:
> Simon Loewenthal/NL/Tele2:
>>
>> Hi,
>>
>> I have a seen a few of these messages popping up in the mail.log
>> over the past weeks. Would someone tell me whether this is a
>> configuration problem with my server, or a remote site?  The 451 error
>> has appeared from a couple of sites, hence I wonder if the problem lies
>> with my site.  In the case of the example below, the message is delivered.
> SMTP is a client-server protocol. 
>
> When sending mail, Postfix is the SMTP client.
>
> When receiving mail, Postfix is the SMTP server.
>
> When the SMTP server replies with "server configuration error" then
> the SMTP server has a problem.
>
>   Wietse
Thank-you Wietse.
Thus, the problem is my broken server.  Next step is to work out where
the problem is.

-- 
Simon Loewenthal/Tele2
GSM: +31 6 2000 5427

 IMPORTANT NOTICE 
PLEASE REPLY TO simon.loewent...@klunky.co.uk
This e-mail (including any attachments) may contain information 
that is confidential or otherwise protected from disclosure and
it is intended only for the addressees. If you are not the intended
recipient, please kindly refrain from copying or distribution.
Other use of information contained in this e-mail (and its attachments)
is frowned upon. If you have received this e-mail in error, kindly
notify us immediately by telephone or e-mail and, if possible, kindly
delete the message (including any attachments) from your system. Of
course, this is not legal advice, nor is it a contract. If it were a
contract, it would have an exchange of value and affirmative agreement
by both parties. If it were legal advice, it should be written by a
lawyer and would have a bill attached.

It ought to be obvious my views in this Email might not represent my
employer's views, & vice-verse. Please note that e-mail messages may
contain computer viruses or other defects. I presume that you understand
the concept of a computer virus, and took reasonable precautions.

Re: Question: 451 4.3.5 Server configuration problem (in reply to RCPT TO command))

[Reindl Harald]

Am 13.09.2011 14:34, schrieb Simon Loewenthal/NL/Tele2:
> On 09/13/2011 02:11 PM, Wietse Venema wrote:
>> Simon Loewenthal/NL/Tele2:
>>>
>>> Hi,
>>>
>>> I have a seen a few of these messages popping up in the mail.log
>>> over the past weeks. Would someone tell me whether this is a
>>> configuration problem with my server, or a remote site?  The 451 error
>>> has appeared from a couple of sites, hence I wonder if the problem lies
>>> with my site.  In the case of the example below, the message is delivered.
>> SMTP is a client-server protocol. 
>>
>> When sending mail, Postfix is the SMTP client.
>>
>> When receiving mail, Postfix is the SMTP server.
>>
>> When the SMTP server replies with "server configuration error" then
>> the SMTP server has a problem.
>>
>>  Wietse
> Thank-you Wietse.
> Thus, the problem is my broken server.  Next step is to work out where
> the problem is.

why is YOUR server broken if the REMOTE server says "configuration problem"?



signature.asc
Description: OpenPGP digital signature

Re: Question: 451 4.3.5 Server configuration problem (in reply to RCPT TO command))

[Simon Loewenthal/NL/Tele2]

On 09/13/2011 02:38 PM, Reindl Harald wrote:
>
> Am 13.09.2011 14:34, schrieb Simon Loewenthal/NL/Tele2:
>> On 09/13/2011 02:11 PM, Wietse Venema wrote:
>>> Simon Loewenthal/NL/Tele2:

 Hi,

 I have a seen a few of these messages popping up in the mail.log
 over the past weeks. Would someone tell me whether this is a
 configuration problem with my server, or a remote site?  The 451 error
 has appeared from a couple of sites, hence I wonder if the problem lies
 with my site.  In the case of the example below, the message is delivered.
>>> SMTP is a client-server protocol. 
>>>
>>> When sending mail, Postfix is the SMTP client.
>>>
>>> When receiving mail, Postfix is the SMTP server.
>>>
>>> When the SMTP server replies with "server configuration error" then
>>> the SMTP server has a problem.
>>>
>>> Wietse
>> Thank-you Wietse.
>> Thus, the problem is my broken server.  Next step is to work out where
>> the problem is.
> why is YOUR server broken if the REMOTE server says "configuration problem"?
>
Because I had mis-read the the statement back-to-front.  Now I
understand it the right way around.  :}

Regards.

-- 
Simon Loewenthal/Tele2
GSM: +31 6 2000 5427

 IMPORTANT NOTICE 
PLEASE REPLY TO simon.loewent...@klunky.co.uk
This e-mail (including any attachments) may contain information 
that is confidential or otherwise protected from disclosure and
it is intended only for the addressees. If you are not the intended
recipient, please kindly refrain from copying or distribution.
Other use of information contained in this e-mail (and its attachments)
is frowned upon. If you have received this e-mail in error, kindly
notify us immediately by telephone or e-mail and, if possible, kindly
delete the message (including any attachments) from your system. Of
course, this is not legal advice, nor is it a contract. If it were a
contract, it would have an exchange of value and affirmative agreement
by both parties. If it were legal advice, it should be written by a
lawyer and would have a bill attached.

It ought to be obvious my views in this Email might not represent my
employer's views, & vice-verse. Please note that e-mail messages may
contain computer viruses or other defects. I presume that you understand
the concept of a computer virus, and took reasonable precautions.

Selection of smtpd_milter using sender access

[Jeetu]

Hi,

I'm using postfix 2.8.4 and trying to select smtpd_milter based on 
sender address.


My check_sender_access is SELECT 'FILTER smtp:[127.0.0.1]:2525' 
and using it under smtpd_recipient_restrictions

My master.cf is
127.0.0.1:2525  inet n   -   n   - -  smtpd
  -o smtpd_milters=inet:localhost:

I get this in logs
Sep 13 18:41:50 outbound2 postfix/smtpd[29888]: NOQUEUE: filter: RCPT 
from unknown[xx.xx.xx.xx]: : Sender address triggers 
FILTER smtp:[127.0.0.1]:2525; from= to= 
proto=ESMTP helo=


The milter is not getting called.
How do i fix it ?

--
-Jeetu

Re: Selection of smtpd_milter using sender access

[Wietse Venema]

Jeetu:
> Hi,
> 
> I'm using postfix 2.8.4 and trying to select smtpd_milter based on 
> sender address.

This is simply not possible, because Milters must see the complete
SMTP session. Postfix will not turn on a Milter in the middle of a
session and replay previous commands to catch up.

Wietse

Re: Question: 451 4.3.5 Server configuration problem (in reply to RCPT TO command))

[Stan Hoeppner]

On 9/13/2011 7:47 AM, Simon Loewenthal/NL/Tele2 wrote:

On 09/13/2011 02:38 PM, Reindl Harald wrote:



why is YOUR server broken if the REMOTE server says "configuration problem"?


Because I had mis-read the the statement back-to-front.  Now I
understand it the right way around.  :}


You still don't understand.  The problem isn't your Postfix MTA, but the 
remote MTA.  Send a similar email to one of these broken servers using a 
Gmail account.  You'll receive a bounce with the same message you pasted 
here: "Server configuration problem".


The only thing confusing you here is the presence of this message in log 
file.  You apparently don't know how to read your mail log...


--
Stan

Re: Selection of smtpd_milter using sender access

[Wietse Venema]

Jeetu:
> I get this in logs
> Sep 13 18:41:50 outbound2 postfix/smtpd[29888]: NOQUEUE: filter: RCPT 
> from unknown[xx.xx.xx.xx]: : Sender address triggers 
> FILTER smtp:[127.0.0.1]:2525; from= to= 
> proto=ESMTP helo=
> 
> The milter is not getting called.

Your filter on [127.0.0.1]:2525 will be used *after* smtpd receives
the entire message, not *while* it receives the message.

> 127.0.0.1:2525  inet n   -   n   - -  smtpd
>-o smtpd_milters=inet:localhost:

Note that the milter will not see the original SMTP client address;
it will see 127.0.0.1 instead.

Wietse

Re: Bouncing an undeliverable message without waiting?

[Bob Proulx]

Jeroen Geilman wrote:
> Bob Proulx wrote:
> >The mail queue has messages addressed to unreachable addresses.  I
> >know that if I do nothing that eventually they will expire normally
> >...
> 
> Altering the status in-queue will be difficult, so you will have to
> devise a trick.
>
> You can try setting maximal_queue_lifetime to 0, and forcing a queue run.
> This will immediately bounce any messages already in the deferred
> queue, and not influence new mail unduly (since one presumes not a
> lot of messages will have this problem over a short window of time).
> 
> Remember to set it back to normal after the queues are cleared!

I think that is a good trick and experimenting with it I find that it
did exactly what I wished to do and exactly answered my question.
Within the constraints of this specialized system and other caveats.
It worked for me and all of that.  Thank you for that suggestion!
However on the actual machine I executed Wietse's solution.  It
executed with more targeted precision.  On this system I did reduce
the maximal_queue_lifetime to a shorter value to avoid this in the
future.

Thanks!
Bob

Re: Bouncing an undeliverable message without waiting?

[Bob Proulx]

Wietse Venema wrote:
> Bob Proulx:
> > I have been trying to deduce if it is possible to force a message
> > waiting in the mail queue with temporary errors (domain name
> > resolution failures) to bounce right now instead of waiting for the
> > timeout.
> 
> It would be incorrect to force a message to bounce. Messages can
> have multiple recipients. It would be more correct to force-bounce
> a recipient.

Sorry for using an imperfect description.  I had an imperfect
understanding of the problem.  I appreciate the education on that
point.

Using Jeroen's suggestion to reduce the maximal_queue_lifetime to a
small value and then flushing the queue had the desired effect due to
Postfix itself understanding the difference in the above points.  It
was sufficient to handle my problem case.

However your solution is more surgically precise and since some people
here have a habit of making the same typo errors repeatedly it has the
convenience of allowing me to target those very common typos specially
and handle them in the future without further action on my part.

> To flag a destination or recipient as undeliverable:
> /etc/postfix/transport:
> typodomain.exampleerror:5.1.2 Bad destination system address

That is a nice solution to the problem and works very well for me.
Thank you for that suggestion.  That is the way I went on the system.

> Flagging one recipient in a queue file as undeliverable requires a
> lot of code that currently does not exist: 1) a way for postsuper
> to mark as "expired" one recipient in the middle of a list of
> recipients, 2) a way to extract from the defer logfile the record
> that says why that recipient was not yet delivered for use in the
> non-delivery notification, and 3) a way to mark that defer logfile
> record as "deleted" so that the problem won't be reported again.

Thanks for the expanded explanation of the problem.  That does sound
messy to implement and for only a small return on investment.  I don't
think it is worth it.  And now that I have a better understanding of
the problem and two recipes that solve the problem for me it isn't
something I require.  I knew there would be a method that would enable
that operation.  I just needed to learn it.

Thanks!
Bob

Re: Issue integrating with Cyrus-SASL

[Crazedfred]

> place an 'n' in the chroot column for each service

Sounds good.

On your advice, I went and turned off chroot, then ran "saslfinger -s" again 
(output attached).
I restarted the saslauthd and postfix services before doing so.
You can see that chroot is off for all components.

Further, based on the Postfix Debugging documentation, I turned on debugging 
for localhost.


Unfortunately, I am running into the same errors when I test telnet:
535 5.7.8 Error: authentication failed: authentication failure

postfix/smtpd[30480]: auxpropfunc error invalid parameter supplied
postfix/smtpd[30480]: _sasl_plugin_load failed on sasl_auxprop_plug_init for 
plugin: ldapdb


The error is different in syslog though, it looks like it just isn't finding 
the right password:
postfix/smtpd[30710]: xsasl_cyrus_server_first: sasl_method plain, 
init_response MY-HASH
postfix/smtpd[30710]: xsasl_cyrus_server_first: decoded initial response
postfix/smtpd[30710]: warning: SASL authentication failure: Password 
verification failed
postfix/smtpd[30710]: warning: localhost.localdomain[127.0.0.1]: SASL plain 
authentication failed: authentication failure
postfix/smtpd[30710]: > localhost.localdomain[127.0.0.1]: 535 5.7.8 Error: 
authentication failed: authentication failure
postfix/smtpd[30710]: watchdog_pat: 0xb91ef1b0
postfix/smtpd[30710]: smtp_get: EOF
postfix/smtpd[30710]: match_hostname: localhost.localdomain ~? 127.0.0.0/8
postfix/smtpd[30710]: match_hostaddr: 127.0.0.1 ~? 127.0.0.0/8
postfix/smtpd[30710]: lost connection after AUTH from 
localhost.localdomain[127.0.0.1]
postfix/smtpd[30710]: disconnect from localhost.localdomain[127.0.0.1]



It seems a less serious error than last time, however, it's still running into 
a brick wall when interfacing with SASL, even though the previously mentioned 
testsaslauthd command succeeds.
saslfinger - postfix Cyrus sasl configuration Tue Sep 13 15:34:52 CDT 2011
version: 1.0.4
mode: server-side SMTP AUTH

-- basics --
Postfix: 2.7.1
System: Debian GNU/Linux 6.0 \n \l

-- smtpd is linked to --
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb75b1000)

-- active SMTP AUTH and TLS parameters for smtpd --
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = 
smtpd_sasl_security_options = noanonymous
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes


-- listing of /usr/lib/sasl2 --
total 756
drwxr-xr-x  2 root root  4096 Jun 26 23:58 .
drwxr-xr-x 58 root root 16384 Sep  2 20:34 ..
-rw-r--r--  1 root root 13436 Dec 19  2010 libanonymous.a
-rw-r--r--  1 root root  1003 Dec 19  2010 libanonymous.la
-rw-r--r--  1 root root 13076 Dec 19  2010 libanonymous.so
-rw-r--r--  1 root root 13076 Dec 19  2010 libanonymous.so.2
-rw-r--r--  1 root root 13076 Dec 19  2010 libanonymous.so.2.0.23
-rw-r--r--  1 root root 15882 Dec 19  2010 libcrammd5.a
-rw-r--r--  1 root root   989 Dec 19  2010 libcrammd5.la
-rw-r--r--  1 root root 15444 Dec 19  2010 libcrammd5.so
-rw-r--r--  1 root root 15444 Dec 19  2010 libcrammd5.so.2
-rw-r--r--  1 root root 15444 Dec 19  2010 libcrammd5.so.2.0.23
-rw-r--r--  1 root root 45328 Dec 19  2010 libdigestmd5.a
-rw-r--r--  1 root root  1012 Dec 19  2010 libdigestmd5.la
-rw-r--r--  1 root root 43144 Dec 19  2010 libdigestmd5.so
-rw-r--r--  1 root root 43144 Dec 19  2010 libdigestmd5.so.2
-rw-r--r--  1 root root 43144 Dec 19  2010 libdigestmd5.so.2.0.23
-rw-r--r--  1 root root 13744 Dec 19  2010 libldapdb.a
-rw-r--r--  1 root root   996 Dec 19  2010 libldapdb.la
-rw-r--r--  1 root root 14540 Dec 19  2010 libldapdb.so
-rw-r--r--  1 root root 14540 Dec 19  2010 libldapdb.so.2
-rw-r--r--  1 root root 14540 Dec 19  2010 libldapdb.so.2.0.23
-rw-r--r--  1 root root 13586 Dec 19  2010 liblogin.a
-rw-r--r--  1 root root   983 Dec 19  2010 liblogin.la
-rw-r--r--  1 root root 13552 Dec 19  2010 liblogin.so
-rw-r--r--  1 root root 13552 Dec 19  2010 liblogin.so.2
-rw-r--r--  1 root root 13552 Dec 19  2010 liblogin.so.2.0.23
-rw-r--r--  1 root root 29140 Dec 19  2010 libntlm.a
-rw-r--r--  1 root root   977 Dec 19  2010 libntlm.la
-rw-r--r--  1 root root 28528 Dec 19  2010 libntlm.so
-rw-r--r--  1 root root 28528 Dec 19  2010 libntlm.so.2
-rw-r--r--  1 root root 28528 Dec 19  2010 libntlm.so.2.0.23
-rw-r--r--  1 root root 13786 Dec 19  2010 libplain.a
-rw-r--r--  1 root root   983 Dec 19  2010 libplain.la
-rw-r--r--  1 root root 14096 Dec 19  2010 libplain.so
-rw-r--r--  1 root root 14096 Dec 19  2010 libplain.so.2
-rw-r--r--  1 root root 14096 Dec 19  2010 libplain.so.2.0.23
-rw-r--r--  1 root root 21498 Dec 19  2010 libsasldb.a
-rw-r--r--  1 root root  1014 Dec 19  2010 libsasldb.la
-rw-r--r--  1 root root 18084 Dec 19  2010 libsasldb.so
-rw-r--r--  1 root root 18084 Dec 19  2010 libsasldb.so.2
-rw-r--r--  1 root root 18084 Dec 19  2010 libsasldb.so.2.0.23
-rw-r--r--  1 root root49 Jun 26 23:58 smtpd.conf

-- listing of /etc

Re: Disclaimer with always_bcc and config problems

[Jeroen Geilman]

On 2011-09-13 00:42, mouss wrote:

Le 13/09/2011 00:04, Jeroen Geilman a écrit :

On 2011-09-12 06:21, Alex wrote:

Hi,

I'm trying to configure a disclaimer footer using altermime with
postfix-2.7.5, amavisd-new-2.6.4. I've tried to follow the examples
for creating a new filter, but the messages appear to be being
reinjected at the wrong spot and are being delivered multiple times to
the always_bcc recipient.

I thought I could outline my current config, and someone could help me
to find what I'm missing. I have about twenty virtual domains, but it
would be okay to use the same disclaimer footer text for each domain.
I'd also like to be sure SASL authenticated clients are permitted as
well.

I'm not sure this configuration will only work with my domains, and
only on outbound mail. How is this controlled?

By limiting the scope of the setting to one or more individual daemons.
Settings in main.cf affect all instances of any particular daemon.

If you need this controlled per domain, either use a recipient access
map with a FILTER action to select among multiple filters, or take care
of the domain in the content_filter.
For 20 domains, adding 20 filters is probably not the easiest solution.
Just parse the domain part in your content_filter and act appropriately.


smtp  inet  n   -   n   -   -   smtpd
 -o receive_override_options=no_address_mappings
 -o content_filter=filter:dummy


I would suggest not naming an actual filter something as generic as
"filter" - use "footer" instead, in this case.
Also, smtP(8) does not receive mail, so this is not the correct place to
apply these settings - they achieve nothing.

the above is an smtpD. see end of line. the "smtp" at start of line is
the name of the service to be found in /etc/services, ie: smtp=25.


Ugh, brainfart.


submission inet n   -   n   -   -   smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o receive_override_options=no_address_mappings
-o content_filter=filter:dummy


They do here, since submission is an smtpD(8) listener.

It is also an smtpD, but not because it's named "submission".


That's not what I said.


  it is an
smtpd as indicated by the last token in the line. again, "submission"
simply means use the port in /etc/services that corresponds to
"submission".





The intended recipient receives a copy of the message, but the
always_bcc user receives the message multiple times.

Yes; always_bcc is invoked on receiving mail.
If you re-inject mail (as you must after it is passed off to a
content_filter), it is received for the second time.
Everything in main.cf is applied anew, including always_bcc.

The re-injection listener (which should NOT be the same daemon as your
normal smtpd(8) listener!) should not apply always_bcc, so set your
receive_override_options there.

You should also be very, very careful about bouncing mail to your
always_bcc address - consider what the result is.

In practical terms, the recipient in always_bcc should never bounce, or
you will have problems.




Aside from the nitpicking, no comments on the actual contents ?

--
J.

Re: Issue integrating with Cyrus-SASL

[Wietse Venema]

Crazedfred:
> > place an 'n' in the chroot column for each service
> 
> Sounds good.
> 
> On your advice, I went and turned off chroot, then ran "saslfinger -s" again 
> (output attached).
> I restarted the saslauthd and postfix services before doing so.
> You can see that chroot is off for all components.
> 
> Further, based on the Postfix Debugging documentation, I turned on debugging 
> for localhost.
> 
> 
> Unfortunately, I am running into the same errors when I test telnet:
> 535 5.7.8 Error: authentication failed: authentication failure
> 
> postfix/smtpd[30480]: auxpropfunc error invalid parameter supplied
> postfix/smtpd[30480]: _sasl_plugin_load failed on sasl_auxprop_plug_init for 
> plugin: ldapdb

According to saslfinger output, Cyrus SASL is trying to use mechanisms
that differ from the ones that you want to use.

Cyrus SASL uses these:

-- mechanisms on localhost --
250-AUTH CRAM-MD5 DIGEST-MD5 PLAIN NTLM LOGIN

You want to use PLAIN and LOGIN instead:

-- content of /usr/lib/sasl2/smtpd.conf --
pwcheck_method: saslauthd
mech_list: login plain

Perhaps Cyrus SASL picks up settings from a different smtpd.conf file.

What is the result of:

find / -name smtpd.conf

and what is the content of the files?

Wietse

Re: Issue integrating with Cyrus-SASL

[Patrick Ben Koetter]

Sorry for the delay.

* Crazedfred :
> I ran "saslfinger -c" and "saslfinger -s" and it does appear that many of
> the relevant services are chrooted. I wasn't quite sure, however, so I
> attached the full output of both commands.

You want server-side debug output, which is 'saslfinger -s'.

> Of interest was the error message (not sure if it's relevant though):
> Cannot find the smtp_sasl_password_maps parameter in main.cf.
> Client-side SMTP AUTH cannot work without this parameter!

That can be ignored with server-side SASL.


> I then changed the OPTIONS of /etc/default/saslauthd to what you reccomended:
> #OPTIONS="-c -m /var/run/saslauthd"
> OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Correct.

> 
> However there are still curious errors (I don't think I've seen the 
> auxpropfunc error before):
> Sep  7 11:25:02 gpasswd[8432]: user postfix added by root to group sasl
> Sep  7 11:26:18 postfix/smtpd[8489]: auxpropfunc error invalid parameter 
> supplied
> Sep  7 11:26:18 postfix/smtpd[8489]: _sasl_plugin_load failed on 
> sasl_auxprop_plug_init for plugin: ldapdb

The Cyrus SASL libsasl library wants to initialize the ldapdb auxprop plugin.
It fails because it isn't configured. You don't want ldapdb. Ignore it.


> Further, postfix is still giving similar errors when authentication fails:
> Sep  7 11:53:20 postfix/smtpd[8821]: connect from 
> localhost.localdomain[127.0.0.1]
> Sep  7 11:53:37 postfix/smtpd[8821]: warning: SASL authentication problem: 
> unable to open Berkeley db /etc/sasldb2: No such file or directory
> Sep  7 11:53:37 postfix/smtpd[8821]: warning: SASL authentication problem: 
> unable to open Berkeley db /etc/sasldb2: No such file or directory
> Sep  7 11:53:37 postfix/smtpd[8821]: warning: SASL authentication failure: 
> Password verification failed
> Sep  7 11:53:37 postfix/smtpd[8821]: warning: 
> localhost.localdomain[127.0.0.1]: SASL plain authentication failed: 
> authentication failure


The smtpd.conf isn't where it should be on Debian systems. Move it from
/usr/lib/sasl2/smtpd.conf to /etc/postfix/sasl/smtpd.conf.

p@rick


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

saslfinger (debugging SMTP AUTH):