Re: smtp port issue

[btb]

On Jun 12, 2017, at 06.42, n...@collinson.fr wrote:
> 
> I want to use port 25025 for outgoing messages. I modified 
> /etc/postfix/master.cf as follows but postfix will not reload.
> 
> smtp  inet  n   -   n   -   -   smtpd
> 25025 init  n   -   n   -   -   smtpd
> 
> Strangely it works with port 2525. In both cases I opened the ports in 
> iptables.

any particular reason you're not using submission, and its customary port, 587, 
for outgoing messages?

Re: Ok to put private network in mynetworks?

[btb]

> On May 17, 2017, at 12.55, Viktor Dukhovni  wrote:
> 
> 
>> On May 17, 2017, at 12:27 PM, b...@bitrate.net wrote:
>> 
>>> I run a docker container on my server. To not have all docker containers 
>>> need to authenticate when sending mail, I added
>>> the private network range 172.16/12 to mynetworks:
>> 
>> I would discourage authorization based on source ip address.  automated 
>> credential configuration is a fairly basic task, and there are a plethora of 
>> benefits to using user/pass [or even a certificate, if desired] over source 
>> ip address.
> 
> And yet, allowing a block of private addresses that are directly managed by 
> the
> same administrators that manage the MTA is quite reasonable.
> 
> If all the nodes in question would in any case be given relay permission (via
> passwords, client certificates, ...) and the risk of IP spoofing is low (BGP
> route forgery is unlikely to be relevant here) then by all means whitelist
> the netblock.

perhaps, although as i stated, there is more to it than that.  for example, 
more fine grained control of authorization, and the potential reduction in 
ambiguity as to what, specifically, is submitting mail.

Re: Ok to put private network in mynetworks?

[btb]

On May 17, 2017, at 10.44, Florian Lindner  wrote:
> 
> Hello,
> 
> I run a docker container on my server. To not have all docker containers need 
> to authenticate when sending mail, I added
> the private network range 172.16/12 to mynetworks:

i would discourage authorization based on source ip address.  automated 
credential configuration is a fairly basic task, and there are a plethora of 
benefits to using user/pass [or even a certificate, if desired] over source ip 
address.

> # Added private network 172.16/12 for Docker
> 
> 
> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 172.16.0.0/12
> 
> 
> * Is this safe?

that's a rather relative/subjective measure - but pursuant to my particular 
philosophies, no.

> * Is there another / better way to achieve what I want?

there are some cases in which i "must" allow authorization based on source ip 
address.  some time ago, i stopped using mynetworks/permit_mynetworks for this. 
 i now use check_client_access 
cidr:${table_directory}/non_auth_submitters.cidr, and i set mynetworks to empty 
[e.g. "mynetworks ="].

always_bcc only after reinjection from amavis

[btb]

hi-

i have a server which relays mail to our content filter server
[amavis/spamassassin/etc], via:

content_filter=lmtp-filter:[mfa.${mydomain}]:lmtp-filter-internal

and returns, via:

# reinjection from content filter
smtp-reinject-internal
inet  n   -   -   -   -   smtpd
-o syslog_name=postfix/smtp-reinject-internal
-o smtpd_banner=${smtpd_reinjection_banner}
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=smtpd_reinjection_restrictions
-o smtpd_relay_restrictions=
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters
-o local_header_rewrite_clients=

i'd like to use always_bcc, to copy all messages to an archival system,
but only after the messages return from the content filter server.

how can i do this?

thanks!

add header with postscreen score

[btb]

is there a way to add a postscreen score/summary header to accepted messages?  
the logs are great, but this could be helpful in reviewing messages and making 
improvements to the configuration.

Re: Dovecot,seive and postfix master.cf

[btb]

On Feb 22, 2017, at 16.21, Ian Evans  wrote:
> 
> Background: Have a postfix/dovecot/amavisd-new system that has been running 
> smoothly for several years. Just a handful of virtual users, ie:
> /home/vmail/example.com/ianevans/Maildir
> 
> As we are starting to use multiple devices finally, decided to move away from 
> pop3/imap to all imap.
> 
> sieve plugin has been configured. All that's left is to have postfix use 
> dovecot lda. Just wanted to make sure that this is all I need to do on the 
> postfix end in master.cf:
> 
> dovecot   unix  –   n   n   –   –   pipe
> flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -d 
> ${recipient}
> 
> Any other config info I should post here to make sure that the dovecot line 
> will not step on any config toes.

i would relay to dovecot via lmtp(8), rather than via pipe(8).  additionally, 
personally, i prefer to use the relay address class for arrangements like this, 
rather than the virtual address class.  lastly, you reference amavis, so i'll 
mention that, in basic setups [which most are] i'd also suggest relaying from 
postfix to amavis, via lmtp, and then from amavis to dovecot, also via lmtp, 
rather than going back through postfix first, which is often how it's been 
done, traditionally.

imo, this simplifies the configuration, and simplifies the flow, conceptually.  
some might point out a caveat regarding constraints on alias expansion or the 
like when not passing mail back to postfix, which is true, but imo, doing alias 
expansion in front of the content filter is the desirable of the two anyway, 
outside of the exception here or there, like anything else.

Re: Relay passwords map and hashing

[btb]

On Dec 12, 2016, at 13.03, Stavros Tsolakos  wrote:
> 
> Dear list
> 
> My apologies if my question has been answered before.
> 
> I want to relay outgoing messages depending on the sender. So far I have
> created 2 tables containing the SMTP relay addresses and the passwords
> respectively.
> 
> From my main.cf:
> 
> sender_dependent_relayhost_maps = hash:/etc/postfix/relayhosts
> smtp_sasl_password_maps = hash:/etc/postfix/relaypasswd
> 
> I am concerned about having the passwords stored in plaintext in
> relaypasswd. Of course, it is converted to a non human readable form by
> postmap, although it might still somehow be converted back to plain. (It
> should, or else how postfix 'knows' what password to login with to the
> relay?)
> 
> Apart from making the file readable by root (0400 permissions), is there
> a way to store the password's hash and *somehow* login to the relay
> using it? (I am emphasizing the word 'somehow' because I can't imagine
> how it can be done, if it can be done at all).

hashing is for verifying of passwords, not for using [supplying] of passwords.  
if the password were hashed, postfix wouldn't have the password [it would only 
have the hash], and thus it could not use the password.  the plaintext [not 
hashed, not encrypted, etc] string must be available to postfix, so it can use 
it.

alternatively, if you can construct a method in which you supply something 
other than the plaintext password to the relay, then perhaps postfix can 
accommodate this.

Re: Port 587 users question

[btb]

On 2016.11.28 13.47, li...@lazygranch.com wrote:
> On Mon, 28 Nov 2016 09:01:41 -0500 btb <b...@bitrate.net> wrote:
> 
>> On 2016.11.27 20.43, li...@lazygranch.com wrote:
>>> I should have mentioned the mail system is on a VPS and I'm the
>>> only user. And yes, trouble makers are on the Internet.
>> 
>> well, this simplifies things quite of bit, of course.
>> 
>>> What lead me to this was I did bzgrep "max auth" and noticed
>>> both smtp and submission was found.
>> 
>> i hope you're not offering smtp auth on port 25.
> 
> Well I think I am based on this anvil entry. What option of postconf 
> would show this?

unless the server in question is strictly an msa,
permit_sasl_authenticated should never be found in the global
config/restrictions.  it should only be found in the restrictions for
the submission service [i.e. master.cf].  smtpd_sasl_auth_enable = yes
goes along with this, and should also only be set for the submission
service.

if you're not already, to help with this distinction, setting a
different syslog name [e.g. -o syslog_name=postfix/submission] for the
submission service can be beneficial.

Re: Port 587 users question

[btb]

On 2016.11.27 20.43, li...@lazygranch.com wrote:
> I should have mentioned the mail system is on a VPS and I'm the only
> user. And yes, trouble makers are on the Internet.

well, this simplifies things quite of bit, of course.

> What lead me to this was I did bzgrep "max auth" and noticed both
> smtp and submission was found.

i hope you're not offering smtp auth on port 25.

(max auth as in checking anvil rate
> limiting). Since I'm the only person that should (we hope) have valid
> usernames and passwords, blocking the port from the internet trouble
> makers make sense  ‎if there is no legitimate reason for others to
> use the port.
> 
> My blocking list of trouble makers is self generated, so I won't be
> on it.
> 
> I do think servers hammering 587 is odd, but I noticed I get about
> two a day. And these are just when rate limiting come in. I suppose
> they could be misconfigured servers.

more likely, it's just compromised devices in general, which may or may
not include servers.

Re: Consulting multiple ldap tables with envelope sender address authorization

[btb]

On 2016.11.28 06.53, mailing lists wrote:
> Hello all,
> 
> I am configurating envelope sender address authorization using ldap 
> tables with Active Directory which has two possible attributes to 
> authenticate users, the legacy and short name "samaccountname" and
> the long name "userprincipalname", so that I am trying is permit 
> authenticate with both identities and authorize as sender address
> the long name.
> 
> The ldap tables work as expected by separate, they resolve the
> envelope address to the sasl identity, but making them work
> simultaneously is failing because the result from the first table
> seems an absolute answer and postfix ignores the second one.
> 
> Does anyone know if there is any way to make the second check if the 
> first check fails to find anything?

the first check didn't fail to find anything.  see below.

> # grep smtpd_sender_login_maps main.cf smtpd_sender_login_maps =
> ldap:/etc/postfix/check_login_sender_mail.cf, 
> ldap:/etc/postfix/check_login_sender_sam.cf

do this instead:  postconf smtpd_sender_login_maps [intentions may
sometimes differ from reality ;) ]

from the postfix docs: "Tables will be searched in the specified order
until a match is found".  in this case, a match is found [(mail=%s)], so
searching stops, and the configured attribute is returned.

from ldap_table(5): "result_attribute (default: maildrop). The
attribute(s)  Postfix  will read from any directory entries. returned by
the lookup[...]

instead, combine the two maps:

result_attribute = samaccountname, userprincipalname

Re: Port 587 users question

[btb]

On Nov 27, 2016, at 16.15, li...@lazygranch.com wrote:
> 
> I hate to bug the list for what is probably a dumb question, but is there any 
> situation where an unauthorized user needs to connect to port 587? I'm 
> wondering if there is some oddball  "edge" case.

well, i suppose it would depend upon what your definition of "unauthorized" 
actually is, but making some assumptions, the short answer is likely no.  since 
you refer below to blocking troublemakers, presumably we're talking about the 
internet, rather than an internal or such network where there might be the 
occasional device which cannot perform smtp auth, encryption, etc., and for 
which an exception might be necessary [for those edge cases, i use 
check_client_access and a cidr map].

> My thought is to use my ipfw table of known trouble makers to block 587.

honestly, i'm not sure i'd bother.  it may be fine, but it's also one more 
thing to include risk for a false positive.

Re: use of dash [and other] characters in parameter names

[btb]

On 2016.11.15 11.44, Wietse Venema wrote:
> btb:
>> since parameters can be user defined, i think it would be good if
>> the documentation stated this, maybe in postconf(5)?  it would
>> alleviate guessing games.
>> 
>> possibly something like:
>> 
>> Postfix main.cf file format [...] ? A logical line starts with
>> non-whitespace text. A line that starts with whitespace continues a
>> logical line.
>> 
>> ? Parameter names are limited to the character set [a-zA-z0-9_].
> 
> This is inaccurate. The above parameter name syntax limitation exists
> only with $name or ${name}, i.e. when a parameter value is used
> in another parameter setting. A name can contain any non-space 
> character with 'name = value' or with master.cf service names.

i see, thanks for clarifying this

> Would spelling out such intricate rules make Postfix easier to use?

i can't speak for everyone, of course, but it might, if it could be done
concisely.  when postfix tells me there was a syntax error, i've become
accustomed to finding valid syntax defined in the documentation.

would this be acceptable?:

The expressions "$name" and "${name}" are recursively replaced with the
value of the named parameter, except where noted. An undefined parameter
value is replaced with the empty value.  Named parameters are limited to
the character set [a-zA-Z0-9_].

-ben

Re: possible typo in postconf(5) documentation

[btb]

On 2016.11.15 11.32, Wietse Venema wrote:
> btb:
>> in the postconf(5) documentation, the format section says:
>> 
>> The expressions "${name:value}" and "${name?{value}}" are replaced
>> with "value" when "$name" is empty. These forms are supported with
>> Postfix versions ? 2.2 and ? 3.0, respectively.
>> 
>> should the ? in "${name?{value}}" be a :?
> 
> Yes. This was corrected in Postfix 3.1.

it looks like it may have been missed in html/postconf.5.html and
proto/postconf.html.prolog, at least as of postfix-3.2-20161106.

-ben

possible typo in postconf(5) documentation

[btb]

in the postconf(5) documentation, the format section says:

The expressions "${name:value}" and "${name?{value}}" are replaced with
"value" when "$name" is empty. These forms are supported with Postfix
versions ≥ 2.2 and ≥ 3.0, respectively.

should the ? in "${name?{value}}" be a :?

-ben

Re: envelope/header rewriting for a single client

[btb]

On Nov 10, 2016, at 17.17, Noel Jones <njo...@megan.vbhcs.org> wrote:
> 
> On 11/10/2016 4:05 PM, btb wrote:
>> hi-
>> 
>> i have an "appliance" which submits mail.  it's inflexible,
>> unfortunately, and uses crappy values for the envelope sender and the
>> from: header.  i have communicated with the vendor in an attempt to
>> rectify this, but as might be expected, the outcome has been less than
>> successful.
>> 
>> hopefully some day, this changes, but in the interim, i'd like to
>> rewrite the envelope sender and the from: header [ala
>> sender_canonical_maps] for all mail from this client.
>> 
>> how should i do this?  is the best method to set up an additional
>> cleanup(8) instance with its own sender_canonical_maps for just this
>> client?  somehow connect the client to its own smtp(8) service to use
>> smtp_generic_maps?  are there other/better methods?
>> 
>> thanks
>> -ben
>> 
> 
> depending on "how" the addresses are broken, you can probably just
> use canonical_maps to always rewrite the offending address to
> something valid.  There shouldn't be any need for additional cleanup
> service unless you're fighting some common misspelling.
> 
> Send specifics of what you're trying to rewrite for further help.

in particular, this client impersonates our users, which we don't want.  it is 
aware of users and their email addresses [it's part of a voicemail system which 
sends voicemail messages as email attachments, and "helpfully" claims the email 
message was sent by the caller].  for us, this is undesirable.

when a user submits a message with a sender of u...@example.com, we of course 
don't want to change that.  however, when this client does it, we do.  the 
localpart is dynamic.  for example, i would like to rewrite a sender of 
/^.*@example.com$/, but only when the message came from this client.  many 
other messages with a sender which matches /^.*@example.com$/ are submitted 
from many other clients, but those don't need to be changed.

envelope/header rewriting for a single client

[btb]

hi-

i have an "appliance" which submits mail.  it's inflexible,
unfortunately, and uses crappy values for the envelope sender and the
from: header.  i have communicated with the vendor in an attempt to
rectify this, but as might be expected, the outcome has been less than
successful.

hopefully some day, this changes, but in the interim, i'd like to
rewrite the envelope sender and the from: header [ala
sender_canonical_maps] for all mail from this client.

how should i do this?  is the best method to set up an additional
cleanup(8) instance with its own sender_canonical_maps for just this
client?  somehow connect the client to its own smtp(8) service to use
smtp_generic_maps?  are there other/better methods?

thanks
-ben

Re: test address expansion with LDAP mapping

[btb]

On Nov 03, 2016, at 14.12, Stephen Ingram  wrote:
> 
> I found a way to test the expansion of normal .db maps:
> 
> postmap -q testuser 'postconf -h virtual_alias_maps'
> 
> however, it doesn't seem to work with LDAP maps. Is there a way to test those 
> as well?

it's worked as documented for me, as long as i can remember.

consult the following reference material included with the software:

postmap(1)
ldap_table(5)
LDAP_README

wherein syntax and multiple literal examples are provided.

beyond that, share actual input and output of the command[s] you are running, 
as well as the contents of your lookup map file.  obfuscate any credentials.

-ben

Re: TLS AUTH forcing - thinkering

[btb]

On 2016.09.28 12.35, KSB wrote:

On 2016.09.28. 18:03, KSB wrote:

