Re: How to block incoming emails with ZIP attachments containing EXE
On 19 Apr 2013 18:47, "Andreas Freyvogel" wrote: > > Hi All, > > I'm not sure if this is the correct group to ask so apologies if it's not. > > I wanted to ask if anyone has a good way of sending emails that have ZIP > attachments that contain EXE files to QUARANTINE. I am using POSTFIX sending > to PROCMAIL and CLAMAV. I've looked into procmail recipies and clamav > options but nothing seems to work well for me. > > Thank you in advance for any assistance. You need a content filter like amavisd Simon
Re: need advice
On 1 Apr 2013 18:16, "Patrick Lists" wrote: > > On 04/01/2013 04:59 PM, Muhammad Yousuf Khan wrote: >> >> so what you please have to suggest. >> and obviously no option of third party like google calender etc. >> we are looking for some centralized solution > > > In addition to the previous suggestions you can also check out Zarafa and Open-Xchange. In addition to all the other options you've been given.com horde.orgsupports ActiveSync and synchronises mail, calendar, address books and tasks/notes. Simon
Re: TLS Question, untrusted connection
On 26 March 2013 10:53, Marko Weber | ZBF wrote: > > > Am 2013-03-26 10:30, schrieb Reindl Harald: >> >> Am 26.03.2013 09:44, schrieb Marko Weber|ZBF: >>> >>> Mar 25 14:04:35 mail postfix/smtpd[31103]: Untrusted TLS connection >>> established from >>> loninmrp15.uk.db.com[160.83.44.131]: TLSv1 with cipher DHE-RSA-AES256-SHA >>> (256/256 bits) >>> >>> why is on incoming mails the TLS connection untrusted? >> >> >> http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57760.html > > > Hi Harald, > u seen that "outgoing" mails do "verified TLS connection?" > > i ask myself why the connection ist "UNTRUSTED" when this client sends to me > the connection is not "trusted" ? > > i use a valid thawte cert on my postfix server. > > i also set in smtpd_sender_restrictions that the client has to use TLS ... > "reject_plaintext_session", > when he delivers mails to me. > > on test from another machine, the TLS connection was also trusted. this > shows me that my certs on postfix server are valid and working. When you connect to the deutsche bank server, your server is telling you that the connection is with the deutsche bank server. i.e. Trusted When the deutsche bank server connects to your server your server is telling you there is a connection from someone claiming to be deutsche bank. i.e. not trusted. Unless you can either give the deutsche bank server a key with which to identify themselves (and persuade them to use it), this will always be the case. Simon
Re: fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup problem
On 5 Mar 2013 19:07, "Wietse Venema" wrote: > > Simon Brereton: > > Mar 5 08:45:14 mail postfix/proxymap[24831]: warning: mysql query > > failed: MySQL server has gone away > > The mysql server closed the connection (or crashed). > > > Mar 5 10:53:22 mail postfix/proxymap[26043]: warning: connect to > > mysql server localhost: Can't connect to local MySQL server through > > socket '/var/run/mysqld/mysqld.sock' (2) > > The mysql did not accept connections (probably was not running). > Thanks Wietse - I'll continue looking for a cause elsewhere.. Simon
Re: fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup problem
On 5 March 2013 16:47, Wietse Venema wrote: > Simon Brereton: >> Hi >> >> After years of a smoothly running mail server, my logs are starting to >> fill with this error message: >> fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table >> lookup problem > > I would expcet to see some warning before an uninformative "fatal" message. > BTW the "(0,lock|fold_fix)" are Postfix-internal flags. It does not mean > that there is a problem locking mysql. the lock would be used with > files such as Berkeley DB. > > Wietse Yes, I suppose there would be! I found two different types. Mar 5 08:45:12 mail postfix/smtpd[24830]: connect from unknown[117.6.222.107] Mar 5 08:45:14 mail postfix/proxymap[24831]: warning: mysql query failed: MySQL server has gone away Mar 5 08:45:14 mail postfix/trivial-rewrite[24833]: fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup problem Mar 5 08:45:15 mail postfix/master[4283]: warning: process /usr/lib/postfix/trivial-rewrite pid 24833 exit status 1 Mar 5 08:45:16 mail postfix/trivial-rewrite[24854]: fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup problem Mar 5 08:45:17 mail postfix/smtpd[24830]: warning: problem talking to service rewrite: Success Mar 5 08:45:17 mail postfix/master[4283]: warning: process /usr/lib/postfix/trivial-rewrite pid 24854 exit status 1 Mar 5 08:45:17 mail postfix/master[4283]: warning: /usr/lib/postfix/trivial-rewrite: bad command startup -- throttling and Mar 5 10:53:21 mail postfix/smtpd[29350]: connect from unknown[81.213.239.67] Mar 5 10:53:22 mail postfix/proxymap[26043]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Mar 5 10:53:22 mail postfix/trivial-rewrite[26046]: fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup problem Mar 5 10:53:23 mail postfix/master[4283]: warning: process /usr/lib/postfix/trivial-rewrite pid 26046 exit status 1 Mar 5 10:53:24 mail postfix/trivial-rewrite[29357]: fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup problem Mar 5 10:53:25 mail postfix/smtpd[29350]: warning: problem talking to service rewrite: Success Mar 5 10:53:25 mail postfix/master[4283]: warning: process /usr/lib/postfix/trivial-rewrite pid 29357 exit status 1 Mar 5 10:53:25 mail postfix/master[4283]: warning: /usr/lib/postfix/trivial-rewrite: bad command startup -- throttling mysqld.sock does exist.. mail:~# ls /var/run/mysqld/mysqld.sock srwxrwxrwx 1 mysql mysql 0 Mar 5 12:14 /var/run/mysqld/mysqld.sock I rebooted the box and until now I haven't had a repeat of the error. I suppose it's just possible that after ~500 days uptime a reset was needed, but I'm always wary when problems like this suddenly appear. There isn't a heavy load, and so I tend to regard symptoms like this as highly suspicious. As per my initial email, I don't think postfix caused this in anyway, but of course it felt the force of it. I wonder now I can increase the redundancy. Simon
fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup problem
Hi
After years of a smoothly running mail server, my logs are starting to
fill with this error message:
fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table
lookup problem
I haven't updated anything or changed any configs (in either mysql or
postfix) so I'd appreciate some hints as to how to track this down?
According to mysql postfix is behaving properly (as you'd expect).
+--+-+---+---+-+--+---+--+
| Id | User| Host | db| Command | Time | State | Info |
+--+-+---+---+-+--+---+--+
| 379 | postfix | localhost | Mail | Sleep | 25 | | NULL
|
So I'm not sure why it thinks there is a lock. I found one stub that
suggested this happened with the mysql.sock was not in the chroot
jail. But as I said, it's been running flawlessly for years, so I
don't forsee that as the issue.
Nevertheless, here's my postconf -n
access_map_reject_code = 550
alias_database = hash:/etc/postfix/aliases
alias_maps = $alias_database
allow_untrusted_routing = no
append_dot_mydomain = no
biff = no
body_checks_size_limit = 51200
bounce_size_limit = 5
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
debug_peer_level = 1
default_destination_concurrency_limit = 25
disable_vrfy_command = yes
fast_flush_domains = $relay_domains
header_checks = regexp:/etc/postfix/header_checks
header_size_limit = 102400
home_mailbox = Maildir/
inet_interfaces = all
invalid_hostname_reject_code = 501
local_destination_concurrency_limit = 2
local_recipient_maps = proxy:unix:passwd.byname $virtual_alias_maps $alias_maps
mail_spool_directory = /var/spool/mail
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 512000
message_size_limit = 2048
mydestination =
mydomain = perlphreak.net
myhostname = mail.perphreak.net
mynetworks = 127.0.0.0/8
mynetworks_style = host
myorigin = $mydomain
recipient_delimiter = -
reject_code = 550
relay_domains = /etc/postfix/mxbackups
relay_domains_reject_code = 550
relayhost =
smtp_tls_CAfile = /etc/ssl/keys/perlphreak-ca.crt
smtp_tls_cert_file = /etc/ssl/keys/mail.perlphreak.net.crt
smtp_tls_key_file = /etc/ssl/private/mail.perlphreak.net.key
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
smtp_tls_session_cache_timeout = 3600s
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) (Debian/GNU)
smtpd_data_restrictions = sleep 1, reject_unauth_pipelining, permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_recipient_limit = 250
smtpd_recipient_restrictions = reject_non_fqdn_sender,
reject_non_fqdn_recipient,permit_sasl_authenticated,
reject_sender_login_mismatch,
reject_authenticated_sender_login_mismatch, check_helo_access
hash:/etc/postfix/helo_checks,reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname,
reject_unknown_sender_domain, reject_unknown_recipient_domain,
permit_mynetworks, reject_unauth_destination,
reject_unlisted_recipient, check_recipient_access
mysql:/etc/postfix/Mail-Disabled.cf, check_helo_access
hash:/etc/postfix/helo_checks,check_recipient_access
hash:/etc/postfix/laxdomains,check_client_access
hash:/etc/postfix/ip_whitelist, check_sender_access
hash:/etc/postfix/backscatter
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
check_policy_service unix:private/policy-spf, check_policy_service
inet:127.0.0.1:10031, reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = perlphreak.net
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sasl_type = dovecot
smtpd_timeout = 300s
smtpd_tls_CAfile = /etc/ssl/keys/perlphreak-ca.crt
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/ssl/keys/mail.perlphreak.net.crt
smtpd_tls_key_file = /etc/ssl/private/mail.perlphreak.net.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 554
virtual_alias_maps = hash:/etc/postfix/virtual_user_aliases,
proxy:mysql:/etc/postfix/mailalias.cf
virtual_gid_maps = static:115
virtual_mailbox_base = /var/spool/mail/virtual
virtual_mailbox_domains = proxy:mysql:/etc/postfix/maildomain.cf
virtual_mailbox_limit = 50
virtual_mailbox_limit_inbox = no
virtual_mai
Re: Lost connection
On 27 February 2013 13:16, Reindl Harald wrote: > > > Am 27.02.2013 13:14, schrieb Muzaffer Tolga Özses: >> >> On 02/27/2013 02:04 PM, Wietse Venema wrote: >>> egrep '(warning|error|fatal|panic): >> >> Unfortunately, all I get was these and similar, and the most recent one is >> from 2 days ago. >> >> egrep '(warning|error|fatal|panic):' /var/log/mail.log | head >> Feb 25 01:56:26 server postfix/smtpd[10324]: warning: >> s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN >> authentication failed: UGFzc3dvcmQ6 >> Feb 25 01:56:28 server postfix/smtpd[10353]: warning: >> s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN >> authentication failed: UGFzc3dvcmQ6 > > well, is 213.165.85.151 the IP of a customer? > has someone troubles? > > if not - ignore it because it's mostly some bad guy trying > tu misuse your machine and looking at the short interval > it seems that it is the case > UGFzc3dvcmQ6 is the hash for password. I have hundred of attempts like this on a daily basis. But as Wietse will point out, this is not his problem. Simon
Re: How useful are header & body checks when used along side Amavis?
On Dec 29, 2012 8:58 AM, "John Allen" wrote: > > My setup is Postfix (2.9.3) + Postgrey + Amavis-new + Dovecot(2.1.7) running on Debian(Wheezy)/Ubuntu(12.04) servers. > I have always assumed that header/body checks were worthwhile because they would catch some mal-mail early and thus reduce the overall cost of processing. > How useful are header & body checks when used along side Amavis? Are they still worthwhile? The 8-10% of mails rejected by my header check for my own IPs or domain names as ehlo alone are probably worth it. The less amavis has to do, the better. Simon
Re: postconf expansion
On Dec 21, 2012 6:13 PM, "Viktor Dukhovni" wrote: > > On Fri, Dec 21, 2012 at 03:10:11PM -0500, Wietse Venema wrote: > > > Viktor Dukhovni: > > > I've not looked too closely at what it would take for "postconf" > > > to be able to perform fully recursive parameter expansion. It is > > > apparently a bit tricky (from past conversations with Wietse). It > > > would be useful however. > > > > I restructured the postconf code 12 months ago, to add support for > > "unknown parameter" warnings, service-dependent parameter names > > (foo_destination_concurrency_limit etc.), and master.cf. > > > > Thanks to this, it is no longer a problem to add support for parameter > > expansion. I'll have a fully-working version by the end of the day. > > Happy new year to you too! Thanks for the holiday present. > > It'll make life easier to tell people to report: For "people" archive viewers should read "people like me" Thanks Wietse! Simon > $ postconf -q u...@example.com $(postconf -Rh virtual_alias_maps|tr ',' ' ') > > (and similar recipes) than to have to explain the details in a series > of posts... > > -- > Viktor.
Re: delivering mail to separate users
On 20 December 2012 12:44, Viktor Dukhovni wrote: > On Thu, Dec 20, 2012 at 12:25:03PM -0500, Simon Brereton wrote: > >> >> I did postmap the virtual_alias_maps. Is there something else I should I >> >> do? >> > >> > No, but you've likely misconfigured other elements of the system. >> >> I think this is ok. Output is: >> mail:/etc/postfix# postconf -h virtual_alias_maps >> proxy:mysql:/etc/postfix/Mail-Alias.cf, >> hash:/etc/postfix/virtual_user_aliases > > So you have two tables mysql and a hash table. > >> > $ postmap -fq newu...@example.com $maps > > After setting "maps" to the exact list tables you configured. > > $ postmap -fq newu...@example.com \ > mysql:/etc/postfix/Mail-Alias.cf \ > hash:/etc/postfix/virtual_user_aliases > > You almost certainly have an entry for "newu...@example.com" > in the mysql table that hides any data in the hash table. Perhaps > you should list the hash table first, if you want it to take > precedence over mysql. With postfix it's always the simple solution. I should have seen that. Reversing the order works now - and is in fact the more correct approach. Thanks! Dec 20 18:17:49 mail dovecot: deliver(direc...@example.org): msgid=<20121220131743.horde.1yqsdfyznp9q01zhfab0...@webmail.example.org>: postmas...@example.org: saved mail to INBOX Dec 20 18:17:49 mail postfix/pipe[31973]: 777B5DC6001: to=, relay=dovecot, delay=1, delays=1/0/0/0.01, dsn=2.0.0, status=sent (delivered via dovecot service) Dec 20 18:17:49 mail dovecot: deliver(newu...@example.org): msgid=<20121220131743.horde.1yqsdfyznp9q01zhfab0...@webmail.example.org>: postmas...@example.org: saved mail to INBOX Dec 20 18:17:49 mail postfix/pipe[31974]: 777B5DC6001: to=, relay=dovecot, delay=1, delays=1/0.01/0/0.02, dsn=2.0.0, status=sent (delivered via dovecot service) Dec 20 18:17:49 mail dovecot: deliver(direc...@example.org): msgid=<20121220131743.horde.1yqsdfyznp9q01zhfab0...@webmail.example.org>: postmas...@example.org: saved mail to INBOX Dec 20 18:17:49 mail postfix/pipe[31976]: 777B5DC6001: to=, orig_to=, relay=dovecot, delay=1, delays=1/0.01/0/0.01, dsn=2.0.0, status=sent (delivered via dovecot service) Dec 20 18:17:49 mail postfix/qmgr[31903]: 777B5DC6001: removed >> > >> > To check that the result of the expansion of the user via >> > $virtual_alias_maps. >> >> Here I ran into problems. >> mail:/etc/postfix# postmap -fq newu...@example.org $maps >> postmap: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key] >> [-q key] [map_type:]file... >> postfix/postmap[31144]: fatal: usage: postmap [-Nfinoprsvw] [-c >> config_dir] [-d key] [-q key] [map_type:]file... > > I'm disappointed you could not then figure it out by reading the manpage, > or parsing the "usage:" message. > > postmap -q key map [optionally more maps] That disappointment is hard to bear, but not unexpected sadly. I've had another look and I still don't get it. Except that $maps can't be expanded by the shell. I feel sure there should be a way to check not just a single file (as I did), but the actual entry from main.cf - but I'm not able to find it. Sorry. Simon
Re: delivering mail to separate users
On 20 December 2012 08:07, Viktor Dukhovni wrote:
> On Thu, Dec 20, 2012 at 12:24:30AM -0500, Simon Brereton wrote:
>
>> >> newu...@example.org direc...@example.org, newu...@example.org
>> >>
>> >> But it occurs to me that this will create a loop - no?
>> >
>> > No, there is no loop, virtual alias expansion eliminates exactly
>> > this kind of loop and delivers email to the leaf address and
>> > to its peers.
>>
>> When I do this mail is only delivered to newu...@example.org and not
>> direc...@example.org as well.
>>
>> I did postmap the virtual_alias_maps. Is there something else I should I do?
>
> No, but you've likely misconfigured other elements of the system.
>
> To test the table contents:
>
> 1. postconf -h virtual_alias_maps
>
> If this contains no unexpanded ${variable} references, just set
>
> maps=$(postconf -h virtual_alias_maps)
>
> Otherwise, figure out what the variables expand to and set
>
> maps="type1:table1 type2:table2 ..."
>
> for all the maps in resulting from the expansion.
I think this is ok. Output is:
mail:/etc/postfix# postconf -h virtual_alias_maps
proxy:mysql:/etc/postfix/Mail-Alias.cf, hash:/etc/postfix/virtual_user_aliases
> 2. Run:
>
> $ postmap -fq newu...@example.com $maps
>
> To check that the result of the expansion of the user via
> $virtual_alias_maps.
Here I ran into problems.
mail:/etc/postfix# postmap -fq newu...@example.org $maps
postmap: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key]
[-q key] [map_type:]file...
postfix/postmap[31144]: fatal: usage: postmap [-Nfinoprsvw] [-c
config_dir] [-d key] [-q key] [map_type:]file...
mail:/etc/postfix#
mail:/etc/postfix# postmap -fq newu...@example.org virtual_alias_maps
postmap: fatal: open database virtual_alias_maps.db: No such file or directory
postfix/postmap[31146]: fatal: open database virtual_alias_maps.db:
No such file or directory
But it pays to read the error messages, so...
mail:/etc/postfix# postmap -fq newu...@example.org virtual_user_aliases
direc...@example.org,newu...@example.org
Which looks good to me.
> 3. Make sure you have not disabled virtual_alias_maps expansion via:
>
> receive_override_options=no_address_mappings
I'm pretty sure this isn't disabled because a different virtual_alias
in the file works (maps to one local domain and one external one).
> 4. Check your logs (http://www.postfix.org/DEBUG_README.html#mail)
>you'll see how many recipients each message expands to, from
>what original addresses, and how each recipient was or failed to be
>delivered.
I did check the logs, which is how I know it wasn't delivered to both users :)
Here's the (sanitized) log out put from a test from the postmaster
account to the newuser.
Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: connect from
localhost[127.0.0.1]
Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: setting up TLS
connection from localhost[127.0.0.1]
Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: Anonymous TLS
connection established from localhost[127.0.0.1]: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits)
Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: 0F96ADC6001:
client=localhost[127.0.0.1], sasl_method=LOGIN,
sasl_username=postmas...@example.org
Dec 20 17:16:32 mail postfix/cleanup[31208]: 0F96ADC6001:
message-id=<20121220121630.horde.zri5flyznp9q00fu59ec...@webmail.example.org>
Dec 20 17:16:32 mail postfix/qmgr[17306]: 0F96ADC6001:
from=, size=934, nrcpt=1 (queue active)
Dec 20 17:16:32 mail dkimproxy.out[11740]: connect from 127.0.0.1
Dec 20 17:16:32 mail dovecot: imap-login: Login:
user=, method=PLAIN, rip=127.0.0.1, secured
Dec 20 17:16:32 mail postfix/smtpd[31210]: connect from localhost[127.0.0.1]
Dec 20 17:16:32 mail postfix/smtp[31209]: discarding EHLO keywords:
8BITMIME STARTTLS
Dec 20 17:16:32 mail postfix/smtpd[31210]: 22D2FDC6003:
client=localhost[127.0.0.1]
Dec 20 17:16:32 mail postfix/submission/smtpd[31207]: disconnect from
localhost[127.0.0.1]
Dec 20 17:16:32 mail dovecot: IMAP(postmas...@example.org):
Disconnected: Logged out bytes=693/384
Dec 20 17:16:33 mail dkimproxy.out[11740]: DKIM signing - signed;
message-id=<20121220121630.horde.zri5flyznp9q00fu59ec...@webmail.example.org>,
signer=<@example.org>, from=
Dec 20 17:16:33 mail postfix/cleanup[31208]: 22D2FDC6003:
message-id=<20121220121630.horde.zri5flyznp9q00fu59ec...@webmail.example.org>
Dec 20 17:16:33 mail postfix/qmgr[17306]: 22D2FDC6003:
from=, size=1679, nrcpt=1 (queue active)
Dec 20 17:16:33 mail postfix/smtp[31209]: 0F96ADC6001:
to=, relay=127.0.0.1[127.0.0.1]:10028, delay=2.1,
delays=1/0/0.08/1, dsn=2.0.0, status=sent (250 2.0.0 Ok
Re: delivering mail to separate users
On 19 December 2012 22:05, Viktor Dukhovni wrote: > On Wed, Dec 19, 2012 at 05:27:17PM -0500, Simon Brereton wrote: > >> One of the clients I support is getting a consultant to do some >> sensitive work for them and so one of the directors wants to get a >> copy of all the mails sent to this new mail box. >> >> At first, I though I would simply set up the new mailbox (all domains >> are virtual) and then add an alias to virtual_alias_maps like: >> >> newu...@example.org direc...@example.org,newu...@example.org >> >> But it occurs to me that this will create a loop - no? > > No, there is no loop, virtual alias expansion eliminates exactly > this kind of loop and delivers email to the leaf address and > to its peers. > > -- > Viktor. Viktor When I do this mail is only delivered to newu...@example.org and not direc...@example.org as well. I did postmap the virtual_alias_maps. Is there something else I should I do? Thanks. Simon
Re: delivering mail to separate users
On Dec 19, 2012 10:06 PM, "Viktor Dukhovni" wrote: > > On Wed, Dec 19, 2012 at 05:27:17PM -0500, Simon Brereton wrote: > > > One of the clients I support is getting a consultant to do some > > sensitive work for them and so one of the directors wants to get a > > copy of all the mails sent to this new mail box. > > > > At first, I though I would simply set up the new mailbox (all domains > > are virtual) and then add an alias to virtual_alias_maps like: > > > > newu...@example.org direc...@example.org,newu...@example.org > > > > But it occurs to me that this will create a loop - no? > > No, there is no loop, virtual alias expansion eliminates exactly > this kind of loop and delivers email to the leaf address and > to its peers. Sweet, thanks! Simon
delivering mail to separate users
Hi
One of the clients I support is getting a consultant to do some
sensitive work for them and so one of the directors wants to get a
copy of all the mails sent to this new mail box.
At first, I though I would simply set up the new mailbox (all domains
are virtual) and then add an alias to virtual_alias_maps like:
newu...@example.org direc...@example.org,newu...@example.org
But it occurs to me that this will create a loop - no?
Looking at the documentation -
http://www.postfix.org/ADDRESS_REWRITING_README.html#auto_bcc - I
could use bcc_maps but if I only specify recipient_bcc_maps, then
director@ will only get a copy of mail sent to newuser - yes? I'd
have to add sender_bcc_maps to get a copy of outgoing mail too - yes?
I realise this could be better done from the MDA and sharing the
mailbox, but I'd have to upgrade Dovecot and this is kind of urgent,
so I want to get something in place before the holidays.
Advice welcome.
Postfix version is 2.7.1-1+squeeze1 from Debian repos.
Postconf is below.
thanks.
Simon
access_map_reject_code = 550
alias_database = hash:/etc/postfix/aliases
alias_maps = $alias_database
allow_untrusted_routing = no
append_dot_mydomain = no
biff = no
body_checks_size_limit = 51200
bounce_size_limit = 5
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
debug_peer_level = 1
default_destination_concurrency_limit = 25
disable_vrfy_command = yes
fast_flush_domains = $relay_domains
header_checks = regexp:/etc/postfix/header_checks
header_size_limit = 102400
home_mailbox = Maildir/
inet_interfaces = all
invalid_hostname_reject_code = 501
local_destination_concurrency_limit = 2
local_recipient_maps = proxy:unix:passwd.byname $virtual_alias_maps $alias_maps
mail_spool_directory = /var/spool/mail
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 512000
message_size_limit = 2048
mydestination =
mydomain = example.net
myhostname = mail.example.net
mynetworks = 127.0.0.0/8
mynetworks_style = host
myorigin = $mydomain
recipient_delimiter = -
reject_code = 550
relay_domains = /etc/postfix/mxbackups
relay_domains_reject_code = 550
relayhost =
smtp_tls_CAfile = /etc/ssl/keys/ca.crt
smtp_tls_cert_file = /etc/ssl/keys/mail.example.net.crt
smtp_tls_key_file = /etc/ssl/private/mail.example.net.key
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
smtp_tls_session_cache_timeout = 3600s
smtpd_data_restrictions = sleep 1, reject_unauth_pipelining, permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_recipient_limit = 250
smtpd_recipient_restrictions = reject_non_fqdn_sender,
reject_non_fqdn_recipient,permit_sasl_authenticated,
reject_sender_login_mismatch,
reject_authenticated_sender_login_mismatch, check_helo_access
hash:/etc/postfix/helo_checks,reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname,
reject_unknown_sender_domain, reject_unknown_recipient_domain,
permit_mynetworks, reject_unauth_destination,
reject_unlisted_recipient, check_recipient_access
mysql:/etc/postfix/Mail-Disabled.cf, check_helo_access
hash:/etc/postfix/helo_checks,check_recipient_access
hash:/etc/postfix/laxdomains,check_client_access
hash:/etc/postfix/ip_whitelist, check_sender_access
hash:/etc/postfix/backscatter
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
check_policy_service unix:private/policy-spf, check_policy_service
inet:127.0.0.1:10031, reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org, reject_rbl_client
cbl.abuseat.org, reject_rbl_client z.mailspike.net,
warn_if_reject, reject_unknown_client, warn_if_reject,
reject_rbl_client tw.countries.nerd.dk, warn_if_reject,
reject_rbl_client kr.countries.nerd.dk, warn_if_reject,
reject_rbl_client cn.countries.nerd.dk, warn_if_reject,
reject_rbl_client dnsbl.sorbs.net,
warn_if_reject, reject_rbl_client dnsbl.njabl.org,
warn_if_reject, reject_rbl_client dul.dnsbl.sorbs.net, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = example.net
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sasl_type = dovecot
smtpd_timeout = 300s
smtpd_tls_CAfile = /etc/ssl/keys/ca.crt
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/ssl/keys/mail.example.net.crt
smtpd_tls_key_file = /etc/ssl/private/mail.example.net.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
unknown_address_reject_code = 554
unknown_client_rejec
Re: SSL Certificates
On Nov 23, 2012 9:48 PM, "The Doctor" wrote: > > I was wondering who is the best CA Cert for Postfix? The one YOU trust the most - even if that's someone no one else has heard of. Simon
Re: Helo command rejected, host not found.
On Aug 16, 2012 1:24 PM, "Jim Wright" wrote: > > On Aug 16, 2012, at 11:48 AM, Simon Brereton wrote: > > > mail #554 5.7.1 : Helo command rejected: Host not found ## > > > > > If I added in a check_helo_access before reject_invalid_helo_name that would work, yes? Or would it be better to turn that line into warn_if_reject? > > > That would work, you would then need to add an entry like the following to let these emails pass: > > SPEXCH07.sp.com OK > > > What I do here when I spot these, and I believe the email may be legitimate, is to put a line like the above in for the problem domain temporarily to let the mails come in, then I do a whois on the domain and fire off an email to the listed contacts and anyone else that seems a likely support resource to let them know about the issue. After that, it's up to them to fix their system. Thanks Jim - that's what I've done for now. > I send such emails from the postmaster account, which doesn't perform all the same checks as other accounts, and won't reject mails for bad helo. I still haven't figured out a satisfactory way of doing this. I have all the postmaster accounts aliased to the main domain but I believe that check for a valid postmaster account is done after permit my networks, which is before the helo checks - it used to be after.. Simon
Helo command rejected, host not found.
Hi I have a line like this in my logs: mail #554 5.7.1 : Helo command rejected: Host not found ## This is clearly because I have reject_invalid_helo_name in my main.cf Unfortunately, the fools at steelpartners.com have decided it's quite okay to helo with sp.com (which actually resolves to Scottish Power). I'm reluctant to remove this as it stops about 25% of my spam attempts. I thought about adding it to /etc/postfix/helo_checks but that is checked AFTER permit my networks, so it wouldn't do any good - right? If I added in a check_helo_access before reject_invalid_helo_name that would work, yes? Or would it be better to turn that line into warn_if_reject? What do other's feel about that line? Simon
Re: Variable Substitutions
On 17 July 2012 15:09, Wietse Venema wrote: > Viktor Dukhovni: >> On Tue, Jul 17, 2012 at 02:49:10PM -0400, Simon Brereton wrote: >> >> > Hi >> > >> > A quick question.. >> > >> > Does Postfix do the variable substitutions after reading the entire file? >> > >> > If I set b=thing1, a=$b, then b=thing2, does the "a" setting become >> > thing1 or thing2?? > > As documented "When the same parameter is defined multiple times, > only the last instance is remembered.". > > Wietse Don't see how I missed that. Sorry. Thanks to Viktor as well. Simon
Re: multiple postmaster aliases
On 25 June 2012 09:23, James B. Byrne wrote:
>
> On Mon, June 25, 2012 11:50, Simon Brereton wrote:
>> On 22 June 2012 16:57, Wietse Venema wrote:
>>> Simon Brereton:
>>>> I would like to use an alias file that routes any of
>>>> postmas...@example.net, postmas...@example.com,
>>>> postmas...@example.info, postmas...@example.org, etc (and also
>>>> abuse@)
>>>> to postmas...@example.com without having to have the mailbox
>>>> created
>>>> in the Accounts table as I currently do. Since any replies to
>>>> these
>>>> emails would be sent from the .com domain only that mailbox and
>>>> that
>>>> entry needs to exist in the Accounts table.
>>>>
>>>> What is the best way to do this?
>
> Have you considered using a regexp style virtual_aliases map?
> Something like: regexp:/etc/postfix/virtual_alaises_regexp
>
> that contains something along the lines of:
>
> /^abuse@example\.[:alpha:]{2,4}$/ postmas...@example.com
> /^postmaster@example\.[:alpha:]{2,4}$/ postmas...@example.com
>
> These regexp are not tested so I doubt that they would work exactly as
> shown but, you get the idea. Note that in this case you absolutely
> MUST have postmas...@example.com mapped to a local delivery mailbox or
> aliased to something that will not match the left hand side of the
> regexp map. Otherwise I suspect that you will get a loop.
Thanks James
I'll play around with that and see where I get to.
Simon
Re: multiple postmaster aliases
On 22 June 2012 16:57, Wietse Venema wrote: > Simon Brereton: >> I would like to use an alias file that routes any of >> postmas...@example.net, postmas...@example.com, >> postmas...@example.info, postmas...@example.org, etc (and also abuse@) >> to postmas...@example.com without having to have the mailbox created >> in the Accounts table as I currently do. Since any replies to these >> emails would be sent from the .com domain only that mailbox and that >> entry needs to exist in the Accounts table. >> >> What is the best way to do this? > > Automation, i.e. some front-end application that automatically > creates the necessary database entries whenever you add a domain. > > I have no first-hand experience, but there are at least a half-dozen > configuration management systems that understand Postfix. Wietse Thanks for your time and reply. My point is I don't want DB entries for those address - I wanted to use a maps file. I'll go an read the documentation some more. Cheers Simon
Re: newsreader and subscription
On May 29, 2012 6:03 PM, "mouss" wrote: > > Le 28/05/2012 09:53, Georg Schönweger a écrit : > > Hi, > > > > i'm using a Newsreader to read this list (via news.gname.org). But afaik > > i have to be subscribed to write to this list. And if i'm subscribed i > > will receive every post via email too, so i receive it twice. > > Is there a way to be subscribed without "receving" posts to my mail address? > > no. almost all mailing lists work this way (posters = members = > recipients). believe it or not, many of us have considered this problem, > but it's not a simple one (open lists such as debian lists currently get > more abuse...). I personally worked on a much much simpler problem: N > persons in a company are subscribed to a single list: the company gets N > copies of the sames messages. would there be a way to get only one copy, > yet allow each person to post "individually"? my anwser so far is: live > with that (not even pruning N-1 messages, because it's harder than it > looks...). keep it simple... > > to fix your problem, get yourself an address that you don't consult, such as >gschoewgere.posto...@gmail.com > it's sub-optimal, but it's so simple. By default gmail doesn't show you your own post. Some mailing software doesn't either.. Simon
Re: attempt to connect by spam appliance
On 23 April 2012 22:28, snowie wrote: > Hello Postfix-users, > > Just curious. I got these continuous attempt to connect to email server > by my spam appliance. > Any advice ? > > Thank you and best regards. > > Snowie > > Apr 24 10:19:15 email postfix/smtpd[2232]: connect from > firewall.abc.com[192.168.0.1] > Apr 24 10:19:16 email postfix/smtpd[2159]: connect from > firewall.abc.com[192.168.0.1] > Apr 24 10:19:18 email postfix/smtpd[2141]: warning: > firewall.abc.com[192.168.0.1]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 > Apr 24 10:19:18 email postfix/smtpd[2232]: warning: > firewall.abc.com[192.168.0.1]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Happens all the time over here. By that, I mean a couple of times a week. Seems some spammers are desperate enough to try SMTP AUTH. Which can work, if you have a weak password and a known account (think postmas...@example.com/Password123 or sno...@example.net/Admin12345; etc). Time to make sure your password policy is up to date and enforced. Personally, I favour length over complexity, but you'll find different opinions on here as you will everywhere. And to be sure, complexity helps when you have physical access to the system, but length will help if you're relying on an internet protocol to make your attempts (inmho, ymmv). Simon
Re: Delaying mail delivery
On Apr 22, 2012 10:23 PM, wrote: > > > > vis...@norpknit.com: > >> I feel that all the messages has to be kept in queue as hold and there > >> should be some script that will check the queue receiving time and will > >> create a crontab with postsupre -r [message ID] for defined time to be > > > > Please describe the PROBLEM that you are trying to solve > > (why delay mail), instead of the SOLUTION (hold and cron)? > > > > For example, > > > > - To avoid receiver mail rate limits (there is a better solution > > in Postfix than hold+cron) > > > > - To inspect mail for badness (there is a better solution in Postfix > > than hold+cron) > > > > - Something else. > > > > Wietse > > > Some users are there; they call me once they press the send/receive button, > yelping "Vishal I did some mistake in that email, can you get it back > " without knowing that once they have pressed the button for > send/receive and the email is delivered within 4 - 20 seconds to > destination. Why not force spell-checking on the clients - that should allow for some error checking.. As others have and will say - your job is IT admin, not hand-holding people too stupid to check their work. Some of these users probably even have degrees ffs! Simon
Re: spam to postmaster
On Feb 17, 2012 6:14 PM, "Reindl Harald" wrote: > > > > Am 17.02.2012 21:59, schrieb Peter Blair: > > On Fri, Feb 17, 2012 at 3:54 PM, Reindl Harald wrote: > >> how do other people act with such braindead sh**t? > > > > Look into greylisting it. You'll find that greylisting could very > > well deal with most of the bots that things like zen.spamhaus.org > > would normally deal with. And strictly speaking, you're not filtering > > it -- just making a policy decision to not accept the transaction > > before the DATA section ;) > > barracuda Spamfirewall does filtering ow whitelisting > noting between > > what i do not understand is how fucking stupid > people are spamming to postmaster/abuse-addresses Because it's one address guaranteed to see it?
Re: High Number Of Connection Attempts
On Feb 4, 2012 1:03 PM, "Pete" wrote: > > On 04/02/2012 17:58, Nick Bright wrote: >> >> On 2/4/2012 11:47 AM, Pete wrote: >>> >>> Hello, >>> >>> Can someone confirm that the log excerpt below is most likely a bot of >>> some kind attempting to authenticate to my Postfix server please ? >>> >> >> That looks like a brute force attempt, or at least a bot looking for >> weak passwords. I see the same things in my logs, too. >> >> The only thing I have found is ConfigServer firewall: >> >> http://configserver.com/cp/csf.html > > > [..] > > Thanks Nick, I'll take a look. I use fail2ban to limit brute auth attempts like that. You can set it up so that 3 fails in a minute is a 20 ban. I'd rather have people call the help desk than a weak password get cracked.. Simon >
Re: Postfix stable release 2.9.0
On Feb 1, 2012 11:20 PM, "ml" wrote: > > > Le mercredi 01 février 2012 à 19:30 -0800, Ori Bani a écrit : > > 2012/2/1 ml : > > > > > > Le jeudi 02 février 2012 à 03:13 +0100, ml a écrit : > > >> Le mercredi 01 février 2012 à 23:01 +0100, Reindl Harald a écrit : > > >> > > > >> > Am 01.02.2012 22:56, schrieb Ori Bani: > > >> > > On Wed, Feb 1, 2012 at 5:58 AM, Wietse Venema < wie...@porcupine.org> wrote: > > >> > >> [An on-line version of this announcement will be available at > > >> > >> http://www.postfix.org/announcements/postfix-2.9.0.html] > > >> > >> > > >> > >> Postfix stable release 2.9.0 is available. The main changes in no > > >> > >> particular order are: > > >> > >> > > >> > > > > >> > > Does anyone know how soon Simon Mudd usually responds to releases like > > >> > > this? Not trying to hurry anyone, *just* asking > > >> > > > >> > who is Simon Mudd? > > >> > > > >> > rebuild postfix usually is a work of 5 minutes > > >> > was there and distributed 2.8.8 two hours ago to 20 machines via RPM > > >> > > > > > > i build with succes a rpm for postfix 2.9.0 for centos 5 > > > for fine for me > > > The main work was done not just SJ Mudd i have adapts required. > > > I still have problems with the patch VDA standard is not to be applied > > > correctly error that prevents the construction of the rpm > > > > > > still rpm source is disponible here > > > http://ns.fakessh.eu/rpms/postfix-2.9.0-1.pcre.pgsql.mysql.sasl2.dovecot.sqlite.rhel5.src.rpm > > > > Yah, I'll stick with Simon, who I think can write a sentence that > > I can read - even if his package will take longer. Something about > > the trust factor perhaps. > > > I assure you that my work is correct and that my rpm is ok Sadly you weren't being judged on your work but on the quality of your second, or third, language.. The OP has decided - and he has that right - that only Mudd's rpm's will do. I'm sure other people will thank you tho. Simon
Re: Queue directories on faster media?
On 30 January 2012 12:49, /dev/rob0 wrote: > On Mon, Jan 30, 2012 at 01:09:29AM -0800, Ori Bani wrote: >> On Mon, Jan 30, 2012 at 12:42 AM, Ralf Hildebrandt >> wrote: >> > * Ori Bani : >> >> I'm curious to get feedback on the idea of mounting all the >> >> postfix queue directories on a faster media (SSD drive in >> >> this case). >> >> >> >> In my case, I have virtual maildirs under /var/spool/postfix >> >> and those would be relocated to elsewhere (onto slower normal >> >> media) because the faster (SSD) media isn't in a RAID >> >> configuration (slower media is). >> > >> > Why are you storing maildirs in the queue directory? >> >> I think it is a legacy thing from a very old how-to. > > Having recently written a Postfix howto, I reviewed quite a few URL please? :) Simon
Re: Stats on smtp method used by clients (with pflogsumm or not)
On 20 January 2012 09:47, James Seymour wrote: > On Fri, 20 Jan 2012 08:15:35 -0500 (EST) > Wietse Venema wrote: > > [snip] >> >> In the logging you will see postfix/smtps/smtpd, >> postfix/submission/smtpd and postfix/smtpd. > [snip] > > Two things (addressed to the OP and other readers): > > 1. This will break Pflogsumm. It expects to see "postfix/smtpd" > 2. (1) is easily-fixed, but you still wouldn't see plain smtp, > smtps and submission broken-out, as Pflogsumm currently has no > code to provide for this. > > If there's sufficiently wide demand for that feature, I can add it. Consider this demand :)
Re: Spamcop listed gmail?
On Jan 19, 2012 7:13 PM, "Steve Fatula" wrote: >> >> From: Robert Fitzpatrick >> To: Postfix >> Sent: Monday, January 16, 2012 1:12 PM >> Subject: Spamcop listed gmail? >> >> Perhaps this is not the place for this, I didn't find a mailing list on >> the spamcop site and just looking to see if this is experienced by >> others. Got two calls this morning, both not receiving mail from gmail >> users and both being blocked by my usage of 'reject_rbl_client >> bl.spamcop.net'. Anyone other users of this config parameter seeing this? >> > You should not block outright. Either use a scoring system (perhaps postscreen), or, DNSWL to first whitelist the servers. > > I personally report yahoo, gmail, etc. all the time via Spamcop when I get spam from them. My hope is they will at least find the account and disable it, possibly, with luck, even block emails going out just like it in the future. What he said... Simon
Re: Postfix Mac Aministration
On 5 January 2012 11:24, Eric Lemings wrote: > > On Jan 4, 2012, at 11:46 PM, Eric Lemings wrote: > >> >> On Jan 4, 2012, at 9:54 PM, /dev/rob0 wrote: >> >>> On Wednesday 04 January 2012 20:45:23 Eric Lemings wrote: I just noticed that two of my Postfix configuration variables were set twice, the latter of which was overriding the former. Here's the new values: >>> >>> The list policy asks for "postconf -n" because that reports values >>> Postfix is actually using. >>> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated reject_rbl_client zen.spamhaus.org reject_rbl_client rbl-plus.mail-abuse.org reject_rbl_client bl.spamcop.net permit >>> >>> MAPS RBL is a paid service only, but I suppose you knew that. >>> smtpd_recipient_restrictions = >>> >>> BTW "client" != "recipient", in case that is what you meant by >>> duplicated settings. They are different settings, but functionally >>> similar. You could consolidate all of your restrictions into >>> smtpd_recipient_restrictions. Unless you need complex whitelisting, >>> it's usually easier that way, to only maintain one set of >>> restrictions. >>> reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_rbl_client relays.ordb.org, reject_rbl_clientlist.dsbl.org, >>> >>> Both of these are LONG dead and gone, so maybe you did not know about >>> MAPS RBL? Also, you have no space there. Furthermore, you pasted your >>> "postconf -n", and it shows a different setting of >>> smtpd_recipient_restrictions. We believe what postconf(1) tells us. >> >> When I first captured the output from postconf -n, I noticed afterwards that >> both variables were set twice in the Postfix main.cf file. Something like >> this: >> >> >> smtpd_client_restrictions = >> smtpd_recipient_restrictions = >> ... >> smtpd_client_restrictions = > other Mac admin tool> >> smtpd_recipient_restrictions = > other Mac admin tool> >> >> I remove the last variables whose values were shown in the first post, then >> reposted the new values. >> >> This change seems to have been my missing link. Since I made it, spam >> arriving in IMAP boxes has dropped drastically in the past several hours. > > Well I spoke too soon. The flood of spam started again this morning. > > Obviously something isn't working. All testimonials I've read say that grey > listing stops 90% of spam but its not working. So post a log snippets as you were asked to do and someone can help you. Simon
Re: Postfix-Amavisd quarantined mail inspection
Ask, not all.. On Dec 29, 2011 9:28 AM, "Simon Brereton" wrote: > > On Dec 29, 2011 9:15 AM, "Nikolaos Milas" wrote: > > > > Hello, > > > > I am using postfix, amavisd-new, spam assassin, clamav on a gateway > system. > > > > A short question (I know it's a bit off-topic but I know that people > here run similar systems): > > > > I've read how to release and/or forward quarantined mail. But can I read > the quarantined mails in situ (i.e. in the quarantine directory)? Can I use > some utility to display it in human-readable form and examine details > (headers, subject, etc.) so I can decide whether it should be released or > not? > > Cat works for me - but all on the amavis list. I believe there's a > command for it. > > Simon >
Re: Postfix-Amavisd quarantined mail inspection
On Dec 29, 2011 9:15 AM, "Nikolaos Milas" wrote: > > Hello, > > I am using postfix, amavisd-new, spam assassin, clamav on a gateway system. > > A short question (I know it's a bit off-topic but I know that people here run similar systems): > > I've read how to release and/or forward quarantined mail. But can I read the quarantined mails in situ (i.e. in the quarantine directory)? Can I use some utility to display it in human-readable form and examine details (headers, subject, etc.) so I can decide whether it should be released or not? Cat works for me - but all on the amavis list. I believe there's a command for it. Simon
Re: Postfix Hold queue
On 1 December 2011 04:56, Roland de Lepper wrote: > Hi, > > Where're planning to migrate postfix from Suse to Ubuntu 10.04 LTS. The > Postfix version on Suse has an higher version number than in Ubuntu 10.04LTS > (2.7.2 - 2.7.0). > > Because of the migration we have to shutdown the MySQL server to make a full > dump of it and import is on the new mailserver. In the meantime, all mail > coming to the old-mailserver will be stored in the HOLD queue. > When the new Mailserver is ready (with the same hostname and > public-ipaddress) I want to copy the HOLD queue from the old mailserver to > the new mailserver, then do a postsuper -r ALL to deliver the messages on > the new mailserver. I can't tell you. But why not stop postfix BEFORE you stop the database? That way every (legitimate) sending server will hold outgoing mail for up to 5 days and you can then copy your DB in peace, move it to the new box, set it up, make sure it's working and generally not operate under any time pressure (so long as you warn your users there is an outage window). Simon
Re: ssh client for new mac laptop
On 24 November 2011 22:16, Keith Steensma wrote: > Anyone have a recommendation for a 'free' client for a mac os x that works > when communicating to a unix/linux server? I haven't found anything when > 'googling' for an answer. Mac OS X is unix - will the built in terminal not do? http://www.unixnewbie.org/putty-equivalent-for-mac-os-x/ Simon
Re: multiple content filters, a sanity check
On 22 November 2011 11:52, David Mehler wrote: > On 11/22/11, Simon Brereton wrote: >> On 21 November 2011 19:33, David Mehler wrote: >>> Hello, >>> >>> I'm running Postfix 2.8 and virtual mailbox domains with a mysql >>> database. I've also got spf and dkim signatures going as well as >>> clamsmtp as an smtp proxy for virus checking. I'd now like to add in >>> dspam antispam capability so that user's can forward emails that are >>> spam or not. My problem is the multiple content filters are mixing me >>> up and I'm not sure I've got the most efficient setup. >>> >>> In master.cf if the smtpd process has a content_filter option on it >>> does that go first in the chain before any content_filter directives >>> in main.cf? My working main.cf and master.cf files are below this >>> message, dspam addon lines are still commented out. If anyone has this >>> setup going I'd appreciate a sanity check. Also, if there are any >>> configuration errors that I've missed please let me know, this is the >>> most complex configuration I've set up to date. >> >> I'm sure you have a good reason for rejecting this idea, but >> amavisd-new would do the DKIM, DSPAM and Virus checking all in one >> filter. Have you considered that? > Hello, > > Thanks for your reply. I've tried amavisd-new in the past and when I > did so it seemed more luck that it all worked vs. at least for me good > configuration. I read the docs but still was more lucky to get it > working, I was looking in to other solutions before I went that route. > Also, when I ran it it seemed to slow things down system resource > wise. > > If I do go there will that mean I wouldn't have to run my setup as is, > just hook amavisd-new in to the running daemons? > > How is your setup? What are you running? Dave - I'm not an expert, but plenty of people (the majority, I would guess) run amavisd with postfix. Plus the amavisd mailing list is also very helpful. What do you mean it was more luck that it worked? In my main.cf, I have defined content_filter = smtp-amavis:[127.0.0.1]:10024 And in master.cf, I have #The amavis reciever 127.0.0.1:10025 inet n - - - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks -o smtpd_bind_address=127.0.0.1 #the amavis connector, to send to amavis smtp-amavis unix - - - - 2 smtp -o smtp_data_done_timeout=1200 -o disable_dns_lookups=yes #Stop Postfix from cleaning emails before sending to amavis pre-cleanup unix n - n - 0 cleanup -o virtual_alias_maps= -o canonical_maps= -o sender_canonical_maps= -o recipient_canonical_maps= -o masquerade_domains= My set up is quite old, so some of these may not be best practice any more. Simon
Re: multiple content filters, a sanity check
On 21 November 2011 19:33, David Mehler wrote: > Hello, > > I'm running Postfix 2.8 and virtual mailbox domains with a mysql > database. I've also got spf and dkim signatures going as well as > clamsmtp as an smtp proxy for virus checking. I'd now like to add in > dspam antispam capability so that user's can forward emails that are > spam or not. My problem is the multiple content filters are mixing me > up and I'm not sure I've got the most efficient setup. > > In master.cf if the smtpd process has a content_filter option on it > does that go first in the chain before any content_filter directives > in main.cf? My working main.cf and master.cf files are below this > message, dspam addon lines are still commented out. If anyone has this > setup going I'd appreciate a sanity check. Also, if there are any > configuration errors that I've missed please let me know, this is the > most complex configuration I've set up to date. I'm sure you have a good reason for rejecting this idea, but amavisd-new would do the DKIM, DSPAM and Virus checking all in one filter. Have you considered that? Simon
sanitizing mysql queries
Hi When I set postfix many moons ago, I wasn't at all sure of what I was doing and I followed a number of different howtos. The result is that I inherited other peoples ideas of how things should be done and lately I've seen advice and bells and whistles that make me think I should go back and streamline things. One thing I'm not at all sure on is how mysql queries are handled. For example, I have in main.cf 772 virtual_alias_maps = proxy:mysql:/etc/postfix/Mail-Alias.cf, hash:/etc/postfix/virtual_user_aliases 774 virtual_mailbox_maps = mysql:/etc/postfix/Mail-Mailbox.cf Now, that's two different ways of doing things right there. Testing on the commandline with: mail:~# postmap -q "si...@example.net" mysql:/etc/postfix/Mail-Alias.cf returns: si...@example.net But http://www.postfix.org/proxymap.8.html recommends I should use proxy: to consolidate connections - so really I should have proxy: in front of the virtual_mailbox_maps as well since this will take the most hammering, yes? Second question... If I want to use mysql:/path/to/file in smtpd_recipient_restrictions should I be using proxy in there too? I'm using postfix 2.7.1 from debian repositories - should I be a query = SELECT forw_addr FROM mxaliases WHERE alias='%s' AND active='1' format or a list of name value pairs? I.e. user = someone password = some_password dbname = customer_database table = mxaliases select_field = forw_addr where_field = alias additional_conditions = AND active = '1' What I'm trying to do is follow advice from /dev/rob0 a few weeks ago about moving the check for disabled users to announce the proper reject and that's when I realised that'd I'd so blindly followed a guide I had no idea of how this really works. Thanks. Simon
Re: Migration from one server to another - best practices?
On 17 November 2011 14:02, Dennis Carr wrote: > I'm about to do a migration from one server to another - old server runs > Debian Lenny, new one runs Squeeze, both with respective current versions of > postfix. > > Long and short is that I'm basically preparing to migrate everything, > including users and a mailman configuration, to the new box. Basic strategy > I have is to shut down smtp on the old server during the course of the > migration, and once postfix is configured on the new box with the users and > mailman aliases, switch the old box over to being a secondary mx for a few > days while DNS settles down. > > Is there a better way to do this, or some sort of online guide I can follow > that can guide me through the process? I'm pretty much the last person who's approach you should listen too, but this is how I did it. You don't say if the mbox/maildirs are also on the same server. If not, this could be easier for you. - Copy over the configuration and start the service - Optionally rsync any mailboxes/maildirs - Confirm delivery is working through the new system - Change over the DNS to point to the new box (MX 10) and the old one as backup (MX 20) - When mails start hitting the new one (probably around 2 hours depending on your DNS TTL, turn off the old one. - Optionally rsync (with a --delete option) any maildir/mailboxes for any mail that was delivered between the DNS switch and turning off the old server. Simon
Re: mail defered on local network
On 17 November 2011 17:14, Tim Dunphy wrote: > Hello list, > > I am attempting to build a basic postfix setup that is able to send mail to > the internet. Receiving email is not a priority. > > I've verified that this basic setup DOES work on an Amazon EC2 instance and > can be used to send email to anyplace it would like. However when I transfer > the config (main.cf and master.cf) to our work network the messages are > deferred and rejected by any mail server it encounters. I'd like very much to > understand why this is happening and to get this config to work on our local > network. > > If I perform a telnet mail test on my local network the message is rejected > and deferred no matter what mail server it tries to communicate with: > > [monitor03:root:/etc/postfix]#telnet localhost 25 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > 220 monitor03.localdomain ESMTP Postfix > HELO monitor03 > 250 monitor03.localdomain > MAIL FROM: > 250 2.1.0 Ok > RCPT TO: > 250 2.1.5 Ok > DATA > 354 End data with . > Subject: test message > test test test > . > 250 2.0.0 Ok: queued as E45C2136357 > quit > 221 2.0.0 Bye > Connection closed by foreign host. > > This is what happens in the mail log when this test is performed: > > Nov 17 16:25:39 monitor03 postfix/smtp[26004]: E45C2136357: > to=, relay=none, delay=4755, > delays=4755/0.02/0.05/0, dsn=4.4.1, status=deferred (connect to > alt4.gmail-smtp-in.l.google.com[74.125.43.27]:25: Connection refused) 4.4.1 is a transient network failure. http://www.ietf.org/rfc/rfc1893.txt What happens if you do your telnet test from the host to google directly? Also, for a direct comparison send the email from the working server to google (even though I believe you that it's a generic problem). Simon
Re: spamcop abusing mail systems worldwide
On 17 November 2011 09:28, wrote: > Zitat von Dan The Man : > >> >> >> Today I had an unhappy unix student try to submit an assignment to me and >> could not. Spamcop has decided to go off blacklisting all yahoo/shaw etc >> servers worldwide. > > The subject is wrong. Spamcop simply list mailservers sending a lot of spam > and Yahoo for example does exactly that. It is the duty of the mailserver > operator to decide if such a list should be used for blocking senders. I agree. In all likelyhood, Spamcop listed the SHAW IP which is where the email originates from and not the Yahoo IP. Perhaps the student will take this as a lesson to choose a better ISP. >> Solution: >> remove: reject_rbl_client bl.spamcop.net >> from your smtpd_recipient_restrictions line until they fix their abuse >> issues. It's not *their* issue. They list servers/IPs that send a significant amount of spam. I would suggest the people with the issue are the IP owners. Not spamcop. But as others have said, you're not obliged to use it. So please don't. Simon
Re: Recipent restrictions
On 17 November 2011 01:13, Dilip Mishra // Viva wrote: > Hello Group, > I want to implement some restrictions on postfix by which it would reject > domains without mx records, as well as those specified in access table. > These are some domains to I do not want to send mails at all. My problem is > that, this setting does not work at all, since the sending IPs are specified > in mynetworks. The moment I change the order of the parameters, it starts to > reject all mails from all the IPs. Please help me to set the correct order > of the parameters in main.cf: > smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, > permit_inet_interfaces, check_recipient_access hash:/etc/postfix/access, > reject_unauth_destination, reject_rbl_client list.dsbl.org, > reject_rbl_client bl.spamcop.net, reject_rbl_client sbl-xbl.spamhaus.org, > reject_rhsbl_sender dsn.rfc-ignorant.org, check_relay_domains I would also suggest that you need permit_sasl_authenticated before permit_mynetworks. And reject_unauth_destination should maybe also be higher up. And what purpose does your relay_domains server at the end? Simon
Re: openspf.org
On 16 November 2011 13:01, David Mehler wrote: > Hello, > > I'm trying to get spf going on my arch postfix server. I'm wanting to > get perl-policyd-spf going and am atempting to download the needed > source. The issue is openspf.org appears down, anyone know why or if > there's an alternative download available? Use openspf.net for now. Simon >
Re: reject_non_fqdn_helo_hostname usefulness, safety
On 10 November 2011 18:45, Steve Fatula wrote: > This check says that the RFC requires a fully qualified hostname for HELO. > Most internet searches show this to be a "safe" check that shouldn't really > kill any real mail. Lately, noticed no ebay mail was coming through, looked > through the logs and see entires like: > Nov 9 20:30:58 host2 postfix/smtpd[16167]: NOQUEUE: reject: RCPT from > mxpool19.ebay.com[66.135.197.25]: 504 5.5.2 : Helo command rejected: > need fully-qualified hostname; from= to= > proto=ESMTP helo= > > mx88 is of course not a FQDN. So, it was correctly rejected per the setting. > Obviously, I can try and whitelist all the ebay servers, but, it's a slight > pain. Could be a moving target, etc. This would allow me to keep the > setting, but > Since this did block mail from a rather well known common mailer, I am > starting to wonder how safe this check really is. Perhaps it's not so safe. > Yes, that is a configuration error on ebays part, but, I don't think you > really want to block ebay mail. > Are you finding this is not as safe a check as it should be, since > presumably the RFC requires it, still, people make mistakes? Is it really of > much use these days anyway for blocking spam? This check alone is responsible for blocking up to 85% of the spam attempts on our system. Verify that the HELO is not localhost, mydomain.tld or ip.add.re.ss takes care of another 5% and rejecting invalid destinations takes care of the rest. Amavis ends up finding less than 1% of what makes it through that and that in itself is 1% of the total attempts. Write them a note with the RFC I say. Standards are no good if you let yours slip because it's Ebay. or Google. or InsetBrandnamehere. Simon
Re: bad From: field
On 10 November 2011 07:21, privat wrote: > After moving to a new host running Ubuntu 10.10 I get in outgoing mails > sent from account "privat" a From:-field > > From: privat > > it used to be before > > From: ulrich.laut...@t-online.de > > In sender_canonical I have > privat@localhost ulrich.laut...@t-online.de > > and in generic > privat@honolulu.local ulrich.laut...@t-online.de > > hostname gives honolulu > domainname gives (none) > > so how can I get rid of the "privat" in the From: field? This is usually set by your MUA. Evolution? Thunderbird? > Slightly related: how do I find the version of my postfix-installation? > > Thanks for any help, http://lmgtfy.com/?q=ubuntu+10.10+find+postfix+version Or dpkg -l packagename as you would for any package on Ubuntu. Simon
Re: Signing injected mail
On 9 November 2011 00:48, Noel Jones wrote: > On 11/8/2011 10:35 PM, Simon Brereton wrote: >> On 8 November 2011 15:30, Wietse Venema >> wrote: >>> Simon Brereton: >>>> On 4 November 2011 15:49, Simon Brereton >>>> wrote: >>>>> Hi >>>>> >>>>> Amavis checks both incoming and outgoing mail. ?DKIMPROXY >>>>> signs outgoing mail (sadly, before Amavis, so amavis >>>>> verifies the signature - but I'm okay with that for now) >>>>> on the submission port. >>>>> >>>>> Mail that is injected (i.e. from CRON, applications, >>>>> etc), still passes through amavis (obviously) but doesn't >>>>> get signed. ?I would like to sign those mails as well. >>>>> >>>>> As I was writing this, it occurred to me that the way to >>>>> do that is to add the content filter in master.cf >>>>> >>>>> ? -o content_filter=dksign:[127.0.0.1]:10028 >>>>> >>>>> I think I need to add that to the pickup line - is that >>>>> correct? ?If not, where do I add it so that mails that >>>>> are injected are added? >>>> >>>> Well in the absence of any one telling me not to be stupid, >>>> I went ahead and tried that. It wasn't a miserable >>>> failure, but it didn't do anything. >>> >>> First, you can add -o content_filter to the pickup daemon >>> only if your content filter is based on SMTP otherwise you >>> get an infinite loop. >>> >>> Second, you need to add the same -o content_filter >>> information as with the smtpd line. There is nothing magical >>> about filters, except perhaps that DKIMPROXY expects to see >>> message headers that the pickup daemon cannot provide. >>> >>> Wietse >>> >>>> If anyone has any pointers on how to do this (or if you'd >>>> like to tell me it's not possible and why) that would be >>>> great. >> >> >> I don't think this is your fault - but that went completely >> over my level of smtp understanding. >> >> Putting the content filter in the pickup (exactly as it is in >> in the smtpd) doesn't appear to do anything. But then I expect >> that's related to your comment about the content-filter being >> based on smtp.. I don't get an infinite loop. I don't get >> anything. >> >> I think I'll have to wait until I start running separate >> amavis/postfix processes to figure this out. >> >> Simon > > > I think you should spend 15 minutes to get amavisd-new to do your > DKIM signing and drop dkimproxy. Better performance, simpler > setup, one less critical component in the mail path. See the > amavisd-new release notes and docs for further info. > Noel, you're almost always right - but I'm so proud of my dkim setup :) Probably this is in the documentation, but since amavis checks ALL mail (incoming and outgoing) doesn't that mean it would try to sign incoming mail? Actually that can't be right. Most people use amavis to check outgoing mail only, so for it to do dkim signing it must be able to tell what's going in and what's going out. I'll RTFM. Simon
Re: Signing injected mail
On 8 November 2011 15:30, Wietse Venema wrote: > Simon Brereton: >> On 4 November 2011 15:49, Simon Brereton >> wrote: >> > Hi >> > >> > Amavis checks both incoming and outgoing mail. ?DKIMPROXY signs >> > outgoing mail (sadly, before Amavis, so amavis verifies the signature >> > - but I'm okay with that for now) on the submission port. >> > >> > Mail that is injected (i.e. from CRON, applications, etc), still >> > passes through amavis (obviously) but doesn't get signed. ?I would >> > like to sign those mails as well. >> > >> > As I was writing this, it occurred to me that the way to do that is to >> > add the content filter in master.cf >> > >> > ? -o content_filter=dksign:[127.0.0.1]:10028 >> > >> > I think I need to add that to the pickup line - is that correct? ?If >> > not, where do I add it so that mails that are injected are added? >> >> Well in the absence of any one telling me not to be stupid, I went >> ahead and tried that. It wasn't a miserable failure, but it didn't do >> anything. > > First, you can add -o content_filter to the pickup daemon only if > your content filter is based on SMTP otherwise you get an infinite > loop. > > Second, you need to add the same -o content_filter information as > with the smtpd line. There is nothing magical about filters, except > perhaps that DKIMPROXY expects to see message headers that the > pickup daemon cannot provide. > > Wietse > >> If anyone has any pointers on how to do this (or if you'd like to tell >> me it's not possible and why) that would be great. I don't think this is your fault - but that went completely over my level of smtp understanding. Putting the content filter in the pickup (exactly as it is in in the smtpd) doesn't appear to do anything. But then I expect that's related to your comment about the content-filter being based on smtp.. I don't get an infinite loop. I don't get anything. I think I'll have to wait until I start running separate amavis/postfix processes to figure this out. Simon
Re: Signing injected mail
On 4 November 2011 15:49, Simon Brereton wrote: > Hi > > Amavis checks both incoming and outgoing mail. DKIMPROXY signs > outgoing mail (sadly, before Amavis, so amavis verifies the signature > - but I'm okay with that for now) on the submission port. > > Mail that is injected (i.e. from CRON, applications, etc), still > passes through amavis (obviously) but doesn't get signed. I would > like to sign those mails as well. > > As I was writing this, it occurred to me that the way to do that is to > add the content filter in master.cf > > -o content_filter=dksign:[127.0.0.1]:10028 > > I think I need to add that to the pickup line - is that correct? If > not, where do I add it so that mails that are injected are added? Well in the absence of any one telling me not to be stupid, I went ahead and tried that. It wasn't a miserable failure, but it didn't do anything. If anyone has any pointers on how to do this (or if you'd like to tell me it's not possible and why) that would be great. Thanks. Simon
Re: understanding the logs
On 8 November 2011 02:53, Stan Hoeppner wrote: > On 11/8/2011 1:13 AM, Geert Mak wrote: > >> We had a user account hacked (weak password) and our SMTP server was used >> for sending spam. We discovered it after our mail server IP began to show up >> in RBLs. We improved the passwords, however the question is how best to >> watch the server in case a similar thing happens again. > > 1. Create and enforce a minimum password complexity policy, preferably > on your web based account creation page, something like: > > http://www.webresourcesdepot.com/10-password-strength-meter-scripts-for-a-better-registration-interface/ For password strength, I'm not sure the conventional wisdom of numbers and punctuation are relevant any more. They help when the attacker is known to you, but password length is a much better indicator of entropy resistance. http://xkcd.com/936/ Simon
Re: executive parser (was: Re: spf configuration woes)
On 6 November 2011 04:22, David Southwell wrote: > On Saturday 05 November 2011 22:40:03 Murray S. Kucherawy wrote: >> > -Original Message- >> > From: owner-postfix-us...@postfix.org >> > [mailto:owner-postfix-us...@postfix.org] On Behalf Of David Southwell >> > Sent: Saturday, November 05, 2011 9:41 AM >> > To: postfix-users@postfix.org >> > Cc: /dev/rob0 >> > Subject: Re: executive parser (was: Re: spf configuration woes) >> > >> > Just to add weight to my last posting - the use of a " " as a critical >> > symbol is really quite idiotic. What cannot be seen should never be that >> > significant! >> >> The current RFC defining email message format is RFC5322, and it uses >> leading whitespace as line continuation in header fields. Its >> antecedents, going back as far as RFC733 (1977) and perhaps further, do >> the same thing. Thus, your assertion appears to be in conflict with quite >> a bit of operational history and experience. > > I think what is being forgotten here is that administrators have to cope with > a whole variety of software. The history of one narrow sphere (e.g.) mail is I think what is being forgotten here is that YOU were too stupid to add an spf filter to some of the most widely used MTA SW on the web. And when you finally figured it out* you chose to be hostile, arrogant and rude. figured it out = had your hand held. Ideally it seems you wanted someone to write your master.cf for you It should be noted I installed an SPF policy a few weeks ago - which I accomplished in less time, with less mails to the list and less coding experience (and a good deal more reading of the documentation). > Hence thoughtful engineers incorporate diagnostic parsers and html > configuration tools. IMHO postfix has been very slow to develop an apporocah > which places the needs of system administrators in the forefront of its > development strategy. > > People make mistakes. Even the most experienced administrators. Administrators > are not primarily programmers. They look at configuration files. During a busy > day they do not want the hassle of having to ask themselves the question "What > do spaces do in this .config .cf file?" Good configuration files make their > formatting requirement obvious. That is why I say the use of " " is, in an > administrator's context, idiotic. It is idiotic because it demands that > adminstrator to ask himself/he > rself the question is this " " significant or insignificant. When there are > hundreds of " " in a file the luckless adminstrator has too much on his/her > plate when trying to fix a problem as quickly as possible. Administrators should be asking themselves all the time if something is significant or not. Everytime I see an indendation I wonder if it's supposed to be a space, a run of spaces or a tab. And what the effects of aligning them all with tabs might be. You are clearly not an administrator. > I have been taking this list silently for years. Amonst a lot of genuinely > helpful contributions I have witnessed a regular splattering of rudeness and > arrogance by some long standing contributors heaped on the heads of luckless > administrators trying to succesfully configure postfix. I had no idea luckless meant to dumb or lazy to follow instructions.. You say you'd run netstat before Wietse asked you to? That being the case, why - in either of the responses immediately after that suggestion did you not simply say "I did that - here's the output". For the luckless administrator in you I'd like to point out that ignoring something someone (indeed the only person engaged on issue) asks you twice to do something and you ignore it that is also rude. And when you get called on that rudeness you complain?!? > The design of Postfix's configuration system and supporting documentation > represents the honest efforts of people who have a single point of focus > namely: > > Making postfix work when it has been given the appropriate configuration data. As does every other piece of SW in the entire world. > IMHO Postfix needs to add to its goals a determination to make configuration a > breeze rather than a challenge. That means diagnostic and corrective parsers > and or an html based configuration interface. Such facilities would cut down > the traffic on this list and stop a few people looking down their noses at > thuose who make a mistake. You want to make it fool-proof? You'll only build a better class of fool to defeat it.
Re: spf configuration woes
On 5 November 2011 08:21, David Southwell wrote: > On Saturday 05 November 2011 05:13:22 Wietse Venema wrote: >> David Southwell: >> > Did you read the original posting and the reply from Kamil. He spotted >> > the primary cause. It was he who spotted the extra " " before >> > policyd-spf in master.cf which was in the part of the post you cut out. >> > >> > So you were right it was an error in the master.cf but noone else spotted >> > it before Kamil made his contribution. >> >> You could have spotted it days ago with lsof/netstat which would >> have told you immediately that postfix was not listening on the >> socket. >> >> Wietse > > Typical Wietse response. Everyone could see postfix was not listening but it And Wietse was trying to get you to find out why - instead of making random changes. He asked you at least twice to run netstat - did you do it? It would have saved you 18 hours and at least 3 long mails if you had. Typically ungrateful response to Wietse's help is more like it. People come on here, expect it him not only to write it, but keep it secure and spot typgraphical errors in their own configs because they're too lazy to look (and that laziness is exemplified by a laziness to follow a simple diagnostic instruction). > took Kamil's careful scrutiny and knowledge to identify why - knowing why was > what led to the solution. Which you'd have had much much earlier without the hand-holding had you followed Wietse's first request to run netstat. > Diagnosis is valuable but without the ability to define the treatment the > diagnosis is merely a matter of record. Only valuable if you follow the steps you're asked to perform. Spoonfeeding and proof-reading your errors in your config files is not diagnosis. > Clearly postfix is need of an intelligent parser that will to pinpoint errors > such as this in master.cf and main.cf. That is because stupid computers are > better at parsing chores than human beings. Postfix has such a parser - which is why the documentation points out that lines should not start with a white-space. RTFM. Simon
Signing injected mail
Hi Amavis checks both incoming and outgoing mail. DKIMPROXY signs outgoing mail (sadly, before Amavis, so amavis verifies the signature - but I'm okay with that for now) on the submission port. Mail that is injected (i.e. from CRON, applications, etc), still passes through amavis (obviously) but doesn't get signed. I would like to sign those mails as well. As I was writing this, it occurred to me that the way to do that is to add the content filter in master.cf -o content_filter=dksign:[127.0.0.1]:10028 I think I need to add that to the pickup line - is that correct? If not, where do I add it so that mails that are injected are added? Thanks. Simon
Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch
On 2 November 2011 18:23, Noel Jones wrote: > On 11/2/2011 2:33 PM, Simon Brereton wrote: > >>> The checks "above" permit_mynetworks and permit_sasl_authenticated >>> are checks you want applied to your networks and authenticated >>> users. Generally it's better to put those checks in >>> smtpd_sender_restrictions. >> >> But I thought the recommended best practice was >> to have it all in smtpd_recipient_restrictions.. :( > > That's a guideline, not a best practices -- big difference. > If you want to apply some restriction to ALL connections -- both > your own senders and outside mail -- it makes sense to put it in a > different section. > > And mostly applies to access tables (check_*_access) since those > must be handled carefully. Finally, I get it (thanks Wietse and Jim).. I was confusing the binary (in most cases) action of check_*_access with the REJECT access of reject_* So, these should be fine anywhere be fine anywhere before reject_unauth_destination... reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, reject_unknown_sender_domain, reject_unknown_recipient_domain, If I put them above mynetworks it applies to my networks too, but doesn't make me an open relay. And I put them above permit_sasl_auth then it applies to all connections (but the HELO ones would likely knock out any road-warriers (but they should be using the submission port anyway, right)? Thanks again for your patience and guidance. Simon
Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch
On 2 November 2011 16:26, James Seymour wrote: > On Wed, 2 Nov 2011 16:12:07 -0400 > Simon Brereton wrote: > > [snip] >> ... but if I put reject_unknown_recipient_domain there >> postconf.5 says it will >> >> Reject the request when Postfix is not final destination for the >> recipient domain, and the RCPT TO domain has no DNS A or MX record, or >> when it has a malformed MX record such as a record with a zero-length >> MX hostname (Postfix version 2.3 and later). >> >> Unless that's meant to say it will Reject the request when Postfix is >> not final destination for the recipient domain, OR the RCPT TO domain >> has no DNS A or MX record, or when it has a malformed MX > > No, it means just what it says it means. If the local Postfix instance > is the final destination it will accept it. Or if a destination for > the RCPT domain can be determined it will accept it. If the local > Postfix instance is not the final destination or it cannot determine > what is, it will be rejected. Well, I think my postulation was closer to your explanation, but either way it's clear now. I'll restore them above mynetworks. Thank-you. Simon
Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch
On 2 November 2011 15:53, James Seymour wrote: > On Tue, 1 Nov 2011 14:31:14 -0400 > Simon Brereton wrote: > > [snip] >> >> ## SPAM STUFF and REJECT CODES ## >> smtpd_recipient_restrictions = >> reject_non_fqdn_sender, >> reject_non_fqdn_recipient, >> permit_sasl_authenticated, >> check_helo_access hash:/etc/postfix/helo_checks, >> permit_mynetworks, > [snip] >> >> Jim Seymour has these two ABOVE permit_mynetworks - > [snip] > > I don't know to which two you refer, but I have what I have above > permit_mynetworks because I want them to apply to even my own local > users. Yes, that was my understanding when I followed your original instructions. But Rob and Noel were telling me that I had too much stuff before reject_unauth_destination.. I was referring to these two: reject_unknown_sender_domain, reject_unknown_recipient_domain, I guess this is a little off-topic now, but I can see why reject_unknown_sender_domain before permit_mynetworks would be sensible - it's stops my users trying to mail with a randomgibberish.tld but if I put reject_unknown_recipient_domain there postconf.5 says it will Reject the request when Postfix is not final destination for the recipient domain, and the RCPT TO domain has no DNS A or MX record, or when it has a malformed MX record such as a record with a zero-length MX hostname (Postfix version 2.3 and later). Unless that's meant to say it will Reject the request when Postfix is not final destination for the recipient domain, OR the RCPT TO domain has no DNS A or MX record, or when it has a malformed MX Simon
Re: MIME Parser Error - Can't Send Email
On 2 November 2011 15:53, Carlos Mennens wrote: > On Wed, Nov 2, 2011 at 3:38 PM, Ralf Hildebrandt > wrote: >> That's probably amavis, not postfix >> Look at the amavis messages in your mail.log > > I think you're right. Postfix appears to be working fine. I'll view > the logs and hit up the Amavisd-new mailing list. Sadly nothing in > /var/log/maillog shows any entries written from Amavis. Just Postfix & > Dovecot. First try to restart amavis - fwiw.. Simon
Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch
On 1 November 2011 18:53, Noel Jones wrote: > On 11/1/2011 1:31 PM, Simon Brereton wrote: >> On 31 October 2011 15:16, Noel Jones wrote: >>> On 10/31/2011 12:31 PM, Simon Brereton wrote: >>>> Googling led me to this thread: >>>> http://comments.gmane.org/gmane.mail.postfix.user/210413 >>>> >>>> But I don't understand how myu...@example.com is not owned by >>>> myu...@example.com >>> >>> Apparently this user didn't authenticate. >>> You define who owns what address in smtpd_sender_login_maps. There >>> are no "automatic" mappings. >> >> Okay, so without smtpd_sender_login_maps those restrictions are worthless, >> yes? > > Right. You must define the user <-> sender address mapping. >> ## SPAM STUFF and REJECT CODES ## >> smtpd_recipient_restrictions = >> reject_non_fqdn_sender, >> reject_non_fqdn_recipient, >> permit_sasl_authenticated, >> check_helo_access hash:/etc/postfix/helo_checks, >> permit_mynetworks, >> reject_unauth_destination, >> reject_unlisted_recipient, >> check_recipient_access hash:/etc/postfix/laxdomains, (this is >> one domain I host that doesn't want the checking done below) >> check_client_access hash:/etc/postfix/ip_whitelist, >> reject_invalid_helo_hostname, >> reject_non_fqdn_helo_hostname, >> reject_unknown_helo_hostname, >> reject_unknown_sender_domain, >> reject_unknown_recipient_domain, >> >> Jim Seymour has these two ABOVE permit_mynetworks - which I can see >> for the sender_domain, but if the recipient_domain was above >> permit_mynetworks, then wouldn't postfix reject everything that wasn't >> in $mydestination? So, should it be above or below? And surely if it >> should be above, then so should the helo_hostname checks, no? > > The checks "above" permit_mynetworks and permit_sasl_authenticated > are checks you want applied to your networks and authenticated > users. Generally it's better to put those checks in > smtpd_sender_restrictions. Gah. There's like 5 people on this list I force myself to obey and you're one of them... But I thought the recommended best practice was to have it all in smtpd_recipient_restrictions.. :( So if I take them out of there, and add in: smtpd_sender_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, permit it won't break anything? Won't make me an open relay and won't make a backscatterer? Simon
Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch
On 31 October 2011 15:16, Noel Jones wrote: > On 10/31/2011 12:31 PM, Simon Brereton wrote: >> Googling led me to this thread: >> http://comments.gmane.org/gmane.mail.postfix.user/210413 >> >> But I don't understand how myu...@example.com is not owned by >> myu...@example.com > > Apparently this user didn't authenticate. > You define who owns what address in smtpd_sender_login_maps. There > are no "automatic" mappings. Okay, so without smtpd_sender_login_maps those restrictions are worthless, yes? >> mail:~# postconf -n | grep smtpd_recipient_restrictions >> smtpd_recipient_restrictions = >> reject_non_fqdn_sender, >> reject_non_fqdn_recipient, >> reject_sender_login_mismatch, >> permit_sasl_authenticated, > > This should be followed by "permit_mynetworks, > reject_unauth_destination," followed by your other UCE checks. > check_sender_access is to check the sender email address, and will > never match an IP. You must use check_client_access to whitelist by IP. Nice catch - thanks. >> reject_unlisted_recipient, >> check_policy_service unix:private/policy-spf, >> check_policy_service inet:127.0.0.1:10031, >> reject_rbl_client bl.spamcop.net, >> reject_rbl_client zen.spamhaus.org, >> reject_rbl_client cbl.abuseat.org, > > cbl is included in zen, so this is a duplicate. This is what I was told - but it's always cbl that does the blocking in the logs. I seldom get a result for zen. >> reject_rbl_client blackholes.mail-abuse.org, > > Do you pay for a subscription to mail-abuse.org? Otherwise this > won't work. I haven't looked at these in a while - removed. >> warn_if_reject, reject_unknown_client, >> warn_if_reject, reject_rhsbl_client dsn.rfc-ignorant.org, >> warn_if_reject, reject_rbl_client dnsbl.sorbs.net, >> warn_if_reject, reject_rbl_client dnsbl.njabl.org, >> warn_if_reject, reject_rbl_client dul.dnsbl.sorbs.net, >> permit It's still not clear to me if I need each warn_if_reject, or if I can just use one. I.e. warn_if_reject, reject_unknown_client, reject_rbl_client tw.countries.nerd.dk, reject_rbl_client kr.countries.nerd.dk, reject_rbl_client cn.countries.nerd.dk, reject_rhsbl_client dsn.rfc-ignorant.org, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client dnsbl.njabl.org, reject_rbl_client dul.dnsbl.sorbs.net, permit >> check_recipient_access hash:/etc/postfix/laxdomains, >> reject_unknown_sender_domain, >> reject_unknown_recipient_domain, >> reject_invalid_helo_hostname, >> reject_non_fqdn_helo_hostname, >> reject_unknown_helo_hostname, >> check_sender_access hash:/etc/postfix/backscatter >> check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, >> permit_mynetworks, >> reject_unauth_destination, > > This is dangerously late for reject_unauth_destination. You should > move it above any check_*_access maps. This is problem with adding things over time. And sometimes I get really confused - to whit. ## SPAM STUFF and REJECT CODES ## smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, permit_sasl_authenticated, check_helo_access hash:/etc/postfix/helo_checks, permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, check_recipient_access hash:/etc/postfix/laxdomains, (this is one domain I host that doesn't want the checking done below) check_client_access hash:/etc/postfix/ip_whitelist, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, reject_unknown_sender_domain, reject_unknown_recipient_domain, Jim Seymour has these two ABOVE permit_mynetworks - which I can see for the sender_domain, but if the recipient_domain was above permit_mynetworks, then wouldn't postfix reject everything that wasn't in $mydestination? So, should it be above or below? And surely if it should be above, then so should the helo_hostname checks, no? check_sender_access hash:/etc/postfix/backscatter check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, check_policy_service unix:private/policy-spf, check_policy_service inet:127.0.0.1:10031, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org, warn_if_reject, reject_unknown_client, warn_if_reject, reject_rbl_client tw.countries.nerd.dk, warn_if_reject, reject_rbl_client kr.countr
Re: reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch
On 31 October 2011 15:16, Noel Jones wrote: > On 10/31/2011 12:31 PM, Simon Brereton wrote: >> Hi >> >> I was evaluating my smptd_recipient_restrictions last week and decided that >> it made no sense to have reject_sender_login_mismatch after >> permit_sasl_authenticated. So I changed it. At the time I was reviewing >> the documentation I wasn't able to figure out the difference between >> reject_authenticated_sender_login_mismatch and reject_sender_login_mismatch. > > Did you see this? > http://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch > > With the "authenticated" version, the sender address is only checked > if the user has authenticated. This allows unauthenticated mail to > use a protected sender address, which may be needed for > notification/invitation services etc. that "spoof" the sender > address for incoming mail. > >> >> Since then I have a few items in the logs like: >> >> Oct 30 17:59:40 mail postfix/smtpd[21281]: connect from >> cpc17cable-connection.cableprovider.com[12.34.56.78] >> Oct 30 17:59:40 mail postfix/smtpd[21281]: setting up TLS connection from >> cpc17cable-connection.cableprovider.com[12.34.56.78] >> Oct 30 17:59:40 mail postfix/smtpd[21281]: Anonymous TLS connection >> established from cpc17cable-connection.cableprovider.com[12.34.56.78]: TLSv1 >> with cipher AES128-SHA (128/128 bits) >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from >> cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 >> : Sender address rejected: not owned by user >> myu...@example.com; from= to= >> proto=ESMTP helo= >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from >> cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 >> : Sender address rejected: not owned by user >> myu...@example.com; from= to= >> proto=ESMTP helo= >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from >> cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 >> : Sender address rejected: not owned by user >> myu...@example.com; from= to= >> proto=ESMTP helo= >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from >> cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 >> : Sender address rejected: not owned by user >> myu...@example.com; from= to= >> proto=ESMTP helo= >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from >> cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 >> : Sender address rejected: not owned by user >> myu...@example.com; from= to= >> proto=ESMTP helo= >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from >> cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 >> : Sender address rejected: not owned by user >> myu...@example.com; from= to= >> proto=ESMTP helo= >> Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from >> cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 >> : Sender address rejected: not owned by user >> myu...@example.com; from= >> to= proto=ESMTP helo= >> Oct 30 18:09:43 mail postfix/smtpd[21281]: timeout after RCPT from >> cpc17cable-connection.cableprovider.com[12.34.56.78] >> Oct 30 18:09:43 mail postfix/smtpd[21281]: disconnect from >> cpc17cable-connection.cableprovider.com[12.34.56.78] >> >> Googling led me to this thread: >> http://comments.gmane.org/gmane.mail.postfix.user/210413 >> >> But I don't understand how myu...@example.com is not owned by >> myu...@example.com > > Apparently this user didn't authenticate. > You define who owns what address in smtpd_sender_login_maps. There > are no "automatic" mappings. Thanks again Noel. That helps my understanding. Cheers Simon
reject_authenticated_sender_login_mismatch vs reject_sender_login_mismatch
Hi I was evaluating my smptd_recipient_restrictions last week and decided that it made no sense to have reject_sender_login_mismatch after permit_sasl_authenticated. So I changed it. At the time I was reviewing the documentation I wasn't able to figure out the difference between reject_authenticated_sender_login_mismatch and reject_sender_login_mismatch. Since then I have a few items in the logs like: Oct 30 17:59:40 mail postfix/smtpd[21281]: connect from cpc17cable-connection.cableprovider.com[12.34.56.78] Oct 30 17:59:40 mail postfix/smtpd[21281]: setting up TLS connection from cpc17cable-connection.cableprovider.com[12.34.56.78] Oct 30 17:59:40 mail postfix/smtpd[21281]: Anonymous TLS connection established from cpc17cable-connection.cableprovider.com[12.34.56.78]: TLSv1 with cipher AES128-SHA (128/128 bits) Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 : Sender address rejected: not owned by user myu...@example.com; from= to= proto=ESMTP helo= Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 : Sender address rejected: not owned by user myu...@example.com; from= to= proto=ESMTP helo= Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 : Sender address rejected: not owned by user myu...@example.com; from= to= proto=ESMTP helo= Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 : Sender address rejected: not owned by user myu...@example.com; from= to= proto=ESMTP helo= Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 : Sender address rejected: not owned by user myu...@example.com; from= to= proto=ESMTP helo= Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 : Sender address rejected: not owned by user myu...@example.com; from= to= proto=ESMTP helo= Oct 30 17:59:43 mail postfix/smtpd[21281]: NOQUEUE: reject: RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78]: 553 5.7.1 : Sender address rejected: not owned by user myu...@example.com; from= to= proto=ESMTP helo= Oct 30 18:09:43 mail postfix/smtpd[21281]: timeout after RCPT from cpc17cable-connection.cableprovider.com[12.34.56.78] Oct 30 18:09:43 mail postfix/smtpd[21281]: disconnect from cpc17cable-connection.cableprovider.com[12.34.56.78] Googling led me to this thread: http://comments.gmane.org/gmane.mail.postfix.user/210413 But I don't understand how myu...@example.com is not owned by myu...@example.com What is the purpose of reject_authenticated_sender_login_mismatch and reject_sender_login_mismatch and should it come before or after permit_sasl_auth? mail:~# postconf -n | grep smtpd_recipient_restrictions smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_sender_login_mismatch, permit_sasl_authenticated, check_helo_access hash:/etc/postfix/helo_checks,check_sender_access hash:/etc/postfix/ip_whitelist, check_recipient_access hash:/etc/postfix/laxdomains,reject_unknown_sender_domain, reject_unknown_recipient_domain,reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, check_sender_access hash:/etc/postfix/backscatter check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, check_policy_service unix:private/policy-spf, check_policy_service inet:127.0.0.1:10031, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client blackholes.mail-abuse.org, reject_rbl_client tw.countries.nerd.dk, reject_rbl_client kr.countries.nerd.dk, reject_rbl_client cn.countries.nerd.dk, reject_rbl_client relays.mail-abuse.org,warn_if_reject, reject_unknown_client, warn_if_reject, reject_rhsbl_client dsn.rfc-ignorant.org, warn_if_reject, reject_rbl_client dnsbl.sorbs.net, warn_if_reject, reject_rbl_client dnsbl.njabl.org, warn_if_reject, reject_rbl_client dul.dnsbl.sorbs.net,permit Postfix is 2.7.1 installed via apt-get on Debian. Thanks. Simon
Re: smtpd_recipient_restrictions
On 27 October 2011 12:07, /dev/rob0 wrote: > On Thursday 27 October 2011 10:32:54 Simon Brereton wrote: >> I know this gets beaten to death on a regular basis, but sometimes > > Indeed it does, such as ... today! Read the "Config check" thread. It's tricky enough understanding my config, let alone someone else's but it did raise some of the questions I had and I didn't want to piggy back.. > I wouldn't trust Spamcop for outright rejection, but it is useful in > postscreen(8) scoring. I've never had a false-positive. If anything it's not useful enough (considering it's supposed to add IPs on a real-time basis). >> This stuff builds up over time and I find I can't always remember >> the rational for putting things in the order I put them. One >> point of concern that I have is that when I added in the >> policy-spf the warnings were clear that it needs to go after >> reject_unauth_destination otherwise it turns the box into an open >> relay. The same logic should apply to the policyd service, yes? > > As well as to anything which might return permit or OK. See the other > thread, and the link posted therein. > >> But yet there it is above reject_unauth_destination and the online >> but http://www.checkor.com/ and >> http://verify.abuse.net/cgi-bin/relaytest says I'm not an open >> relay, so I'm confused. > > You probably are open for certain relay attempts. An online checker > cannot test for all possible combinations of sender, EHLO, et c. Cheers. I'll fix that. >> Looking over the list though, I propose: >> >> ## SPAM STUFF and REJECT CODES ## >> smtpd_recipient_restrictions = reject_non_fqdn_sender, >> reject_non_fqdn_recipient, >> reject_sender_login_mismatch, >> # shouldn't this be before permit_sasl? > > Yes, if you're using that. Also a good idea to put user submission on > a separate smtpd(8) service. Submission port is open but not all clients can use it, so we remain open on 25 for SASL authentication. That may change in the future. Whilst rereading postconf.5 I found: reject_authenticated_sender_login_mismatch Enforces the reject_sender_login_mismatch restriction for authenticated clients only. This feature is available in Postfix version 2.1 and later. reject_unauthenticated_sender_login_mismatch Enforces the reject_sender_login_mismatch restriction for authenticated clients only. This feature is available in Postfix version 2.1 and later. Should I add those in here (or only on the submission port)? I don't really understand their usage. Surely if sender login is mismatched, that's not authenticated? So my understanding (clearly wrong) is that reject_unauthenticated_sender_login_mismatch = reject_sender_login_mismatch and reject_authenticated_sender_login_mismatch can't happen because a mismatch wouldn't authenticate the sender! What have I missed? >> I'd be grateful for comments/suggestions. Are there newer/better >> RBLs I should be using? > > Quality of DNSBL is more important than quality. I have posted my > postscreen rules which are doing a very good job. I'd recommend that > you look that up and consider upgrading if you are pre-2.8. > > Also, the Barracuda BRBL is a very nice service, almost on par with > Zen in terms of effectiveness, and has seemed very safe here. 2.8 is waiting for a debian port :) My understanding is that once 2.8 is installed I don't need the policyd (at least not for grey-listing, but it might be useful for other things. At that stage I'll probably upgrade it to 2.0 anyway and see what new features it has. Haven't seen Cami on here in a while though.. I appreciate the advice and patience. Simon
smtpd_recipient_restrictions
Hi I know this gets beaten to death on a regular basis, but sometimes I get in a muddle and I'd appreciate a sanity check. Currently my main.cf looks like: ## SPAM STUFF and REJECT CODES ## smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, permit_sasl_authenticated, reject_sender_login_mismatch, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/ip_whitelist, check_recipient_access hash:/etc/postfix/laxdomains, check_sender_access hash:/etc/postfix/backscatter reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, permit_mynetworks, check_policy_service inet:127.0.0.1:10031, reject_unlisted_recipient, reject_unauth_destination, check_policy_service unix:private/policy-spf, reject_rbl_client bl.spamcop.net, reject_rbl_client cbl.abuseat.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client blackholes.mail-abuse.org, reject_rbl_client tw.countries.nerd.dk, reject_rbl_client kr.countries.nerd.dk, reject_rbl_client cn.countries.nerd.dk, reject_rbl_client relays.mail-abuse.org, reject_rhsbl_sender dsn.rfc-ignorant.org, warn_if_reject, reject_unknown_client, warn_if_reject, reject_rhsbl_client dsn.rfc-ignorant.org, warn_if_reject, reject_rbl_client dnsbl.sorbs.net, warn_if_reject, reject_rbl_client dnsbl.njabl.org, warn_if_reject, reject_rbl_client dul.dnsbl.sorbs.net, permit This stuff builds up over time and I find I can't always remember the rational for putting things in the order I put them. One point of concern that I have is that when I added in the policy-spf the warnings were clear that it needs to go after reject_unauth_destination otherwise it turns the box into an open relay. The same logic should apply to the policyd service, yes? But yet there it is above reject_unauth_destination and the online but http://www.checkor.com/ and http://verify.abuse.net/cgi-bin/relaytest says I'm not an open relay, so I'm confused. Looking over the list though, I propose: ## SPAM STUFF and REJECT CODES ## smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_sender_login_mismatch, # shouldn't this be before permit_sasl? permit_sasl_authenticated, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/ip_whitelist, check_recipient_access hash:/etc/postfix/laxdomains, #domains that don't want grey-listing and rigourous helo checking - would be better to put this after unknown_recipient_domain, yes? reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, check_sender_access hash:/etc/postfix/backscatter # the other items will catch more and should therefore come first, yes? permit_mynetworks, reject_unlisted_recipient, reject_unauth_destination, # does the order of reject_unlisted and reject_unauth matter? Both are mysql lookups but domain should come before recipient, no? check_policy_service unix:private/policy-spf, check_policy_service inet:127.0.0.1:10031, # makes sense to put the grey-listing after SPF verified hosts, yes? reject_rbl_client bl.spamcop.net, reject_rbl_client cbl.abuseat.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client blackholes.mail-abuse.org, reject_rbl_client tw.countries.nerd.dk, reject_rbl_client kr.countries.nerd.dk, reject_rbl_client cn.countries.nerd.dk, reject_rbl_client relays.mail-abuse.org, reject_rhsbl_sender dsn.rfc-ignorant.org, warn_if_reject, reject_unknown_client, warn_if_reject, reject_rhsbl_client dsn.rfc-ignorant.org, warn_if_reject, reject_rbl_client dnsbl.sorbs.net, warn_if_reject, reject_rbl_client dnsbl.njabl.org, warn_if_reject, reject_rbl_client dul.dnsbl.sorbs.net, # can I group all the warn_if_rejects? Permit I'd be grateful for comments/suggestions. Are there newer/better RBLs I should be using? Simon
Re: Send periodic announcement to our customers
On 27 October 2011 07:42, nima chavooshi wrote: > Hi > In our company we want to send periodic announcement or newsletter mail to > our customers (approximate 5 e-mail). because most of our customers have > email account on yahoo and google and AOL mail services, I concern about > that these mail services detect our emails as spam! > Is there any recommendation for send bulk mail ? > Thanks in advance How have you acquired the email address of these "customers"? Because if you haven't acquired them through a double op-in process (either a link confirmation or email reply), no amount of SPF and DKIM records (which are what you need to investigate) are going to keep you out of spam filters. Simon
Re: Using Postfix to check and verify SPF
On 26 October 2011 10:27, Scott Kitterman wrote: > On 10/26/2011 10:17 AM, Simon Brereton wrote: > ... >> >> So my obvious question to the list is - Can I get amavis to explicity >> add a header with the SPF validity, and if not, can I do this with >> policyd? And if not, and I must install postfix-policyd-spf-python >> or postfix-policyd-spf-perl which do you recommend and why? > > There is an amavis user list that you should consult for amavis support. True - but most people use it. Googling didn't help, so it's unlikely that it can do it - still worth asking the wise people here though. > postfix-policyd-spf-perl is very simple and is, IMO, not suitable for > anything other than hobby installs. postfix-policyd-spf-python is well > documented, supports a wide variety of configurations for different uses and > is much more complete. > > I'm the last one to do any work on the Perl implementation and the developer > of the Python implementation. Unless you are severely allergic to Python > and prepared to read/modify Perl source, I'd use the Python one. It is > available as a distribution package in many distros. Thanks for the advice. Curiously for a "hobby installs" package it has more howtos and documentation on Google. I'm not adverse to python, but I'd still like reassurance that two policy filters is the way to go.. For my edification, where would you put it in my restrictions? smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, permit_sasl_authenticated, reject_sender_login_mismatch, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/ip_whitelist, check_recipient_access hash:/etc/postfix/laxdomains, check_sender_access hash:/etc/postfix/backscatter reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre permit_mynetworks, check_policy_service inet:127.0.0.1:10031, reject_unlisted_recipient, reject_unauth_destination, reject_rbl_client bl.spamcop.net, reject_rbl_client cbl.abuseat.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client blackholes.mail-abuse.org, reject_rbl_client tw.countries.nerd.dk, reject_rbl_client kr.countries.nerd.dk, reject_rbl_client cn.countries.nerd.dk, reject_rbl_client relays.mail-abuse.org, reject_rhsbl_sender dsn.rfc-ignorant.org, warn_if_reject, reject_unknown_client, warn_if_reject, reject_rhsbl_client dsn.rfc-ignorant.org, warn_if_reject, reject_rbl_client dnsbl.sorbs.net, warn_if_reject, reject_rbl_client dnsbl.njabl.org, warn_if_reject, reject_rbl_client dul.dnsbl.sorbs.net, permit Simon
Using Postfix to check and verify SPF
Hi I finally got around to implementing SPF for my mail server and domains. A lot easier than I thought it would be, certainly much easier than DKIM and I'm ashamed I didn't do it earlier. In the course of doing that, I noticed that gmail/yahoo both add X-Headers about the validity of the SPF record. I would like to do the same. It doesn't, however, seem sensible to me to have the MTA do that if the content-filter will do it - so I fiddled around with amavis, installed Mail::SPF and now amavis purports to check the SPF record. Well, and good, except that a) it doesn't add a specific tag line about the SPF validity (unless it's a fail) and b) I probably want to REJECT forged mail and not DISCARD or TAG.. Although the last option isn't the worst option in the world. Looking at how to get postfix to do the lifting on this, I find on http://www.postfix.org/addon.html that " Note: Postfix already ships with SPF support, in the form of a plug-in policy daemon. This is the preferred integration model, at least until SPF is mandated by standards." Well and good - but I don't seem to find further information in the documentation. Added to which, I already pass incoming mail off to postfix-policyd for greylisting. Do I really want to pass it off to a separate content filter adding even more hops? On http://www.postfix.org/docs.html I found http://www.freesoftwaremagazine.com/articles/focus_spam_postfix?page=0%2C1# which says " use the smtpd-policy.pl script that ships with Postfix to handle SPF, and Postgrey as an add-on greylisting policy server. They’re defined in my master.cf file as: spfpolicy unix - nn - - spawn user=nobody argv=/usr/bin/perl /usr/local/libexec/postfix/smtpd-policy.pl" But I don't find smtpd-policy.pl in the files installed with Postfix - so I assume that's poetic licence..? And it's actually installed from postfix-policyd-spf-perl, yes? But I notice there's also a python option - postfix-policyd-spf-python. So my obvious question to the list is - Can I get amavis to explicity add a header with the SPF validity, and if not, can I do this with policyd? And if not, and I must install postfix-policyd-spf-python or postfix-policyd-spf-perl which do you recommend and why? Thanks. Simon
Re: A Problem No One Has Solved According To Googling
On 25 October 2011 15:06, Jack Fredrikson wrote:
> Here is a problem that many postfix users have had that has apparently never
> been resolved! I appeal to you for your help. I have been googling this for
> a very long time now. Here is my problem
>
> Oct 25 10:49:18 myserver postfix/pipe[3712]: 0423257901AB: to=,
> relay=dovecot, delay=109318, delays=109318/0.14/0/0.1, dsn=4.3.0,
> status=deferred (temporary failure
> Look at this comment I found while googling:
> http://blog.absolutedisaster.co.uk/osticket-plesk-9-postfix-pipe-mail-to-a-progr
> From the maillog:
> 1.
> Oct 1 14:10:39 serverXXX-XX pipe[9594]: fatal: pipe_command: execvp /var/www/vhosts/{domain}.com/subdomains/support/httpdocs/api/pipe.php: Permission denied
> 2.
> Oct 1 14:10:39 serverXXX-XX postfix/pipe[9088]: EF2541117B5: to=, relay=pipeSupportEmails, delay=3.5, delays=3.4/0/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: pipe: fatal: pipe_command: execvp /var/www/vhosts/{domain}.com/subdomains/support/httpdocs/api/pipe.php: Permission denied )
Two very different errors.
Simon
Re: I've Got To Be Close...
On 24 October 2011 11:20, Jack Fredrikson wrote:
> Hi;
> I'm still getting this (and *only* this) error:
> Oct 24 08:18:01 myserver postfix/pipe[21761]: 5CC9F5790195:
> to=, relay=dovecot, delay=0.66, delays=0.64/0/0/0.02,
> dsn=4.3.0, status=deferred (temporary failure)
Sounds like your file permissions on the mail spool are wrong. Check
your a) your dovecot conf and test with 666 and b) make sure dovecot
(since that's what you're using to do the delivery) is the owner of
that directory.
Somewhere in this section...
> master {
> path = /var/run/dovecot/auth-master
> mode = 0660
> user = vmail
> group = mail
> }
> client {
> path = /var/spool/postfix/private/auth
> mode = 0660
> user = postfix
> group = mail
> }
And this is probably better off discussed on the dovecot list now that
you seem to have gotten postfix sorted out.
Although, since you expressed an intention to do spam filtering, I'd
suggest once you have resolved this problem come back here with a
postconf -n and ask for some hardening tips. But you can start here:
http://linxnet.com/postfix_contrib.html
Simon
> queue_directory = /var/spool/postfix
> myorigin = $mydomain
> command_directory = /usr/sbin
> daemon_directory = /usr/libexec/postfix
> mail_owner = postfix
> inet_interfaces = all
> unknown_local_recipient_reject_code = 550
> debug_peer_list =
> sendmail_path = /usr/sbin/sendmail.postfix
> newaliases_path = /usr/bin/newaliases
> mailq_path = /usr/bin/mailq
> setgid_group = postdrop
> html_directory = no
> manpage_directory = /usr/local/man
> sample_directory = /etc/postfix
> readme_directory = no
> mydomain = myserver.com
> mydestination =
> $mydomain,
> $myhostname,
> localhost.$mydomain
> mail_spool_directory = /var/spool/mail
> home_mailbox = Mailbox
> disable_vrfy_command = yes
> show_user_unknown_table_name = no
> data_directory = /var/lib/postfix
> myhostname = myserver.com
> inet_interfaces = localhost, $myhostname
> mynetworks = $config_directory/mynetworks
> relay_domains =
> proxy:mysql:$config_directory/mysql_relay_domains_maps.cf
> virtual_mailbox_base = /var/vmail
> virtual_mailbox_domains = bar.com another.com myserver.com
> virtual_mailbox_maps = hash:/etc/postfix/vmailbox
> virtual_alias_maps = hash:/etc/postfix/virtual
> virtual_minimum_uid = 89
> virtual_uid_maps = static:89
> virtual_gid_maps = static:89
> virtual_transport = dovecot
> dovecot_destination_recipient_limit = 1
> smtpd_sasl_auth_enable = yes
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated, reject_unauth_destination
> smtpd_sasl_security_options = noanonymous
> broken_sasl_auth_clients = yes
> smtpd_sasl_type = dovecot
> smtpd_sasl_path = /var/spool/postfix/private/auth
> smtpd_sasl_application_name = smtpd
> smtpd_soft_error_limit = 10
> smtpd_hard_error_limit = 20
> smtpd_helo_required = yes
> disable_vrfy_command = yes
> non_fqdn_reject_code = 504
> invalid_hostname_reject_code = 450
> maps_rbl_reject_code = 554
> alias_maps = hash:/etc/aliases
> reject_unknown_client = false
> reject_unknown_hostname = false
> mailbox_command = /usr/local/libexec/dovecot/deliver
>
> Please advise.
> TIA,
> Jack
>
>
Re: Down To One Problem?
On 23 October 2011 13:13, Jack Fredrikson wrote:
> I may be dreaming, but this could be my last problem with my installation.
> After following all your good advice, I still have this one problem and it
> is pervasive in all emails:
> Oct 23 09:50:58 myserver postfix/pipe[30578]: BB2BB5790262:
> to=, relay=dovecot, delay=12684, delays=12683/0.18/0/0.27,
> dsn=4.3.0, status=deferred (temporary failure. Command output: doveconf:
> Warning: NOTE: You can get a new clean config file with: doveconf -n >
> dovecot-new.conf doveconf: Warning: Obsolete setting in
> /usr/local/etc/dovecot/dovecot.conf:5: imap_client_workarounds=outlook-idle
> is no longer necessary doveconf: Warning: Obsolete setting in
> /usr/local/etc/dovecot/dovecot.conf:17: add auth_ prefix to all settings
> inside auth {} and remove the auth {} section completely doveconf: Warning:
> Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:19: passdb pam {}
> has been replaced by passdb { driver=pam } doveconf: Warning: Obsolete
> setting in /usr/local/etc/dovecot/dovecot.conf:21: userdb passwd {} has been
> replaced by userdb { driver=passwd } doveconf: Warning: Obsolete setting in
> /usr/local/etc/dovecot/dovecot.conf:23: auth_user has been replaced by
> service auth { user } dov
>
> The strange thing about this is that googling "temporary failure. Command
> output: doveconf: Warning: NOTE: You can get a new" brings up only
> references to my post on this subject to the dovecot mailing list (which has
> not responded)! That is, it appears nobody else has this problem! With
> everyone else it's a matter of "Commad output: doveconf" throwing out some
> error. So, what's the confounded problem?!
Probably best off asking on Dovecot about this one - but as I recall
you started with an ancient version of Dovecot. So if you didn't get
rid of it completely you may well be using an old style config which
is causing the errors.
Open up your dovecot conf and have a look at these specific items...
Warning: Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:5:
imap_client_workarounds=outlook-idle is no longer necessary
Warning: Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:17:
add auth_ prefix to all settings inside auth {} and remove the auth {}
section completely
Warning: Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:19:
passdb pam {} has been replaced by passdb { driver=pam }
Warning: Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:21:
userdb passwd {} has been replaced by userdb { driver=passwd }
Warning: Obsolete setting in /usr/local/etc/dovecot/dovecot.conf:23:
auth_user has been replaced by service auth { user } dov
My advice would be to do what it says and start with a new config.
Back up your old one for SQL specific stuff, run You can get a new
clean config file with: doveconf -n >> dovecot-new.conf doveconf as
suggested and start from there.
Simon
Re: First Insallation, Bouncing Emails
2011/10/21 Leslie León Sinclair : > Something like: > > > user = user_for_db > password = password_for_db > hosts = localhost > dbname = database_name > query = SELECT goto FROM alias WHERE address='%s' AND active = '1' > Thanks. But I think we should see what the OP has in his. As someone already pointed out, if it's not using the correct quote it will be misinterpreted. Simon
Re: First Insallation, Bouncing Emails
On 21 October 2011 10:52, Jack Fredrikson wrote: > > From: Reindl Harald > To: postfix-users@postfix.org > Sent: Friday, October 21, 2011 10:39 AM > Subject: Re: First Insallation, Bouncing Emails > > > I'm on CentOS, not Debian > > Ralf Hildebrandt writes: > >>> Oct 20 10:13:57 example postfix/proxymap[28446]: warning: mysql query >>> failed: You have an error in your SQL syntax; check the manual that >>> corresponds to your MySQL server version f >>> or the right syntax to use near '??gifteatszone.com??? AND active = 1' at >>> line 1 >>> Oct 20 10:13:57 example postfix/proxymap[28444]: warning: mysql query >>> failed: You have an error in your SQL syntax; check the manual that >>> corresponds to your MySQL server version f >>> or the right syntax to use near '??awakelunch.info??? AND active = 1' at >>> line 1 > >> Check those > > That error appears to come from a file called > /etc/postfix/mysql_virtual_alias_maps.cf that has this line: > SELECT goto FROM alias WHERE address = ‘%s’ AND active = 1 > Therefore, the address has question marks in it. Looks like a hacker, no? What does /etc/postfix/mysql_virtual_alias_maps.cf look like? Simon
Re: Content filter after DKIM proxy
On 18 October 2011 14:27, Noel Jones wrote: > On 10/18/2011 1:20 PM, Simon Brereton wrote: > >> I already use amavis to do the dkim checking on incoming mails. I'm >> using dkimproxy to sign outgoing mails (and I confess I only found out >> about opendkim after I'd set it up, so I'm not keen to change it at >> the moment - though of course, your vote carries significant weight. > > I think the hour or less it would take to get amavisd-new to sign > outgoing mail would be well spent. > > I think the hour or less it would take to replace dkimproxy with > OpenDKIM would be well spent. Awww.. But I just go it working! Seriously, I will take a look at the amavis idea. I had no idea amavis could do that. However, Steve made a good point - a standalone package might update and keep pace with standards. So I might investigate opendkim when I get the chance (I have a bunch of things to do with dovecot and procmail first. And I'd like to implement dnssec as well). Thanks for all the advice and feedback Noel. Simon
Re: Content filter after DKIM proxy
On 19 October 2011 14:04, Steve Jenkins wrote: > On Wed, Oct 19, 2011 at 12:03 PM, Steve Jenkins > wrote: >>> >>> The following isn't one of my normal walkthrough HowTo blog posts, but it >>> does contain some notes I wrote to myself about things to consider when >>> deploying OpenDKIM with Amavis-new. I've also got additional stuff there >>> detailing how to configure OpenDKIM, too (disclosure: I'm the maintainer of >>> the Fedora / EPEL OpenDKIM package). > > Drat - forgot the link. Sorry. :) > http://stevejenkins.com/blog/2011/02/tips-for-installing-amavis-new-clamav-and-spamassassin-using-postfix-on-fedora-12/ > SteveJ Cheers The biggest issue I had setting up dkimproxy wasn't dkimproxy - it was getting bind9 to behave. That said, I enjoyed your site. Some useful stuff there. Simon
Re: Content filter after DKIM proxy
On 18 October 2011 15:01, Simon Deziel wrote: > On 10/18/2011 01:41 PM, Simon Brereton wrote: >> On 18 October 2011 13:27, Simon Deziel wrote: >>> On 10/18/2011 01:12 PM, Simon Brereton wrote: >>>> Hi >>>> >>>> I expect that this is not recommended practice, but before I implemented >>>> DKIM signing, Amavis used to scan ALL mail - incoming and outgoing - and I >>>> was happy with that. >>> >>> I don't know if that's would suites you but Amavis is capable of >>> performing the DKIM verification/signature steps as well. >> >> Thanks. Yup, Amavis is checking DKIM signatures, but that's not what >> I was getting at. I want Amavis to scan and rate my users out-going >> mails as well as the incoming ones. > > Amavisd-new can do DKIM *signature* too, no need to add another content > filter for that. > > Once properly configured Amavisd-new will perform DKIM verification for > incoming emails and will DKIM sign your outgoing emails. This goes > without saying that Amavisd-new will do the usual virus/spam scoring on > both ways. > >> Prior to me implementing >> dkimproxy, it was doing that. I've added the amavis content filter to >> the socket and so far it's doing what I want (i.e. rating out-going >> mails) but it would be nice to have a sanity check as to whether >> that's the right way to do it. > > As outlined by Noel, the best setup is to have Amavisd-new doing all the > DKIM related checks and signatures. Thanks both of you. I had no idea. I'll look into it - it would certainly make admin easier. Simon
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 18 October 2011 14:17, Noel Jones wrote: > On 10/18/2011 12:04 PM, Simon Brereton wrote: >> On 13 October 2011 20:11, Noel Jones wrote: >>> The only place you should really care about encryption is if your >>> own clients submit SASL authenticated mail -- the far most common >>> auth mechanisms are PLAIN and LOGIN which really should be protected >>> inside a TLS connection. This is commonly controlled by using >>> "smtpd_tls_auth_only = yes", and if you use the recommended >>> submission port, setting '-o smtpd_enforce_tls=yes' on the >>> submission entry in master.cf. In these cases, if TLS isn't used or >>> doesn't work, the client can't transfer mail. >> >> >> Sorry to resurrect this - and gmail won't let me amend the subject. >> After reading this, I was concerned about my submission port >> settings.. I have: >> >> 10 submission inet n - n - - smtpd >> 11 -o smtpd_delay_reject=yes >> 12 -o receive_override_options=no_address_mappings >> 13 -o content_filter=dksign:[127.0.0.1]:10028 >> 14 -o smtpd_enforce_tls=yes >> 15 -o smtpd_sasl_auth_enable=yes >> 16 -o smtpd_client_restrictions=permit_sasl_authenticated,reject >> >> >> Is "smtpd_enforce_tls=yes" a suitable replacement/substitute for >> "smtpd_tls_auth_only = yes? > > They do different things; I expect most people use both. > > smtpd_enforce_tls is obsolete, instead use > -o smtpd_tls_security_level=encrypt > This setting will reject all mail from unencrypted connections. The > "encrypt" setting must not be used on a public-facing port 25, but > is widely used and recommended on the submission port. > > smtpd_tls_auth_only prevents postfix from offering or accepting the > AUTH command until after an encrypted session is started. It is > commonly used on both the submission port and on port 25. > Thanks for the clarification. I'm using both without an issue (so far - I'm waiting for the one user - and there's always one) to tell me their client has stopped working. Cheers Simon
Re: Content filter after DKIM proxy
On 18 October 2011 13:52, Noel Jones wrote: > On 10/18/2011 12:12 PM, Simon Brereton wrote: >> Hi >> >> I expect that this is not recommended practice, but before I implemented >> DKIM signing, Amavis used to scan ALL mail - incoming and outgoing - and I >> was happy with that. >> >> If I want Amavis to scan and rate the mail after dkim proxy has signed it, >> is that as simple as adding the content filter to the incoming socket? >> Curently when dkim returns the mail it looks like this (in master.cf).. >> >> ### local TCP socket for relay with dkimproxy.out >> 127.0.0.1:10029 inet n - n - 10 smtpd >> -o content_filter= >> -o >> receive_override_options=no_unknown_recipient_checks,no_header_body_checks >> -o >> smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject >> -o smtpd_authorized_xforward_hosts=127.0.0.0/8 >> >> If I add smtp-amavis:[127.0.0.1]:10024 (as it is in my main.cf, will this >> pass it off to amavis to be scanned? > > that looks OK, but see below. > > >> >> Is there a good reason to not do this? Is there a better way to do this? > > Yes and yes. Rather than using dkim-proxy, I strongly recommend > using the amavisd-new built-in DKIM signing and verifying. If you > can't use that for some reason, the other excellent choice is the > OpenDKIM milter. Using dkim-proxy is a distant third. > > Reasons include simpler setup and reliability. Thanks Noel. Clarity is not my strong point this week :( I already use amavis to do the dkim checking on incoming mails. I'm using dkimproxy to sign outgoing mails (and I confess I only found out about opendkim after I'd set it up, so I'm not keen to change it at the moment - though of course, your vote carries significant weight. What I was trying to do, and what've you confirmed works, and what I've since tested is to get amavis to scan for spam/viruses on outgoing mail. Since I'm only using dkimproxy to sign outgoing mails I can't have it sign them after they've been scanned by amavis (although I admit this would make more sense), since I would have to add the dkimproxy filter to the incoming amavis socket and then it would try to sign mails it has no business signing. Currently what I have - and I'm okay is: mail comes in on the submission port after auth and with enforced TLS. It is passed to dkimproxy to sign. Dkimproxy passes it to amavis to check for spam/viri and then passes it back to postfix who sends it out. (The fact that doing it this way means that amavis verifies the signature dkim JUST added is not optimal but acceptable). The main thing is that all outgoing mail (not just the ones clients or sendmail submit on port 25 have X-Scanned-by headers and a spam rating. I'm aware some hosts will strip those and replace them with their own, but I'd prefer they leave my site with them, than with not. Cheers Simon
Re: Content filter after DKIM proxy
On 18 October 2011 13:27, Simon Deziel wrote: > On 10/18/2011 01:12 PM, Simon Brereton wrote: >> Hi >> >> I expect that this is not recommended practice, but before I implemented >> DKIM signing, Amavis used to scan ALL mail - incoming and outgoing - and I >> was happy with that. > > I don't know if that's would suites you but Amavis is capable of > performing the DKIM verification/signature steps as well. Thanks. Yup, Amavis is checking DKIM signatures, but that's not what I was getting at. I want Amavis to scan and rate my users out-going mails as well as the incoming ones. Prior to me implementing dkimproxy, it was doing that. I've added the amavis content filter to the socket and so far it's doing what I want (i.e. rating out-going mails) but it would be nice to have a sanity check as to whether that's the right way to do it. Simon
Content filter after DKIM proxy
Hi I expect that this is not recommended practice, but before I implemented DKIM signing, Amavis used to scan ALL mail - incoming and outgoing - and I was happy with that. If I want Amavis to scan and rate the mail after dkim proxy has signed it, is that as simple as adding the content filter to the incoming socket? Curently when dkim returns the mail it looks like this (in master.cf).. ### local TCP socket for relay with dkimproxy.out 127.0.0.1:10029 inet n - n - 10 smtpd -o content_filter= -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject -o smtpd_authorized_xforward_hosts=127.0.0.0/8 If I add smtp-amavis:[127.0.0.1]:10024 (as it is in my main.cf, will this pass it off to amavis to be scanned? Is there a good reason to not do this? Is there a better way to do this? Thanks for any advice/pointers. Simon
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 13 October 2011 20:11, Noel Jones wrote: > The only place you should really care about encryption is if your > own clients submit SASL authenticated mail -- the far most common > auth mechanisms are PLAIN and LOGIN which really should be protected > inside a TLS connection. This is commonly controlled by using > "smtpd_tls_auth_only = yes", and if you use the recommended > submission port, setting '-o smtpd_enforce_tls=yes' on the > submission entry in master.cf. In these cases, if TLS isn't used or > doesn't work, the client can't transfer mail. Sorry to resurrect this - and gmail won't let me amend the subject. After reading this, I was concerned about my submission port settings.. I have: 10 submission inet n - n - - smtpd 11-o smtpd_delay_reject=yes 12-o receive_override_options=no_address_mappings 13-o content_filter=dksign:[127.0.0.1]:10028 14-o smtpd_enforce_tls=yes 15-o smtpd_sasl_auth_enable=yes 16-o smtpd_client_restrictions=permit_sasl_authenticated,reject Is "smtpd_enforce_tls=yes" a suitable replacement/substitute for "smtpd_tls_auth_only = yes? The TLS readme only talks about smtpd_tls_auth_only (and warns against it) for server-server connections. Simon
Re: Spammers attempting SASL auth.
On 17 October 2011 19:43, Stan Hoeppner wrote: > On 10/17/2011 10:50 AM, Simon Brereton wrote: > >> Does your approach for sending to abuse work for Roadrunner? I have >> 1000 pings a day from a host on RR cable and when I tried to email >> abb...@rr.com, the connection timed out and the mail sits in the queue >> for 5 days before timing out. > > Simon if you're having zombie problems and you're not yet using > postscreen (2.8 or later required), I suggest you give my FQrDNS based > PCRE table zombie/residential blocker a spin. It's super simple to > setup. Instructions are included as comments in the top of the PCRE file: > > http://www.hardwarefreak.com/fqrdns.pcre > > You didn't provide the connection info for the rr.com woodpecker, so I > can't verify if I'm blocking it. The table is currently blocking 7 rDNS > patterns in rr.com, most if not all of it. If it doesn't block your > particular rr.com woodpecker please provide the connection info and I'll > write another expression to kill it, or modify an existing one. Thanks Stan. I'll check that out. I am using postfix-policyd on 2.7.1 atm. My woodpecker is unfortunately pecking on dovecot - so fail2ban takes care of him every 4 failures Oct 17 05:26:58 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Oct 17 05:26:58 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Oct 17 05:47:00 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Oct 17 05:47:58 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Oct 17 05:47:58 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Oct 17 05:48:58 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Oct 17 05:48:58 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Oct 17 06:09:01 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Oct 17 06:09:58 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Oct 17 06:09:58 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Oct 17 06:10:58 mail dovecot: imap-login: Disconnected (no auth attempts): rip=74.66.25.222, lip=83.170.64.86, TLS handshaking: Disconnected Thanks to all for the help/perspective. Simon
Re: Spammers attempting SASL auth.
On 17 October 2011 11:38, John Hinton wrote: > On 10/17/2011 11:13 AM, Simon Brereton wrote: >> >> Hi >> >> This is a new one on me - I've never seen spammers attempt to use to SASL >> Auth to inject spam. Has anyone else seen this? >> >> Oct 17 15:07:16 mail postfix/smtpd[14422]: connect from >> unknown[208.86.147.92] >> Oct 17 15:07:16 mail dovecot: auth(default): >> passdb(newslet...@mydomain.net,208.86.147.92): Attempted login with password >> having illegal chars >> Oct 17 15:07:17 mail dovecot: pop3-login: Disconnected (auth failed, 1 >> attempts): user=, method=PLAIN, rip=208.86.147.92, >> lip=83.170.64.84 >> Oct 17 15:07:18 mail postfix/smtpd[14403]: warning: 208.86.147.92: >> hostname default-208-86-147-92.nsihosting.net verification failed: Name or >> service not known >> >> >> Simon >> > I use Fail2Ban to block (automatic firewall) these attempts. You can't be > too restrictive or you'll block real users trying to set up their email > accounts. Fail2Ban can be set to do a Whois lookup on the offending IP > address. If I see it is a US provider, I normally forward the message to the > abuse@ address and more times than not, they take care of the kiddie script > problem. > > Basically, they run dictionary attacks on every service available to the > public. Hi John - I can see it is a dictionary attack. I get loads of them and they don't worry me - I've just never had one try to authenticate for the purpose of sending spam. All these attempts failed because the users they were trying (newsletter, test, dummy, etc) don't exist. I've already asked over at the Dovecot list what happens if they hit a real user... In the meantime I need to update my dovecot jail. I just wondered if anyone else had seen a brute-force attack on SASL before.. Does your approach for sending to abuse work for Roadrunner? I have 1000 pings a day from a host on RR cable and when I tried to email abb...@rr.com, the connection timed out and the mail sits in the queue for 5 days before timing out. Simon
Spammers attempting SASL auth.
Hi This is a new one on me - I've never seen spammers attempt to use to SASL Auth to inject spam. Has anyone else seen this? Oct 17 15:07:16 mail postfix/smtpd[14422]: connect from unknown[208.86.147.92] Oct 17 15:07:16 mail dovecot: auth(default): passdb(newslet...@mydomain.net,208.86.147.92): Attempted login with password having illegal chars Oct 17 15:07:17 mail dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=208.86.147.92, lip=83.170.64.84 Oct 17 15:07:18 mail postfix/smtpd[14403]: warning: 208.86.147.92: hostname default-208-86-147-92.nsihosting.net verification failed: Name or service not known Simon
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 13 October 2011 20:11, Noel Jones wrote: > On 10/13/2011 6:39 PM, Simon Brereton wrote: >> smtp_tls_CAfile = ? >> smtp_tls_cert_file = ? >> smtp_tls_key_file = ? > > Typcially these would be set to the same cert & keys as used by smtpd. Since these are self-signed certificates, would it be possible to use a URL for the CA file? Simon
Re: TLS Issues. certificate unknown: SSL alert number 46:
On 13 October 2011 19:16, Noel Jones wrote:
> On 10/13/2011 5:41 PM, Mark Homoky wrote:
>> On 11 Oct 2011, at 15:54, "Simon Brereton"
>> wrote:
>>
>>>>>
>>>>> this is obseleted (I'm running 2.7.1) and to use
>>>>> smtpd_tls_security_level = may instead - however, vim tells me that
>>>>> the former is a valid configurable (it's highlighted) whilst the
>>>>> latter is not. That's part of my confusion.
>>>>
>>>> The authors of vim are not Postfix experts.
>>>
>>> Among the other things it's not practical enough to know is how vim does
>>> this anyway. I assumed there was some sort of file it checks in the
>>> postfix sources. But I'll amend this.
>>
>> No, it's a vim syntax file IIRC.
>
>
> Yes.
>
>
>> It might be useful for someone senior in Postfix development to look this
>> over?
>>
>
> Postfix evolves, the vim syntax file hasn't. Updating the current
> vim syntax file probably isn't terribly complicated, but is well
> outside the scope of postfix and would be an ongoing project.
>
> If you want to fix it, just go through the postconf(5) and
> master(5) man pages and make sure all valid parameters are included
> in the vim file (Probably near 800 if you also include all the valid
> smptd_*_restrictions options).
>
> My solution would be to remove the misleading vim syntax file.
With all due respect to Mr Jones - for the inexperienced among us that
would be like amputating the leg to fix a broken ACL. No, the message
is clear - believe the postconf (5) more than the pretty colours in
vim. Problem solved.
If it bugged me enough I'd file a bug report with the vim people. I
may yet do that in the spirit of contributing to opensource since I
can't code worth a fig.
I'd still like some more hand-holding on my earlier questions in
response to Viktor..
> With no other settings for the SMTP client, outgoing TLS is disabled
> on your machine. You need "smtp_tls_security_level = may".
Thanks - you've already made the TLS_README more understandable. I've
added that. Do I need to add other parameters?
smtp_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_CAfile = ?
smtp_tls_cert_file = ?
smtp_tls_key_file = ?
smtp_tls_loglevel = 1
> > smtpd_tls_CAfile = /etc/ssl/keys/ca.crt smtpd_tls_cert_file =
> > /etc/ssl/keys/mail..net.crt
>
> Not needed, you neither ask for nor verify client certs.
Should I be? And if so, how do I do that? Bearing in mind, I think
I'd only want to verify them if they are actually used.
But the errors in my log are down and so for now I can live with it
unless anyone has anything more to add. The problem with TLS/SSL is
one always has the horrible suspicion one has left a gaping back-door
open...
Simon
RE: TLS Issues. certificate unknown: SSL alert number 46:
> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Viktor Dukhovni
> On Fri, Oct 07, 2011 at 05:15:20PM -0400, Simon Brereton wrote:
>
> > postfix/smtpd[25614]: warning: TLS library problem:
> 25614:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown:s3_pkt.c:1102:SSL alert number 46:
>
> This client could not verify your server certificate, its SSL stack
> sent an "alert" to that effect.
Viktor - as always, I thank you - the help and advice on this is list is
unparalleled.
I presume they couldn't verify it because it's self-signed certificate?
> > I have absolutely no idea if my server is using TLS if it's offered
> for outgoing mail.
> >
> > In main.cf I have smtpd_use_tls = yes but the documentation tells
> me
> > this is obseleted (I'm running 2.7.1) and to use
> > smtpd_tls_security_level = may instead - however, vim tells me that
> > the former is a valid configurable (it's highlighted) whilst the
> > latter is not. That's part of my confusion.
>
> The authors of vim are not Postfix experts.
Among the other things it's not practical enough to know is how vim does this
anyway. I assumed there was some sort of file it checks in the postfix
sources. But I'll amend this.
> > mail:~# postconf -n | grep -i TLS
> > smtp_tls_note_starttls_offer = yes
> > smtp_tls_session_cache_database =
> btree:${data_directory}/smtp_scache
>
> With no other settings for the SMTP client, outgoing TLS is disabled
> on your machine. You need "smtp_tls_security_level = may".
Thanks - you've already made the TLS_README more understandable. I've added
that. Do I need to add other parameters?
smtp_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_CAfile = ?
smtp_tls_cert_file = ?
smtp_tls_key_file = ?
smtp_tls_loglevel = 1
> > smtpd_tls_CAfile = /etc/ssl/keys/ca.crt smtpd_tls_cert_file =
> > /etc/ssl/keys/mail..net.crt
>
> Not needed, you neither ask for nor verify client certs.
Should I be? And if so, how do I do that? Bearing in mind, I think I'd only
want to verify them if they are actually used.
> > smtpd_tls_loglevel = 2
>
> Too noisy. No more than 1, unless you're debugging a TLS
> interoperability problem
I'd put it at 2 to try and ascertain if it was me or the connecting host at
fault. Your reply above indicates it me (or at least because the host cant
verify my certificate)..
> > smtpd_use_tls = yes
>
> Use "smtpd_tls_security_level = may"
Fixed. Thanks.
> > And how can I be sure those errors in the logs are the connecting
> host and not mine?
>
> Reduce the loglevel to 1, then ignore most TLS warnings that don't
> correlate with non-delivery of mail. Sadly, it is not practical for
> everyone to learn SSL deeply enough to understand all the warnings.
I'm deeply and painfully aware of this :(
Simon
TLS Issues. certificate unknown: SSL alert number 46:
Hi
My log files has a moderate amount of TLS warnings:
postfix/smtpd[25614]: warning: TLS library problem: 25614:error:14094416:SSL
routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1102:SSL
alert number 46:
I'm aware that this could be (according to an older thread on this list) just
an issue with the clients that are connecting to me. However, I'd like to be
sure that this is the case.
I've spent all day reading http://www.postfix.org/TLS_README.html but I'm not
really any the wiser.
What I would like is:
SMTP
:: MUAs connecting on 587 are required to use TLS
:: MUAs connecting on 25 can use TLS if the want to
SMTPD
:: Hosts connecting to me are offered TLS and use it
:: That my server use TLS if it is offered by a remote host
I think I'm fixed on the first one. My master.cf says:
submission inet n - n - - smtpd
-o smtpd_delay_reject=yes
-o receive_override_options=no_address_mappings
-o content_filter=dksign:[127.0.0.1]:10028
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_tls_security_level=encrypt
I think the error is related to the third point.
And I have absolutely no idea if my server is using TLS if it's offered for
outgoing mail.
In main.cf I have smtpd_use_tls = yes but the documentation tells me this is
obseleted (I'm running 2.7.1) and to use smtpd_tls_security_level = may instead
- however, vim tells me that the former is a valid configurable (it's
highlighted) whilst the latter is not. That's part of my confusion.
mail:~# postconf -n | grep -i TLS
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_tls_CAfile = /etc/ssl/keys/ca.crt
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/ssl/keys/mail..net.crt
smtpd_tls_key_file = /etc/ssl/private/mail..net.key
smtpd_tls_loglevel = 2
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
How can I be sure my server is using TLS for hosts that offer it?
And how can I be sure those errors in the logs are the connecting host and not
mine?
Thanks for any advice.
Simon
RE: Changing SASL Auth from Cyrus to Dovecot
> -Original Message- > From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] On Behalf Of Sahil Tandon > On Tue, 2011-05-03 at 23:58:47 +0200, Simon Brereton wrote: > > > I'm trying to change my SASL auth from Cyrus to Dovecot. > > > > I have Dovecot all set up - it's authenticating IMAP users and > postfix > > is using dovecot-lda to deliver mail, but when I changes main.cf to > > use Dovecot SMTP Auth wasn't working. > > > > After a few hours of fruitless searching I finally thought I had > the > > issue - turning the postfix logging way up says that cyrus is still > > being called for the auth > > > > May 3 17:57:33 jonty postfix/smtpd[22116]: > xsasl_cyrus_server_first: > > sasl_method plain, init_response AHRlc3QAdGVzdHBhc3M= May 3 > 17:57:33 > > jonty postfix/smtpd[22116]: xsasl_cyrus_server_first: decoded > initial response testuser Now, I've reloaded postfix after I made the > following changes: > > > > smtp_sasl_type = dovecot > > smtp != smtpd. Doh! Thanks for the spot. > > My gut feeling is that this is not a postfix issue > > Indeed; just human error. So we're in violent agreement there then. Thanks, this is all working now.
RE: Changing SASL Auth from Cyrus to Dovecot
> -Original Message- > From: Wietse Venema [mailto: > Simon Brereton: > > Hi > > > > I'm trying to change my SASL auth from Cyrus to Dovecot. > > You have not shown any evidence that your Postfix version actually > comes with Dovecot support. Actually - because I knew you'd say that - I included this root@jonty:~# postconf -a cyrus dovecot in my original post. For the record, it's from the Debian repository. root@jonty:~# postconf mail_version mail_version = 2.7.1
Changing SASL Auth from Cyrus to Dovecot
Hi
I'm trying to change my SASL auth from Cyrus to Dovecot.
I have Dovecot all set up - it's authenticating IMAP users and postfix is using
dovecot-lda to deliver mail, but when I changes main.cf to use Dovecot SMTP
Auth wasn't working.
After a few hours of fruitless searching I finally thought I had the issue -
turning the postfix logging way up says that cyrus is still being called for
the auth
May 3 17:56:52 jonty postfix/smtpd[22116]: Anonymous TLS connection
established from unknown[192.168.1.4]: TLSv1 with cipher DHE-RSA-AES256-SHA
(256/256 bits)
May 3 17:56:52 jonty postfix/smtpd[22116]: xsasl_cyrus_server_create: SASL
service=smtp, realm=(null)
May 3 17:56:52 jonty postfix/smtpd[22116]: name_mask: noanonymous
May 3 17:57:15 jonty postfix/smtpd[22116]: < unknown[192.168.1.4]: ehlo
localhost
May 3 17:57:15 jonty postfix/smtpd[22116]: > unknown[192.168.1.4]:
250-mail.spamfreeisp.net
May 3 17:57:15 jonty postfix/smtpd[22116]: > unknown[192.168.1.4]:
250-PIPELINING
May 3 17:57:15 jonty postfix/smtpd[22116]: > unknown[192.168.1.4]: 250-SIZE
2048
May 3 17:57:15 jonty postfix/smtpd[22116]: > unknown[192.168.1.4]: 250-ETRN
May 3 17:57:15 jonty postfix/smtpd[22116]: > unknown[192.168.1.4]: 250-AUTH
LOGIN CRAM-MD5 DIGEST-MD5 PLAIN NTLM
May 3 17:57:15 jonty postfix/smtpd[22116]: match_list_match: unknown: no match
May 3 17:57:15 jonty postfix/smtpd[22116]: match_list_match: 192.168.1.4: no
match
May 3 17:57:15 jonty postfix/smtpd[22116]: > unknown[192.168.1.4]:
250-AUTH=LOGIN CRAM-MD5 DIGEST-MD5 PLAIN NTLM
May 3 17:57:15 jonty postfix/smtpd[22116]: > unknown[192.168.1.4]:
250-ENHANCEDSTATUSCODES
May 3 17:57:15 jonty postfix/smtpd[22116]: > unknown[192.168.1.4]: 250-8BITMIME
May 3 17:57:15 jonty postfix/smtpd[22116]: > unknown[192.168.1.4]: 250 DSN
May 3 17:57:33 jonty postfix/smtpd[22116]: < unknown[192.168.1.4]: auth plain
AHRlc3QAdGVzdHBhc3M=
May 3 17:57:33 jonty postfix/smtpd[22116]: xsasl_cyrus_server_first:
sasl_method plain, init_response AHRlc3QAdGVzdHBhc3M=
May 3 17:57:33 jonty postfix/smtpd[22116]: xsasl_cyrus_server_first: decoded
initial response testuser
Now, I've reloaded postfix after I made the following changes:
smtp_sasl_type = dovecot
smtpd_sasl_path = private/auth
In fact, I stopped and restarted it too - and still it doesn't appear to
hand-over to Dovecot for the auth.
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = mailsystem
group = mailsystem
}
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = mailsystem
}
}
ls /var/spool/postfix/private/auth
srw-rw 1 postfix mailsystem 0 May 3 18:49 /var/spool/postfix/private/auth
postconf -a
cyrus
dovecot
My gut feeling is that this is not a postfix issue - but confirmation of that
would be useful. Or even a hint on how to confirm that (at which point someone
will probably point out some type or something).
Thanks.
Simon
RE: SASL Authentication and debugging..
> -Original Message- > From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] On Behalf Of Simon Brereton > I turned up mysql logging and did another test - and no query > appeared in the mysql log! In an effort to prove to myself, I did an > imap login attempt (which also uses mysql) and the query appears in > the mysql log. It looks to me as if SASL isn't talking to mysql (but > then I had the same impression it wasn't listening to the imap server > when I tried rimap too). It would help to have the sasl mysql libraries installed! Doh. So, if saslauth won't work, not matter what you do - debug with sasldb and if that works out of the box you probably don't have the library installed. Simon
RE: SASL Authentication and debugging..
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Patrick Ben Koetter
> * Simon Brereton :
> > > > Saslfinger -s says:
> > >
> > > saslfinger also reports much other, useful information which we
> need
> > > to debug your problem. Please post complete output.
> >
> > Gladly.I was hoping you'd step in. Just to let you know, I've
> tried
> > both auxprop and saslauthd as the pwcheck method.
> >
> > I even tried rimap - and with courier authdaemon logging turned up
> to
> > 2, I can see the MYSQL is call is successful (i.e. IMAP validates)
> and
> > still SASL says authentication failed.
>
> We'll simplify first, and make it feature-complete later.
>
>
> > root@jonty:~# saslfinger -s
> > saslfinger - postfix Cyrus sasl configuration Wed Apr 13 05:52:12
> BST
> > 2011
> > version: 1.0.4
> > mode: server-side SMTP AUTH
> >
> > -- basics --
> > Postfix: 2.7.1
> > System: Debian GNU/Linux 6.0 \n \l
> >
> > -- smtpd is linked to --
> > libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7672000)
> >
> > -- active SMTP AUTH and TLS parameters for smtpd --
> > broken_sasl_auth_clients = yes smtpd_sasl_auth_enable = yes
> > smtpd_sasl_local_domain = spamfreeisp.net
>
> $smtpd_sasl_local_domain required or because you found it on a
> website?
Probably the latter - although I don't think I've touched it much since you
helped me set it up about 5 years ago.
> > smtpd_sasl_security_options = noanonymous smtpd_tls_CAfile =
> > /root/certauth/cacert.pem smtpd_tls_auth_only = no
> smtpd_tls_cert_file
> > = /etc/postfix/ssl/mail.spamfreeisp.net.cert
> > smtpd_tls_key_file = /etc/postfix/ssl/mail.spamfreeisp.net.key
>
> Just as a sidenote: You might want to move your key and certs to
> /etc/ssl/...
> and own them root:ssl-cert and then "adduser postfix ssl-cert" to
> make it the "Debian way".
Good point. Will do that when I get to the end.
> > smtpd_tls_loglevel = 1
> > smtpd_tls_received_header = yes
> > smtpd_tls_session_cache_database =
> > btree:${queue_directory}/smtpd_scache
> > smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes
> > -- content of /etc/postfix/sasl/smtpd.conf --
>
> Make this as follows and REMOVE the semi-colon at the end of your
> sql_select:-statement:
>
> pwcheck_method: auxprop
> mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5
> auxprop_plugin: sql
> sql_engine: mysql
> sql_hostnames: localhost
> sql_user: --- replaced ---
> sql_passwd: --- replaced ---
> sql_database: Mail
> sql_select: SELECT Password FROM MailAccounts WHERE Username =
> '%u@%r'
Done.
> > -- active services in /etc/postfix/master.cf -- # service type
> > private unpriv chroot wakeup maxproc command + args
> > # (yes) (yes) (yes) (never) (100)
> > smtp inet n - - - - smtpd -v
> > submission inet n - n - - smtpd
> > -o receive_override_options=no_address_mappings
> > -o content_filter=dksign:[127.0.0.1]:10028
> > -o smtpd_enforce_tls=yes
> > -o smtpd_sasl_auth_enable=yes
> > -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>
> Disable TLS for the moment.
> What do you get when you run "postconf smtpd_delay_reject"?
smtpd_delay_reject = yes
> Post verbose smtpd log that shows an authentication attempt if AUTH
> still fails after the changes.
>
> Caution
>
> When posting logs of the SASL negotiations to public lists,
> please keep in
> mind that username/password information is trivial to recover
> from the
> base64-encoded form written to log files.
Part of my problem is that I can't get SASL logging verbosity to the point
where I can see the passwords! If I could, that would help.
Two attempts.
Apr 13 14:54:10 jonty postfix/master[28058]: reload -- version 2.7.1,
configuration /etc/postfix
Apr 13 14:54:10 jonty postfix/anvil[1821]: statistics: max connection rate
1/60s for (smtp:192.168.1.4) at Apr 13 14:51:58
Apr 13 14:54:10 jonty postfix/anvil[1821]: statistics: max connection count 1
for (smtp:192.168.1.4) at Apr 13 14:51:58
Apr 13 14:54:10 jonty postfix/anvil[1821]: statistics: max cache size 1 at Apr
13 14:51:58
Apr 13 14:54:33 jonty postfix/smtpd[1834]: connect from unknown[192.168.1.4]
Apr 13 14:54:46 jonty postfix/smtpd[1834]: warning: SASL authentication
failure: Password verification failed
Apr 13 14:54:46 jonty postfix/smtpd[1834]: warning: unknown[192.168.1.4]: SASL
PLAIN authentication failed: authent
RE: SASL Authentication and debugging..
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Patrick Ben Koetter
> * Simon Brereton :
> > Probably not the best place for this, but hopefully someone will
> tell
> > me what I'm doing wrong anyway..
> >
> > I've gotten the TLS up and working. And SASL auth seemed to be
> > working. I installed saslfinger and everything was fine there.
> But
> > when trying to locally inject mail on the submission port, I get:
> >
> > Apr 11 20:31:10 jonty postfix/smtpd[28787]: setting up TLS
> connection
> > from localhost[127.0.0.1] Apr 11 20:31:10 jonty
> postfix/smtpd[28787]:
> > Anonymous TLS connection established from localhost[127.0.0.1]:
> TLSv1
> > with cipher DHE-RSA-AES256-SHA (256/256 bits) Apr 11 20:31:10 jonty
> > postfix/smtpd[28787]: warning: localhost[127.0.0.1]: SASL LOGIN
> > authentication failed: authentication failure Apr 11 20:31:10 jonty
> > postfix/smtpd[28787]: disconnect from localhost[127.0.0.1]
> >
> > I turned the verbosity up in smtpd.conf to try and diagnose this,
> and
> > it does nothing (which I guess is my biggest issue).
> >
> > 1 # Global Parameters
> > 2 log_level: 7
> > 3 pwcheck_method: auxprop
> > 4 #pwcheck_method: saslauthd
> >
> > Saslfinger -s says:
>
> saslfinger also reports much other, useful information which we need
> to debug your problem. Please post complete output.
Gladly.I was hoping you'd step in. Just to let you know, I've tried both
auxprop and saslauthd as the pwcheck method.
I even tried rimap - and with courier authdaemon logging turned up to 2, I can
see the MYSQL is call is successful (i.e. IMAP validates) and still SASL says
authentication failed.
root@jonty:~# saslfinger -s
saslfinger - postfix Cyrus sasl configuration Wed Apr 13 05:52:12 BST 2011
version: 1.0.4
mode: server-side SMTP AUTH
-- basics --
Postfix: 2.7.1
System: Debian GNU/Linux 6.0 \n \l
-- smtpd is linked to --
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7672000)
-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = spamfreeisp.net
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /root/certauth/cacert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/ssl/mail.spamfreeisp.net.cert
smtpd_tls_key_file = /etc/postfix/ssl/mail.spamfreeisp.net.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
-- listing of /usr/lib/sasl2 --
total 704
drwxr-xr-x 2 root root 4096 Mar 8 14:21 .
drwxr-xr-x 79 root root 32768 Apr 4 19:18 ..
-rw-r--r-- 1 root root 13436 Dec 19 12:29 libanonymous.a
-rw-r--r-- 1 root root 1003 Dec 19 12:29 libanonymous.la
-rw-r--r-- 1 root root 13076 Dec 19 12:29 libanonymous.so
-rw-r--r-- 1 root root 13076 Dec 19 12:29 libanonymous.so.2
-rw-r--r-- 1 root root 13076 Dec 19 12:29 libanonymous.so.2.0.23
-rw-r--r-- 1 root root 15882 Dec 19 12:29 libcrammd5.a
-rw-r--r-- 1 root root 989 Dec 19 12:29 libcrammd5.la
-rw-r--r-- 1 root root 15444 Dec 19 12:29 libcrammd5.so
-rw-r--r-- 1 root root 15444 Dec 19 12:29 libcrammd5.so.2
-rw-r--r-- 1 root root 15444 Dec 19 12:29 libcrammd5.so.2.0.23
-rw-r--r-- 1 root root 45328 Dec 19 12:29 libdigestmd5.a
-rw-r--r-- 1 root root 1012 Dec 19 12:29 libdigestmd5.la
-rw-r--r-- 1 root root 43144 Dec 19 12:29 libdigestmd5.so
-rw-r--r-- 1 root root 43144 Dec 19 12:29 libdigestmd5.so.2
-rw-r--r-- 1 root root 43144 Dec 19 12:29 libdigestmd5.so.2.0.23
-rw-r--r-- 1 root root 13586 Dec 19 12:29 liblogin.a
-rw-r--r-- 1 root root 983 Dec 19 12:29 liblogin.la
-rw-r--r-- 1 root root 13552 Dec 19 12:29 liblogin.so
-rw-r--r-- 1 root root 13552 Dec 19 12:29 liblogin.so.2
-rw-r--r-- 1 root root 13552 Dec 19 12:29 liblogin.so.2.0.23
-rw-r--r-- 1 root root 29140 Dec 19 12:29 libntlm.a
-rw-r--r-- 1 root root 977 Dec 19 12:29 libntlm.la
-rw-r--r-- 1 root root 28528 Dec 19 12:29 libntlm.so
-rw-r--r-- 1 root root 28528 Dec 19 12:29 libntlm.so.2
-rw-r--r-- 1 root root 28528 Dec 19 12:29 libntlm.so.2.0.23
-rw-r--r-- 1 root root 13786 Dec 19 12:29 libplain.a
-rw-r--r-- 1 root root 983 Dec 19 12:29 libplain.la
-rw-r--r-- 1 root root 14096 Dec 19 12:29 libplain.so
-rw-r--r-- 1 root root 14096 Dec 19 12:29 libplain.so.2
-rw-r--r-- 1 root root 14096 Dec 19 12:29 libplain.so.2.0.23
-rw-r--r-- 1 root root 21498 Dec 19 12:29 libsasldb.a
-rw-r--r-- 1 root root 1014 Dec 19 12:29 libsasldb.la
-rw-r--r-- 1 root root 18084 Dec 19 12:29 libsasldb.so
-rw-r--r-- 1 root root 18084 Dec 19 12:29 libsasldb.so.2
-rw-r--r-- 1 root root 18084 Dec 19 12:29 libsasldb.so.2.0.23
-- listing of /etc/postfix/sasl --
total 12
drwxr
RE: SASL Authentication and debugging..
> From: Simon Brereton > Probably not the best place for this, but hopefully someone will tell > me what I'm doing wrong anyway.. > > I've gotten the TLS up and working. And SASL auth seemed to be > working. I installed saslfinger and everything was fine there. But > when trying to locally inject mail on the submission port, I get: > > Apr 11 20:31:10 jonty postfix/smtpd[28787]: setting up TLS connection > from localhost[127.0.0.1] Apr 11 20:31:10 jonty postfix/smtpd[28787]: > Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1 > with cipher DHE-RSA-AES256-SHA (256/256 bits) Apr 11 20:31:10 jonty > postfix/smtpd[28787]: warning: localhost[127.0.0.1]: SASL LOGIN > authentication failed: authentication failure Apr 11 20:31:10 jonty > postfix/smtpd[28787]: disconnect from localhost[127.0.0.1] > > I turned the verbosity up in smtpd.conf to try and diagnose this, and > it does nothing (which I guess is my biggest issue). > > 1 # Global Parameters > 2 log_level: 7 I've done some more investigating on this - I still can't get more lines into the log, so it's a bit like working blindfolded. This is a new set-up based off my old configuration and I figured out that actually SASL auth isn't working on port 25 either. After staring at http://www.postfix.org/SASL_README.html for an hour.. ... The value sent by Postfix is the name of the server component that will use Cyrus SASL. It defaults to smtpd and is configured with one of the following variables: /etc/postfix/main.cf: # Postfix 2.3 and later smtpd_sasl_path = smtpd ... Okay. Check. I have this file in /etc/postfix/sasl/smtpd.conf in both configurations (and in fact it's the same file - and the one where I tried to increase the verbosity and failed). ... Cyrus SASL configuration file location The location where Cyrus SASL searches for the named file depends on the Cyrus SASL version and the OS/distribution used. You can read more about the following topics: Cyrus SASL version 2.x searches for the configuration file in /usr/lib/sasl2/. Cyrus SASL version 2.1.22 and newer additionally search in /etc/sasl2/. Some Postfix distributions are modified and look for the Cyrus SASL configuration file in /etc/postfix/sasl/, /var/lib/sasl2/ etc. See the distribution-specific documentation to determine the expected location. Note Cyrus SASL searches /usr/lib/sasl2/ first. If it finds the specified configuration file there, it will not examine other locations. ... How can I find where Cyrus or Postfix are expecting to find this file? I'm starting to suspect that I don't have it in the right location for the new installation. Also from the SASL_README.. ... saslauthd - Cyrus SASL password verification service Communication between the Postfix SMTP server (read: Cyrus SASL's libsasl) and the saslauthd server takes place over a UNIX-domain socket. saslauthd usually establishes the UNIX domain socket in /var/run/saslauthd/ and waits for authentication requests. The Postfix SMTP server must have read+execute permission to this directory or authentication attempts will fail. ... Whilst my /etc/default/saslauth has been modified to include OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" /var/run/saslauth exists on the new server, but not on the old. However, /var/spool/postfix/var/run/saslauthd, also exists. On neither server though does postfix have read+execute permissions (both are owned by root). Changing this so that postfix does have read+execute to the mux doesn't change anything. What am I doing wrong?
SASL Authentication and debugging..
Hi
Probably not the best place for this, but hopefully someone will tell me what
I'm doing wrong anyway..
I've gotten the TLS up and working. And SASL auth seemed to be working. I
installed saslfinger and everything was fine there. But when trying to locally
inject mail on the submission port, I get:
Apr 11 20:31:10 jonty postfix/smtpd[28787]: setting up TLS connection from
localhost[127.0.0.1]
Apr 11 20:31:10 jonty postfix/smtpd[28787]: Anonymous TLS connection
established from localhost[127.0.0.1]: TLSv1 with cipher DHE-RSA-AES256-SHA
(256/256 bits)
Apr 11 20:31:10 jonty postfix/smtpd[28787]: warning: localhost[127.0.0.1]: SASL
LOGIN authentication failed: authentication failure
Apr 11 20:31:10 jonty postfix/smtpd[28787]: disconnect from localhost[127.0.0.1]
I turned the verbosity up in smtpd.conf to try and diagnose this, and it does
nothing (which I guess is my biggest issue).
1 # Global Parameters
2 log_level: 7
3 pwcheck_method: auxprop
4 #pwcheck_method: saslauthd
5 mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5
6 #mech_list: PLAIN LOGIN
7 allow_plaintext: true
8 # saslauthd Parameters
9 #saslauthd_path: /var/state/saslauthd/mux
10 saslauthd_path: /var/spool/postfix/var/run/saslauthd/mux
11 # Auxiliary Plugin Paramters
12 auxprop_plugin: sql
13 sql_engine: mysql
14 #sql_hostnames: 127.0.0.1
15 sql_hostnames: localhost
16 sql_user: postfix
17 sql_passwd: 804LCi
18 sql_database: Mail
19 sql_select: select Password from MailAccounts where Username = '%u@%r';
20 # or Username = '%u@%r' or (Username = '%u' and ForwardAdd = '') or
Username = '%u.%r';
21 sql_usessl: no
Saslfinger -s says:
-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /root/certauth/cacert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/ssl/mail.cert
smtpd_tls_key_file = /etc/postfix/ssl/mail.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
How can I increase the SASL logging to debug this?
Thanks.
Simon
Re: To install a PostFix-based mailserver with Content Filters do I need to have multiple servers?
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] On Behalf Of jeremy.als...@imap-mail.com > Hi Victor. > > On Fri, 08 Apr 2011 00:59 -0400, "Victor Duchovni" > wrote: > > Start simple, and add features gradually. There is a steep learning > > curve for a novice to deploy a complex production system with no > prior > > experience. > > It sure feels pretty steep already. I guess I'm glad I'm not just > imagining things. > > I'm pretty sure I want to stick with the single Instance setup. Like > you said, for now at the least. > > I found a pretty good example, Spamassassin + ClamAV + Postfix > WITHOUT Amavis (Debian) > http://www.xtarutaru.com/2009/04/16/spamassassin-clamav-postfix- > without-amavis-debian/ > that along with Daniel's comments that's helping me to make sense of > this a bit better. There's a ton of howtos out there - I'm sure you can find one that suits all your needs. The nice thing about this one is that it'll keep you on the track you've been advised on - i.e. keeping things simple and adding features as you go. I would recommend using amavis for your spam and virus checking though. The Howto you're looking at specifically doesn't use it because of resource constraints on the host. However, it sounds like you don't have that constraint. > I'm still going to read through some more of those Multiple Instance > examples so maybe I can get some idea which road to point myself down > for later. > > If I do any of the Multiple Instance setup is there a good Document > that tells what configuration goes into what file? Does > configuration flow down from the 1st one you setup ? So that > PostScreen configuration, which looks to do some of the work I want > done, goes into which config file? Personally, I don't think you need multiple instances. If the book you got was The Book of Postfix, then it was written by contributors to this list - and you can't go wrong. Setting up my own mail server to handle mail for multiple domains with spam and virus checking is one of the most worthwhile and fun things I've ever done. I really want to encourage you to stay on the learning curve you've chosen. I've been successfully blocking up to 98% of traffic (when the Rustock botnet was running) using a very simple set up but my false negatives are almost non-existent and my false positives are very low. I'm sure there are more valid opinions but my advice for what it's worth is: . Set up postfix to receive and send mail securely (i.e. don't be an open-relay!) . Get your delivery agent set up (Courier/Dovecot) and working . Implement some sort of sender authentication e.g. SASL - though it will depend on your choices above) even if your users will only send mail to the server from inside the network . Some sort of log reporting (pflogsumm/postfix-logwatch) working . Add in the postfix's native spam controls, limiting and checks . Then look at content filtering (spam, virus and other objectionable content) - as you've already learnt this can be handed off to a different server/service, even if they're on the same host . Then look at more advanced controls like grey-listing and postscreen If in doubt, ask and remember that most defaults are there for a reason. Consider the implications before changing them (but some will need to be changed to suit your set-up). Have fun.
RE: SASL Error on Submission port
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] On Behalf Of Victor Duchovni > On Thu, Apr 07, 2011 at 07:37:50PM +0200, Simon Brereton wrote: > > > > From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > > > us...@postfix.org] On Behalf Of Patrick Ben Koetter > > > * Simon Brereton > > > > Hi > > > > > > > > Running 2.3.8 Debian package (I'll be upgrading shortly), I was > > > already supporting TLS and SASL auth. One of my users recently > > > moved to RCN and they block port 25 so I'm trying to open 587. > > > > > > > > I added this to my master.cf > > > > > > > > > > > > submission inet n - - - - smtpd > > > > > > Is the saslauthd socket in the Postfix chroot? If not edit > > > /etc/default/saslauthd. > > > > I'm not sure. I'm pretty sure I don't have postfix running > chrooted - I think I thought that was too complex. > > > > It is chrooted. A non-chrooted smtpd looks like: > > smtp inet n - n - - smtpd Probably because this was installed using apt-get.. Thanks. So, I sat looking at this mail for a while wondering if you were telling me more, or if I should wait for a reply to my other email, and then I thought, well, it can't hurt to try.. So I changed master.cf And lo and behold.. Apr 7 17:12:16 donald postfix/smtpd[24257]: connect from 3.myvzw.com[174.255.113.31] Apr 7 17:12:17 donald postfix/smtpd[24257]: setting up TLS connection from 3.myvzw.com[174.255.113.31] Apr 7 17:12:17 donald postfix/smtpd[24257]: TLS connection established from 3.myvzw.com[174.255.113.31]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Apr 7 17:12:18 donald postfix/smtpd[24257]: disconnect from 3.myvzw.com[174.255.113.31] No error on the client's parameter's checks. This looks hopeful... Apr 7 17:13:05 donald postfix/smtpd[24257]: connect from 3.myvzw.com[174.255.113.31] Apr 7 17:13:06 donald postfix/smtpd[24257]: setting up TLS connection from 3.myvzw.com[174.255.113.31] Apr 7 17:13:08 donald postfix/smtpd[24257]: TLS connection established from 3.myvzw.com[174.255.113.31]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Apr 7 17:13:11 donald postfix/smtpd[24257]: 4970CA94109: client=3.myvzw.com[174.255.113.31], sasl_method=PLAIN, sasl_username=myu...@mydomain.net Apr 7 17:13:14 donald postfix/cleanup[24263]: 4970CA94109: message-id= Apr 7 17:13:14 donald postfix/qmgr[24255]: 4970CA94109: from=, size=923, nrcpt=1 (queue active) Success! Thanks guys. Once again the support on this list is amazing (so long as you listen to it and not try blindly to go against it). Can anyone educate me as to why it needs to be outside the jail when it works normally? The two lines from my master.cf look like: 9 smtp inet n - - - - smtpd -v 10 submission inet n - n - - smtpd 11 -o smtpd_enforce_tls=yes 12 -o smtpd_tls_auth_only=yes 13 -o smtpd_sasl_auth_enable=yes 14 -o smtpd_sasl_security_options=noanonymous 15 -o smtpd_client_restrictions=permit_sasl_authenticated,reject Thanks.
RE: SASL Error on Submission port
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] On Behalf Of Patrick Ben Koetter > * Simon Brereton > > Hi > > > > Running 2.3.8 Debian package (I'll be upgrading shortly), I was > already supporting TLS and SASL auth. One of my users recently moved > to RCN and they block port 25 so I'm trying to open 587. > > > > I added this to my master.cf > > > > > > submission inet n - - - - smtpd > > Is the saslauthd socket in the Postfix chroot? If not edit > /etc/default/saslauthd. I'm not sure. I'm pretty sure I don't have postfix running chrooted - I think I thought that was too complex. /etc/default/saslauthd says: OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" And as my other mail shows SASL auth is working fine when the connection is made on port 25. Just not when it comes in on the submission port.. Simon
RE: Re: SASL Error on Submission port
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] On Behalf Of Victor Duchovni > On Thu, Apr 07, 2011 at 04:53:59PM +0200, Simon Brereton wrote: > > > However, when I test I get a SASL auth error. If I switch my > client back to port 25, there is no SASL error. > > > > Connecting to port 25 > > Apr 7 10:00:30 donald postfix/smtpd[21028]: connect from > > 18.myvzw.com[174.252.18.98] Apr 7 10:00:31 donald > > postfix/smtpd[21028]: setting up TLS connection from > > 18.myvzw.com[174.252.18.98] Apr 7 10:00:32 donald > > postfix/smtpd[21028]: TLS connection established from > > 18.myvzw.com[174.252.18.98]: TLSv1 with cipher DHE-RSA-AES256-SHA > > (256/256 bits) Apr 7 10:00:34 donald postfix/smtpd[21028]: > disconnect > > from 18.myvzw.com[174.252.18.98] > > Did you actually login here? I see no evidence of SASL, send a > message and show the logging. That's because the software (on my phone) doesn't actually send a message - it's simply confirms that the parameters are correct. The only difference between the two is to change the port number. All the username and password details remained untouched. But since you ask, here's the test actually sending a message: Apr 7 12:38:50 donald postfix/smtpd[22046]: connect from 3.myvzw.com[174.252.3.219] Apr 7 12:38:51 donald postfix/smtpd[22046]: setting up TLS connection from 3.myvzw.com[174.252.3.219] Apr 7 12:38:53 donald postfix/smtpd[22046]: TLS connection established from 3.myvzw.com[174.252.3.219]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Apr 7 12:38:55 donald postfix/smtpd[22046]: disconnect from 3.myvzw.com[174.252.3.219] Apr 7 12:40:00 donald postfix/smtpd[22046]: connect from 3.myvzw.com[174.252.3.219] Apr 7 12:40:01 donald postfix/smtpd[22046]: setting up TLS connection from 3.myvzw.com[174.252.3.219] Apr 7 12:40:02 donald postfix/smtpd[22046]: TLS connection established from 3.myvzw.com[174.252.3.219]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Apr 7 12:40:03 donald postfix/smtpd[22046]: B7BADA940A5: client=3.myvzw.com[174.252.3.219], sasl_method=PLAIN, sasl_username=myu...@mydomain.net Apr 7 12:40:06 donald postfix/cleanup[22072]: B7BADA940A5: message-id= Apr 7 12:40:06 donald postfix/qmgr[22038]: B7BADA940A5: from=, size=920, nrcpt=1 (queue active) > > Connecting from port 587 > > Apr 7 10:01:04 donald postfix/smtpd[21032]: connect from > > 18.myvzw.com[174.252.18.98] Apr 7 10:01:06 donald > > postfix/smtpd[21032]: setting up TLS connection from > > 18.myvzw.com[174.252.18.98] Apr 7 10:01:07 donald > > postfix/smtpd[21032]: TLS connection established from > > 18.myvzw.com[174.252.18.98]: TLSv1 with cipher DHE-RSA-AES256-SHA > > (256/256 bits) Apr 7 10:01:09 donald postfix/smtpd[21032]: > warning: > > SASL authentication failure: Password verification failed Apr 7 > > 10:01:09 donald postfix/smtpd[21032]: warning: > > 18.myvzw.com[174.252.18.98]: SASL PLAIN authentication failed: > > authentication failure I attempted to increase logging before doing this. Changing the value in /etc/postfix/sasl/smtpd.conf didn't appear to have an effect. Adding -v to the submission line in master.cf created far too much logging. However, I have -v on the smtpd line in master.cf and I don't get the same amount of logging when I connect to port 25 (I assume because it's not specified twice and therefore increasing the verbosity). However, here's the sending test on port 587 (even though the client says it won't work). Apr 7 12:37:24 donald postfix/smtpd[22019]: smtp_get: EOF Apr 7 12:37:24 donald postfix/smtpd[22019]: match_hostname: 3.myvzw.com ~? 127.0.0.0/8 Apr 7 12:37:24 donald postfix/smtpd[22019]: match_hostaddr: 174.252.3.219 ~? 127.0.0.0/8 Apr 7 12:37:24 donald postfix/smtpd[22019]: match_list_match: 3.myvzw.com: no match Apr 7 12:37:24 donald postfix/smtpd[22019]: match_list_match: 174.252.3.219: no match Apr 7 12:37:24 donald postfix/smtpd[22019]: warning: problem talking to server private/anvil: Success Apr 7 12:37:25 donald postfix/smtpd[22019]: auto_clnt_close: disconnect private/anvil stream Apr 7 12:37:25 donald postfix/smtpd[22019]: auto_clnt_open: connected to private/anvil Apr 7 12:37:25 donald postfix/smtpd[22019]: send attr request = disconnect Apr 7 12:37:25 donald postfix/smtpd[22019]: send attr ident = submission:174.252.3.219 Apr 7 12:37:25 donald postfix/smtpd[22019]: private/anvil: wanted attribute: status Apr 7 12:37:25 donald postfix/smtpd[22019]: input attribute name: status Apr 7 12:37:25 donald postfix/smtpd[22019]: input attribute value: 0 Apr 7 12:37:25 donald postfix/smtpd[22019]: private/anvil: wanted attribute: (list terminator) Apr 7 12:37:25 donald postfix/smtpd[22019]: input attribute name: (e
SASL Error on Submission port
Hi Running 2.3.8 Debian package (I'll be upgrading shortly), I was already supporting TLS and SASL auth. One of my users recently moved to RCN and they block port 25 so I'm trying to open 587. I added this to my master.cf submission inet n - - - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes #-o smtpd_sasl_security_options=noanonymous # I added that to mirror main.cf, but no change -o smtpd_client_restrictions=permit_sasl_authenticated,reject However, when I test I get a SASL auth error. If I switch my client back to port 25, there is no SASL error. Connecting to port 25 Apr 7 10:00:30 donald postfix/smtpd[21028]: connect from 18.myvzw.com[174.252.18.98] Apr 7 10:00:31 donald postfix/smtpd[21028]: setting up TLS connection from 18.myvzw.com[174.252.18.98] Apr 7 10:00:32 donald postfix/smtpd[21028]: TLS connection established from 18.myvzw.com[174.252.18.98]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Apr 7 10:00:34 donald postfix/smtpd[21028]: disconnect from 18.myvzw.com[174.252.18.98] Connecting from port 587 Apr 7 10:01:04 donald postfix/smtpd[21032]: connect from 18.myvzw.com[174.252.18.98] Apr 7 10:01:06 donald postfix/smtpd[21032]: setting up TLS connection from 18.myvzw.com[174.252.18.98] Apr 7 10:01:07 donald postfix/smtpd[21032]: TLS connection established from 18.myvzw.com[174.252.18.98]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Apr 7 10:01:09 donald postfix/smtpd[21032]: warning: SASL authentication failure: Password verification failed Apr 7 10:01:09 donald postfix/smtpd[21032]: warning: 18.myvzw.com[174.252.18.98]: SASL PLAIN authentication failed: authentication failure Why is your software bro.. What did I do wrong? :) I assumed that main.cf sasl parameters would apply to any port that used sasl. postconf -n | grep sasl broken_sasl_auth_clients = yes smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, permit_sasl_authenticated, reject_sender_login_mismatch, check_client_access hash:/var/lib/pop-before-smtp/hosts,check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/ip_whitelist, check_recipient_access hash:/etc/postfix/laxdomains,reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_sender_domain,reject_unknown_recipient_domain, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname,permit_mynetworks, check_policy_service inet:127.0.0.1:10031, reject_unlisted_recipient, reject_unauth_destination,reject_rbl_client bl.spamcop.net, reject_rbl_client cbl.abuseat.org, reject_rbl_client zen.spamhaus.org, reject_rbl_client blackholes.mail-abuse.org,reject_rbl_client tw.countries.nerd.dk, reject_rbl_client kr.countries.nerd.dk, reject_rbl_client cn.countries.nerd.dk, reject_rbl_client relays.mail-abuse.org,reject_rhsbl_sender dsn.rfc-ignorant.org, warn_if_reject, reject_unknown_client, warn_if_reject, reject_rhsbl_client dsn.rfc-ignorant.org, warn_if_reject, reject_rbl_client dnsbl.sorbs.net, warn_if_reject, reject_rbl_client dnsbl.njabl.org, warn_if_reject, reject_rbl_client dul.dnsbl.sorbs.net,permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = mydomain.net smtpd_sasl_security_options = noanonymous Let me know if you want the whole thing. Is there something else I need to insert in main.cf Thanks.
RE: Increase the mail spped in postfix
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] On Behalf Of Johan Pappu > > How do I Increase my mail sending speed in postfix to all the > destinations? > > Do i need to make changes in main.cf? > > Please suggest me http://lmgtfy.com/?q=postfix+increase+throughput+all+destinations&l=1
RE: Making my own pipe..
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] On Behalf Of Jeroen Geilman > Sent: Saturday, March 26, 2011 2:34 PM > To: postfix-users@postfix.org > Subject: Re: Making my own pipe.. > > On 03/25/2011 12:02 AM, Simon Brereton wrote: > > Hi > > > > I'm still trying to get Postfix to use deliverquota to deliver the > mails to my Maildirs. > > > > The only thing I could find on the net was a comment from Magnus > http://www.irbs.net/internet/postfix/0412/1673.html that I had to > make my own pipe. > > > > So this is my attempt: > > > > deliverquota unix - n n - - pipe > > flags=DRhu user=vmail argv=/usr/bin/deliverquota > $domain/$recipient > > > > One concern - vmail is not a user on my system (and since I copied > this from the maildrop pipe, I'm now wondering how mail is delivered > at all. > > > > Not via maildrop, since the user does not exist. > The first message postfix tries to deliver to the maildrop transport > will crash it with a fatal error. > > For basic information on how (local) mail is delivered, read > http://www.postfix.org/OVERVIEW.html#delivering I agree with your diagnosis :) I'm just now confused as to what *is* delivering mail. I'll try to figure that out. > > My first question is, is $domain/$recipient the way to deliver a > Maildir structure that is always domain.tld/user where user is the > portion before the @ - this is the way I've understood man pipe, but > I'd like to be sure. > > Do I need it to be unpriv or not? > > > > The choice of mailstore is unrelated to any other postfix > configuration options; it's just a choice. > If you want mail to be stored in /var/mail/domain.tld/username then > the above will accomplish that. > > I'm unsure what you mean by "unpriv" - postfix does not execute > setuid root programs, so in that sense, everything is unprivileged. Thanks for the validation. As for the unpriv - I was just going off the table headers in master.cf > > My second question is what happens when deliverquota refuses to > deliver the mail because the Maildir is over quota? Does postfix try > to deliver a DNS? > > > > > > That depends on the status deliverquota returns to postfix. > If it's a temporary error, the message will be deferred and retried > later. > If it's a permanent error, the message will be rejected and postfix > will > generate a DSN back to the originator. Okay - either will be great so long as the permanent error is something about over quota. Or can be customised as such. Thanks for the pointers.
Making my own pipe..
Hi I'm still trying to get Postfix to use deliverquota to deliver the mails to my Maildirs. The only thing I could find on the net was a comment from Magnus http://www.irbs.net/internet/postfix/0412/1673.html that I had to make my own pipe. So this is my attempt: deliverquota unix - n n - - pipe flags=DRhu user=vmail argv=/usr/bin/deliverquota $domain/$recipient One concern - vmail is not a user on my system (and since I copied this from the maildrop pipe, I'm now wondering how mail is delivered at all. My first question is, is $domain/$recipient the way to deliver a Maildir structure that is always domain.tld/user where user is the portion before the @ - this is the way I've understood man pipe, but I'd like to be sure. Do I need it to be unpriv or not? My second question is what happens when deliverquota refuses to deliver the mail because the Maildir is over quota? Does postfix try to deliver a DNS? Thanks.
