Re: How to drop the recipient address hostname when delivering mail via LMTP?

[Ralph Seichter]

On 29.08.10 21:40, Noel Jones wrote:

> Sorry, I forgot to specify the map type in my example. It must be
> either regexp: or pcre:.

No need for you to apologize. I feel quite silly, because you obviously
specifed a regular expression in your example, and I read it as such. I
don't know what made me specify a map type of 'hash'.

Alas, this does not work. The line

  /^...@server\.domain\.tld$/ joe

strips the domainpart just fine, but Postfix attempts a LMTP delivery to
j...@domain.tld. I assume this happens because of "myorigin = $mydomain".

As Victor pointed out, LMTP addresses need to be fully qualified, and
Postfix seems to refuse to be told otherwise -- which is correct. Maybe
something can be done on Dovecot's side.

-Ralph

Migrating from sendmail, a few questions...

[Jean-Yves Avenard]

Hi there.

Moving from sendmail to a macos 10.6 server that ships with postfix..

There are a few things that I'm trying to replicate from sendmail into
postifx, but I'm not having much luck.

Problems:
1- People on local network (e.g. from 192.168.0.0/24) can send email
without authentication (so mail server act has an open relay for local
machines). I played with the "mynetwork" config, but I'm getting
errors like "Authentication required 530 5.7.0 Must issue a STARTTLS
command first", when trying to send an email.

2- When using a non encrypted connection , only accept the CRAM-MD5
and Kerberos authentication methods

3- When using encrypted connection (via TLS or SSL), accept LOGIN,
PLAIN, Kerberos and CRAM-MD5 authentication methods.

4- I have added in sendmail a very simple rule allowing to create
dummy email address such as:
reg-username-ser...@domain.com

this is equivalent to usern...@domain.com

In sendmail, I would ad in the main .mc file:

LOCAL_CONFIG
Klist regex -s2,1,3 -d+ ^(reg)-(.+)-(.+)$$
LOCAL_RULE_0
R$+ < @ $=w . > $: $(list $1 $: $1 $) < @ $2 . >

I thought I could add something like this in the canonical file:
/^(reg)-(.*)-(.*)$/ ${2}

However, I read in a few place that this would break recipient validation.

And no, I do not want to use the + character, as there are too many
sites not allowing emails with a +, nor do I want to use - as there
are users with hyphenated names.

Thank you in advance for your help
Jean-Yves

Re: Migrating from sendmail, a few questions...

[Jean-Yves Avenard]

Hi again

On 30 August 2010 22:56, Jean-Yves Avenard  wrote:
> 4- I have added in sendmail a very simple rule allowing to create
> dummy email address such as:
> reg-username-ser...@domain.com
>
> this is equivalent to usern...@domain.com
>
> In sendmail, I would ad in the main .mc file:
>
> LOCAL_CONFIG
> Klist regex -s2,1,3 -d+ ^(reg)-(.+)-(.+)$$
> LOCAL_RULE_0
> R$+ < @ $=w . > $: $(list $1 $: $1 $) < @ $2 . >
>
> I thought I could add something like this in the canonical file:
> /^(reg)-(.*)-(.*)$/ ${2}
>
> However, I read in a few place that this would break recipient validation.

Should add that while with the canonical above I do get the email to
the proper mailbox delivered, the recipient is being rewritten to the
simple form instead.
so if I send to reg-jya-likelyspam...@domain.com, the recipient I can
see in the mail client is j...@domain.com

And I loose the whole idea I had to start with, which was to be able
to identify who is the one spamming and leaked the submitted email
address.

JY

Re: Migrating from sendmail, a few questions...

[Charles Marcus]

On 2010-08-30 8:56 AM, Jean-Yves Avenard  wrote:
> Moving from sendmail to a macos 10.6 server that ships with postfix..

Per the welcome message you received when you joined the list:

TO REPORT A PROBLEM see:
http://www.postfix.org/DEBUG_README.html#mail

This means, at a minimum, postfix version, output of postconf -n and
unedited NON-verbose logs exhibiting the problem...

-- 

Best regards,

Charles

Re: Migrating from sendmail, a few questions...

[Wietse Venema]

Jean-Yves Avenard:
> > I thought I could add something like this in the canonical file:
> > /^(reg)-(.*)-(.*)$/ ${2}
> >
> > However, I read in a few place that this would break recipient validation.
> 
> Should add that while with the canonical above I do get the email to
> the proper mailbox delivered, the recipient is being rewritten to the
> simple form instead.
> so if I send to reg-jya-likelyspam...@domain.com, the recipient I can
> see in the mail client is j...@domain.com

I kindly suggest that you read the manual (RTFM) before asking
questions that are already answered there.

Canonical mappings can rewrite the envelope addresses (i.e.  what
Postfix delivers) without changing the addresses in the message
header (i.e. what the mail client shows).

http://www.postfix.org/ADDRESS_REWRITING_README.html

If it is not documented, then it is not supported.

Wietse

Re: local_recipient_maps with LDAP

[Victor Duchovni]

On Sun, Aug 29, 2010 at 01:20:39AM +0200, Marco Rebsamen wrote:

>   query_filter = proxyaddresses=...@domain1.ch*

DO NOT use wildcard "*" patters to match recipients. The correct query
is:

query_filter = proxyAddresses=smtp:%...@domain1.ch

or, more typically:

query_filter = proxyAddresses=smtp:%s

Since AD will need to know all the proxyAddresses for a given user,
so there is generally no need to normalize the domain.

-- 
Viktor.

Re: Migrating from sendmail, a few questions...

[Jean-Yves Avenard]

Hi

On 30 August 2010 23:25, Charles Marcus  wrote:
> On 2010-08-30 8:56 AM, Jean-Yves Avenard  wrote:
>> Moving from sendmail to a macos 10.6 server that ships with postfix..
>
> Per the welcome message you received when you joined the list:
>
> TO REPORT A PROBLEM see:
> http://www.postfix.org/DEBUG_README.html#mail
>
> This means, at a minimum, postfix version, output of postconf -n and
> unedited NON-verbose logs exhibiting the problem...

I'm not reporting a "problem", it's more a configuration issue...
Can't see how a log could help here.

Here is the output of sendmail -bv reg-jya-likelyspam...@avenard.org
--
This is the mail system at host m.domain.com.

Enclosed is the mail delivery report that you requested.

   The mail system

 (expanded from
): delivery via dovecot: delivers to
command: /usr/libexec/dovecot/deliver
---

As for postconf -n