Hi!
I would like to use smtpd_tls_auth_only=yes at least for submission
port, but we have rare customers who have old scannners which don't
support SSL/TLS(as they say).


for this, i use the following:

table_directory = ${config_directory}/tables
smtpd_tls_security_level = may

smtpd_recipient_restrictions =
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_unauth_pipelining
check_client_access cidr:${table_directory}/non_auth_submitters.cidr
reject_plaintext_session
permit_sasl_authenticated
reject

this offers encryption, allows non encrypted/non authenticated 
exceptions to clients listed in non_auth_submitters.cidr, but rejects 
attempts by any other clients to not use encryption or authentication.


-ben

Re: Inserting a unique ID into the email header with Postfix alone

[btb]

On Mar 18, 2016, at 07.20, Istvan Prosinger  wrote:
> 
> Hello Everyone!
> 
> I need to insert something like
> 
> X-MY-ID-some-unique-ID
> 
> into each email's header for local tracking purposes.
> 
> The unique ID doesn't have to be some complicated hash, it can be something 
> like the + or  ... which would be mostly unique.
> 
> Any ideas if such a thing could be done with just prepending in header 
> checks, without external filtering?

others have already answered the question, but as an aside, it's my 
understanding that rfc 6648 discourages/deprecates use of the "X-" prefix in, 
among a number of things, email headers.

-ben

smime.p7s
Description: S/MIME cryptographic signature

Re: Adding a noreply address

[btb]

On 2016.01.26 10.54, Matt Bayliss wrote:

I'm trying to find the correct/best practice method for setting up a
black hole email address for such items as "noreply" addresses when
sending alerts from monitoring devices etc.


if you intend no mail to be sent to this address anyway, and will just 
throw away any mail that arrives, then why bother accepting mail for the 
address at all?  pick an address you like, configure your various 
devices to use it when sending mail, and don't worry about postfix.  if 
someone tries to send mail to that address, postfix will reject it.


-ben

Re: Adding a noreply address

[btb]

> On Jan 26, 2016, at 15.52, Steve Jenkins <st...@stevejenkins.com> wrote:
> 
> On Tue, Jan 26, 2016 at 12:07 PM, btb <b...@bitrate.net> wrote:
> On 2016.01.26 10.54, Matt Bayliss wrote:
> I'm trying to find the correct/best practice method for setting up a
> black hole email address for such items as "noreply" addresses when
> sending alerts from monitoring devices etc.
> 
> if you intend no mail to be sent to this address anyway, and will just throw 
> away any mail that arrives, then why bother accepting mail for the address at 
> all?  pick an address you like, configure your various devices to use it when 
> sending mail, and don't worry about postfix.  if someone tries to send mail 
> to that address, postfix will reject it.
> 
> Yep. It all boils down to what you want to occur if someone replies to the 
> "noreply" address.
> 
> 1) Want the reply to disappear and not bounce back to the sender? Point the 
> noreply alias to /dev/null (that's different than setting up a "noreply" user 
> -- an alias is not a user account).
> 
> 2) Want the reply to bounce back to the sender? Make sure you don't have a 
> noreply alias or catchall, and Postfix will send the appropriate "no such 
> recipient" error to the sender.
> 
> 3) Want to send a custom "Sorry, we don't check this email account so please 
> don't expect a reply" message to the sender? Set up an auto-reply (and send 
> the incoming message at /dev/null), but do so prudently so as to avoid any 
> backscatter concerns (seriously... backscatter and auto-reply wars are no 
> bueno).
> 
> Option has the most potential pitfalls, so I'm a fan of Options 1 and 2. Both 
> are completely acceptable as "best practices" for "black hole" email 
> addresses for alerts from monitoring devices.

fwiw, i would never consider accepting mail and then discarding it "best 
practices" [which is a term i'm not fond of anyway] - especially if you knew 
full well that was your intent before the message even arrived.  very much 
agreed on the backscatter/autoresponder caution though.

-ben

Re: postscreen: DNSBL rank not seen in logs for some ip addresses

[btb]

On 2015.12.16 11.35, Wietse Venema wrote:


The client was not listed at some DNSBL


this explains it, thanks.  i don't know why, but i was expecting 
postscreen to tell me that the client was not listed.  i now see in the 
docs that it's only logged if postscreen_dnsbl_threshold is met.


-ben

postscreen: DNSBL rank not seen in logs for some ip addresses

[btb]

hi-

i've become accustomed to seeing log passages like this:

>grep -iF '[142.4.19.85]:52366' mail.log
Dec 16 09:41:09 mta1 postfix/postscreen[27678]: CONNECT from 
[142.4.19.85]:52366 to [10.3.70.6]:25
Dec 16 09:41:15 mta1 postfix/postscreen[27678]: DNSBL rank 5 for 
[142.4.19.85]:52366
Dec 16 09:41:15 mta1 postfix/tlsproxy[29186]: CONNECT from 
[142.4.19.85]:52366
Dec 16 09:41:15 mta1 postfix/tlsproxy[29186]: Anonymous TLS connection 
established from [142.4.19.85]:52366: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Dec 16 09:41:15 mta1 postfix/postscreen[27678]: NOQUEUE: reject: RCPT 
from [142.4.19.85]:52366: 550 5.7.1 Service unavailable; client 
[142.4.19.85] blocked using zen.spamhaus.org; 
from=, 
to=, proto=ESMTP, 
helo=
Dec 16 09:41:15 mta1 postfix/postscreen[27678]: HANGUP after 0.54 from 
[142.4.19.85]:52366 in tests after SMTP handshake
Dec 16 09:41:15 mta1 postfix/postscreen[27678]: DISCONNECT 
[142.4.19.85]:52366

Dec 16 09:41:15 mta1 postfix/tlsproxy[29186]: DISCONNECT [142.4.19.85]:52366

but sometimes, the DNSBL rank seems to be absent:

>grep -iF '[104.47.32.71]:33498' mail.log.1
Dec 10 14:20:36 mta1 postfix/postscreen[32607]: CONNECT from 
[104.47.32.71]:33498 to [10.3.70.6]:25
Dec 10 14:20:42 mta1 postfix/tlsproxy[2980]: CONNECT from 
[104.47.32.71]:33498
Dec 10 14:20:42 mta1 postfix/tlsproxy[2980]: Anonymous TLS connection 
established from [104.47.32.71]:33498: TLSv1.2 with cipher 
ECDHE-RSA-AES256-SHA384 (256/256 bits)
Dec 10 14:20:42 mta1 postfix/postscreen[32607]: NOQUEUE: reject: RCPT 
from [104.47.32.71]:33498: 450 4.3.2 Service currently unavailable; 
from=, to=, proto=ESMTP, 
helo=
Dec 10 14:20:42 mta1 postfix/postscreen[32607]: HANGUP after 0.64 from 
[104.47.32.71]:33498 in tests after SMTP handshake
Dec 10 14:20:42 mta1 postfix/postscreen[32607]: PASS NEW 
[104.47.32.71]:33498

Dec 10 14:20:42 mta1 postfix/tlsproxy[2980]: DISCONNECT [104.47.32.71]:33498
Dec 10 14:20:42 mta1 postfix/postscreen[32607]: DISCONNECT 
[104.47.32.71]:33498


is this expected?  if not, how can i determine why it's happening?

thanks
-ben

Re: order of actions in postfix

[btb]

> On Nov 16, 2015, at 02.53, Vicki Brown  wrote:
> 
> [...] discards email to non-existent recipient addresses [...]

on a side note, don't accept mail and then discard it.  instead, reject it.

-ben

TLS_README and computing fingerprint values

[btb]

hi-

in TLS_README it's instructed to use the following command to compute an sha-1 
public key fingerprint:

openssl x509 -in foo.example.com-cert.pem -noout -pubkey | openssl pkey -pubin 
-outform DER | openssl dgst -sha1 -c
(stdin)= 7e:8b:82:2e:c8:9a:bc:f9:ae:1a:de:e6:9a:6c:b3:3b:b3:34:21:7a

that didn't work for me, but:

openssl x509 -noout -in foo.example.com-cert.pem -fingerprint
SHA1 Fingerprint=A2:76:67:9B:B1:B8:4A:2F:DF:10:12:94:67:62:BE:47:6F:08:0F:12

did work.

as seen, they both output valid digests, but the values differ.  i wondered if 
i might be doing something wrong when using the first command [and how i could 
troubleshoot].  i'm using postfix 2.11.3 and openssl 1.0.1f on ubuntu 15.04.  i 
also experience this with postfix 2.11.0 and openssl 1.0.1f on ubuntu 14.04

-ben

Re: TLS_README and computing fingerprint values

[btb]

 On Jun 14, 2015, at 18.21, Viktor Dukhovni postfix-us...@dukhovni.org wrote:
 
 On Sun, Jun 14, 2015 at 02:28:31PM -0400, b...@bitrate.net wrote:
 
 In TLS_README it's instructed to use the following command to compute an
 sha-1 public key fingerprint:
 
 $ openssl x509 -in foo.example.com-cert.pem -noout -pubkey |
  openssl pkey -pubin -outform DER |
  openssl dgst -sha1 -c
  (stdin)= 7e:8b:82:2e:c8:9a:bc:f9:ae:1a:de:e6:9a:6c:b3:3b:b3:34:21:7a
 
 that didn't work for me,
 
 Rather unfortunate that you don't explain how or why.  Most likely you're
 using a version of OpenSSL that is older than 1.0.0, and does not have the
 pkey command.  For RSA keys you can replace openssl pkey with openssl 
 rsa.
 
 This computes a public key fingerprint.
 
 $ openssl x509 -noout -in foo.example.com-cert.pem -fingerprint
 SHA1 Fingerprint=A2:76:67:9B:B1:B8:4A:2F:DF:10:12:94:67:62:BE:47:6F:08:0F:12
 
 did work.
 
 This computes the certificate fingerprint, not the public key
 fingerprint.
 
 as seen, they both output valid digests, but the values differ.
 
 As expected.

that explains my ignorance.  certificate fingerprint versus public key 
fingerprint.  i'm using check_ccert_access, and testing again, it does in fact 
work, as documented, with either certificate or public key fingerprint.  what i 
was doing to convince myself it wasn't working initially, i'm now not sure of.

on a related note, is it possible for a public key fingerprint to collide with 
the certificate fingerprint of some other cert?

-ben

Re: session id for postscreen

[btb]

 On Mar 05, 2015, at 12.51, Wietse Venema wie...@porcupine.org wrote:
 
 btb:
 when reviewing postscreen entries in logs, it's difficult to quickly 
 grep for entries relevant to a particular session, since the only unique 
 value in the entry is the pid, which is quite long lived and spans many 
 sessions.  i wondered how practical it might be to include a unique id 
 along with the log message, to assist in exercises like this.
 
 Instead of a session ID, you could use the remote IP address and
 TCP port.  In the example below, that is [198.251.79.135]:60343.
 
 Untested PCRE pattern: (for|from)\s(\[[0-9a-f:.]+\]:\d+).
 Use $2 to extract the interesting bits.
 
   Wietse
 
 Mar  5 00:06:22 spike postfix/postscreen[95625]: CONNECT from 
 [198.251.79.135]:60343 to [168.100.189.2]:25
 Mar  5 00:06:22 spike postfix/postscreen[95625]: PREGREET 14 after 0.05 from 
 [198.251.79.135]:60343: EHLO ylmf-pc\r\n
 Mar  5 00:06:22 spike postfix/postscreen[95625]: DNSBL rank 2 for 
 [198.251.79.135]:60343
 Mar  5 00:06:22 spike postfix/postscreen[95625]: HANGUP after 0.11 from 
 [198.251.79.135]:60343 in tests after SMTP handshake
 Mar  5 00:06:22 spike postfix/postscreen[95625]: DISCONNECT 
 [198.251.79.135]:60343

ah, of course.  thanks wietse and noel for this idea, it should be more than 
adequate.  i understand the importance of efficiency in postscreen, and wanting 
to avoid adding things that will slow it down.

-ben

session id for postscreen

[btb]

when reviewing postscreen entries in logs, it's difficult to quickly 
grep for entries relevant to a particular session, since the only unique 
value in the entry is the pid, which is quite long lived and spans many 
sessions.  i wondered how practical it might be to include a unique id 
along with the log message, to assist in exercises like this.


-ben

Re: Next Dumb question - mynetworks

[btb]

 On Feb 14, 2015, at 16.14, John j...@klam.ca wrote:
 
 Does mynetworks have to contain anything other than 127.0.0.1/8 and ::1/128.

for whatever it's worth, my personal preference is to, as a rule, always set 
mynetworks to empty.  i make an effort to not allow relaying based on source ip 
address, and in the occasional scenario in which it cannot be avoided 
[typically antiquated client software or sometimes appliances which cannot do 
encryption/smtp auth], i use check_client_access with a cidr map.  the end 
result is the same, but i find it more explicitly conveys what is going on.

-ben

Re: Postfix configuration postconf

[btb]

 On Feb 08, 2015, at 05.55, John j...@klam.ca wrote:
 
 Is there a way of checking for unnecessary entries in the Postfix main or 
 master config files.
 I was looking through the mailing list and noticed the point that Victor made 
 about smtpd_tls_session_cache_database being mostly unnecessary. 
 This made me wonder if I have entries in the config files that are 
 duplicating defaults. The obvious method would be to check each entry against 
 the manual, however, probably over thinking this, I wondered if the manual 
 and my distribution (Debian Jessie) my be different.

i use this to reveal duplicates in main.cf:

(postconf -d; postconf -n) | sort | uniq -d

-ben

Re: numerical score result for postscreen_access_list?

[btb]

On 2015.01.22 10.35, wie...@porcupine.org (Wietse Venema) wrote:

btb:

we have a small local blacklist, mostly used for clients which
aren't listed in dnsbls.

postscreen_access_list = 
cidr:$table_directory/postscreen_access_list-rejects.cidr

sometimes when a larger netblock gets listed, it can have the
unintended consequences of blocking well behaved clients which
happen to be within that netblock:

Jan 20 09:37:10 mta2 postfix/postscreen[18045]: CONNECT from 
[64.26.60.147]:58250 to [10.3.70.6]:25


In the CIDR table, specify netblocks as follows:

192.168.1.1 dunno
192.168.1.0/24  reject

I.e. specify the good clients before the bad ones. Instead of dunno
specify permit if you are certain that the host is not a bot.


right.  we do that now.  taking advantage of whitelist negative scoring 
to reduce some of the administrative burden would be nice though, and 
also avoid the fix it after finding out it's broken scenario.

numerical score result for postscreen_access_list?

[btb]

we have a small local blacklist, mostly used for clients which aren't listed in 
dnsbls.

postscreen_access_list = 
cidr:$table_directory/postscreen_access_list-rejects.cidr

sometimes when a larger netblock gets listed, it can have the unintended 
consequences of blocking well behaved clients which happen to be within that 
netblock:

Jan 20 09:37:10 mta2 postfix/postscreen[18045]: CONNECT from 
[64.26.60.147]:58250 to [10.3.70.6]:25
Jan 20 09:37:10 mta2 postfix/postscreen[18045]: BLACKLISTED [64.26.60.147]:58250
Jan 20 09:37:10 mta2 postfix/dnsblog[18133]: addr 64.26.60.147 listed by domain 
list.dnswl.org as 127.0.5.0
Jan 20 09:37:16 mta2 postfix/postscreen[18045]: NOQUEUE: reject: RCPT from 
[64.26.60.147]:58250: 550 5.3.2 Service currently unavailable; 
from=u...@example.org, to=u...@example.com, proto=ESMTP, 
helo=smtpauth05.mfg.siteprotect.com
Jan 20 09:37:16 mta2 postfix/postscreen[18045]: DISCONNECT [64.26.60.147]:58250

in the above case, if the netblock could be listed in postscreen_access_list as

64.26.0.0/183

rather than

64.26.0.0/18reject

then a client in that scenario could avoid penalization, with

postscreen_dnsbl_threshold = 3
postscreen_dnsbl_whitelist_threshold = -1
postscreen_dnsbl_sites = [...] list.dnswl.org=127.[0..255].[0..255].[0..255]*-4

is a feature like this something that might be considered?  overall, it seems 
like a scoring element in postscreen_access_list would complement the essence 
of postcreen in general.

-ben

Re: numerical score result for postscreen_access_list?

[btb]

On 2015.01.22 12.18, wie...@porcupine.org (Wietse Venema) wrote:

Wietse:

In the CIDR table, specify netblocks as follows:

192.168.1.1 dunno
192.168.1.0/24  reject

I.e. specify the good clients before the bad ones. Instead of
dunno specify permit if you are certain that the host is not
a bot.


btb:

right.  we do that now.  taking advantage of whitelist negative
scoring to reduce some of the administrative burden would be nice
though, and also avoid the fix it after finding out it's broken
scenario.


Instead of postscreen_access_list, you could use rbldnsd (or
equivalent) to mix local blacklists with remote whitelists.

I am not ready to give postscreen_access_list control over other
tests (if postscreen_access_list must be able to control dnsbl,
then it must also be able to control pregreet and so on). Nor am I
ready to make every postscreen feature a DNSBL-like score.


thanks, this makes sense.  we'll use a local dnsbl.  additionally, this 
will fit in well with my earlier question about cidr:/ lookup using a 
network map.


-ben

Re: postscreen stopped working today for a few hours

[btb]

On 2015.01.15 22.21, Viktor Dukhovni wrote:

On Thu, Jan 15, 2015 at 09:57:53PM -0500, b...@bitrate.net wrote:


i happened to notice that on one of our two mxes, no postscreen activity was 
logged between 06:25:09 and 11:54:42:

Jan 15 06:25:09 mta2 postfix/postscreen[22371]: DISCONNECT 
[103.242.116.92]:37543
Jan 15 11:54:42 mta2 postfix/postscreen[25663]: CONNECT from 
[209.85.213.183]:41380 to [10.3.70.6]:25


Note the change of pid!  You probably ran postfix reload right
around then.


no postfix reload, there, no.  those two log entries are 5+ hours apart. 
 it was just to illustrate the time period.



but other postfix activity was *logging* normally, and mail was flowing 
normally:

all of this makes it seems like postscreen wasn't working during that period, 
and i'm wondering why that might be.


Actually it was working, just wasn't logging!


i thought so too.  it seemed the most obvious answer, but i began to 
change my mind when i saw mail getting accepted which should have been 
rejected by postscreen_access_list.  it also doesn't explain why postfix 
was logging other process activity successfully during that time.



I avoid sending SIGHUP to the log daemon, and use syslog-ng with
date based output files which are expired by scripts other than
logrotate, that way I don't lose any log messages.


thanks for this suggestion, we may do that.


postconf -Mf

smtp   inet  n   -   -   -   1   postscreen


Yep, it's chrooted.  You need to configure syslog to add a log
socket to the jail, or turn off chroot.


during this period, postfix activity from all other postfix processes is 
getting logged successfully, most of which are chrooted, and postscreen 
is logging fine outside of this one period. i think chroot is not the 
culprit here.


-ben

Re: postscreen stopped working today for a few hours

[btb]

On 2015.01.16 09.43, wie...@porcupine.org (Wietse Venema) wrote:

btb:

postconf -Mf

smtp   inet  n   -   -   -   1   postscreen


Yep, it's chrooted.  You need to configure syslog to add a log
socket to the jail, or turn off chroot.


during this period, postfix activity from all other postfix processes is
getting logged successfully, most of which are chrooted, and postscreen
is logging fine outside of this one period. i think chroot is not the


You are missing an important detail.

On a busy server postscreen will run forever. It will never reconnect
to the new syslog server.

On a busy or idle server, smtpd runs only for a few minutes. The
next smtpd process will automatically to the new syslog server.

I am 99.99% certain that chroot is the problem here.


thanks, i'll concede this analysis.  i don't have enough forensic 
evidence to confirm but i now believe that the symptom of mail appearing 
to get through which shouldn't have was the red herring [sorry viktor!] 
- that the client in question was added to postscreen_access_list just 
after this, and it was just a coincidence of timing.