bash-3.2# postconf -n
biff = no
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
enable_server_options = yes
header_checks = pcre:/etc/postfix/custom_header_checks
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
mail_owner = _postfix
mailbox_size_limit = 0
mailbox_transport = dovecot
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_domains =
message_size_limit = 15728640
mydestination = $myhostname, localhost.$mydomain, localhost,
domain.com, $mydomain
mydomain = hydrix.com
mydomain_fallback = localhost
myhostname = m.domain.com
mynetworks = 127.0.0.0/8,192.168.0.0/23
newaliases_path = /usr/bin/newaliases
queue_directory = /private/var/spool/postfix
readme_directory = /usr/share/doc/postfix
recipient_canonical_maps = pcre:/etc/postfix/canonical
recipient_delimiter = +
relayhost =
sample_directory = /usr/share/doc/postfix/examples
sendmail_path = /usr/sbin/sendmail
setgid_group = _postdrop
smtpd_client_restrictions = permit_mynetworks
permit_sasl_authenticated reject_rbl_client zen.spamhaus.org permit
smtpd_enforce_tls = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
smtpd_pw_server_security_options = gssapi,cram-md5
smtpd_recipient_restrictions = permit_sasl_authenticated
permit_mynetworks  reject_unauth_destination check_policy_service
unix:private/policy permit
smtpd_sasl_auth_enable = yes
smtpd_tls_CAfile =
/etc/certificates/*.domain.com.8867E7D7D51B86638E02CD570752FE19F1D53683.chain.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file =
/etc/certificates/*.domain.com.8867E7D7D51B86638E02CD570752FE19F1D53683.cert.pem
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
smtpd_tls_key_file =
/etc/certificates/*.domain.com.8867E7D7D51B86638E02CD570752FE19F1D53683.key.pem
smtpd_use_pw_server = yes
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_domains = $virtual_alias_maps hash:/etc/postfix/virtual_domains
virtual_alias_maps = $virtual_maps hash:/etc/postfix/virtual_users

Thanks

Re: Migrating from sendmail, a few questions...

[Jean-Yves Avenard]

Hi


On 30 August 2010 23:43, Wietse Venema  wrote:

> I kindly suggest that you read the manual (RTFM) before asking
> questions that are already answered there.
>
> Canonical mappings can rewrite the envelope addresses (i.e.  what
> Postfix delivers) without changing the addresses in the message
> header (i.e. what the mail client shows).
>
> http://www.postfix.org/ADDRESS_REWRITING_README.html
>
> If it is not documented, then it is not supported.
>
>        Wietse
>


I have read this document already (and more than once), in particular
http://www.postfix.org/ADDRESS_REWRITING_README.html#receiving

I wouldn't have posted such questions, if I hadn't spent many hours by
myself trying to solve my issues :(

This document states:
"Postfix never rewrites message header addresses from remote SMTP
clients when the remote_header_rewrite_domain parameter value is empty
(the default setting)."

(with an introduction containing: "Message header address rewriting is
frowned upon by mail standards,").

I did *not* define remote_header_rewrite_domain anywhere, yet the
recipient is being rewritten. Unless I misread how this configuration
parameter actually works.

Forgot to add that I'm using postfix 2.5.5

JY

Re: Log the applied TLS policy

[Victor Duchovni]

On Sat, Aug 28, 2010 at 07:02:48PM +0200, martin f krafft wrote:

> We are using $smtp_tls_policy_maps, in addition to

This is a feature of the Postfix SMTP *client*, that sends mail to
remote sites.

> Due to some issues we've been having[0], I would like to have a more
> permanent means of confirmation that everything is in order.
> Specifically, I would like to see in the logs when a security policy
> was matched and applied. No matter how high I set

The security policy is indirectly logged when certificate matching
(fingerprint, verify or secure) is required, since the destination
will be logged as "Verified".

2010-08-30T09:58:09-04:00 amnesiac postfix/smtp[8804]:
Verified TLS connection established to
cluster12.us.messagelabs.com[85.158.136.227]:25:
TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

while for destinations with opportunistic TLS or mandatory encryption
without authentication, you see:

2010-08-30T09:59:04-04:00 amnesiac postfix-out/smtp[8758]:
Trusted TLS connection established to
cluster8.us.messagelabs.com[216.82.241.83]:25:
TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

> Is it possible to configure postfix to log when it applies
> a security policy?

The policy can be rather long, perhaps you just want to
log the resulting security level, or do you want the nexthop
lookup key? It may be possible to tweak the above log entry,
to include the desired security level...

> Is it possible to have postfix add this information to the received
> header? Would this be something worthwhile?

Received headers are a feature of the Postfix SMTP server, that
receives mail *from* remote destinations, so clearly the answer
is: NO.

-- 
Viktor.

Re: Migrating from sendmail, a few questions...

[Jean-Yves Avenard]

On 30 August 2010 23:58, Jean-Yves Avenard  wrote:

> I did *not* define remote_header_rewrite_domain anywhere, yet the
> recipient is being rewritten. Unless I misread how this configuration
> parameter actually works.
>

Oh, I see what's going on, as I'm doing my test from a local subnet,
the address is being rewritten

adding:
local_header_rewrite_clients =

fixed it...

Now for my TLS / SSL , LOGIN authentication questions if you may ? :P

JY

Re: Lookup key of smtp_tls_policy_maps

[Victor Duchovni]

On Sat, Aug 28, 2010 at 07:00:58PM +0200, martin f krafft wrote:

> > The Postfix TLS security policy is based on where the mail is going
> > (its destination domain or administratively defined gateway).
> 
> With "administratively defined gateway", you mean an entry in
> transport_maps?

Yes. This is typically again a domain, unless you use the "[hostname]"
syntax.

> Is it intentional then that the TLS policy map is
> searched for the nexthop, if one is defined there?

Yes.

> Does it /also/ check the policy for the recipient domain?

No. TLS policy is by nexthop. TLS is a hop-by-hop security protocol,
not an end-to-end security mechanism like S/MIME or OpenPGP.

> > DNSSEC validated MX RRsets cannot yet be used as the source for
> > certificate name matching. I am not currently inclined to implement
> > this, I'd rather use DNSSEC more fully to just dispense with public
> > CAs and obtain securely published peer certs or fingerprints.
> 
> We have established that the maps are indexed by recipient domain
> (and/or possibly "administratively defined gateway", see above), and
> that DNS data are never used for this lookup.

Correct.

> Now you are talking about the verification match. You say that it's
> not possible to use DNS data for verification. In the light of this,
> what then is the difference between the "verify" and the "secure"
> policies?

The default matching rules for "verify" include the MX hostname.
The "verify" security level is not recommended. Its inclusion in the
design is (with 20/20 hindsight) an error. Since one can specify the
matching rules for "secure", there is not really a need for a different
"verify" level that differs only in the default matching rules.

-- 
Viktor.

Re: local_recipient_maps with LDAP

[Patrick Ben Koetter]

* Victor Duchovni :
> On Sun, Aug 29, 2010 at 01:20:39AM +0200, Marco Rebsamen wrote:
> 
> > query_filter = proxyaddresses=...@domain1.ch*
> 
> DO NOT use wildcard "*" patters to match recipients. The correct query
> is:
> 
> query_filter = proxyAddresses=smtp:%...@domain1.ch
> 
> or, more typically:
> 
> query_filter = proxyAddresses=smtp:%s

Is "smtp:%s" sufficient? IIRC the main mail address is noted as "SMTP:%s". A
query that catches those too would be this:

 query_filter = (|(proxyAddresses=smtp:%s)(proxyAddresses=SMTP:%s))

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):

Re: local_recipient_maps with LDAP

[Patrick Ben Koetter]

* Patrick Ben Koetter :
> Is "smtp:%s" sufficient? IIRC the main mail address is noted as "SMTP:%s". A
> query that catches those too would be this:
> 
>  query_filter = (|(proxyAddresses=smtp:%s)(proxyAddresses=SMTP:%s))

On second thought...

A query that matches all aliases goes like this:

  query_filter = proxyAddresses=smtp:%s

A query filter that matches final recipients:

  query_filter = proxyAddresses=SMTP:%s

To limit query to local domain addresses only add the domainpart:

  query_filter = proxyAddresses=smtp:%...@example.com

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):

Re: local_recipient_maps with LDAP

[Victor Duchovni]

On Mon, Aug 30, 2010 at 04:39:46PM +0200, Patrick Ben Koetter wrote:

> * Victor Duchovni :
> > On Sun, Aug 29, 2010 at 01:20:39AM +0200, Marco Rebsamen wrote:
> > 
> > >   query_filter = proxyaddresses=...@domain1.ch*
> > 
> > DO NOT use wildcard "*" patters to match recipients. The correct query
> > is:
> > 
> > query_filter = proxyAddresses=smtp:%...@domain1.ch
> > 
> > or, more typically:
> > 
> > query_filter = proxyAddresses=smtp:%s
> 
> Is "smtp:%s" sufficient? IIRC the main mail address is noted as "SMTP:%s". A
> query that catches those too would be this:

The proxyAddresses field is matched case-insensitively. No fancy gymnastics
required:

>  query_filter = (|(proxyAddresses=smtp:%s)(proxyAddresses=SMTP:%s))

The first string matches both.

-- 
Viktor.

Re: local_recipient_maps with LDAP

[Victor Duchovni]

On Mon, Aug 30, 2010 at 04:45:39PM +0200, Patrick Ben Koetter wrote:

> * Patrick Ben Koetter :
> > Is "smtp:%s" sufficient? IIRC the main mail address is noted as "SMTP:%s". A
> > query that catches those too would be this:
> > 
> >  query_filter = (|(proxyAddresses=smtp:%s)(proxyAddresses=SMTP:%s))
> 
> On second thought...
> 
> A query that matches all aliases goes like this:
> 
>   query_filter = proxyAddresses=smtp:%s
> 
> A query filter that matches final recipients:
> 
>   query_filter = proxyAddresses=SMTP:%s

This is wrong. Both queries find the same results.

-- 
Viktor.

Re: local_recipient_maps with LDAP

[Patrick Ben Koetter]

* Victor Duchovni :
> > Is "smtp:%s" sufficient? IIRC the main mail address is noted as "SMTP:%s". A
> > query that catches those too would be this:
> 
> The proxyAddresses field is matched case-insensitively. No fancy gymnastics
> required:
> 
> >  query_filter = (|(proxyAddresses=smtp:%s)(proxyAddresses=SMTP:%s))
> 
> The first string matches both.

Case-insensitive because the matching rule for proxyAddresses is
case-insensitive?

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):

Re: Migrating from sendmail, a few questions...

[Adam Tauno Williams]

On Mon, 2010-08-30 at 22:56 +1000, Jean-Yves Avenard wrote:
> Hi there.
> Moving from sendmail to a macos 10.6 server that ships with postfix..
> There are a few things that I'm trying to replicate from sendmail into
> postifx, but I'm not having much luck.
> Problems:
> 2- When using a non encrypted connection , only accept the CRAM-MD5
> and Kerberos authentication methods
> 3- When using encrypted connection (via TLS or SSL), accept LOGIN,
> PLAIN, Kerberos and CRAM-MD5 authentication methods.



"A separate parameter controls Postfix SASL mechanism policy during a
TLS-encrypted SMTP session. The default is to copy the settings from the
unencrypted session:"

smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous

See 
for list of the available documentation.

HINT:  The Postfix documentation is rather crazy,  you need to just
keep-on-a-clicking till you find the option the detail you need just so
happens to be listed under.  And be prepared to *constantly* be accused
by members of this list that you are lazy/incompetent/illiterate and
didn't look at the documentation.

> 4- I have added in sendmail a very simple rule allowing to create
> dummy email address such as:
> reg-username-ser...@domain.com
> this is equivalent to usern...@domain.com

I think using plussed addresses would be easier, and is a generally
recognized standard.  Otherwise perhaps some kind of regular expression
rewrite?

Re: local_recipient_maps with LDAP

[Victor Duchovni]

On Mon, Aug 30, 2010 at 04:58:48PM +0200, Patrick Ben Koetter wrote:

> * Victor Duchovni :
> > > Is "smtp:%s" sufficient? IIRC the main mail address is noted as 
> > > "SMTP:%s". A
> > > query that catches those too would be this:
> > 
> > The proxyAddresses field is matched case-insensitively. No fancy gymnastics
> > required:
> > 
> > >  query_filter = (|(proxyAddresses=smtp:%s)(proxyAddresses=SMTP:%s))
> > 
> > The first string matches both.
> 
> Case-insensitive because the matching rule for proxyAddresses is
> case-insensitive?

Yes, naturally. The case of the "smtp" prefix only matters when it
is used as a result value, not when it is a lookup key.

-- 
Viktor.

Re: Migrating from sendmail, a few questions...

[Jean-Yves Avenard]

Hi

On 31 August 2010 01:00, Adam Tauno Williams  wrote:
> "A separate parameter controls Postfix SASL mechanism policy during a
> TLS-encrypted SMTP session. The default is to copy the settings from the
> unencrypted session:"
>
> smtpd_sasl_security_options = noanonymous, noplaintext
> smtpd_sasl_tls_security_options = noanonymous

I've had played with those settings already, to no available.
I have:
smtpd_use_tls = yes
smtpd_enforce_tls = no
smtpd_tls_auth_only = no
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous

telnet localhost 25 shows:
250-AUTH LOGIN PLAIN CRAM-MD5 GSSAPI
250-STARTTLS

connection via SSL:
250-AUTH LOGIN PLAIN CRAM-MD5 GSSAPI

FWIW, under sendmail, I would do:
define(`confAUTH_OPTIONS', `A,p,y')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl
define(`confAUTH_MECHANISMS',`LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl

it's the 'p' in confAUTH_OPTIONS that does it all..

>
> See 
> for list of the available documentation.
>
> HINT:  The Postfix documentation is rather crazy,  you need to just
> keep-on-a-clicking till you find the option the detail you need just so
> happens to be listed under.  And be prepared to *constantly* be accused
> by members of this list that you are lazy/incompetent/illiterate and
> didn't look at the documentation.

I had noticed :)

I've found the postifx documentation to be extremely complete... I was
surprised actually by the extent of the documentation, pleasant
surprise.

> I think using plussed addresses would be easier, and is a generally
> recognized standard.  Otherwise perhaps some kind of regular expression
> rewrite?

Because when using a +, I've found that it is often not accepted as a
valid email by many vendors ..
I've found my answer already... thanks for that

Cheers
JY

LDAP maps and bind referrals

[Victoriano Giralt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello, we are using LDAP for mail routing with Postfix. We have moved the
directory infrastructure and we can now do things without tearing down
servers, but ... when a server is not able to perform a search it send back
a bind referral.

How does Postfix react to this?

I see this in the logs:
Aug 30 18:10:27 correoe1 postfix/proxymap[19744]: warning:
dict_ldap_connect: Unable to bind to server ldap://10.0.1.6:389
ldap://10.0.1.7:389 as cn=bind dn here: 9 (Partial results and referral
received)
Aug 30 18:10:27 correoe1 postfix/smtpd[19816]: NOQUEUE: reject: RCPT from
mailfwd.nih.gov[128.231.90.106]: 451 4.3.0 :
Temporary lookup failure; from=
to= proto=ESMTP helo=

It seems that postfix tries does not know what to do, as the system in the
referral is not reachable (that is what might require second thoughts), but
the firewall produces an immediate TCP reset, so 10.0.1.6 should, IMHO, be
considered unreachable and 10.0.1.7 tried instead.

Am I totally confused? Is this the intended flow?

Thank you.
- --
Victoriano Giralt
Systems Manager
Central ICT Services
University of Malaga
SPAIN
- -
A: Yes.
| > Q: Are you sure ?
|> >> A: Because it reverses the logical flow of conversation.
|>> >>> Q: Why is top posting annoying in email ?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFMe9lXV6+mDjj1PTgRAkaNAJ4787Vp+PZs+NUUM15nB7l4yLUdFwCgssG1
5UM7IkyVOL559vzwVeRO4A0=
=3B7Y
-END PGP SIGNATURE-

Re: LDAP maps and bind referrals

[Victor Duchovni]

On Mon, Aug 30, 2010 at 06:16:24PM +0200, Victoriano Giralt wrote:

> How does Postfix react to this?

> I see this in the logs:
> Aug 30 18:10:27 correoe1 postfix/proxymap[19744]: warning:
> dict_ldap_connect: Unable to bind to server ldap://10.0.1.6:389
> ldap://10.0.1.7:389 as cn=bind dn here: 9 (Partial results and referral
> received)
> Aug 30 18:10:27 correoe1 postfix/smtpd[19816]: NOQUEUE: reject: RCPT from
> mailfwd.nih.gov[128.231.90.106]: 451 4.3.0 :
> Temporary lookup failure; from=
> to= proto=ESMTP helo=
>
> It seems that postfix tries does not know what to do, as the system in the
> referral is not reachable (that is what might require second thoughts), but
> the firewall produces an immediate TCP reset, so 10.0.1.6 should, IMHO, be
> considered unreachable and 10.0.1.7 tried instead.
>
> Am I totally confused? Is this the intended flow?

The LDAP library hands Postfix a connection, when Postfix fails
to bind it gives up.

-- 
Viktor.

Re: Migrating from sendmail, a few questions...

[Wietse Venema]

Jean-Yves Avenard:
> Hi
> 
> On 31 August 2010 01:00, Adam Tauno Williams  wrote:
> > "A separate parameter controls Postfix SASL mechanism policy during a
> > TLS-encrypted SMTP session. The default is to copy the settings from the
> > unencrypted session:"
> >
> > smtpd_sasl_security_options = noanonymous, noplaintext
> > smtpd_sasl_tls_security_options = noanonymous
> 
> I've had played with those settings already, to no available.
> I have:
> smtpd_use_tls = yes
> smtpd_enforce_tls = no
> smtpd_tls_auth_only = no
> smtpd_sasl_security_options = noanonymous, noplaintext
> smtpd_sasl_tls_security_options = noanonymous

When reporting a problem, please follow the mailing list
welcome message's instructions.

In particular, use "postconf -n" command output instead
of cut-and-paste from main.cf.

Wietse

Re: Migrating from sendmail, a few questions...

[Jean-Yves Avenard]

Hi

On 31 August 2010 02:38, Wietse Venema  wrote:
> When reporting a problem, please follow the mailing list
> welcome message's instructions.
>
> In particular, use "postconf -n" command output instead
> of cut-and-paste from main.cf.

I already posted those in an earlier message, am I supposed to provide
this information in every single message I post?

In the mean time, I've given up on this particular matter, I simply
won't accept any authentication outside SSL/TLS as I've spent way too
many times on this matter already.

Now, I only need to find out why local users can't sent email outside
the local network without authentication


bash-3.2# postconf -n
biff = no
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
enable_server_options = yes
header_checks = pcre:/etc/postfix/custom_header_checks
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
local_header_rewrite_clients =
mail_owner = _postfix
mailbox_size_limit = 0
mailbox_transport = dovecot
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_domains =
message_size_limit = 15728640
mydestination = $myhostname, localhost.$mydomain, localhost,
domain.com, $mydomain
mydomain = domain.com
mydomain_fallback = localhost
myhostname = domain.com
mynetworks = 127.0.0.0/8,192.168.0.0/23
newaliases_path = /usr/bin/newaliases
queue_directory = /private/var/spool/postfix
readme_directory = /usr/share/doc/postfix
recipient_canonical_maps = pcre:/etc/postfix/canonical
recipient_delimiter = +
relayhost =
sample_directory = /usr/share/doc/postfix/examples
sendmail_path = /usr/sbin/sendmail
setgid_group = _postdrop
smtpd_client_restrictions = permit_mynetworks
permit_sasl_authenticated reject_rbl_client zen.spamhaus.org permit
smtpd_enforce_tls = no
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
smtpd_pw_server_security_options = gssapi,cram-md5,plain,login
smtpd_recipient_restrictions = permit_sasl_authenticated
permit_mynetworks  reject_unauth_destination check_policy_service
unix:private/policy permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_tls_CAfile =
/etc/certificates/*.domain.com.8867E7D7D51B86638E02CD570752FE19F1D53683.chain.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file =
/etc/certificates/*.domain.com.8867E7D7D51B86638E02CD570752FE19F1D53683.cert.pem
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
smtpd_tls_key_file =
/etc/certificates/*.domain.com.8867E7D7D51B86638E02CD570752FE19F1D53683.key.pem
smtpd_use_pw_server = yes
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_domains = $virtual_alias_maps hash:/etc/postfix/virtual_domains
virtual_alias_maps = $virtual_maps hash:/etc/postfix/virtual_users

Re: LDAP maps and bind referrals

[Victoriano Giralt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Victor Duchovni wrote:
|> It seems that postfix tries does not know what to do, as the system in the
|> referral is not reachable (that is what might require second thoughts), but
|> the firewall produces an immediate TCP reset, so 10.0.1.6 should, IMHO, be
|> considered unreachable and 10.0.1.7 tried instead.
|>
|> Am I totally confused? Is this the intended flow?
|
| The LDAP library hands Postfix a connection, when Postfix fails
| to bind it gives up.
Thanks, Victor. As usual, you're right ;)

Once the LDAP library has been properly tamed, everything is working nicely.

For the records, as it is OpenLDAP under the hood, adding

NETWORK_TIMEOUT 2
REFERRALS   off

to /etc/openldap/ldap.conf (normal RHEL location, YMMV) made the trick. The
timeout value is incidental, I have reduced it as directory servers are
very close (same LAN segment) to Postfix servers and should respond almost
immediately.

- --
Victoriano Giralt
Systems Manager
Central ICT Services
University of Malaga
SPAIN
- -
A: Yes.
| > Q: Are you sure ?
|> >> A: Because it reverses the logical flow of conversation.
|>> >>> Q: Why is top posting annoying in email ?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFMe+OWV6+mDjj1PTgRAh6DAKCUtOqEjsw46h9JqRG805C1M5XqiACgy+gf
mahu0/1tEk7mei8zAJVmZC0=
=w70H
-END PGP SIGNATURE-

John/SML is out of the office.

[John/SML]

I will be out of the office starting  08/30/2010 and will not return until
09/05/2010.

I will respond to your message when I return.

Re: Migrating from sendmail, a few questions...

[Wietse Venema]

Jean-Yves Avenard:
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_authenticated_header = yes
> smtpd_sasl_security_options = noanonymous, noplaintext
> smtpd_sasl_tls_security_options = noanonymous

If this does not announce the SASL mechanisms that you expect, then
the missing mechanisms are not installed with the Cyrus SASL library.

Each Cyrus SASL is provided as a shared object file. On many systems
these files are called /usr/libsasl/digestmd5.so.1, /usr/libsasl/plain.so.1
and so on.

I don't know if Patrik's saslfinger tool works on MacOS, but it
would list out these files for you (along with "postconf -n" output
and other information that helps to quickly solve many problems
with Cyrus SASL deployment).

Wietse

Re: Migrating from sendmail, a few questions...

[Wietse Venema]

Wietse Venema:
> Jean-Yves Avenard:
> > smtpd_sasl_auth_enable = yes
> > smtpd_sasl_authenticated_header = yes
> > smtpd_sasl_security_options = noanonymous, noplaintext
> > smtpd_sasl_tls_security_options = noanonymous
> 
> If this does not announce the SASL mechanisms that you expect, then
> the missing mechanisms are not installed with the Cyrus SASL library.
> 
> Each Cyrus SASL is provided as a shared object file. On many systems
> these files are called /usr/libsasl/digestmd5.so.1, /usr/libsasl/plain.so.1
> and so on.

To make things more interesting, Cyrus SASL is controlled with a
configuration file that can specify a mechanism filter. See 
http://www.postfix.org/SASL_README.html for the gory details

> I don't know if Patrik's saslfinger tool works on MacOS, but it
> would list out these files for you (along with "postconf -n" output
> and other information that helps to quickly solve many problems
> with Cyrus SASL deployment).
> 
>   Wietse
> 
> 

Re: Migrating from sendmail, a few questions...

[Victor Duchovni]

On Tue, Aug 31, 2010 at 02:57:05AM +1000, Jean-Yves Avenard wrote:

> smtpd_pw_server_security_options = gssapi,cram-md5,plain,login
> smtpd_recipient_restrictions = permit_sasl_authenticated
> permit_mynetworks  reject_unauth_destination check_policy_service
> unix:private/policy permit
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_authenticated_header = yes
> smtpd_sasl_security_options = noanonymous, noplaintext
> smtpd_sasl_tls_security_options = noanonymous
> smtpd_use_pw_server = yes

Note also, that Apple modifies the Postfix SASL support to integrate
Apple's Directory service and security services. To get support for
these, contact Apple...

-- 
Viktor.

Re: Migrating from sendmail, a few questions...

[Patrick Ben Koetter]

I just started to follow this thread and had deleted the rest before. If I can
be of any assistance in terms of Cyrus SASL let me know. Mac OS X runs its own
special Cyrus SASL and I might not be able to help all the way. Anyway... 

p...@rick


* Wietse Venema :
> Wietse Venema:
> > Jean-Yves Avenard:
> > > smtpd_sasl_auth_enable = yes
> > > smtpd_sasl_authenticated_header = yes
> > > smtpd_sasl_security_options = noanonymous, noplaintext
> > > smtpd_sasl_tls_security_options = noanonymous
> > 
> > If this does not announce the SASL mechanisms that you expect, then
> > the missing mechanisms are not installed with the Cyrus SASL library.
> > 
> > Each Cyrus SASL is provided as a shared object file. On many systems
> > these files are called /usr/libsasl/digestmd5.so.1, /usr/libsasl/plain.so.1
> > and so on.
> 
> To make things more interesting, Cyrus SASL is controlled with a
> configuration file that can specify a mechanism filter. See 
> http://www.postfix.org/SASL_README.html for the gory details
> 
> > I don't know if Patrik's saslfinger tool works on MacOS, but it
> > would list out these files for you (along with "postconf -n" output
> > and other information that helps to quickly solve many problems
> > with Cyrus SASL deployment).
> > 
> > Wietse
> > 
> > 
> 

-- 
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):

Re: Migrating from sendmail, a few questions...

[Adam Tauno Williams]

On Mon, 2010-08-30 at 13:04 -0400, Wietse Venema wrote:
> Jean-Yves Avenard:
> > smtpd_sasl_auth_enable = yes
> > smtpd_sasl_authenticated_header = yes
> > smtpd_sasl_security_options = noanonymous, noplaintext
> > smtpd_sasl_tls_security_options = noanonymous
> If this does not announce the SASL mechanisms that you expect, then
> the missing mechanisms are not installed with the Cyrus SASL library.

No, as demonstrate previously in the thread:

telnet localhost 25 shows:
250-AUTH LOGIN PLAIN CRAM-MD5 GSSAPI
250-STARTTLS


- the issue is that Postfix advertises "LOGIN" and "PLAIN" regardless of
the presence of "noplaintext" in smtpd_sasl_security_options




Interesting there appears to be a "smtp_sasl_mechanism_filter" but I
don't find anywhere a similar filter for clients (I always assumed that
smtpd_sasl_*_security_options implied one).

Re: Migrating from sendmail, a few questions...

[Victor Duchovni]

On Mon, Aug 30, 2010 at 01:32:25PM -0400, Adam Tauno Williams wrote:

> On Mon, 2010-08-30 at 13:04 -0400, Wietse Venema wrote:
> > Jean-Yves Avenard:
> > > smtpd_sasl_auth_enable = yes
> > > smtpd_sasl_authenticated_header = yes
> > > smtpd_sasl_security_options = noanonymous, noplaintext
> > > smtpd_sasl_tls_security_options = noanonymous
> > If this does not announce the SASL mechanisms that you expect, then
> > the missing mechanisms are not installed with the Cyrus SASL library.
> 
> No, as demonstrate previously in the thread:
> 
> telnet localhost 25 shows:
> 250-AUTH LOGIN PLAIN CRAM-MD5 GSSAPI
> 250-STARTTLS
> 
> 
> - the issue is that Postfix advertises "LOGIN" and "PLAIN" regardless of
> the presence of "noplaintext" in smtpd_sasl_security_options

Probably not surprising when the Cyrus library is pre-empted by Apple's
"pw" server, and the mechanism list is defined in an Apple-specific
configuration parameter.

-- 
Viktor.

check header from, reply-to, message-id domains against spamhaus dbl?

[Stan Hoeppner]

Is there a straightforward (i.e. relatively painless) way to check the
header from, reply-to, and message-id domains against dbl.spamhaus.org
and reject on a positive reply as with reject_r*bl_client?

Without having to write a content filter to be called in action
filter:nexthop in header_checks.pcre?

-- 
Stan

Re: check header from, reply-to, message-id domains against spamhaus dbl?

[Victor Duchovni]

On Mon, Aug 30, 2010 at 01:06:28PM -0500, Stan Hoeppner wrote:

> Is there a straightforward (i.e. relatively painless) way to check the
> header from, reply-to, and message-id domains against dbl.spamhaus.org
> and reject on a positive reply as with reject_r*bl_client?

Not from Postfix. There is currently no support in cleanup(8)
for extracting domains from headers and applying RBL checks. The
Postfix SMTP server does not look at the message content.

> Without having to write a content filter to be called in action
> filter:nexthop in header_checks.pcre?

It would need to be a pre-queue proxy filter, to reject mail.

-- 
Viktor.

Re: check header from, reply-to, message-id domains against spamhaus dbl?

[Michael Orlitzky]

On 08/30/2010 02:06 PM, Stan Hoeppner wrote:
> Is there a straightforward (i.e. relatively painless) way to check the
> header from, reply-to, and message-id domains against dbl.spamhaus.org
> and reject on a positive reply as with reject_r*bl_client?
> 
> Without having to write a content filter to be called in action
> filter:nexthop in header_checks.pcre?
> 

Use SpamAssassin 3.3.1, which adds the URIBL_DBL_SPAM rule.

Re: check header from, reply-to, message-id domains against spamhaus dbl?

[Wietse Venema]

Victor Duchovni:
> On Mon, Aug 30, 2010 at 01:06:28PM -0500, Stan Hoeppner wrote:
> 
> > Is there a straightforward (i.e. relatively painless) way to check the
> > header from, reply-to, and message-id domains against dbl.spamhaus.org
> > and reject on a positive reply as with reject_r*bl_client?
> 
> Not from Postfix. There is currently no support in cleanup(8)
> for extracting domains from headers and applying RBL checks. The
> Postfix SMTP server does not look at the message content.

Some courageous person could implement this as:

header_checks = tcp:127.0.0.1:port

and write a Perl script that rips domain names from headers and
runs them through dbl lookups.

I don't have time, but with Net::DNS this should involve no more
than a dozen lines of code (using the spawn(8) daemon for connection
management). As a stand-alone program, maybe two dozen lines.

Wietse

> > Without having to write a content filter to be called in action
> > filter:nexthop in header_checks.pcre?
> 
> It would need to be a pre-queue proxy filter, to reject mail.
> 
> -- 
>   Viktor.
> 
> 

AW: local_recipient_maps with LDAP

[Marco Rebsamen]

Ok, I'm really confused about that LDAP lookup stuff :-/
What I want to do is to check if an address to which a message is addressed 
really exists.

I'm currently using this script for local receipient checks:

bind_dn = j...@hive.loc
bind_pw = 
server_host = 192.168.8.254

#Global Catalog port
server_port = 3268

search_base = DC=hive, DC=loc
query_filter = proxyAddresses=smtp:*...@unimatrix0.ch
result_attribute = proxyAddresses

the result is the complete list of all addresses a user has. But I'm not sure 
if this is right. I delivered a test message by hand through telnet and somehow 
it got delivered to any address in the result even in the system. So I guess I 
really missed something... :-/


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
Im Auftrag von Victor Duchovni
Gesendet: Montag, 30. August 2010 17:17
An: postfix-users@postfix.org
Betreff: Re: local_recipient_maps with LDAP

On Mon, Aug 30, 2010 at 04:58:48PM +0200, Patrick Ben Koetter wrote:

> * Victor Duchovni :
> > > Is "smtp:%s" sufficient? IIRC the main mail address is noted as 
> > > "SMTP:%s". A
> > > query that catches those too would be this:
> > 
> > The proxyAddresses field is matched case-insensitively. No fancy gymnastics
> > required:
> > 
> > >  query_filter = (|(proxyAddresses=smtp:%s)(proxyAddresses=SMTP:%s))
> > 
> > The first string matches both.
> 
> Case-insensitive because the matching rule for proxyAddresses is
> case-insensitive?

Yes, naturally. The case of the "smtp" prefix only matters when it
is used as a result value, not when it is a lookup key.

-- 
Viktor.

Re: local_recipient_maps with LDAP

[Victor Duchovni]

On Mon, Aug 30, 2010 at 08:50:33PM +0200, Marco Rebsamen wrote:

> 
> Ok, I'm really confused about that LDAP lookup stuff :-/
> What I want to do is to check if an address to which a message is addressed 
> really exists.
> 
> I'm currently using this script for local receipient checks:
> 
> bind_dn = j...@hive.loc
> bind_pw = 
> server_host = 192.168.8.254
> 
> #Global Catalog port
> server_port = 3268
> 
> search_base = DC=hive, DC=loc
> query_filter = proxyAddresses=smtp:*...@unimatrix0.ch
> result_attribute = proxyAddresses

What is that pesky "*" doing in your query filter!!!

Why is "proxyAddresses" the right result attribute. I would use "mail".

Report problems accurately with supporting "postconf -n" output,
table definitions AND logs!

-- 
Viktor.

postscreen update: DNSBL filters and weights

[Wietse Venema]

Postscreen is a single Postfix 2.8 daemon that keeps spambots away
from Postfix SMTP server processes, so that more Postfix server
resources remain available for handling mail. It will hopefully
become part of the next stable Postfix release.

Below is a quote from the release notes about new filter and weight
support for postscreen DNSBL lookup results. This was released
earlier as non-production snapshot. It has held up well, and after
some polishing of documentation and comments, it should be ready.

Next steps are a) support for different expiration times for
different tests, b) a dummy SMTP engine (similar to the smtp-sink
test program) to log the client/helo/sender/recipient for blocked
mail, and c) a simple form of greylisting if time permits.

Wietse

Incompatibility with snapshot 20100830
==

Use "postfix reload" after installing this code, otherwise the
dnsblog(8) daemon may complain.  The postscreen-to-dnsblog protocol
had to be changed to support DNSBL query result filters.

Major changes with snapshot 20100830


Postscreen DNSBL support is extended with optional fixed-string
filters, with optional integral weight factors, and with an adjustable
threshold to block SMTP clients with DNSBL score >= that threshold.
Support for wild-card patterns will be added later.

The updated postscreen configuration syntax is:

postscreen_dnsbl_sites = domain[=ipaddr][*weight] ...
postscreen_dnsbl_threshold = score

Elements inside [] are optional, ipaddr is an IPv4 address, and
weight and score are integral numbers. The [] are not part of the
postscreen_dnsbl_sites input.  By default, weight and score are
equal to 1, and entries without filter will match any non-error
DNSBL reply.  Use a negative weight value for whitelisting.

Examples:

To use example.com as a high-confidence blocklist, and to block
mail with example.net and example.org only when both agree, use:

postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites = example.com*2, example.net, example.org

To filter only DNSBL replies containing 127.0.0.4, use:

postscreen_dnsbl_sites = example.com=127.0.0.4

See also postconf(5) for the fine details.

Re: Log the applied TLS policy

[martin f krafft]

also sprach Wietse Venema  [2010.08.28.2324 +0200]:
> > Due to some issues we've been having[0], I would like to have a more
> > permanent means of confirmation that everything is in order.
> > Specifically, I would like to see in the logs when a security policy
> > was matched and applied. No matter how high I set
> 
> Turn on -v verbose logging.

Indeed, this produces, e.g. in this test case:

  postfix/smtp[9743]: global TLS level: may
  postfix/smtp[9743]: maps_find: smtp_tls_policy_maps: 
hash:/etc/postfix/tls_policy(0,lock|fold_fix): madduck.net = secure 
match=.mx.madduck.net
  postfix/smtp[9743]: effective TLS level: secure

but it also produces a *slew* of other information, which drowns the logs.



also sprach Victor Duchovni  
[2010.08.30.1604 +0200]:
> > Due to some issues we've been having[0], I would like to have a more
> > permanent means of confirmation that everything is in order.
> > Specifically, I would like to see in the logs when a security policy
> > was matched and applied. No matter how high I set
> 
> The security policy is indirectly logged when certificate matching
> (fingerprint, verify or secure) is required, since the destination
> will be logged as "Verified".
> 
> 2010-08-30T09:58:09-04:00 amnesiac postfix/smtp[8804]:
>   Verified TLS connection established to
>   cluster12.us.messagelabs.com[85.158.136.227]:25:
>   TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

This requires smtp_tls_loglevel >= 1, but thanks for the tip!

This showed something curious:

My tls_policy maps recipient domains one.com and two.com, both handled by MX
a.mx.madduck.net, to "secure match=.mx.madduck.net".

Now I just sent something to three.com, which is also handled by
a.mx.madduck.net, but it is not listed in the tls_policy maps. Yet,
the connection was Trusted:

  postfix/smtp[10212]: setting up TLS connection to 
a.mx.madduck.net[2001:470:9aad::1]:25
  postfix/smtp[10212]: Trusted TLS connection established to 
a.mx.madduck.net[2001:470:9aad::1]:25: TLSv1 with cipher DHE-RSA-AES256-SHA 
(256/256 bits)
  postfix/smtp[10212]: C0ADEDD6: to=, 
relay=a.mx.madduck.net[2001:470:9aad::1]:25, delay=8.6, delays=0.09/0/0.52/8, 
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as ED507427513)

Why did this happen?

With -v, it says:

  postfix/smtp[10676]: global TLS level: may
  postfix/smtp[10676]: maps_find: smtp_tls_policy_maps: three.com: not found
  postfix/smtp[10676]: maps_find: smtp_tls_policy_maps: .com: not found
  postfix/smtp[10676]: effective TLS level: may
  […]
  postfix/smtp[10676]: send attr cache_id = 
smtp:2001:470:9aad::1:25:seamus.madduck.net&p=1&c=ALL:+RC4:@STRENGTH

Has it cached the session? Is this what $smtp_tls_session_cache_database is 
about?

> > Is it possible to configure postfix to log when it applies
> > a security policy?
> 
> The policy can be rather long, perhaps you just want to log the
> resulting security level, or do you want the nexthop lookup key?
> It may be possible to tweak the above log entry, to include the
> desired security level...

I'd love a statement like "selected `secure' security level and
verified match=.mx.madduck.net because of nexthop mapping
madduck.net" or the like.

> > Is it possible to have postfix add this information to the
> > received header? Would this be something worthwhile?
> 
> Received headers are a feature of the Postfix SMTP server, that
> receives mail *from* remote destinations, so clearly the answer
> is: NO.

Of course, that is what "received" implies.

Maybe Postfix could thus add a different header? Or is adding
headers by the SMTP client a no-go?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"the unexamined life is not worth living"
 -- platon
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Lookup key of smtp_tls_policy_maps

[martin f krafft]

also sprach Victor Duchovni  
[2010.08.30.1611 +0200]:
> > Is it intentional then that the TLS policy map is searched for
> > the nexthop, if one is defined there?
> 
> Yes.
> 
> > Does it /also/ check the policy for the recipient domain?
> 
> No. TLS policy is by nexthop. TLS is a hop-by-hop security
> protocol, not an end-to-end security mechanism like S/MIME or
> OpenPGP.

Good point, very illuminating perspective; thank you for clearing
this up for me.

> > Now you are talking about the verification match. You say that
> > it's not possible to use DNS data for verification. In the light
> > of this, what then is the difference between the "verify" and
> > the "secure" policies?
> 
> The default matching rules for "verify" include the MX hostname.
> The "verify" security level is not recommended. Its inclusion in
> the design is (with 20/20 hindsight) an error. Since one can
> specify the matching rules for "secure", there is not really
> a need for a different "verify" level that differs only in the
> default matching rules.

But I beg to differ with your hindsight, but only with a small
use-case: if you can be sure that *all* DNS responses are
secure/trustworthy (read: closed set of zones, DNSSEC validation by
the recursor on the MX), then "verify" allows you to keep the match
information in one place: the DNS MX records.

Arguably, this is a teeny-tiny use-case, so I tend to agree with
you.

Thanks,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"america may be unique in being a country which has leapt
 from barbarism to decadence without touching civilization."
-- john o'hara
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

AW: local_recipient_maps with LDAP

[Marco Rebsamen]

-Ursprüngliche Nachricht-
Von: Victor Duchovni [mailto:victor.ducho...@morganstanley.com] 
Gesendet: Montag, 30. August 2010 21:18
An: Marco Rebsamen
Cc: postfix-users@postfix.org
Betreff: Re: local_recipient_maps with LDAP

On Mon, Aug 30, 2010 at 08:50:33PM +0200, Marco Rebsamen wrote:

> 
> Ok, I'm really confused about that LDAP lookup stuff :-/
> What I want to do is to check if an address to which a message is addressed 
> really exists.
> 
> I'm currently using this script for local receipient checks:
> 
> bind_dn = j...@hive.loc
> bind_pw = 
> server_host = 192.168.8.254
> 
> #Global Catalog port
> server_port = 3268
> 
> search_base = DC=hive, DC=loc
> query_filter = proxyAddresses=smtp:*...@unimatrix0.ch
> result_attribute = proxyAddresses

What is that pesky "*" doing in your query filter!!!

It's a damn wildcard! I thought I would need it because when I tried to find 
the right parameters for this LDAP request I could not find find anything until 
I used this star!

Why is "proxyAddresses" the right result attribute. I would use "mail".

I don't know ?! Is it not ?! from where should I know that ?! Why do I need an 
email address as return anyway ?! I would say the address is already written in 
the message ? It makes no sense to me to return an email address maybe I 
just don't understand the whole thing and someone should tell me what I should 
do?!

Report problems accurately with supporting "postconf -n" output,
table definitions AND logs!

...same as above

-- 
Viktor.

Re: Log the applied TLS policy

[Victor Duchovni]

On Mon, Aug 30, 2010 at 09:42:29PM +0200, martin f krafft wrote:

> also sprach Victor Duchovni  
> [2010.08.30.1604 +0200]:
> > > Due to some issues we've been having[0], I would like to have a more
> > > permanent means of confirmation that everything is in order.
> > > Specifically, I would like to see in the logs when a security policy
> > > was matched and applied. No matter how high I set
> > 
> > The security policy is indirectly logged when certificate matching
> > (fingerprint, verify or secure) is required, since the destination
> > will be logged as "Verified".
> > 
> > 2010-08-30T09:58:09-04:00 amnesiac postfix/smtp[8804]:
> > Verified TLS connection established to
> > cluster12.us.messagelabs.com[85.158.136.227]:25:
> > TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
> 
> This requires smtp_tls_loglevel >= 1, but thanks for the tip!
> 
> This showed something curious:
> 
> My tls_policy maps recipient domains one.com and two.com, both handled by MX
> a.mx.madduck.net, to "secure match=.mx.madduck.net".
> 
> Now I just sent something to three.com, which is also handled by
> a.mx.madduck.net, but it is not listed in the tls_policy maps. Yet,
> the connection was Trusted:

Exactly as promised. Trusted != Verified. Trusted just means that
the peer certificate signature is valid, but no actual validation
of the peername took place.

-- 
Viktor.

Re: local_recipient_maps with LDAP

[Victor Duchovni]

On Mon, Aug 30, 2010 at 09:46:26PM +0200, Marco Rebsamen wrote:

> > > search_base = DC=hive, DC=loc
> > > query_filter = proxyAddresses=smtp:*...@unimatrix0.ch
> > > result_attribute = proxyAddresses
> > 
> > What is that pesky "*" doing in your query filter!!!
> 
> It's a damn wildcard! I thought I would need it because when I tried
> to find the right parameters for this LDAP request I could not find find
> anything until I used this star!

Get rid of it. With the "smtp:" prefix properly set to match the actual
data in Microsoft's AD, you no longer need the "*" and using it lowers
performance and creates backscatter when you accept invalid names that
are prefixes of valid names.

> > Why is "proxyAddresses" the right result attribute. I would use "mail".
> 
> I don't know ?! Is it not ?! from where should I know that ?!

By understanding what you are doing... :-(

> Why do I need an email address as return anyway ?!

You need some non-empty attribute as a result, ideally a single-valued
one that keeps the result-set small. Using "mail" makes sense.

-- 
Viktor.

Re: Log the applied TLS policy

[martin f krafft]

also sprach Victor Duchovni  
[2010.08.30.2148 +0200]:
> Exactly as promised. Trusted != Verified. Trusted just means that
> the peer certificate signature is valid, but no actual validation
> of the peername took place.

Oh, I am sorry for this oversight on my side.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
who's general failure, and why's he reading my disk?
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: How to drop the recipient address hostname when delivering mail via LMTP?

[mouss]

 Le 30/08/2010 11:19, Ralph Seichter a écrit :

On 29.08.10 21:40, Noel Jones wrote:


Sorry, I forgot to specify the map type in my example. It must be
either regexp: or pcre:.

No need for you to apologize. I feel quite silly, because you obviously
specifed a regular expression in your example, and I read it as such. I
don't know what made me specify a map type of 'hash'.

Alas, this does not work. The line

   /^...@server\.domain\.tld$/ joe

strips the domainpart just fine, but Postfix attempts a LMTP delivery to
j...@domain.tld. I assume this happens because of "myorigin = $mydomain".


don't try to generate non fqdn addresses. smtp and lmtp require a 
domain. any smtp/lmtp software that thinks otherwise is borked and must 
be fixed. if it has such simple bugs, it may have a lot more dangerous 
bugs.



As Victor pointed out, LMTP addresses need to be fully qualified, and
Postfix seems to refuse to be told otherwise -- which is correct. Maybe
something can be done on Dovecot's side.

are you saying dovecot lmtp implementation has such a bug?

Re: How to drop the recipient address hostname when delivering mail via LMTP?

[Ralph Seichter]

On 30.08.10 22:11, mouss wrote:

> are you saying dovecot lmtp implementation has such a bug?

I think that Dovecot is a great piece of software and would not presume
to imply that it has a faulty LMTP implementation. More likely, I made
some mistake in configuring Dovecot. Currently, all my efforts of using
a Dovecot LMTP socket for Postfix's local deliveries fail, unless I add

  auth_username_format = %Ln

to my Dovecot config. As far as I understand it, this parameter removes
the domain part from all user lookups. I have not yet found a way to
provide userdb data (using LDAP or /etc/passwd as sources) with fully
qualified LMTP recipient addresses. Where would one specify such data in
/etc/passwd anyway, unless by (mis)using the GECOS field?

So, I don't say Dovecot has a bug, but I can't seem to find a way to
accomodate the needs of both Postfix and Dovecot, where the former
relies on fully qualified addresses which the latter rejects, at least
in my setup. This is quite vexing.

-Ralph

Regexp for blocking dynamic hosts?

[Patrick Lists]

Hi,

I got a lot of spam lately from dynamic hosts so gradually I have been 
adding rules to block them with the help of the rules from

http://gabacho.reto.jp/en/anti-spam/anti-spam-system.html

Unfortunately this type keeps slipping through:
Received: from 200-161-108-143.dsl.telesp.net.br

My regex foo is pretty non-existant. Does anyone know what regexp line 
would block such a hostname?


Thanks for any pointers.

Regards,
Patrick

Identifying instance owner for different Postfix processes

[Justin Pasher]

Hello,

I have a box running multiple instances of Postfix on multiple IP 
addresses (this is a pre-2.6 installation, so the multiple instances are 
handled the old way by defining multiple postfix config directories). I 
currently have "syslog_name" set for each instance so I can correlate 
the log entries with each instance. However, when individual Postfix 
processes are started (smtp, smtpd, pickup, etc), they are not 
identified in any way in ps (that I can find) in regards to which 
instance they belong to.


So far, the only work-around I've figured out is to add an additional 
parameter to the corresponding process in master.conf (something like this:)


smtp  inet  n   -   n   -   -   smtpd
   -o syslog_name=postfix-myname

This allows me to identify the process in ps by seeing the parameters 
with which it was launched. However, I have to do this for each process 
in master.conf, which clutters things up a bit (it also creates multiple 
places to change the name if I need to). Is there a cleaner way to do 
this than overriding each processes with a redundant parameter like this?


Thanks.

--
Justin Pasher

Re: check header from, reply-to, message-id domains against spamhaus dbl?

[Stan Hoeppner]

Wietse Venema put forth on 8/30/2010 1:29 PM:
> Victor Duchovni:
>> On Mon, Aug 30, 2010 at 01:06:28PM -0500, Stan Hoeppner wrote:
>>
>>> Is there a straightforward (i.e. relatively painless) way to check the
>>> header from, reply-to, and message-id domains against dbl.spamhaus.org
>>> and reject on a positive reply as with reject_r*bl_client?
>>
>> Not from Postfix. There is currently no support in cleanup(8)
>> for extracting domains from headers and applying RBL checks. The
>> Postfix SMTP server does not look at the message content.
> 
> Some courageous person could implement this as:
> 
> header_checks = tcp:127.0.0.1:port
> 
> and write a Perl script that rips domain names from headers and
> runs them through dbl lookups.
> 
> I don't have time, but with Net::DNS this should involve no more
> than a dozen lines of code (using the spawn(8) daemon for connection
> management). As a stand-alone program, maybe two dozen lines.

I'm really new to these particular Postfix features.  What would the
responses need to be?

"REJECT reason" if it hits in the dnsbl?
"DUNNO" if it doesn't hit?

Will we be sending one header line at a time to the perl daemon (at
least I assume you suggest to run it as a daemon) or does this dump the
entire header out all at once?  I.e. does the perl daemon send one
response per header line or one response after processing the entire header?

I don't have the skills to write this myself or I'd be on it in a
heartbeat, but I'm going to see if there are any takers on spam-l.
There are a few perl "heavy hitters" there.  I just want to post clear
and "complete" requirements up front.  Is there anything else I'm
missing?  Is having some Postfix experience a necessary prerequisite for
writing this?  The few folks I'm thinking of are more qpsmtp and
sendmail types. :(

Sorry for any nubish questions.  I'm out of my element here.

Thanks Wietse.

-- 
Stan

Re: Regexp for blocking dynamic hosts?

[Stan Hoeppner]

Patrick Lists put forth on 8/30/2010 4:34 PM:
> Hi,
> 
> I got a lot of spam lately from dynamic hosts so gradually I have been
> adding rules to block them with the help of the rules from
> http://gabacho.reto.jp/en/anti-spam/anti-spam-system.html
> 
> Unfortunately this type keeps slipping through:
> Received: from 200-161-108-143.dsl.telesp.net.br
> 
> My regex foo is pretty non-existant. Does anyone know what regexp line
> would block such a hostname?

/^[12]?[0-9]{1,2}(-[12]?[0-9]{1,2}){3}\.(customer|dsl|dial-up)\.telesp\.net\.br$/
REJECT  Generic - Please relay via ISP (telesp.net.br)

That's all one line, TB wrapped it.  You may as well just use this.
Over 1600 regex patterns matching generic dynamics and statics.  Rejects
all generic dynamics, tags generic statics.  Provided with no
warranties, use at your own risk, etc.  Has worked well here.

http://www.hardwarefreak.com/fqrdns.regexp

Use in main.cf as:

check_client_access regexp:/etc/postfix/fqrdns.regexp

-- 
Stan

Re: Regexp for blocking dynamic hosts?

[Patrick Lists]

On 08/31/2010 12:40 AM, Stan Hoeppner wrote:
[snip]


/^[12]?[0-9]{1,2}(-[12]?[0-9]{1,2}){3}\.(customer|dsl|dial-up)\.telesp\.net\.br$/
REJECT  Generic - Please relay via ISP (telesp.net.br)

That's all one line, TB wrapped it.  You may as well just use this.
Over 1600 regex patterns matching generic dynamics and statics.  Rejects
all generic dynamics, tags generic statics.  Provided with no
warranties, use at your own risk, etc.  Has worked well here.

http://www.hardwarefreak.com/fqrdns.regexp

Use in main.cf as:

 check_client_access regexp:/etc/postfix/fqrdns.regexp


Thanks Stan. Much appreciated.

Regards,
Patrick

Re: check header from, reply-to, message-id domains against spamhaus dbl?

[Wietse Venema]

Stan Hoeppner:
> Wietse Venema put forth on 8/30/2010 1:29 PM:
> > Victor Duchovni:
> >> On Mon, Aug 30, 2010 at 01:06:28PM -0500, Stan Hoeppner wrote:
> >>
> >>> Is there a straightforward (i.e. relatively painless) way to check the
> >>> header from, reply-to, and message-id domains against dbl.spamhaus.org
> >>> and reject on a positive reply as with reject_r*bl_client?
> >>
> >> Not from Postfix. There is currently no support in cleanup(8)
> >> for extracting domains from headers and applying RBL checks. The
> >> Postfix SMTP server does not look at the message content.
> > 
> > Some courageous person could implement this as:
> > 
> > header_checks = tcp:127.0.0.1:port
> > 
> > and write a Perl script that rips domain names from headers and
> > runs them through dbl lookups.
> > 
> > I don't have time, but with Net::DNS this should involve no more
> > than a dozen lines of code (using the spawn(8) daemon for connection
> > management). As a stand-alone program, maybe two dozen lines.
> 
> I'm really new to these particular Postfix features.  What would the
> responses need to be?

The responses must be as documented in the header_checks(5) manpage.

In addition, tcp_table(5) documents an on-the-wire protocol to
signal whether a lookup completed with found/notfound/error. This
is a completely separate matter of what is sent as the content of
header_checks lookups and results.

> Will we be sending one header line at a time to the perl daemon (at
> least I assume you suggest to run it as a daemon) or does this dump the
> entire header out all at once?  I.e. does the perl daemon send one
> response per header line or one response after processing the entire header?

Header lines are inspected one at a time as documented in the
header_checks(5) manpage.

> I don't have the skills to write this myself or I'd be on it in a
> heartbeat, but I'm going to see if there are any takers on spam-l.
> There are a few perl "heavy hitters" there.  I just want to post clear
> and "complete" requirements up front.  Is there anything else I'm
> missing?  Is having some Postfix experience a necessary prerequisite for
> writing this?  The few folks I'm thinking of are more qpsmtp and
> sendmail types. :(
> 
> Sorry for any nubish questions.  I'm out of my element here.

The manpages in question are:

header_checks(5) for the table-driven mechanism
tcp_table(5) for the table lookup mechanism.

Wietse

Re: Regexp for blocking dynamic hosts?

[JunkYardMail1]

.*

--
From: "Patrick Lists" 
Sent: Monday, August 30, 2010 2:34 PM
To: 
Subject: Regexp for blocking dynamic hosts?


Hi,

I got a lot of spam lately from dynamic hosts so gradually I have been 
adding rules to block them with the help of the rules from

http://gabacho.reto.jp/en/anti-spam/anti-spam-system.html

Unfortunately this type keeps slipping through:
Received: from 200-161-108-143.dsl.telesp.net.br

My regex foo is pretty non-existant. Does anyone know what regexp line 
would block such a hostname?


Thanks for any pointers.

Regards,
Patrick 

Re: local_recipient_maps with LDAP

[Jamrock]

"Marco Rebsamen"  wrote in message 
news:f70fd6682c026e40970a322e98e764545...@tranceiver.hive.loc...
  Hello Everybody

   

  I wan't to have my local recipeints checked against my Active Directory. So I 
have created the .cf file with the LDAP parameters:

   

  bind_dn = u...@domain.local

  bind_pw = **

  server_host = 192.168.8.254

   

  #Global Catalog port

  server_port = 3268

   

  search_base = DC=domain, DC=local

  query_filter = proxyAddresses=*%s*

   

  and changed the main.cf file: 

  local_recipient_maps = ldap:/etc/postfix/local_recipient_maps.cf 
unix:passwd.byname

   

  If i do this now:

  postmap -v -q 'u...@domain.ch' ldap:/etc/postfix/local_recipient_maps.cf

   

  It tells me "Search found 1 match(es)". But If i try to deliver a message 
with the same address postfix tells me "User not known in local recipient maps"

  How can i figure out whats wrong ?

   

  Thanks





  The following has worked for me.  Don't know if it is the best way or not.



  Step 1



  Create a user in Active Directory for Postfix to use.  

  First name = postfix

  Lastname =

  User Logon Name = postfix

  User cannot change password

  Password never expires





  Step 2



  Add the following to the /etc/postfix/main.cf:




  # Prevents mail from being sent to local user accounts

  local_transport = virtual




  # Information about mailboxes

  virtual_mailbox_base = /var/postfix/maildirs/

  virtual_mailbox_maps = ldap:/etc/postfix/ldap_mailboxes.cf 

  virtual_minimum_uid = 501

  virtual_uid_maps = static:501

  virtual_gid_maps = static:502




  # Files storing user and group information

  virtual_maps = ldap:/etc/postfix/ldap_users.cf, 
ldap:/etc/postfix/ldap_groups.cf



  Step 3

  Create /etc/postfix/ldap_mailboxes.cf 

  server_host = ldap://mail.testcompany.com:389

  version = 3

  search_base = cn=users,dc=testcompany,dc=com

  query_filter = (&(mail=%s) (objectClass=user))

  result_attribute = samaccountname

  result_format = %s/

  bind_dn = postfix

  bind_pw = DFD321



  Step 4

  Create /etc/postfix/ldap_users.cf

   server_host = ldap://mail.testcompany.com:389

  version = 3

  search_base = cn=users,dc=testcompay,dc=com

  query_filter = (&(mail=%s) (objectClass=user))

  result_attribute = samaccountname

  bind_dn = postfix

  bind_pw = DFD321



  Step 5

  Create /etc/postfix/ldap_groups.cf

   server_host = ldap://mail.testcompany.com:389

  version = 3

  search_base = ou=mail_groups,dc=testcompay,dc=com

  query_filter = (&(mail=%s) (objectClass = group))

  special_result_attribute = member

  leaf_result_attribute = mail

  bind_dn = postfix

  bind_pw = DFD321



  Once you get this working, you will need to think about ssl encryption 
between the Linux box and the Windows box.

Re: Regexp for blocking dynamic hosts?

[Stan Hoeppner]

Patrick Lists put forth on 8/30/2010 6:00 PM:
> On 08/31/2010 12:40 AM, Stan Hoeppner wrote:
> [snip]
>>
>> /^[12]?[0-9]{1,2}(-[12]?[0-9]{1,2}){3}\.(customer|dsl|dial-up)\.telesp\.net\.br$/
>>
>> REJECTGeneric - Please relay via ISP (telesp.net.br)
>>
>> That's all one line, TB wrapped it.  You may as well just use this.
>> Over 1600 regex patterns matching generic dynamics and statics.  Rejects
>> all generic dynamics, tags generic statics.  Provided with no
>> warranties, use at your own risk, etc.  Has worked well here.
>>
>> http://www.hardwarefreak.com/fqrdns.regexp
>>
>> Use in main.cf as:
>>
>>  check_client_access regexp:/etc/postfix/fqrdns.regexp
> 
> Thanks Stan. Much appreciated.

You're welcome.  That was given to me by a gracious SA in response to an
inquiry I made on spam-l some time ago.  I'm just paying it forward, so
to speak.  I was grateful for it, as I'm guessing quite a bit of time
went into building it, a little bit at a time, over a long period.

-- 
Stan

Re: Identifying instance owner for different Postfix processes

[Noel Jones]

On 8/30/2010 4:54 PM, Justin Pasher wrote:

Hello,

I have a box running multiple instances of Postfix on multiple
IP addresses (this is a pre-2.6 installation, so the multiple
instances are handled the old way by defining multiple postfix
config directories). I currently have "syslog_name" set for
each instance so I can correlate the log entries with each
instance. However, when individual Postfix processes are
started (smtp, smtpd, pickup, etc), they are not identified in
any way in ps (that I can find) in regards to which instance
they belong to.

So far, the only work-around I've figured out is to add an
additional parameter to the corresponding process in
master.conf (something like this:)

smtp inet n - n - - smtpd
-o syslog_name=postfix-myname

This allows me to identify the process in ps by seeing the
parameters with which it was launched. However, I have to do
this for each process in master.conf, which clutters things up
a bit (it also creates multiple places to change the name if I
need to). Is there a cleaner way to do this than overriding
each processes with a redundant parameter like this?

Thanks.




The only bone I have to throw will reduce the number of places 
to change it.


# main.cf
my_syslog_name = instanceX
syslog_name = $my_syslog_name

# master.cf
foo    foo
  -o syslog_name=$my_syslog_name

canonical_maps pattern causes NDR to be sent as requeued message

[D G Teed]

First, I submit my postconf -n, made anonymous, but should still be
accurate.

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
alternate_config_directories = /etc/postfix-alt
anvil_rate_time_unit = 60s
anvil_status_update_time = 600s
biff = no
bounce_queue_lifetime = 4d
bounce_size_limit = 2000
bounce_template_file = /etc/postfix/bounce.cf
canonical_maps = pcre:/etc/postfix/lowercase,hash:/etc/postfix/genericstable
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = lmtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
disable_vrfy_command = yes
fast_flush_domains = serv1.example.com, serv2.example.com, serv3.example.com,
serv4.example.com, serv5.example.com, s
erv6.example.com
html_directory = no
in_flow_delay = 5s
inet_interfaces = localhost,myself.example.com
initial_destination_concurrency = 200
invalid_hostname_reject_code = 556
lmtp_sasl_auth_enable = no
lmtp_sasl_security_options =
local_recipient_maps = hash:/etc/postfix/recipient
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
masquerade_domains = !alt.example.com example.com
maximal_backoff_time = 21600s
message_size_limit = 1000
minimal_backoff_time = 10800s
mydestination = example.com
myhostname = myself.example.com
mynetworks = 111.111.0.0/16, 127.0.0.0/8
mynetworks_style = class
newaliases_path = /usr/bin/newaliases.postfix
qmgr_message_active_limit = 2
queue_directory = /var/spool/postfix
queue_run_delay = 500s
rbl_reply_maps = hash:/etc/postfix/rbl_reply
readme_directory = no
recipient_delimiter = +
relay_domains = example.com
relay_recipient_maps = hash:/etc/postfix/recipient
relocated_maps =
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_client_connection_count_limit = 20
smtpd_client_connection_rate_limit = 60
smtpd_client_event_limit_exceptions = $mynetworks
smtpd_client_message_rate_limit = 60
smtpd_client_restrictions = reject_unlisted_recipient, check_client_access
cidr:/etc/postfix/client.cidr, check_sender_access
hash:/etc/postfix/whitelist, check_recipient_access
hash:/etc/postfix/recipient_access, check_client_access
hash:/etc/postfix/access, reject_invalid_hostname,
reject_unknown_reverse_client_hostname
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_error_sleep_time = 10s
smtpd_helo_required = yes
smtpd_helo_restrictions = check_helo_access hash:/etc/postfix/helo_access,
reject_invalid_hostname
smtpd_recipient_restrictions = reject_unknown_recipient_domain,
reject_unauth_destination, check_policy_service inet:127.0.0.1:2501,
reject_unknown_sender_domain, reject_non_fqdn_recipient,
reject_non_fqdn_sender, reject_invalid_hostname, check_recipient_access
hash:/etc/postfix/serv3_overquota, check_recipient_access
hash:/etc/postfix/recipient_access, check_sender_access
hash:/etc/postfix/whitelist, check_client_access hash:/etc/postfix/access,
reject_rbl_client PRIVATEKEYREMOVED.r.mail-abuse.com, reject_rbl_client
zen.spamhaus.org, permit
smtpd_sasl_auth_enable = no
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/blacklist,
check_sender_access hash:/etc/postfix/whitelist, check_client_access
hash:/etc/postfix/access, reject_unknown_sender_domain,
reject_non_fqdn_sender
smtpd_timeout = 60s
transport_maps = hash:/etc/postfix/transport
unknown_address_reject_code = 550
unknown_client_reject_code = 555
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/relocated
hash:/etc/postfix/class_lists hash:/etc/postfix/virtual

My server will properly not queue email for most addresses sent to bogus
addresses.

Aug 30 22:30:20 myself postfix/smtpd[25013]: NOQUEUE: reject: RCPT from
mta03.anisp.ca[24.111.111.111]: 550 5.1.1 <12345...@example.com>: Recipient
address rejected: User unknown in local recipient table

However, if the email address is of the format of 6 numbers followed by a
letter, then the message is
queued and bounced.

Aug 30 22:30:03 myself postfix/local[25084]: 9E79419CF2D: to=<
1234...@example.com>, relay=local, delay=0.26, delays=0.13/0.07/0/0.05,
dsn=5.1.1, status=bounced (unknown user: "123456t")

The pattern of six digits and one letter is significant to how common email
addresses are set up at our institution.

The canonical_maps entry pointing to lowercase is related to this.
lowercase contains:

/^([0-9]{6}[a...@example.com)$/ $1

It seems the message was queued somehow as a result of this.  Is there a
suggested workaround
to avoid unknown users from being queued?

I'm not sure why this was set up by a predecessor.  It doesn't seem to do
anything in my read of it,
although it might be taking advantage of a canonical maps feature related to
lowercase.

--Donald

Recipient_delimiter

[Constance Mallon]

I have a question regarding recipient delimiters.  I need to set the recipient 
delimiter for my mailing lists (mailman) with "-" but I also need to set the 
recipient_delimiter to "+" for my calendar server.

How can I set the recipient_delimiter to include both values?

Thank you for your assistance

:)

Re: Migrating from sendmail, a few questions...

[Jean-Yves Avenard]

Hi

On 31 August 2010 03:04, Wietse Venema  wrote:
>
> If this does not announce the SASL mechanisms that you expect, then
> the missing mechanisms are not installed with the Cyrus SASL library.

I do appreciate that you took the time to answer my questions..
Especially as I understand it you're the author of postfix and I'm
sure you have a very busy schedule.

But it seems to me that you haven't read what I asked for.

>
> Each Cyrus SASL is provided as a shared object file. On many systems
> these files are called /usr/libsasl/digestmd5.so.1, /usr/libsasl/plain.so.1
> and so on.
>
> I don't know if Patrik's saslfinger tool works on MacOS, but it
> would list out these files for you (along with "postconf -n" output
> and other information that helps to quickly solve many problems
> with Cyrus SASL deployment).

The issue isn't about not having the SASL mechanisms I want. The issue
is being able to distinguish which mechanisms are allowed during a
TLS/SSL session vs a clear text one.

The documentation states that it can be controlled with
smtpd_sasl_security_options and smtpd_sasl_tls_security_options and
provide different mechanism according to the communication medium
used.

Yet it doesn't. It always announce the same mechanism, SSL being used or not.

JY

Re: Migrating from sendmail, a few questions...

[Jean-Yves Avenard]

Hi

On 31 August 2010 03:42, Victor Duchovni
 wrote:
>
> Probably not surprising when the Cyrus library is pre-empted by Apple's
> "pw" server, and the mechanism list is defined in an Apple-specific
> configuration parameter.

I just compiled sendmail for mac os 10.6.

And it's behaving perfectly with Apple's cyrus library, when you use
sendmail's confAUTH option.

clear session to smtp gives me:

250-AUTH DIGEST-MD5 CRAM-MD5
250-STARTTLS

Over TLS:
250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5

So whatever sendmail is doing to check if it's a secure login method
is working, the one in postfix doesn't seem to

JY