i guess i consider lost logs to be a bug - i'll submit a bug report to 
ubuntu for this.  in your opinion, would this be something the postfix 
package maintainer should address, or the syslog-ng packager maintainer 
[or is it just the admin's fault]?


-ben

Re: cidr:/ lookup using network map [e.g. mysql]

[btb]

On 2014.12.15 23.51, Peter wrote:

On 12/16/2014 07:22 AM, btb wrote:

with various sized netblocks rejected therein.  this all works fine.
i have more than one mx, and would like to store this data in a
centralized location and query over the network instead of
duplicating the files on each mx.  i don't believe postfix can
currently do this, aside from a traditional access(5) lookup which is
limited to octet boundaries.  am i wrong?  if not, could this be
considered as a possible feature?  could this potentially be done
with pipemap?


Postfix can't do it, but if you google for mysql cidr you will come
across various ways to do CIDR matches in mysql, just pick one that
works for you and off you go.


thanks, i'll look into this


Also if you haven't locked in your decision to use mysql yet you may
want to consider postgresql instead which has native CIDR and other
network data types and functions you can work with.


i'm not at all committed to mysql.  it just served as a practical example.

thanks
-ben

cidr:/ lookup using network map [e.g. mysql]

[btb]

hi-

i currently have:

postscreen_access_list = cidr:$table_directory/postscreen_access_list.cidr

with various sized netblocks rejected therein.  this all works fine.  i have 
more than one mx, and would like to store this data in a centralized location 
and query over the network instead of duplicating the files on each mx.  i 
don't believe postfix can currently do this, aside from a traditional access(5) 
lookup which is limited to octet boundaries.  am i wrong?  if not, could this 
be considered as a possible feature?  could this potentially be done with 
pipemap?

thanks-
-ben

Re: cidr:/ lookup using network map [e.g. mysql]

[btb]

On Dec 15, 2014, at 17.47, Wietse Venema wrote:

 btb:
 hi-
 
 i currently have:
 
 postscreen_access_list = cidr:$table_directory/postscreen_access_list.cidr
 
 with various sized netblocks rejected therein.  this all works
 fine.  i have more than one mx, and would like to store this data
 in a centralized location and query over the network instead of
 duplicating the files on each mx.  i don't believe postfix can
 currently do this, aside from a traditional access(5) lookup which
 is limited to octet boundaries.  am i wrong?  if not, could this
 be considered as a possible feature?  could this potentially be
 done with pipemap?
 
 cidr is a sequential map that tries each pattern in a fixed order
 until a match is found. How is try each pattern in order supposed
 to work when patterns are stored in a hash, btree, lmdb, ldap,
 *sql*, or memcache table?

well, since i was thinking in terms of network lookups, my focus was sql/ldap.  
i'm not sure if/how this could work with the others you mention, aside from 
just reading the contents as a list, but i guess that wouldn't serve much 
purpose, since the plain text file already does that for local storage.

for sql though, i envisioned a query that would return the same data that would 
be read from the text file, a list of patterns and a matching result for each, 
for postfix to iterate through.  i know this would be a different type of query 
than is currently used for sql maps.

i'll have to think more about this.

-ben

Re: Configuring MSA in postfix

[btb]

 On Nov 14, 2014, at 14.47, Wietse Venema wie...@porcupine.org wrote:
 
 Alamgir Shamim:
 Hello,
 
 Can you please tell me how to configure MSA with postfix. I want to
 create all local user in MSA. local user's mail will be delivered in
 MSA and out going mail will be forwarded to another mail gateway. That
 mail gateway will have two instances. On instance will accept only
 mail from MSA and will forward all outgoing mail. Another instance
 will receive all incoming mail destined to our corporate domain. Can
 you please guide me how to do this.
 
 MSA = mail submission agent, i.e. the program that injects an email
 message into the email infrastructure. In today's world that is
 usually an end-user machine (or mobile device) that runs a mail
 client program.

i'd always understood an msa to be a mail server listening on e.g. port 587, 
accepting connections from end user software [mua]:

https://en.wikipedia.org/wiki/Mail_submission_agent

ben

delaying mail before passing to next hop

[btb]

hi-

short version:
i have an mx which, after doing the initial handling [postscreen, etc] of 
messages arriving from the internet, relays mail to another computer for 
content filtering [amavis/spamassassin]:

relay_transport = lmtp-filter:[mfa.example.com]:lmtp-filter-external

after a message has been accepted, i'd like to delay its relay to the content 
filter for five minutes.  can postfix do this?

longer version:
i've noticed a recent trend in which a message arrives, passes 
postscreen/various smtpd_*_restrictions, and is passed to the content filter, 
which passes it as clean, having not matched many rules [in particular, network 
tests like uri dnsbls, razor/pyzor, etc].

minutes later, the same message arrives [timestamps, message ids, etc differ], 
in that time has made its way into the results of various network tests, and is 
then marked is spam.

e.g. my consideration for this approach.  i'd also be interested in general 
thoughts on this problem, and other possibilities.  i'm not particularly fond 
of artificial delays, and the various implications [e.g. queue sizes, user 
expectations, etc], but in the context of a controlled environment [e.g. after 
postfix has accepted the message, i'm willing to at least entertain the 
possibility.

thanks-ben

Re: delaying mail before passing to next hop

[btb]

On Nov 13, 2014, at 15.02, Noel Jones njo...@megan.vbhcs.org wrote:
 
 On 11/13/2014 11:14 AM, b...@bitrate.net wrote:
 hi-
 
 short version:
 i have an mx which, after doing the initial handling [postscreen, etc] of 
 messages arriving from the internet, relays mail to another computer for 
 content filtering [amavis/spamassassin]:
 
 relay_transport = lmtp-filter:[mfa.example.com]:lmtp-filter-external
 
 after a message has been accepted, i'd like to delay its relay to the 
 content filter for five minutes.  can postfix do this?
 
 longer version:
 i've noticed a recent trend in which a message arrives, passes 
 postscreen/various smtpd_*_restrictions, and is passed to the content 
 filter, which passes it as clean, having not matched many rules [in 
 particular, network tests like uri dnsbls, razor/pyzor, etc].
 
 minutes later, the same message arrives [timestamps, message ids, etc 
 differ], in that time has made its way into the results of various network 
 tests, and is then marked is spam.
 
 e.g. my consideration for this approach.  i'd also be interested in general 
 thoughts on this problem, and other possibilities.  i'm not particularly 
 fond of artificial delays, and the various implications [e.g. queue sizes, 
 user expectations, etc], but in the context of a controlled environment 
 [e.g. after postfix has accepted the message, i'm willing to at least 
 entertain the possibility.
 
 thanks-ben
 
 
 This is exactly why greylisting was invented.  Have you tried that?

i don't know about exactly, but yes, i did briefly consider that greylisting 
would have a somewhat similar effect.  it would introduce a delay, but at the 
cost of all of the other side effects of greylisting, which would likely cause 
more problems than it would solve, imho.  that's why i wanted to do it after 
the message was accepted, where the onus can be fully on me regarding its fate.

-ben

Re: delaying mail before passing to next hop

[btb]

 On Nov 13, 2014, at 13.00, Robert Schetterer r...@sys4.de wrote:
 
 Am 13.11.2014 um 18:14 schrieb b...@bitrate.net:
 hi-
 
 short version:
 i have an mx which, after doing the initial handling [postscreen, etc] of 
 messages arriving from the internet, relays mail to another computer for 
 content filtering [amavis/spamassassin]:
 
 relay_transport = lmtp-filter:[mfa.example.com]:lmtp-filter-external
 
 after a message has been accepted, i'd like to delay its relay to the 
 content filter for five minutes.  can postfix do this?
 
 longer version:
 i've noticed a recent trend in which a message arrives, passes 
 postscreen/various smtpd_*_restrictions, and is passed to the content 
 filter, which passes it as clean, having not matched many rules [in 
 particular, network tests like uri dnsbls, razor/pyzor, etc].
 
 minutes later, the same message arrives [timestamps, message ids, etc 
 differ], in that time has made its way into the results of various network 
 tests, and is then marked is spam.
 
 e.g. my consideration for this approach.  i'd also be interested in general 
 thoughts on this problem, and other possibilities.  i'm not particularly 
 fond of artificial delays, and the various implications [e.g. queue sizes, 
 user expectations, etc], but in the context of a controlled environment 
 [e.g. after postfix has accepted the message, i'm willing to at least 
 entertain the possibility.
 
 thanks-ben
 
 
 interesting, didnt notice such yet
 
 you might hold mail, and release it by cron etc

thanks - cron came to mind initially for me too.  i wondered though if postfix 
might offer a mechanism of its own.

Re: Add --version option to postfix

[btb]

On Sep 27, 2014, at 07.48, Wietse Venema wie...@porcupine.org wrote:

 Use postconf -d, not postconf -n. -n is for settings in the
 configuration file, -d is for the built-in settings which include
 the version, release date, and so on.

this reminds me - some time long ago, i happened to notice that 
config_directory seems to be the lone exception to the postconf -n behavior 
described in postconf(1).  it’s not of much consequence, at least for me, but i 
was just curious why [presuming it’s intentional].

-ben

Re: Add --version option to postfix

[btb]

On Sep 27, 2014, at 10.42, Viktor Dukhovni postfix-us...@dukhovni.org wrote:

 On Sat, Sep 27, 2014 at 10:24:13AM -0400, b...@bitrate.net wrote:
 
 On Sep 27, 2014, at 07.48, Wietse Venema wie...@porcupine.org wrote:
 
 Use postconf -d, not postconf -n. -n is for settings in the
 configuration file, -d is for the built-in settings which include
 the version, release date, and so on.
 
 This reminds me - some time long ago, I happened to notice that
 config_directory seems to be the lone exception to the postconf -n
 behavior described in postconf(1).  It's not of much consequence,
 at least for me, but I was just curious why [assuming it's
 intentional].
 
 To support the MAIL_CONFIG environment variable and the -c
 command-line option, the value of config_directory is added to
 the key-value hash of data extracted from main.cf.  This is done
 even when neither are specified.

i see.  may i ask how being included in postconf -n specifically ties into 
support for the MAIL_CONFIG environment variable and the -c” command-line 
option? i’m not being skeptical - i genuinely don’t understand, and would like 
to.

-ben

Re: Add --version option to postfix

[btb]

On Sep 27, 2014, at 10.32, Wietse Venema wie...@porcupine.org wrote:

 b...@bitrate.net:
 On Sep 27, 2014, at 07.48, Wietse Venema wie...@porcupine.org wrote:
 
 Use postconf -d, not postconf -n. -n is for settings in the
 configuration file, -d is for the built-in settings which include
 the version, release date, and so on.
 
 this reminds me - some time long ago, i happened to notice that
 config_directory seems to be the lone exception to the postconf
 -n behavior described in postconf(1).  it's not of much consequence,
 at least for me, but i was just curious why [presuming it's
 intentional].
 
 I suppose your idea is to put the main.cf file in a different
 location, then specify that location in the main.cf file, and not
 create a chicken-and-egg problem.

no, that’s not my idea at all!  :)  i like main.cf right where it is, in 
/etc/postfix/.  i like chickens and eggs too, but only to eat - not in 
programming or system administration.  i was only curious why config_directory 
was included in the output of postconf -n, while postconf(1) seemed to indicate 
it shouldn’t be.  it truly was nothing more than an idle curiosity.  sorry if 
my wording was ambiguous and conveyed the wrong idea.

-ben

Re: Add --version option to postfix

[btb]

On Sep 27, 2014, at 11.20, Viktor Dukhovni postfix-us...@dukhovni.org wrote:

 On Sat, Sep 27, 2014 at 10:42:27AM -0400, Wietse Venema wrote:
 
 [root@mail-gw:~]$ postconf -n | grep config_directory
 config_directory = /etc/postfix
 
 You're welcome to fix that. I'm now working on other things, 
 supporting per-milter and per-policy service settings.
 
 There's a subtlety here.  Lots of settings in main.cf use
 ${config_directory}, so that needs to be set early to the -c
 option value, $MAIL_CONFIG in the environment or finally the
 compiled-in default value.  Because of catch-22 none of these
 come from main.cf itself.  So that value is pushed into the parameter
 dictionary early, before main.cf is read.  Otherwise it would have
 to be added to the configuration dictionary in one of two places:
 
* Before reading main.cf, but only if explicitly passed in via
  the environment or the -c option.
 
* After loading main.cf, but only if not already set.
 
 There would still be anomalies, for example when looking at postconf
 -n via postmulti(1), the MAIL_CONFIG environment variable will be
 set by postmulti(1) to indicate the desired instance even when that
 instance is the default instance.  And for non-default instances
 it is still useful to see config_directory reported, though it
 is most likely is not (and should not be) set in main.cf itself.
 
postmulti -i instance -x postconf -n

you read my mind.  thanks for this detail.

-ben

Re: Input requested: append_dot_mydomain default change

[btb]

On Sep 22, 2014, at 11.41, Wietse Venema wie...@porcupine.org wrote:

 This time PLEASE refrain from sidetracking the discussion. I want
 to know what will break when the default changes, if that is not
 too much to ask for.
 
 Summary:
 
 Until now, Postfix has a default setting append_dot_mydomain = yes.
 This performs autocompletion from user@host to user@host.$mydomain.
 But this default setting is becoming problematic.
 
 I need to find out what will break when the default is changed to no.
 
 How many people expect that this change would be a problem? It *may*
 affect mail that is submitted with the sendmail command line, or
 aliases that expand to user@host instead of user@host.domain.  Email
 addresses in SMTP *should* already be fully qualified.  But I also
 know that the real world often does not behave as it *should*.
 Hence this query to the postfix-users list.

given a poll, my vote would be to change the default to “no”.  this would not 
be a problem for me, because i set this to “no anyway, as a general rule, on 
all my systems.  sendmail submission and alias expansion will not break for me, 
as addresses used/referenced in these contexts are fully qualified.  mail 
submitted via smtp will not break for me because 
reject_non_fqdn_sender/reject_non_fqdn_recipient are always included in 
smtpd_*_restrictions, also as a general rule.

i do this because i prefer that the onus for constructing properly formed 
messages be placed on the client rather than on postfix, and to some degree, 
out of principle, driven by aspirations for “purity”, so to speak.  while i 
have had to make concessions on occasion for uncooperative software, changing 
append_dot_mydomain back to “yes” has never been among them.  the practical 
value of this for me is that it aids in identifying/correcting clients/software 
which aren’t behaving as desired.

that being said, it’s not something i’m particularly adamant about.  the value 
for me is that it’s something i can set.

-ben

add header for canonical recipients

[btb]

hi-

i'm not quite certain the subject is an accurate synopsis.  apologies if it's 
misleading.  we have a proprietary system which delivers voicemail messages as 
email attachments.  it submits mail via submission to postfix, which looks like 
this:

Sep 18 16:03:33 msa postfix/submission/smtpd[21286]: 3hzTdK1j5ZzyQn: 
client=phonesrv.example.com[10.25.40.1], sasl_method=LOGIN, 
sasl_username=phonesrv
Sep 18 16:03:33 msa postfix/cleanup[21289]: 3hzTdK1j5ZzyQn: 
message-id=001d7...@phonesrv.example.com
Sep 18 16:03:33 msa postfix/qmgr[11026]: 3hzTdK1j5ZzyQn: 
from=VOICE/+1nnn5551...@phonesrv.example.com, size=385664, nrcpt=1 (queue 
active)
Sep 18 16:03:33 msa postfix/internal/smtp[21290]: 3hzTdK1j5ZzyQn: 
to=us...@example.com, relay=mta.example.com[10.3.70.5]:25, delay=0.11, 
delays=0.04/0.02/0.01/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 
3hzTdK2DdyzJmy2)
Sep 18 16:03:33 msa postfix/qmgr[11026]: 3hzTdK1j5ZzyQn: removed

occasionally, misconfiguration of the system [e.g. a typo, etc.] results in 
attempted delivery to an invalid address, which postfix of course rejects.  the 
client then generates a bounce to VOICE/+1nnn5551...@phonesrv.example.com, 
which comes back to postfix, since the client relays all mail through postfix.  
to ensure this is seen by the right people, i've done this:

main.cf:
recipient_canonical_maps = hash:${table_directory}/canonical_recipients
virtual_alias_maps =
proxy:ldap:${table_directory}/virtual_alias_maps-address_literals.cf
proxy:ldap:${table_directory}/virtual_alias_maps-domains.cf

canonical_recipients:
@phonesrv.example.com   
pbx_monitor...@systems.example.com

pbx_monitor...@systems.example.com is a virtual alias:

postmap -q 'pbx_monitor...@systems.example.com' 
ldap:./virtual_alias_maps-domains.cf 
us...@example.com,us...@example.com

this works, but in the received message there is no reference to 
pbx_monitor...@systems.example.com - only:

From: postmas...@phonesrv.example.com
To: VOICE/1nnn5551212@phonesrv.example.com

how can i add a reference in the message to the recipient_canonical_maps lookup 
result [a header, preferably?]?  i'd like to do this so the name of the 
distribution list/virtual alias can be used in the mua for filtering to a 
specific mailbox.  i know there are other criteria which would function for the 
purposes of filtering, but i'd like to use this method if possible.  it would 
allow me to avoid reliance on strings/characteristics from the proprietary 
system, which may change.

thanks
-ben

Re: add header for canonical recipients

[btb]

On Sep 18, 2014, at 20.17, Viktor Dukhovni postfix-us...@dukhovni.org wrote:

 On Thu, Sep 18, 2014 at 07:51:53PM -0400, btb wrote:
 
 From: postmas...@phonesrv.example.com
 To: VOICE/1nnn5551212@phonesrv.example.com
 
 Is that the address or the display name?  What is the content
 of the complete To: header as stored in the mailbox (rather
 than displayed by some MUA).

is direct imap output [see below] sufficient?  it’s a bit more convoluted to 
retrieve the content directly from disk, but i can do that if need be.

a FETCH 17 BODY[HEADER]
* 17 FETCH (BODY[HEADER] {1470}
Received: from mfa.example.com (LHLO localhost) (10.3.70.9) by
 mda.example.com with LMTP; Thu, 4 Sep 2014 08:42:49 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.9 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9]
autolearn=ham autolearn_force=no
X-Amavis-OS-Fingerprint: MYNETWORKS, [10.36.40.26]:36290
Received: from mta1.example.com ([10.3.70.5])
by localhost (mfa.example.com [10.3.70.9]) (amavisd-new, port 11024)
with LMTP id Me79vjYqeOyN; Thu,  4 Sep 2014 08:42:44 -0400 (EDT)
Received: from mta.systems.example.com (mta.systems.example.com [10.36.40.26])
by mta1.example.com (Postfix) with ESMTPS id 3hphW80tp5zJmqq;
Thu,  4 Sep 2014 08:42:44 -0400 (EDT)
Received: from phonesrv.example.com (phonesrv.example.com [10.25.40.1])
(using TLSv1 with cipher RC4-MD5 (128/128 bits))
(No client certificate requested)
by msa.systems.example.com (Postfix) with ESMTPSA id 3hphW80SZrzyQn
for VOICE/pnnn5551...@phonesrv.example.com; Thu,  4 Sep 2014 08:42:44 
-0400 (EDT)
From: postmas...@phonesrv.example.com
To: VOICE/pNNN5551212@phonesrv.example.com
Date: Thu, 4 Sep 2014 08:42:44 -0400
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=9B095B5ADSN=_01CF6F07A968860C00D6phonesrv.example.co
X-DSNContext: 7ce717b1 - 1196 - 0002 - 
Message-ID: l1c00gozo0...@phonesrv.example.com
Subject: Delivery Status Notification (Failure)
a OK FETCH completed

Re: different transport for all mail introduced via sendmail(1)

[btb]

On 2014.09.10 14.02, wie...@porcupine.org (Wietse Venema) wrote:
 btb:
 hi-

 i have a mail submission server [submission/587 only] [msa.example.com]
 for our users [config below].  in that context, it's working as desired.
we also have another, separate, msa [msa.systems.example.com], which
 servers and other infrastructure devices use for submitting mail.  how
 can i configure postfix so that all mail introduced via sendmail(1) on
 msa.example.com [regardless of envelope sender/recipient, etc] is
 delivered directly to msa.systems.example.com:submission,
 
 /etc/postfix/master.cf:
  pickup ..   ..   ..   ..   ..   ..   ..   ..  pickup
   -o filter=smtp_pickup:a.systems.example.com:submission
  smtp_pickup ..  ..   ..   ..   ..   ..   ..   ..  smtp
   -o 
 smtp_sender_dependent_authentication=$smtp_pickup_sender_dependent_authentication
   -o smtp_sasl_password_maps=$smtp_pickup_sasl_password_maps
 
 and smtp auth is performed with the necessary credentials,
 
 Perhaps you mean sender-dependent credentials?
 
 /etc.postfix/master.cf:
  smtp_pickup_sender_dependent_authentication = yes
  smtp_pickup_sasl_password_maps = hash:/etc/postfix/smtp_pickup_sasl_pass

here's what i ended up with [i think -o filter=... was meant to be -o 
content_filter=... ? - and in this case, it's just a single set of credentials]:

main.cf:
null_client_syslog_name = postfix/null_client
null_client_content_filter = 
smtp-nullclient:[msa.systems.${mydomain}]:submission
null_client_sasl_auth_enable = yes
null_client_sasl_tls_security_options = noanonymous
null_client_sasl_password_maps = 
hash:${table_directory}/null_client_smtp_auth_creds

master.cf:
pickupunix  n   -   -   60  1   pickup
-o content_filter=${null_client_content_filter}

smtp-nullclientunix  -   -   -   -   10   smtp
-o syslog_name=${null_client_syslog_name}
-o smtp_sasl_auth_enable=${null_client_sasl_auth_enable}
-o 
smtp_sasl_tls_security_options=${null_client_sasl_tls_security_options}
-o smtp_sasl_password_maps=${null_client_sasl_password_maps}

this seems to be working well, thanks.

-ben

different transport for all mail introduced via sendmail(1)

[btb]

hi-

i have a mail submission server [submission/587 only] [msa.example.com] 
for our users [config below].  in that context, it's working as desired. 
 we also have another, separate, msa [msa.systems.example.com], which 
servers and other infrastructure devices use for submitting mail.  how 
can i configure postfix so that all mail introduced via sendmail(1) on 
msa.example.com [regardless of envelope sender/recipient, etc] is 
delivered directly to msa.systems.example.com:submission, and smtp auth 
is performed with the necessary credentials, while not changing any 
other existing elements of mail flow [for example, mail addressed to 
f...@systems.example.com, introduced via submission, should not be 
delivered directly to msa.systems.example.com:submission, but rather 
follow the unadulterated delivery path]?


thanks
-ben

postconf -nf
address_verify_negative_expire_time = 30m
address_verify_negative_refresh_time = 5m
address_verify_poll_count = 20
address_verify_poll_delay = 1s
alias_database =
alias_maps =
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
content_filter = lmtp-filter:[mfa.example.com]:lmtp-filter-internal
delay_warning_time = 4h
disable_vrfy_command = yes
dist_list_restrictions = check_recipient_access
pcre:${table_directory}/dist_lists.pcre
enable_long_queue_ids = yes
local_header_rewrite_clients = check_address_map
cidr:${table_directory}/local_header_rewrite_clients.cidr
local_recipient_maps =
local_transport = error:local mail delivery is disabled
masquerade_domains = ${mydomain}
message_size_limit = 20971520
mydestination =
mydomain = example.com
myhostname = msa.${mydomain}
mynetworks =
myorigin = ${mydomain}
parent_domain_matches_subdomains =
pki_directory = ${config_directory}/pki
proxy_read_maps = ${virtual_alias_maps}
proxy:ldap:${table_directory}/sender_logins.cf
proxy:ldap:${table_directory}/dist_lists.cf
smtp_address_preference = ipv4
smtp_helo_name = ${myhostname}
smtp_tls_CAfile = /etc/pki/trusted_root_authorities/ca-certificates.crt
smtp_tls_fingerprint_digest = sha1
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = ${myhostname} ESMTP mail_submission_service
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_sender
reject_unknown_sender_domain reject_non_fqdn_recipient
reject_unknown_recipient_domain reject_unauth_pipelining
check_recipient_access hash:${table_directory}/bogus_domains
check_recipient_access
hash:${table_directory}/recipient_verification_domains
check_recipient_access proxy:ldap:${table_directory}/dist_lists.cf
check_recipient_access
pcre:${table_directory}/filter_training_transport.pcre 
check_client_access
cidr:${table_directory}/non_auth_submitters.cidr 
reject_plaintext_session

reject_sender_login_mismatch permit_sasl_authenticated reject
smtpd_reinjection_banner = ${myhostname} ESMTP mail_reinjection_service
smtpd_reinjection_restrictions = check_client_access
cidr:${table_directory}/reinjection_access.cidr reject
smtpd_relay_restrictions =
smtpd_restriction_classes = smtpd_reinjection_restrictions
dist_list_restrictions
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = inet:[::1]:sasl
smtpd_sasl_type = dovecot
smtpd_sender_login_maps = proxy:ldap:${table_directory}/sender_logins.cf
smtpd_tls_CAfile = /etc/pki/trusted_root_authorities/ca-certificates.crt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = ${pki_directory}/${myhostname}-cert.pem
smtpd_tls_dh1024_param_file = ${pki_directory}/dh_2048.pem
smtpd_tls_dh512_param_file = ${pki_directory}/dh_512.pem
smtpd_tls_fingerprint_digest = sha1
smtpd_tls_key_file = ${pki_directory}/${myhostname}-key.pem
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
strict_rfc821_envelopes = yes
table_directory = ${config_directory}/tables
transport_maps = hash:${table_directory}/transports
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 554
unknown_relay_recipient_reject_code = 554
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_domains =
virtual_alias_expansion_limit = 2000
virtual_alias_maps = proxy:ldap:${table_directory}/virtual_aliases.cf

postconf -Mf
smsp   inet  n   -   -   -   -   smtpd
pickup unix  n   -   -   60  1   pickup
cleanupunix  n   -   -   -   0   cleanup
qmgr   unix  n   -   n   300 1   qmgr
tlsmgr unix  -   -   -   1000?   1   tlsmgr
rewriteunix  -   -   -   -   -   trivial-rewrite
bounce unix  -   -   -   -   0   bounce
defer  unix  -   -   -   -   0   

understanding documentation for always_add_missing_headers, local_header_rewrite_clients and cleanup(8)

[btb]

hi-

if i'm interpreting correctly, the documentation for cleanup(8) says 
that (Resent-) From:,  To:,  Message-Id:, and Date: headers are always 
inserted:


The cleanup(8) daemon always performs the following transformations:

· Insert missing message headers: (Resent-) From:, To:, Message-Id:, and 
Date:.

[...]

the postconf(5) documentation for always_add_missing_headers and 
local_header_rewrite_clients seems to say this is only the case for 
earlier than postfix 2.6.  my experience with 2.11 just now supports this.


is the cleanup(8) documentation a little behind the current behavior?

sort of related, the postconf(5) documentation for 
local_header_rewrite_clients doesn't mention adding missing headers, but 
setting


local_header_rewrite_clients = check_address_map 
cidr:${table_directory}/local_header_rewrite_clients.cidr


does add From: and Date: [i only tested those two].  could the 
documentation for local_header_rewrite_clients be made to more closely 
reflect the documentation for always_add_missing_headers and cleanup(8)?


-ben

Re: understanding documentation for always_add_missing_headers, local_header_rewrite_clients and cleanup(8)

[btb]

On Aug 27, 2014, at 19.36, Wietse Venema wie...@porcupine.org wrote:

 btb:
 hi-
 
 if i'm interpreting correctly, the documentation for cleanup(8) says 
 that (Resent-) From:,  To:,  Message-Id:, and Date: headers are always 
 inserted:
 
 This is enabled with to local_header_rewrite_clients and
 always_add_missing_headers, as documented in more detail in the
 postconf(5) manpage.

yes, that’s the behavior i’m seeing.  i was just asking about the man page for 
cleanup.  it seems like Insert missing message headers:” should be in the 
optional section, not the always group, since they’re not always inserted - 
only if local_header_rewrite_clients/always_add_missing_headers are used.

-ben

understanding address_verify_poll_delay

[btb]

with respect to my previous question about address verification, i think 
i'm not understanding address_verify_poll_delay correctly.  while 
working on troubleshooting the 6.2 second delay during the smtp 
handshake, i'd set address_verify_poll_delay to 15 seconds, expecting 
that postfix would then wait up to that long for verification of an 
address to occur.  after doing this, i noticed 15 second delays in 
between each recipient verification, which i wasn't expecting [see below 
log excerpt].  is this expected?  i interpreted an address verification 
request to be each of the individual probes shown in the log excerpt, 
and so expected postfix to wait up to that long for each to complete, 
but not wait that long in between each probe once successful.


thanks
-ben

Jul  9 16:48:16 msa01 postfix/smtpd[31514]: connect from 
clientl.example.com[10.68.15.100]
Jul  9 16:48:16 msa01 postfix/smtpd[31514]: Anonymous TLS connection 
established from clientl.example.com[10.68.15.100]: TLSv1 with cipher 
ECDHE-RSA-AES256-SHA (256/256 bits)
Jul  9 16:48:16 msa01 postfix/cleanup[31493]: 3h7szh5t3yzJnMV: 
message-id=3h7szh5t3yzj...@msa.example.com
Jul  9 16:48:16 msa01 postfix/qmgr[24500]: 3h7szh5t3yzJnMV: 
from=double-bou...@example.com, size=216, nrcpt=1 (queue active)
Jul  9 16:48:16 msa01 postfix/lmtp[31505]: 3h7szh5t3yzJnMV: 
to=testuser-3...@example.com, relay=mda.example.com[10.59.1.57]:7025, 
delay=0.04, delays=0.03/0/0.01/0.01, dsn=2.1.5, status=deliverable (250 
2.1.5 Recipient OK)

Jul  9 16:48:16 msa01 postfix/qmgr[24500]: 3h7szh5t3yzJnMV: removed
Jul  9 16:48:31 msa01 postfix/smtpd[31514]: 3h7szz6skPzJnMV: 
client=clientl.example.com[10.68.15.100], sasl_method=PLAIN, 
sasl_username=user01
Jul  9 16:48:32 msa01 postfix/cleanup[31520]: 3h7szz74sKzJnP1: 
message-id=3h7szz74skzj...@msa.example.com
Jul  9 16:48:32 msa01 postfix/qmgr[24500]: 3h7szz74sKzJnP1: 
from=double-bou...@example.com, size=216, nrcpt=1 (queue active)
Jul  9 16:48:32 msa01 postfix/lmtp[31512]: 3h7szz74sKzJnP1: 
to=testuser-3...@example.com, relay=mda.example.com[10.59.1.57]:7025, 
delay=0.25, delays=0.24/0/0.01/0.01, dsn=2.1.5, status=deliverable (250 
2.1.5 Recipient OK)

Jul  9 16:48:32 msa01 postfix/qmgr[24500]: 3h7szz74sKzJnP1: removed
Jul  9 16:48:47 msa01 postfix/cleanup[31520]: 3h7t0H0BFrzJnP1: 
message-id=3h7t0h0bfrzj...@msa.example.com
Jul  9 16:48:47 msa01 postfix/qmgr[24500]: 3h7t0H0BFrzJnP1: 
from=double-bou...@example.com, size=216, nrcpt=1 (queue active)
Jul  9 16:48:47 msa01 postfix/lmtp[31505]: 3h7t0H0BFrzJnP1: 
to=testuser-3...@example.com, relay=mda.example.com[10.59.1.57]:7025, 
delay=0.04, delays=0.01/0/0.01/0.01, dsn=2.1.5, status=deliverable (250 
2.1.5 Recipient OK)

Jul  9 16:48:47 msa01 postfix/qmgr[24500]: 3h7t0H0BFrzJnP1: removed
Jul  9 16:49:02 msa01 postfix/cleanup[31520]: 3h7t0Z0VHwzJnP1: 
message-id=3h7t0z0vhwzj...@msa.example.com
Jul  9 16:49:02 msa01 postfix/qmgr[24500]: 3h7t0Z0VHwzJnP1: 
from=double-bou...@example.com, size=216, nrcpt=1 (queue active)
Jul  9 16:49:02 msa01 postfix/lmtp[31512]: 3h7t0Z0VHwzJnP1: 
to=testuser-3...@example.com, relay=mda.example.com[10.59.1.57]:7025, 
delay=0.02, delays=0.01/0/0/0.01, dsn=2.1.5, status=deliverable (250 
2.1.5 Recipient OK)

Jul  9 16:49:02 msa01 postfix/qmgr[24500]: 3h7t0Z0VHwzJnP1: removed
Jul  9 16:49:17 msa01 postfix/cleanup[31520]: 3h7t0s0qsyzJnP1: 
message-id=3h7t0s0qsyzj...@msa.example.com
Jul  9 16:49:17 msa01 postfix/qmgr[24500]: 3h7t0s0qsyzJnP1: 
from=double-bou...@example.com, size=216, nrcpt=1 (queue active)
Jul  9 16:49:17 msa01 postfix/lmtp[31505]: 3h7t0s0qsyzJnP1: 
to=testuser-3...@example.com, relay=mda.example.com[10.59.1.57]:7025, 
delay=0.03, delays=0.01/0/0.01/0, dsn=2.1.5, status=deliverable (250 
2.1.5 Recipient OK)

Jul  9 16:49:17 msa01 postfix/qmgr[24500]: 3h7t0s0qsyzJnP1: removed

Re: understanding address_verify_poll_delay

[btb]

On Jul 9, 2014, at 18.48, Wietse Venema wie...@porcupine.org wrote:

 btb:
 with respect to my previous question about address verification, i think 
 i'm not understanding address_verify_poll_delay correctly.  while 
 working on troubleshooting the 6.2 second delay during the smtp 
 handshake, i'd set address_verify_poll_delay to 15 seconds, expecting 
 that postfix would then wait up to that long for verification of an 
 address to occur.  
 
 address_verify_poll_delay (default: 3s)
   The DELAY BETWEEN QUERIES for the completion of an address verification
   request in progress.

it is this exact wording which left me confused.  is each queue id a single 
address verification request?  or is the entire session while the client waits 
for all addresses to be verified a single address verification request?  logic 
would seem to indicate the former.  in any case, i want postfix to wait up to 
15 seconds for each address before deciding the status isn’t deliverable, not 
wait for 15 seconds idling after a verification request takes a fraction of a 
second to complete.  how can these two elements of time be set independent of 
each other?

-ben

Re: understanding address_verify_poll_delay

[btb]

On Jul 9, 2014, at 19.35, Wietse Venema wie...@porcupine.org wrote:

 address_verify_poll_delay (default: 3s)
   The DELAY BETWEEN QUERIES for the completion of an address verification
   request in progress.
 
 This specifies the delay betweem the $address_verify_poll_count
 queries for one address verification request in progress.

in the logs i shared, postfix completes verification of one address:

Jul  9 16:49:02 msa01 postfix/cleanup[31520]: 3h7t0Z0VHwzJnP1: 
message-id=3h7t0z0vhwzj...@msa.example.com
Jul  9 16:49:02 msa01 postfix/qmgr[24500]: 3h7t0Z0VHwzJnP1: 
from=double-bou...@example.com, size=216, nrcpt=1 (queue active)
Jul  9 16:49:02 msa01 postfix/lmtp[31512]: 3h7t0Z0VHwzJnP1: 
to=testuser-3...@example.com, relay=mda.example.com[10.59.1.57]:7025, 
delay=0.02, delays=0.01/0/0/0.01, dsn=2.1.5, status=deliverable (250 2.1.5 
Recipient OK)
Jul  9 16:49:02 msa01 postfix/qmgr[24500]: 3h7t0Z0VHwzJnP1: removed

then waits 15 seconds before starting verification of the next address:

Jul  9 16:49:17 msa01 postfix/cleanup[31520]: 3h7t0s0qsyzJnP1: 
message-id=3h7t0s0qsyzj...@msa.example.com
Jul  9 16:49:17 msa01 postfix/qmgr[24500]: 3h7t0s0qsyzJnP1: 
from=double-bou...@example.com, size=216, nrcpt=1 (queue active)
Jul  9 16:49:17 msa01 postfix/lmtp[31505]: 3h7t0s0qsyzJnP1: 
to=testuser-3...@example.com, relay=mda.example.com[10.59.1.57]:7025, 
delay=0.03, delays=0.01/0/0.01/0, dsn=2.1.5, status=deliverable (250 2.1.5 
Recipient OK)
Jul  9 16:49:17 msa01 postfix/qmgr[24500]: 3h7t0s0qsyzJnP1: removed

this is not a delay between the $address_verify_poll_count queries for one 
address verification request in progress.  this is a delay between two 
different address verifications requests, for two different addresses.  one 
completes, and is no longer in progress.  then the next one begins.

it seems to me that address_verify_poll_delay is not only affecting the delay 
between queries for one request, but also the delay between one request and the 
next.  given the documentation, i don’t think this should be happening.

-ben

address verification: Address verification in progress

[btb]

we use recipient address verification amongst some of our own domains.  on 
occasion, i see the following log entries:

Jul  6 08:26:22 msa-aux postfix/smsp/smtpd[2545]: connect from 
client.example.com[10.48.40.102]
Jul  6 08:26:22 msa-aux postfix/smsp/smtpd[2545]: Anonymous TLS connection 
established from client.example.com[10.48.40.102]: TLSv1 with cipher 
DHE-RSA-AES256-SHA (256/256 bits)
Jul  6 08:26:23 msa-aux postfix/cleanup[2552]: 3h5pzz1NVpzyQm: 
message-id=3h5pzz1nvpz...@msa-aux.systems.example.com
Jul  6 08:26:23 msa-aux postfix/qmgr[5256]: 3h5pzz1NVpzyQm: 
from=double-bou...@systems.example.com, size=238, nrcpt=1 (queue active)
Jul  6 08:26:29 msa-aux postfix/smsp/smtpd[2545]: NOQUEUE: reject: RCPT from 
client.example.com[10.48.40.102]: 450 4.1.1 j...@example.com: Recipient 
address rejected: unverified address: Address verification in progress; 
from=rsm...@mail.example.com to=j...@example.com proto=ESMTP 
helo=client.example.com
Jul  6 08:26:29 msa-aux postfix/smsp/smtpd[2545]: disconnect from 
client.example.com[10.48.40.102]
Jul  6 08:26:29 msa-aux postfix/kvcc-internal/smtp[2553]: 3h5pzz1NVpzyQm: 
to=j...@example.com, relay=mta.example.com[10.3.70.5]:25, delay=6.4, 
delays=0.01/0.02/6.2/0.21, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
Jul  6 08:26:29 msa-aux postfix/qmgr[5256]: 3h5pzz1NVpzyQm: removed
Jul  6 08:28:14 msa-aux postfix/verify[2551]: close database 
/var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley 
DB bug)

postfix appears to begin the verification process, but seems to reject the 
message just before the recipient is determined to be deliverable.  here's the 
related log snippit from 10.3.70.5: 

Jul  6 08:26:23 mta1 postfix/postscreen[16943]: CONNECT from 
[10.36.40.26]:45643 to [10.3.70.5]:25
Jul  6 08:26:29 mta1 postfix/postscreen[16943]: PASS OLD [10.36.40.26]:45643
Jul  6 08:26:29 mta1 postfix/smtpd[16952]: connect from 
msa-aux.systems.example.com[10.36.40.26]
Jul  6 08:26:29 mta1 postfix/smtpd[16952]: Anonymous TLS connection established 
from msa-aux.systems.example.com[10.36.40.26]: TLSv1.2 with cipher 
AECDH-AES256-SHA (256/256 bits)
Jul  6 08:26:29 mta1 postfix/smtpd[16952]: 3h5q054KcRzJmm1: 
client=msa-aux.systems.example.com[10.36.40.26]
Jul  6 08:26:29 mta1 postfix/smtpd[16952]: disconnect from 
msa-aux.systems.example.com[10.36.40.26]

a bit later, a message from the same client, to that now verified recipient, is 
processed successfully:

Jul  6 08:43:50 msa-aux postfix/smsp/smtpd[2642]: Anonymous TLS connection 
established from client.example.com[10.48.40.102]: TLSv1 with cipher 
DHE-RSA-AES256-SHA (256/256 bits)
Jul  6 08:43:50 msa-aux postfix/smsp/smtpd[2642]: 3h5qN66fp6zyQm: 
client=client.example.com[10.48.40.102], sasl_method=PLAIN, 
sasl_username=client_postfix
Jul  6 08:43:50 msa-aux postfix/cleanup[2648]: 3h5qN66fp6zyQm: 
message-id=d09f36dab46b8e9ad95da0e90d1aa...@www.example.com
Jul  6 08:43:50 msa-aux postfix/qmgr[5256]: 3h5qN66fp6zyQm: 
from=rsm...@mail.example.com, size=2123, nrcpt=1 (queue active)
Jul  6 08:43:50 msa-aux postfix/smsp/smtpd[2642]: disconnect from 
client.example.com[10.48.40.102]
Jul  6 08:43:51 msa-aux postfix/kvcc-internal/smtp[2649]: 3h5qN66fp6zyQm: 
to=j...@example.com, relay=mta.example.com[10.3.70.5]:25, delay=0.24, 
delays=0.04/0.02/0.01/0.18, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 
3h5qN710RqzJmm1)
Jul  6 08:43:51 msa-aux postfix/qmgr[5256]: 3h5qN66fp6zyQm: removed

this isn't consistent - most mail is verified and then relayed successfully.  
it seems to happen once every few hundred messages or so.  how can i further 
troubleshoot why this is occurring?

on a semi-related note, how can the verified recipient be included in the log 
entry on the server against which verification is being performed?:

Jul  6 08:26:29 mta1 postfix/smtpd[16952]: 3h5q054KcRzJmm1: 
client=msa-aux.systems.example.com[10.36.40.26]

this would be helpful in troubleshooting.

thanks
-ben

Re: address verification: Address verification in progress

[btb]

On 2014.07.07 12.25, btb wrote:

we use recipient address verification amongst some of our own domains.  on 
occasion, i see the following log entries:

Jul  6 08:26:22 msa-aux postfix/smsp/smtpd[2545]: connect from 
client.example.com[10.48.40.102]
Jul  6 08:26:22 msa-aux postfix/smsp/smtpd[2545]: Anonymous TLS connection 
established from client.example.com[10.48.40.102]: TLSv1 with cipher 
DHE-RSA-AES256-SHA (256/256 bits)
Jul  6 08:26:23 msa-aux postfix/cleanup[2552]: 3h5pzz1NVpzyQm: 
message-id=3h5pzz1nvpz...@msa-aux.systems.example.com
Jul  6 08:26:23 msa-aux postfix/qmgr[5256]: 3h5pzz1NVpzyQm: 
from=double-bou...@systems.example.com, size=238, nrcpt=1 (queue active)
Jul  6 08:26:29 msa-aux postfix/smsp/smtpd[2545]: NOQUEUE: reject: RCPT from 
client.example.com[10.48.40.102]: 450 4.1.1 j...@example.com: Recipient address rejected: 
unverified address: Address verification in progress; from=rsm...@mail.example.com 
to=j...@example.com proto=ESMTP helo=client.example.com
Jul  6 08:26:29 msa-aux postfix/smsp/smtpd[2545]: disconnect from 
client.example.com[10.48.40.102]
Jul  6 08:26:29 msa-aux postfix/example-internal/smtp[2553]: 3h5pzz1NVpzyQm: 
to=j...@example.com, relay=mta.example.com[10.3.70.5]:25, delay=6.4, 
delays=0.01/0.02/6.2/0.21, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
Jul  6 08:26:29 msa-aux postfix/qmgr[5256]: 3h5pzz1NVpzyQm: removed
Jul  6 08:28:14 msa-aux postfix/verify[2551]: close database 
/var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley 
DB bug)

postfix appears to begin the verification process, but seems to reject the 
message just before the recipient is determined to be deliverable.  here's the 
related log snippit from 10.3.70.5:

Jul  6 08:26:23 mta1 postfix/postscreen[16943]: CONNECT from 
[10.36.40.26]:45643 to [10.3.70.5]:25
Jul  6 08:26:29 mta1 postfix/postscreen[16943]: PASS OLD [10.36.40.26]:45643
Jul  6 08:26:29 mta1 postfix/smtpd[16952]: connect from 
msa-aux.systems.example.com[10.36.40.26]
Jul  6 08:26:29 mta1 postfix/smtpd[16952]: Anonymous TLS connection established 
from msa-aux.systems.example.com[10.36.40.26]: TLSv1.2 with cipher 
AECDH-AES256-SHA (256/256 bits)
Jul  6 08:26:29 mta1 postfix/smtpd[16952]: 3h5q054KcRzJmm1: 
client=msa-aux.systems.example.com[10.36.40.26]
Jul  6 08:26:29 mta1 postfix/smtpd[16952]: disconnect from 
msa-aux.systems.example.com[10.36.40.26]

a bit later, a message from the same client, to that now verified recipient, is 
processed successfully:

Jul  6 08:43:50 msa-aux postfix/smsp/smtpd[2642]: Anonymous TLS connection 
established from client.example.com[10.48.40.102]: TLSv1 with cipher 
DHE-RSA-AES256-SHA (256/256 bits)
Jul  6 08:43:50 msa-aux postfix/smsp/smtpd[2642]: 3h5qN66fp6zyQm: 
client=client.example.com[10.48.40.102], sasl_method=PLAIN, 
sasl_username=client_postfix
Jul  6 08:43:50 msa-aux postfix/cleanup[2648]: 3h5qN66fp6zyQm: 
message-id=d09f36dab46b8e9ad95da0e90d1aa...@www.example.com
Jul  6 08:43:50 msa-aux postfix/qmgr[5256]: 3h5qN66fp6zyQm: 
from=rsm...@mail.example.com, size=2123, nrcpt=1 (queue active)
Jul  6 08:43:50 msa-aux postfix/smsp/smtpd[2642]: disconnect from 
client.example.com[10.48.40.102]
Jul  6 08:43:51 msa-aux postfix/example-internal/smtp[2649]: 3h5qN66fp6zyQm: 
to=j...@example.com, relay=mta.example.com[10.3.70.5]:25, delay=0.24, 
delays=0.04/0.02/0.01/0.18, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 
3h5qN710RqzJmm1)
Jul  6 08:43:51 msa-aux postfix/qmgr[5256]: 3h5qN66fp6zyQm: removed

this isn't consistent - most mail is verified and then relayed successfully.  
it seems to happen once every few hundred messages or so.  how can i further 
troubleshoot why this is occurring?

on a semi-related note, how can the verified recipient be included in the log 
entry on the server against which verification is being performed?:

Jul  6 08:26:29 mta1 postfix/smtpd[16952]: 3h5q054KcRzJmm1: 
client=msa-aux.systems.example.com[10.36.40.26]

this would be helpful in troubleshooting.

thanks
-ben


i neglected to include my config.  please see below.

postconf -nf
address_verify_negative_expire_time = 30s
address_verify_negative_refresh_time = 30s
address_verify_positive_expire_time = 12h
address_verify_positive_refresh_time = 6h
alias_database =
alias_maps =
allow_local_senders = check_sender_access
hash:${table_directory}/allowed_sender_domains
append_dot_mydomain = no
base_recipient_restrictions = reject_non_fqdn_sender
reject_unknown_sender_domain reject_non_fqdn_recipient
reject_unknown_recipient_domain check_recipient_access
hash:${table_directory}/bogus_domains check_recipient_access
hash:${table_directory}/recipient_verification_domains
reject_unauth_pipelining
biff = no
config_directory = /etc/postfix
delay_warning_time = 4h
disable_vrfy_command = yes
enable_long_queue_ids = yes
local_recipient_maps =
local_transport = error:local mail delivery is disabled
message_size_limit = 10485760
mydestination =
mydomain = systems.example.com

Re: address verification: Address verification in progress

[btb]

On 2014.07.07 12.39, Wietse Venema wrote:

Find out why it takes 6.2 seconds to connect over TCP and to
complete the SMTP handshake with the remote SMTP server.


given postscreen_greet_wait, it's a coincidence that the remote server's 
postscreen logs show that same delay ~6 second delay, but list it as 
PASS OLD:


Jul  6 08:26:23 mta1 postfix/postscreen[16943]: CONNECT from 
[10.36.40.26]:45643 to [10.3.70.5]:25

Jul  6 08:26:29 mta1 postfix/postscreen[16943]: PASS OLD [10.36.40.26]:45643

the timing seems to suggest postscreen, but obviously PASS OLD says 
otherwise.  other PASS OLD log entries show no such delay.  i'll 
investigate further.


in the mean time, how can i configure postfix to wait longer for 
verification?


-ben

logging when message_size_limit is exceeded

[btb]

hi-

when message_size_limit is exceeded, i see the following logs:

Jun 24 11:20:21 mta postfix/postscreen[5758]: CONNECT from 
[173.201.193.182]:45771 to [10.3.70.5]:25
Jun 24 11:20:21 mta postfix/postscreen[5758]: PASS OLD [173.201.193.182]:45771
Jun 24 11:20:21 mta postfix/smtpd[7066]: connect from 
p3plsmtp18-01-2.prod.phx3.secureserver.net[173.201.193.182]
Jun 24 11:20:21 mta postfix/smtpd[7066]: NOQUEUE: reject: MAIL from 
p3plsmtp18-01-2.prod.phx3.secureserver.net[173.201.193.182]: 552 5.3.4 Message 
size exceeds fixed limit; proto=ESMTP 
helo=p3plwbeout18-01.prod.phx3.secureserver.net
Jun 24 11:21:21 mta postfix/smtpd[7066]: disconnect from 
p3plsmtp18-01-2.prod.phx3.secureserver.net[173.201.193.182]

can this event be correlated with the envelope sender and recipient[s]?  it 
would be a helpful detail in the process of associating reports from end users 
with this event.

-ben

Re: logging when message_size_limit is exceeded

[btb]

On Jun 24, 2014, at 19.35, Wietse Venema wie...@porcupine.org wrote:

 btb:
 Jun 24 11:20:21 mta postfix/postscreen[5758]: CONNECT from 
 [173.201.193.182]:45771 to [10.3.70.5]:25
 Jun 24 11:20:21 mta postfix/postscreen[5758]: PASS OLD 
 [173.201.193.182]:45771
 Jun 24 11:20:21 mta postfix/smtpd[7066]: connect from 
 p3plsmtp18-01-2.prod.phx3.secureserver.net[173.201.193.182]
 Jun 24 11:20:21 mta postfix/smtpd[7066]: NOQUEUE: reject: MAIL from 
 p3plsmtp18-01-2.prod.phx3.secureserver.net[173.201.193.182]: 552 5.3.4 
 Message size exceeds fixed limit; proto=ESMTP 
 helo=p3plwbeout18-01.prod.phx3.secureserver.net
 Jun 24 11:21:21 mta postfix/smtpd[7066]: disconnect from 
 p3plsmtp18-01-2.prod.phx3.secureserver.net[173.201.193.182]
 
 can this event be correlated with the envelope sender and recipient[s]?
 it would be a helpful detail in the process of associating reports
 from end users with this event.
 
 There is no sender and there is no recipient. Postfix rejects the
 MAIL FROM command.

thanks for this.  i wrongly assumed this event occurred after 
message_size_limit bytes had been transmitted.  i’ve read rfc 1870 and i think 
i better understand this now.  iiuc, given that the client supplies SIZE=N as a 
parameter to MAIL FROM, while rejected, is the attempted sender at least 
potentially known, and could perhaps be logged?  in that same vein, thinking 
about the spirit of smtpd_delay_reject - while i understand rejecting mail 
based on size is not an smtpd_*_restriction, could the same logic/rationale be 
applied - to allow postfix to log those additional details?

 In fact, a smart client would have hung up before even sending the
 MAIL FROM command. Postfix announces the SIZE limit in the EHLO
 response. All you'd see in the logfile are a connect and disconnect.

yes, it sadly seems uninterested in the announced SIZE limit.  it seems ironic 
now too, given that it’s using the MAIL FROM SIZE parameter.  i noticed the 60 
second delay before disconnecting, after it’s rejected, and wondered if the not 
so smart client is left confused when the rejection occurs prior to RCPT TO, 
and if honoring smtpd_delay_reject might be helpful in encouraging it to not 
sit idle, as the documentation alludes to.  of course, it could just be 
connection caching?  i can test some more and see if that client’s behavior 
differs when rejected after RCPT TO, which i guess would answer that question.

making some assumptions about the validity of my above comments, could i 
propose a setting to allow size rejections to wait until after RCPT TO?  i 
think the documentation might look like this:

smtpd_delay_size_reject (default: no)

Wait until the RCPT TO command before enforcing $message_size_limit.

This feature is turned off by default for backwards compatibility.

Like $smtpd_delay_reject turning on this setting has one major benefit: it 
allows Postfix to log recipient address information when rejecting a client 
name/address or sender address, so that it is possible to find out whose mail 
is being rejected.

-ben

Re: Email disappearing into a black hole...

[btb]

On Feb 15, 2014, at 23.14, SH Development listacco...@starionline.com wrote:

 Feb 15 21:12:36 mail postfix/pipe[23969]: 931AF2F4F36: 
 to=aaa...@mail.starionhost.net, 
 orig_to=aaa...@stariontech.com, relay=cyrus, delay=0, status=sent

you’ve configured postfix to pass mail to cyrus for delivery [relay=cyrus].  
postfix has done so [status=sent].  postfix cannot control what cyrus does with 
mail - consult your cyrus logs.

-ben

Re: Email disappearing into a black hole...

[btb]

On Feb 15, 2014, at 23.14, SH Development listacco...@starionline.com wrote:

 Feb 15 21:12:36 mail postfix/pipe[23969]: 931AF2F4F36: 
 to=aaa...@mail.starionhost.net, 
 orig_to=aaa...@stariontech.com, relay=cyrus, delay=0, status=sent

you’ve configured postfix to pass mail to cyrus for delivery [relay=cyrus].  
postfix has done so [status=sent].  postfix cannot control what cyrus does with 
mail - consult your cyrus logs.

-ben

Re: Find which port a user connected to?

[btb]

On 2014.01.22 11.41, Chris Richards wrote:

Basically, I need to find out which users are connecting to port 25
instead of 587.


man 5 postconf.  see syslog_name.  also see the sample config which 
comes with the software.  this includes a submission config which uses 
syslog_name


-ben

Re: rewrite sender address when recipient is non local

[btb]

On 2013.10.22 09.56, Noel Jones wrote:

On 10/22/2013 8:41 AM, btb wrote:

On 2013.10.21 17.54, Noel Jones wrote:

On 10/21/2013 3:53 PM, btb wrote:

i have a scenario in which certain email is sent using envelope
senders that contain host names that are known only on the local
lan/network, and unknown on the internet.  most mail expressing that
characteristic stays local, but occasionally, some is legitimately
destined for the public internet.  to that end, with such mail, i'd
like to change the sender domain part to @example.com, but only if
the recipient domain part does not end in example.com [both the
sender and recipient domain part may be @example.com,
@foo.example.com, @bar.foo.example.com, etc].

what is the right method for doing this?  given
ADDRESS_REWRITING_README, it seem to possibly be a fit for either
masquerade_domains or smtp_generic_maps, but i'm not certain, and
i'm not sure how to apply selectively.

-ben


smtp_generic_maps will do that nicely. Add the rewriting on the
smtp outgoing transport in master.cf to limit rewriting to
non-local recipient domains only.

#master.cf
# find the existing smtp unix ... smtp transport and add to it:
-o smtp_generic_maps=regexp:/etc/postfix/generic.regexp


# generic.regexp
/^(.*)@some\.fantasy\.invalid$/  $1...@example.com


thanks.  wrt limit rewriting to non-local recipient domains only, by stays 
local, i meant local in terms of the local network, not in terms of postfix.  
postfix is responsible for only systems.example.com:

virtual_mailbox_domains = ldap:$table_directory/virtual_mailbox_domains.cf


postmap -q 'systems.example.com' ldap:./tables/virtual_mailbox_domains.cf

systems.example.com

while everything else leaves via smtp and is delivered via mx records - some of 
which is for other recipients ending in @example.com or .example.com [delivered 
to other hosts on the local network], and the rest of course out onto the 
internet.  how can i apply smtp_generic_maps selectively, for only certain 
recipient domains [ones not ending in @example.com or .example.com] leaving via 
smtp - the goal being to rewrite the sender to @example.com for mail destined 
for the internet?

-ben



Postfix doesn't have a specific feature to rewrite the sender based
on the recipient.

Arrange for internal network traffic to use a specific transport,
such as the relay transport, and let internet traffic use the
default smtp transport.


thanks for this guidance.  i have what [given my testing so far] appears 
to be a setup working as desired, but would appreciate any critiques or 
feedback wrt considerations i may have overlooked.


# transport used by mail leaving the local network
smtp  unix  -   -   -   -   -   smtp
-o smtp_helo_name=msa.example.com
-o smtp_generic_maps=regexp:$table_directory/generic.regexp

# transport used by mail not leaving the local network
example-internal  unix  -   -   -   -   -   smtp
-o syslog_name=postfix/example-internal

cat transports
# handled by postfix virtual(8)
foo.example.com :
# valid/known on the internet
bar.example.com :

example.com example-internal:
.example.comexample-internal:

cat generic.regexp
# rewrite everything that ends in .example.com, except bar.example.com
if !/^(.*)@bar\.example\.com$/
/^(.*)@.*\.example\.com$/  $1...@example.com
endif

-ben

possible alternative methods for exclusion to transport_maps entry

[btb]

this stems from another discussion 
[http://archives.neohapsis.com/archives/postfix/2013-10/0454.html].


i'm currently doing:

transport_maps = hash:$table_directory/transports

cat transports
example.com example-internal:
foo.example.com smtp:
.example.comexample-internal:

example-internal  unix  -   -   -   -   -   smtp
-o syslog_name=postfix/example-internal

this appears to be working as desired.  mail to @example.com or 
@.example.com is using the example-internal transport, with the 
exception of mail to @foo.example.com, which is using the regular smtp 
transport.


i'm wondering if this could be done in a different manner, that wouldn't 
require the explicit smtp reference for foo.example.com - for example:


example.com example-internal:
.example.com!foo.example.comexample-internal:

the essence being to say that foo.example.com will use whatever 
transport it would have used if transport_maps weren't in use, rather 
than the explicit reference to smtp:


i know that specific example is not valid, but was just curious if i'd 
perhaps missed something in the documentation, or there was some other 
similar method that might be possible.


-ben

Re: rewrite sender address when recipient is non local

[btb]

On 2013.10.21 17.54, Noel Jones wrote:
 On 10/21/2013 3:53 PM, btb wrote:
 i have a scenario in which certain email is sent using envelope
 senders that contain host names that are known only on the local
 lan/network, and unknown on the internet.  most mail expressing that
 characteristic stays local, but occasionally, some is legitimately
 destined for the public internet.  to that end, with such mail, i'd
 like to change the sender domain part to @example.com, but only if
 the recipient domain part does not end in example.com [both the
 sender and recipient domain part may be @example.com,
 @foo.example.com, @bar.foo.example.com, etc].

 what is the right method for doing this?  given
 ADDRESS_REWRITING_README, it seem to possibly be a fit for either
 masquerade_domains or smtp_generic_maps, but i'm not certain, and
 i'm not sure how to apply selectively.

 -ben
 
 smtp_generic_maps will do that nicely. Add the rewriting on the
 smtp outgoing transport in master.cf to limit rewriting to
 non-local recipient domains only.
 
 #master.cf
 # find the existing smtp unix ... smtp transport and add to it:
-o smtp_generic_maps=regexp:/etc/postfix/generic.regexp
 
 
 # generic.regexp
 /^(.*)@some\.fantasy\.invalid$/  $1...@example.com

thanks.  wrt limit rewriting to non-local recipient domains only, by stays 
local, i meant local in terms of the local network, not in terms of postfix.  
postfix is responsible for only systems.example.com:

virtual_mailbox_domains = ldap:$table_directory/virtual_mailbox_domains.cf

postmap -q 'systems.example.com' ldap:./tables/virtual_mailbox_domains.cf 
systems.example.com

while everything else leaves via smtp and is delivered via mx records - some of 
which is for other recipients ending in @example.com or .example.com [delivered 
to other hosts on the local network], and the rest of course out onto the 
internet.  how can i apply smtp_generic_maps selectively, for only certain 
recipient domains [ones not ending in @example.com or .example.com] leaving via 
smtp - the goal being to rewrite the sender to @example.com for mail destined 
for the internet?

-ben

Re: Quick question on mynetworks

[btb]

On Oct 3, 2013, at 06.30, Mark Goodge m...@good-stuff.co.uk wrote:

 I know I could solve the problem by using authentication, but a lot of the 
 outbound email is generated by cron scripts on a server inside the network, 
 and rewriting all of them to authenticate when sending mail is likely to be 
 considerably more effort than updating mynetworks as and when the IP changes.

use a simple null client.  i'd recommend msmtp.  no configuration changes to 
the cron jobs or scripts they run is necessary.

-ben

Re: Is there a way to apply policy only to outgoing mail?

[btb]

On 2013.09.04 09.29, Przemysław Orzechowski wrote: Hi
 
 Im trying to get cbpolicyd to be applied only to outgoing mail (Postfix 
 vresion 2.7.0)

you don't apply it to outgoing mail.  you apply it to incoming mail [this is 
why the terms incoming and outgoing are typically best avoided]
 
 I'm trying to get a setup where i can limit mails each authenticated 
 user can send / hour

submissioninetn   -   -   -   -   smtpd
[...]
-o 
smtpd_recipient_restrictions=[...],check_policy_service,inet:127.0.0.1:10031
[...]

i would use a restriction class though, so most work can be confined to main.cf 
and master.cf be be a bit less awkward.

-ben

Re: Disabling user submission on port 25

[btb]

On 2013.08.27 00.32, LuKreme wrote:


That seem like a bit much. I allow the web-server (which hosts the
webmail) in mynetworks, since users mailing from there are already
authenticated. I can see there are situations where it would be a
good idea.


web mail users should perform proper smtp authentication, just like they 
would if they used any other client software.  among numerous benefits, 
it allows for easier auditing.


-ben

Re: postfix.org down?

[btb]

On 2013.08.20 10.23, Charles Marcus wrote:

for me at least...


http://www.downforeveryoneorjustme.com/www.postfix.org

Re: Setting up SPF in Postfix for sending

[btb]

On Aug 16, 2013, at 01.56, Rob Tanner rtan...@linfield.edu wrote:

 What is it, besides adding the correct the DNS TXT records

as there is a formal dns rr type for spf defined in rfc4408, you'll of course 
want to include that as well.

-ben

Re: Setting up SPF in Postfix for sending

[btb]

On Aug 16, 2013, at 15.06, Scott Kitterman post...@kitterman.com wrote:

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

interesting.  thank you for calling attention to this.

-ben

Re: Advice on Debian/postscreen and optimization

[btb]

On 2013.08.06 15.34, John Allen wrote:

Is there a more up to date guide that I could reference as I review my
existing setup.


it's unlikely you'll get much endorsement here of arbitrary howtos or 
guides.  instead, i'd encourage you to simply share your config 
[postconf -nf; postconf -Mf], and solicit a critique.



Debian does not seem to include Postscreen


what gives you this impression?  the 2.10 debian package i'm familiar 
with does.


-ben

Re: dovecot: imap-login: Aborted login

[btb]

On Jul 21, 2013, at 21.55, Adnane m...@adnane.me wrote:

 Hello every one
 
 first I'am new to mail servers,
 
 I have followed this tutorial -- 
 https://library.linode.com/email/postfix/postfix2.9.6-dovecot2.0.19-mysql?format=print
  to set up
 an Ubuntu 12.04 Dovecot postfix mail box for a subdomain mailer.adnane.me,  I 
 think I followed every thing right but I get
 disconnected when I try to access adn...@mailer.adnane.me with thunderbird
 
 dig mx mailer.adnane.me +short
 1 mailer.adnane.me.
 
 
 root@mailer:~# tail -f /var/log/syslogJul
 Jul 22 03:34:41 mailer dovecot:imap-login: Disconnected (no auth attempts): 
 rip=41.251.155.145, lip=5.135.151.43, TLS
 Jul 22 03:35:02 mailer dovecot: imap-login: Disconnected (no auth attempts): 
 rip=41.251.155.145, lip=5.135.151.43, TLS handshaking: Disconnected
 Jul 22 03:35:02 mailer dovecot: imap-login: Disconnected (no auth attempts): 
 rip=41.251.155.145, lip=5.135.151.43, TLS handshaking: Disconnected
 Jul 22 03:35:03 mailer dovecot: imap-login: Disconnected (no auth attempts): 
 rip=41.251.155.145, lip=5.135.151.43, TLS: Disconnected
 
 plz let me know which conf files I need to post here, tnx.

you seem to have inadvertently posted to the wrong mailing list.  consult the 
dovecot web site for information on its community support.

-ben

Re: Backup mx on cable

[btb]

On Jul 9, 2013, at 21.56, Fred Zinsli fred.zin...@shooter.co.nz wrote:

 This is something I hadn't considered at all.
 In order for me to better understand the consequences of my actions are
 you able to explain to me why that is the case, and what situation would
 need to arise for that to happen. Or simply point me to the appropriate
 articles so I can read and investigate this.
 
 It is looking more and more like I should be leasing another VPS server to
 host my backup DNS and MX.

honestly, i simply wouldn't bother with a backup mx.  what is the actual 
problem you're trying to solve by running a backup mx?  the contemporary 
internet is remarkably well connected - the days in which the truly practical 
application of a backup mx were back when hosts/sites often spent the majority 
of their time disconnected from the internet.

-ben

Re: Send email for users from any location

[btb]

On 2013.07.08 08.25, Dotan Cohen wrote:

Form googling I found this solution online but it does not work as I
expected.


instead of googling, simply use the postfix documentation that came with 
the software.  your goal is accomplished by implementing smtp auth, 
which postfix offers by way of sasl authentication.  to that end, this 
is documented in SASL_README.  i would recommend that you use dovecot 
rather than cyrus for sasl.  while SASL_README of course includes a fair 
amount of documentation for the associated sasl software, you'll likely 
also want to reference the documentation provided with that software as 
well.


on a related note, as this is for humans to send mail from their mail 
clients, you'll want to configure a proper submission [port 587] 
service.  see the commented example in master.cf for a starting point. 
smtp auth should be offered only via the submission service, and not via 
mx service [port 25].  additionally, encryption should be required for 
submission traffic.


-ben

Re: smtpd optional authentication and relay

[btb]

On Jul 4, 2013, at 20.44, W T Riker wtriker@gmail.com wrote:

 On 7/4/2013 8:36 PM, Wietse Venema wrote:
 W T Riker:
 On 7/4/2013 8:01 PM, Wietse Venema wrote:
 gw1500:
 It is not clear from the documentation if this is possible or how to do
 it but I want to make authentication optional but if a user does
 authenticate then I want to permit relaying. Can someone help?
 This is how permit_sasl_authenticated works.
 
 http://www.postfix.org/SASL_README.html#server_sasl_authz
 Thanks for the reply. I already have that much working. Where I am stuck
 is permitting relaying from authenticated users regardless of host while
 prohibiting everything else.
 I answered the question how to make authentication optional.
 
 Perhaps someone else can figure out what you mean with permitting
 relaying from authenticated users while prohibiting everything else
 when only seconds ago you asked how to make authentication optional.
 
  Wietse
 
 Sorry that I was not clear. With this configuration, will any
 non-authenticated client still be able to deliver mail to a local
 recipient but not be permitted to relay email to non-local recipients?

i'd counsel against this.  instead, set up a proper submission service [see the 
commented out example in master.cf], and use separate streams for mx and 
submission.  presumably you're asking about providing relay service for 
client [e.g. mua] software.  clients should use submission [port 587], not port 
25.  port 25 is for servers to talk to other servers.  setting up separate 
streams/services allows you to require encryption and authentication for all 
connections [eg. clients] to the submission service, and allows you to avoid 
offering it unnecessarily on port 25.

-ben

Re: postfix+ejabberd

[btb]

On Jul 3, 2013, at 16.31, Dejan Doder dode...@gmail.com wrote:

 Hi group , 
 sorry because I have general question
 Did anyone have experience with integration posfix and ejabberd ?

integration how?  what is your goal?

Re: question about auth, smtpd and roundcube

[btb]

On Jun 21, 2013, at 03.50, Felix Rubio Dalmau felixrubiodal...@gmail.com 
wrote:

 Sorry for disturbing you, Ben
 
   Thank you for your answer, but there is one point I don't fully get: If 
 I 
 set up an smtp [25] to offer encryption without auth, a submission [587] to 
 require encryption and auth, and I want roundcube to access the mail server 
 with auth but without encryption I am stuck at the same point, right?
 
   Finally, I have configured smtp [25] to offer encryption, and auth only 
 under tls. I have also set up a submission [587] without encryption, 
 requiring 
 auth, for roundcube. Finally I have closed port 587 using iptables, so can be 
 used only through the loopback interface.

let's please keep the discussion on the list, so others may participate.

the key here is the I want roundcube to access the mail server with auth but 
without encryption.  why bother?  roundcube happily performs encryption just 
fine, it hurts nothing to do it, and it obviates the need for unnecessary 
special treatment.

you should not be offering auth on port 25, encryption or not.  we don't need 
to get into all of the corner cases or special use cases, but far and away, for 
the average environment, auth is for clients, and clients are to use port 
submission/587.  if you're using submission/587 for roundcube only [as you seem 
to indicate], then why go to all of the trouble to intentionally disable 
encryption when it works just fine?

-ben

Re: question about auth, smtpd and roundcube

[btb]

On 2013.06.20 04.51, Felix Rubio Dalmau wrote:

Hi all,

I have set up a postfix+dovecot+roundcube installation. Currently, I 
have
set up these smtpd parameters:

smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_discard_ehlo_keyword_address_maps = hash:/etc/postfix/discard_ehlo

inside discard_helo, I have set 127.0.0.1 starttls,silent-discard to
allow roundcube connecting without TLS.

With this setup, roundcoube can't connect because it is not on a TLS
connection. If I set up roundcube to use TLS and comment
smtpd_discard_ehlo_keyword_address_maps, everything goes fine.

The question is: how can I allow smtpd_tls_auth_only only on non-local
connections?


this is overcomplicated.  set up a proper submission service [587] which 
requires encryption and authentication.  configure smtp service [25] to 
offer [but not require] encryption and to not offer auth.  configure 
roundcube to use submission+encryption+smtp auth, just like any other 
mail client.


-ben

http://www.postfix.org/

[btb]

the postfix website seems to be acting unexpectedly.  http://www.postfix.org/ 
appears to have been replaced with what was previously 
http://www.postfix.org/documentation.html [and an old version?] rather than 
what [iirc] it used to be - http://www.postfix.org/start.html

i thought i'd mention it in case it was inadvertent.

-ben

Re: Odd trivial-rewrite complaint with postfix 2.10

[btb]

On 2013.04.22 13.35, Quanah Gibson-Mount wrote:

This started showing up sporadically in our logs after upgrading to
postfix 2.10:

Apr 22 14:42:50 zqa-061 postfix/trivial-rewrite[30487]: warning: do
not list domain zqa-061.eng.vmware.com in BOTH mydestination and
virtual_mailbox_domains

However, it is not listed in both:

zimbra@zqa-061:~$ postconf mydestination mydestination = localhost

zimbra@zqa-061:~$ postconf virtual_mailbox_domains
virtual_mailbox_domains = proxy:ldap:/opt/zimbra/conf/ldap-vmd.cf

Searching using the filter defined in ldap-vmd.cf:

zimbra@zqa-061:~$ ldapsearch -x -LLL -H
ldap://zqa-061.eng.vmware.com:389 -D
uid=zmpostfix,cn=appaccts,cn=zimbra -w test123
((zimbraDomainName=*)(zimbraDomainType=local)(zimbraMailStatus=enabled))
zimbraDomainName dn: dc=zqa-061,dc=eng,dc=vmware,dc=com
zimbraDomainName: zqa-061.eng.vmware.com

Clearly, localhost != zqa-061.eng.vmware.com


provide postconf -nf and postconf -Mf

-ben

Re: Another sanity check request

[btb]

On Apr 13, 2013, at 15.33, Russell Jones russ...@jonesmail.me wrote:

 Hi all,
 
 Upgrading mail server from Postfix 2.9 to 2.10. Could I get a quick sanity 
 check to ensure my (fairly simple) setup is sane with the new 
 smtpd_relay_restrictions? Thanks :-)
 
 smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
 reject_unauth_destination
 smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated 
 check_client_access hash:/etc/postfix/rbl_override reject_rbl_client 
 zen.spamhaus.org

really, neither of permit_mynetworks nor permit_sasl_authenticated belong in 
any global restrictions.  smtp auth [e.g sasl] is for submission clients, which 
should be using submission/587, and these days, i really just discourage use of 
permit_mynetworks altogether.

-ben

Re: Another sanity check request

[btb]

On Apr 13, 2013, at 15.48, Reindl Harald h.rei...@thelounge.net wrote:

 
 Am 13.04.2013 21:42, schrieb b...@bitrate.net:
 
 On Apr 13, 2013, at 15.33, Russell Jones russ...@jonesmail.me wrote:
 
 Hi all,
 
 Upgrading mail server from Postfix 2.9 to 2.10. Could I get a quick sanity 
 check to ensure my (fairly simple) setup is sane with the new 
 smtpd_relay_restrictions? Thanks :-)
 
 smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
 reject_unauth_destination
 smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated 
 check_client_access hash:/etc/postfix/rbl_override reject_rbl_client 
 zen.spamhaus.org
 
 really, neither of permit_mynetworks nor permit_sasl_authenticated belong in 
 any global restrictions.  
 smtp auth [e.g sasl] is for submission clients, which should be using 
 submission/587, and these days, 
 
 fine - in the real life you start not from scratch

in the real world, both [and more] things happen.

 have fun calling hundrets and thousands of users especially with broken
 clients like a iPhone and explain them what to do to change the port

perhaps, perhaps not.

 in a perfect world i would even close port 25 from the WAN because
 the MX is a dedicated spam-firewall, but as said above this world
 exists mostly only if you are a startup with no existing customers

huh?

 i really just discourage use of permit_mynetworks altogether
 
 if you are not stupid enough to add a /24 network there it is pretty fine
 you do not want to pass every internal server sending a system-message to
 check_recipient_access which may be a spam-filter

sorry, i have no idea what you're talking about.

Re: Another sanity check request

[btb]

On Apr 13, 2013, at 16.03, Russell Jones russ...@jonesmail.me wrote:

  really, neither of permit_mynetworks nor permit_sasl_authenticated belong 
  in any global restrictions.  
 smtp auth [e.g sasl] is for submission clients, which should be using 
 submission/587, and these days,
 
 
 This is contrary to what is in the docs as an example, however I have port 25 
 closed off in master.cf to prevent authentication anyway. 587 is the only 
 port I permit authenticated relaying against.

you offer no service whatsoever on port 25?  postfix is not listening on that 
port?  if that's truly the case, then, to be pedantic, you're running an msa, 
not an mta, in which case you could argue that is an exception to the rule, and 
such global settings wouldn't necessarily be discouraged.

 smtpd -o smtpd_sasl_auth_enable=no

i'm confused.  if you are still listening on port 25, and have set an override 
in master.cf to disable sasl, then there is no reason for including the 
aforementioned restrictions in the global restrictions anyway.  by leaving them 
in there, all you're doing is unnecessarily increasing the risk, should 
somehow, for some unexpected reason, sasl be enabled [yes, stranger things have 
happened, even to reasonably responsible admins].  also, i'd note that from a 
security perspective, that approach is backwards.  globally, 
smtpd_sasl_auth_enable should be off, and only enabled for the specific 
services in master.cf which require it.

-ben

Re: Another sanity check request

[btb]

On Apr 13, 2013, at 16.40, Reindl Harald h.rei...@thelounge.net wrote:
 
 that your discourage use of permit_mynetworks is far from reality as
 also do not use SASAL and submission on port 25 as well if someone
 asks for ANOTHER sanity check after upgrade to a new version?

i'm not sure why it seems to be so hard for you to differentiate between 
suggestions as to what would be good to do and what may or may not be easy or 
hard, given a particular set of circumstances.  reality takes care of itself. 
 do we really need to attach reality disclaimers every time someone makes a 
suggestion that someone, somewhere, might consider impractical to implement?  
let's please focus on more useful discussion.

-ben

Re: Another sanity check request

[btb]

On Apr 13, 2013, at 17.10, Russell Jones russ...@jonesmail.me wrote:

 
 On 4/13/2013 3:44 PM, b...@bitrate.net wrote:
 you offer no service whatsoever on port 25?  postfix is not listening on 
 that port?  if that's truly the case, then, to be pedantic, you're running 
 an msa, not an mta, in which case you could argue that is an exception to 
 the rule, and such global settings wouldn't necessarily be discouraged.
 
 I do and I am offering SASL services, let me clarify. It might be useful if I 
 just include what the line looks like. This isn't what I was asking about in 
 my original email, and has been working fine for quite some time, but just 
 for clarification on this subject for others reading here's the config:
 
 1.2.3.4:smtpinetn   -   n   -   - smtpd -o 
 smtpd_sasl_auth_enable=no -o smtpd_tls_key_file=/etc/postfix/mail.key -o 
 smtpd_tls_cert_file=/etc/postfix/mail.crt -o myhostname=mail.server.com
 1.2.3.4:submission inet n   -   n   -   - smtpd -o 
 smtpd_sasl_auth_enable=yes -o smtpd_tls_key_file=/etc/postfix/mail.key -o 
 smtpd_tls_cert_file=/etc/postfix/mail.crt -o myhostname=mail.server.com

this does offer clarity, yes.  in the context of my comments, as long as you do 
not set smtpd_sasl_auth_enable in main.cf, it's not strictly necessary to set 
smtpd_sasl_auth_enable=no for the smtp service.  the compiled in default will 
be used.  that said, it's not really hurting anything, and could be argued to 
be an extra layer of security, lest something weird happen [but let's please 
not debate that].

 I want only servers talking to port 25, not clients. Hence why I do not 
 permit authentication against the smtp port, only the submission port. Then, 
 in the smtpd_relay_restrictions, I permit authenticated clients to relay.
 
 
  globally, smtpd_sasl_auth_enable should be off, and only enabled for the 
  specific services in master.cf which require it.
 
 It is.
 
 
  really, neither of permit_mynetworks nor permit_sasl_authenticated belong 
  in any global restrictions.
 
 Still confused as to why permit_sasl_authenticated shouldn't be in the 
 smtpd_relay/recipient_restrictions section. Is there a better place to define 
 smtpd_relay/recipients configuration instead of main.cf?

in my opinion, the better place is in master.cf, for only the desired service 
[e.g. submission].  to go a step further, cases like this can make good use of 
restriction classes, so you can keep the majority of settings and activity in 
main.cf - e.g.:

main.cf:
smtpd_restriction_classes =
base_recipient_restrictions,
submission_recipient_restrictions

base_recipient_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unauth_pipelining

submission_recipient_restrictions =
base_recipient_restrictions,
permit_sasl_authenticated,
reject

master.cf:
submission inet n   -   n   -   - smtpd
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=submission_recipient_restrictions
-o smtpd_tls_key_file=/etc/postfix/mail.key
-o smtpd_tls_cert_file=/etc/postfix/mail.crt
-o smtpd_tls_security_level=encrypt
-o myhostname=mail.server.com

refer to the documentation and examples for more specifics on the submission 
service, especially the other example overrides.

-ben

Re: Setting up secure submission for remote users

[btb]

On 2013.04.12 07.01, LuKreme wrote:

In our previous episode (Thursday, 11-Apr-2013), b...@bitrate.net
said:

you can certainly upgrade without breaking everything.  as with
anything else, it just takes some care and consideration.  as far
as procmail goes, i'd consider losing procmail to be a benefit.
why do you think you need it?


Because I use it extensively.


that's a foregone conclusion.  the question is for what do you use it.  in the 
vast majority of cases, sieve can do everything procmail can do.  if you were 
to switch from courier to dovecot for imap, delivery via lmtp from postfix to 
dovecot offers a number of benefits, only one of which is easy integration of 
sieve.

-ben

Re: SMTPS 465

[btb]

On Apr 12, 2013, at 15.25, Joan Moreau j...@grosjo.net wrote:

 Hi,
 
 I am stuck with making my SSL SMTPS (port 465) works, while it was working 
 fine since ever.

others have helped with the specifics of your question, so i'll address the 
philosophical aspect of it :) .  while it may take some coordination to do so 
if you have an existing user base using smtps, you should be using 
submission+starttls instead.  smtps is a long since deprecated, never 
standardized protocol, which now misappropriates a port which has been formally 
assigned by iana to another protocol, for quite some time.

-ben

Re: Setting up secure submission for remote users

[btb]

On Apr 11, 2013, at 20.11, LuKreme krem...@kreme.com wrote:

 Reindl Harald opined on Thursday 11-Apr-2013@16:58:28
 mynetworks should be genrally used with care and only for specific
 address instead whole networks with sooner or later potentially
 infected clients which can be banned if using auth even if the
 malware leaks auth data and abuse it from outside
 
 Mynetworks currently contains the mail server, the webmail server, and my 
 home fixed IP since I do not have secure submission working as of now.

i would very strongly encourage you to get a properly configured submission 
service up and running.  it's really not terribly difficult, and there's just 
no reason for a webmail server nor whatever email programs you use at home to 
not be authenticating.  in all honesty, i'm a proponent of doing away with 
mynetworks entirely, and if truly necessary, using check_client_access instead.

 I’m reading up on dovecot-1.2.17 and dovecot-2.1.16 and trying to decide if I 
 can switch to either of those without breaking everything. One item of 
 concern was reading a comment that “postfix hands the mail off to dovecot for 
 local delivery” which makes me think I will lose procmail as my LDA. That 
 would be bad.

you can certainly upgrade without breaking everything.  as with anything else, 
it just takes some care and consideration.  as far as procmail goes, i'd 
consider losing procmail to be a benefit.  why do you think you need it?

 I’m also wondering if I can set dovecot up to only work with port 587 and 
 keep cyrus-sasl for port 993, at least for now. I know it seems redundant, 
 and it would be a stepping stone to ensure that current users are able to 
 connect as they do now. (IMAP-SSL with “Password” for either local users or 
 mysql users).


does this mean that you want to use dovecot sasl with postfix, for submission, 
and cyrus sasl with your imap software?  it's certainly possible, but i 
question the actual benefit.

-ben

Re: Setting up virtual domains correctly

[btb]

On Apr 9, 2013, at 19.56, Quanah Gibson-Mount qua...@zimbra.com wrote:

 I'm trying to fix my virtual domain configuration with postfix, which as 
 noted in a prior discussion was done incorrectly by some unknown to me person 
 in the past.
 
 The main issue right now is that it has:
 
 virtual_transport = error
 
 which I was told makes little sense, so I'm trying to correct our 
 configuration.
 
 First, all of our data is stored in LDAP (domains, users, etc).  For my test 
 setup, the real domain is zre-ldap002.eng.vmware.com.  I've created a 
 virtual (alias) domain example.com.
 
 With my default configuration, if I send mail to u...@example.com AND the 
 user exists as u...@zre-ldap002.eng.vmware.com, mail delivery occurs.

likely, the reason this works is because virtual_transport is never being 
used, if actual delivery for every recipient is passed off somewhere else via 
lmtp as you seem to perhaps indicate below.

 postmap on my base transport works for this:
 zimbra@zre-ldap002:~$ postmap -q u...@zre-ldap002.eng.vmware.com 
 ldap:/opt/zimbra/conf/ldap-transport.cf
 lmtp:zre-ldap002.eng.vmware.com:7025

please supply postconf -nf and postconf -Mf, or if an older version, postconf 
-n and master.cf with comments removed.

what is lmtp:zre-ldap002.eng.vmware.com:7025?  if you're not actually doing 
delivery with the postfix virtual(8) lda, i'd suggest that using virtual at all 
doesn't really make much sense.  instead, consider using the relay domain class.

also, based solely on the attribute names, it's not quite clear to me what 
exactly is supposed to happen with various scenarios.  that being said, using 
catchalls is rarely if ever a good idea.  they will be abused, and at the very 
least, problematic.

Re: Running namecache service on postfix server?

[btb]

On Feb 26, 2013, at 11.51, Viktor Dukhovni postfix-us...@dukhovni.org wrote:

 On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote:
 
 I have recently updated my DNS server and am observing the traffic
 from my mail server to constantly query for names.  Some of these
 names are frequent requests, for example: zen.spamhaus.org.  So I
 was thinking that I could benefit from running a namecaching setup
 on my mail server platform.  This would cut down on traffic and time
 on my mail server.
 
 Is this a practice that is common?  Are there any downsizes to doing this?
 
 When Postfix support for DANE (RFC 6698) is introduced, there will
 be a requirement to operate a local nameserver that is DNSSEC aware
 on any machine that wants to take advantage of peer certificate details
 published via DNSSEC to scalably deliver verified TLS email to many
 sites without the overhead of local per-site configuration.

why must the nameserver be local?  i gather the point is to be able to trust 
the dns responses, which of course goes without saying - but there are methods 
for accomplishing this in scenarios with a non local nameserver, aren't there?  
i think rfc 6698 speaks to this briefly?

-ben

Re: Testing out SMTPS

[btb]

On 2013.02.04 13.27, Robert Moskowitz wrote:

http://www.emailsecuritygrader.com


as with most helpful websites like this, this one is perpetuating 
misinformation.  smtps has long since been deprecated, having been 
superseded by starttls.  it also would appear to perpetuate the behavior 
of offering submission service via port 25, which is largely discouraged.



And from there I became aware that I probably don't have SMTPS (port
465) configured properly.


with reference to the above, instead, configure a proper 
submission+starttls service [port 587].  there is an example included in 
the master.cf config file which comes with postfix.


these days, new implementation of smtps should be restricted to existing 
environments in which smtps is already in use by clients.  even then, it 
really should be used only until clients have been converted to use 
proper submission+starttls.


And tried to telnet into localhost 465.

telnet is not suitable for testing things which employ this sort of 
encryption. instead, use something like openssl s_client or gnutls-cli



The one pointer I have found so far on telneting into 465 shows that I
should have also gotten a:

220   ESMTP Postfix

sending a 'ehlo' results in the connection closing.


this is misinformation.  with smtps, encryption must be established 
before any smtp related dialog can occur.  telnet does not do this sort 
of encryption.


-ben

Re: Dovecot LDA - Active Directory userbase

[btb]

On Jan 30, 2013, at 09.34, Peter von Nostrand wrote:

 dovecot unix - n n - - pipe
  flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/dovecot-lda -f
 ${sender} -d ${recipient}

i'd encourage you to consider delivering to dovecot via lmtp[1] rather than 
pipe, and thus to consider using the relay domain class[2] instead of virtual.  
doing this has been beneficial for me in terms of logic and postfix 
concepts/terminology. additionally, there are often performance benefits as 
well.

[1] http://wiki2.dovecot.org/LMTP
[2] http://www.postfix.org/ADDRESS_CLASS_README.html

-ben

Re: Sufficiently locked down?

[btb]

On Jan 24, 2013, at 22.57, Stan Hoeppner wrote:

 commendably, he is at least making an attempt to properly use submission 
 [which, btw, is far from useless and has nothing to do with the route a 
 packet might take].
 
 The primary features of the submission service are TLS encryption and
 authentication.

the primary feature of the submission service is to provide different ports for 
servers and clients, so that the appropriate policy can be applied to each, 
independently.  these policies are quite obviously completely subjective, and 
may or may not include smtp auth [and thus with it, encryption].  the 
submission protocol defines a port for clients to use, period.  it does not say 
use port 587, unless you are talking to localhost, in which case use port 25.

 Even the user logging of submission is useless, as it's a single user box.


hmm, not sure where you got this idea.  there have been no such statements from 
the op.

-ben

Re: Sufficiently locked down?

[btb]

On Jan 25, 2013, at 13.29, Stan Hoeppner wrote:

 On 1/25/2013 10:18 AM, b...@bitrate.net wrote:
 On Jan 24, 2013, at 22.57, Stan Hoeppner wrote:
 
 The primary features of the submission service are TLS encryption and
 authentication.
 
 the primary feature of the submission service is to provide different ports 
 for servers and clients, 
 
 You might want to read this before repeating your statement above:
 
 http://www.engardelinux.org/modules/index/list_archives.cgi?list=postfix-userspage=0425.htmlmonth=2012-03


the sample configuration postfix offers does not define the submission 
protocol.  rather, it emphasizes my point that it is a personal choice.

at this point, this thread has become non beneficial to the op, and should be 
suspended until he returns with the additional requested data.

-ben

Re: Upgrade for Postfix Mailman

[btb]

On Jan 25, 2013, at 15.07, Jeff Bernier wrote:

 Hello All,
 
 I am currently running Mailman (2.1.14) and Postfix (2.4.3) on an aging Mac
 OS X server (10.5.8). Mailman and Postfix on this system are Apple's
 implementation on their platform of course. Apple no longer supports the
 Xserve platform, and I am in need of replacing this system, and upgrading
 to newer versions of Postfix and Mailman.

you may already know this, but do note that while the xserve and mac os x 
server have gone away, the underlying components themselves [apple and 
otherwise] have not, and are now just hidden away within regular mac os x.  
apple sells software that you add to your standard install to provide the apple 
management mechanisms as were found in os x server.  of course, this means that 
an xserve is not needed either, since it runs just fine on any mac.

that being said, *do not* misinterpret this information as a suggestion or 
encouragement that you do this - it is intended only as information, for the 
sake of it.  quite to the contrary, if i were to offer encouragement, it would 
be to move away from apple products for this sort of thing, but not because the 
platform has changed.

 We use Postfix for our on campus SMTP Gateway, and Mailman for a small
 number of active lists. The traffic is light.
 
 Can anyone recommend a good replacement to this? Recommended Unix/Linux?

whatever os you prefer is likely perfectly fine.  i'd encourage you to use an 
operating system you're comfortable with rather than a particular os just for 
the sake of postfix.  what's more important is that you run reasonably current 
versions of the software - this may or may not mean using the version available 
in the operating system's software repositories.

 Is a VM environment an option?

in a nutshell - certainly, of course.  many people routinely run mail servers 
on virtual guests.  degree of utilization can always become a factor, be it a 
virtual guest or otherwise, but even moderately high loads can be quite 
efficiently accommodated by a competent admin.

-ben

Re: Sufficiently locked down?

[btb]

On Jan 24, 2013, at 01.08, Stan Hoeppner wrote:

 On 1/23/2013 2:23 PM, Grant wrote:
 I thought my postfix setup was configured to send mail on port 587 and
 receive mail on port 25, so I was surprised to find that I could send
 mail from the local machine on port 25.  Is my config OK?
 
 Postfix never sends mail *from* TCP 25 or TCP 587.  These are receive
 ports.  Outbound connections occur on high ports.  You're not properly
 describing your use case, actually not at all.  Would you please?
 
 You're right, I didn't word that correctly.  I thought mail received
 on port 25 could only be delivered locally with my config, but I was
 able to send mail to any destination via port 25.  The mail client and
 mail server are on the same machine.
 
 You haven't identified a problem Grant. 

it seems quite clear to me the behavior he is attempting to understand/correct. 
 commendably, he is at least making an attempt to properly use submission 
[which, btw, is far from useless and has nothing to do with the route a 
packet might take].

grant - please show master.cf with comments removed.

general comments regarding your current postconf -n output:

you likely have a number of redundant settings in main.cf.  something like 
(postconf -d; postconf -n) | sort | uniq -d can be helpful in identifying these 
unnecessary main.cf entries and simplifying your config.  also, a 
message_size_limit of 40mb is rather large.  i'd encourage you to reduce that.  
lastly, i'd strongly encourage enforcing some additional basic 
smtpd_recipient_restrictions - e.g.

smtpd_recipient_restrictions =
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_non_fqdn_recipient
reject_unauth_destination
permit

note that permit is not strictly necessary, but isn't necessarily a bad idea 
either, imo.

in addition, you probably ought to employ some basic antispam restrictions.  
things like

reject_unknown_client_hostname
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname

as well as some basic rbl checks [not to mention postscreen] are worth 
consideration.

do note that some of those restrictions may be more prone to collateral damage 
[perhaps most notably helo related restrictions], so you might consider testing 
these with warn_if_reject first.

lastly, don't miss the warning postconf printed regarding 
smtpd_relay_restrictions

-ben

Re: main.cf: How to remove mynetworks?

[btb]

On Oct 28, 2012, at 12.47, thorso...@lavabit.com wrote:

 Hi,
 
 I don't want to send emails directly from my server. (I'm going to
 connect from a client.)
 
 I have the following settings in main.cf:
 
 mynetworks = 127.0.0.0/8
 smtpd_recipient_restrictions =
 permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination
 
 I guess that I should remove permit_mynetworks, but what about
 mynetworks? Should I remove that line or it will be enough to use
 the following?
 
 mynetworks =

i'm a fan of not using mynetworks as well, and prefer to use 
check_client_access for what mynetworks was traditionally used to accomplish.  
to be thorough, you'd do both.  do keep in mind though that there are a number 
of other parameters whose defaults reference mynetworks or permit_mynetworks.  
this doesn't mean it can't be done, and it works fine for me, but you just need 
to be aware that other adjustments may be necessary as well, depending on the 
particulars of your setup.

-ben