Re: address rewriting with pcre?
On 17-Mar-2009, at 08:52, Victor Duchovni wrote:
On Tue, Mar 17, 2009 at 10:01:53AM -0400, Charles Marcus wrote:
On 3/17/2009 9:43 AM, Erwan David wrote:
You may generate the pcre file with a line
/recipient_([...@_]+)@localdomain/recipient+$...@localdomain
for each valid recipient. This would preserve the validation of
recipient at RCPT TO stage.
Interesting... and maybe a good candidate for my first usable
scripting
attempt.
Perl is the natural choice for this:
$ echo u...@example.com |
domain=example.com perl -lpe '
s{^(.*)\...@\q$env{domain}\e$}
{/^\Q$1\E_(.*)\...@\q$env{domain}\e\$/
$1+\${...@$env{domain}}o;'
/^user_(.*)@example\.com$/ user+$...@example.com
In practice instead of echo ... | Perl would read a list of
addresses from
a file. The \Q...\E construct is the critical ingredient for
quoting PCRE
special characters in the address localpart and domain.
I came up with this one liner:
$ ls -1 /usr/local/virtual/ | grep @ | sed 's/^\([...@]*\)@\(.*\)$/\/
^\1_\(.*\)@\2$\/ \1+$...@\2/'
testu...@example.com = /^testuser_(.*)@example.com$/ testuser+$...@example.com
But the sed works for dumping all the virtual users into a .pcre map
for postfix.
--
My mind is going. There is no question about it. I can feel it. I can
feel it. I can feel it. I'm... afraid.
Re: address rewriting with pcre?
On 19-Mar-2009, at 04:14, Charles Marcus wrote: On 3/19/2009 5:55 AM, LuKreme wrote: I came up with this one liner: $ ls -1 /usr/local/virtual/ | grep @ | sed 's/^\([...@]*\)@\(.*\)$/\/^\1_\(.*\)@\2$\/ \1+$...@\2/' testu...@example.com = /^testuser_(.*)@example.com$/ testuser+$...@example.com But the sed works for dumping all the virtual users into a .pcre map for postfix. I guess I'll just have to wait and see if this ever gets support natively... it isn't that big of a problem, but it is very annoying when I run into a site that doesn't allow using a plussed address, and having an optional character or two that I could designate on a per site basis would be very convenient. Well, the sed I posted can easily create the virtual table you need without causing backscatter. $ ls -1 /usr/local/virtual/ | grep @ | \ sed 's/^\([...@]*\)@\(.*\)$/\/^\1_\(.*\)@\2$\/ \1+$...@\2/' \ /etc/postfix/virtual_address.pcre main.cf: virtual_alias_maps = hash:$config_directory/virtual pcre:$config_directory/virtual_address.pcre, mysql:$config_directory/mysql_virtual_alias_maps.cf of course the sed will work for any input in the form of 'u...@example.com ' If your user list changes frequently you can put it in a crontab. Mine changes infrequently enough I can afford to run it manually. -- Over 3,500 gay marriages and, what, no hellfire? I was promise hellfire. And riots. What gives? -- Mark Morford
Re: address rewriting with pcre?
On 19-Mar-2009, at 04:45, Wietse Venema wrote:
$ ls -1 /usr/local/virtual/ | grep @ | sed 's/^\([...@]*\)@\(.*\)$/
\/
^\1_\(.*\)@\2$\/ \1+$...@\2/'
testu...@example.com = /^testuser_(.*)@example.com$/ testuser+$...@example.com
This is BROKEN. You are not escaping any of the regexp metacharacters
such as '.' and so on.
All righty, I didn't escape the . but since exampleqcom or example$com
are not valid hostnames and the match is anchored to both the start
and end of the string AND since it is pulling the data from my own
list of existing users, I'm not seeing that it's much of a risk.
But sure, you can escape the . if you like, it only adds a few
characters to the sed portion.
sed 's/^\([...@]*\)@\([^.]*\)\.\(.*\)$/\/^\1_\(.*\)@\2\\.\3$\/ \1+${1}@
\2\\.\3/'
--
Well boys, we got three engines out, we got more holes in us than a
horse trader's mule, the radio is gone and we're leaking fuel
and if we was flying any lower why we'd need sleigh bells on
this thing... but we got one little budge on those Roosskies.
At this height why they might harpoon us but they dang sure
ain't gonna spot us on no radar screen!
Re: Question about anvil settings
On 19-Mar-2009, at 04:44, Wietse Venema wrote: LuKreme: My server is pretty light weight, and I don't tend to get too many floods of spammers, but are these defaults reasonable to mitigate the damage that a flood might do? Are these defaults anything a normal user is ever going to hit? A normal user is NEVER going to hit these limits. As documented, anvil is for out-of-control clients. It is not a traffic quota tool, and must not be used for that purpose. OK, but if the numbers were lowered to ... oh, say smtpd_client_connection_rate_limit = 8 smtpd_client_connection_count_limit = 20 A normal user is still never going to hit them I'd think. Obviously, on a large server with a LAN or a lot of people maybe behind a single IP those numbers wouldn't work. OTOH, I'm not changing anything at this point. -- I AM ZOMBOR! (kelly) ZOMBOR!
Re: cyrus sasl2 and authentication [LONG]
On 18-Mar-2009, at 02:38, Patrick Ben Koetter wrote: * LuKreme krem...@kreme.com: path to which socket there? $ ls -ls /var/run/saslauthd/ total 2 0 srwxrwxrwx 1 root postfix 0 Mar 17 03:52 mux mux it is. Starting saslauthd. saslauthd[91067] :main: could not chdir to: /var/run/ saslauthd/mux saslauthd[91067] :main: chdir: No such file or directory saslauthd[91067] :main: Check to make sure the directory exists and is saslauthd[91067] :main: writeable by the user this process runs as. If I set it to /var/run/saslauthd/ it starts up root 91078 0.0 0.3 5168 1924 ?? Is8:24AM 0:00.01 /usr/ local/sbin/saslauthd -a pam -m /var/run/saslauthd/ pwcheck_method: saslauthd mech_list: plain login Read it this way: libsasl use saslauthd to process authentication. saslauthd use PAM as backend. PAM use PAM mysql as backend ... Ok, but I still get: submit-tls/smtpd[91093]: Anonymous TLS connection established from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: TLSv1 with cipher AES128-SHA (128/128 bits) submit-tls/smtpd[91093]: warning: SASL authentication failure: Can only find author (no password) submit-tls/smtpd[91093]: warning: c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: SASL PLAIN authentication failed: bad protocol / cancel submit-tls/smtpd[91093]: lost connection after AUTH from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Is there anyway to test sasl locally and verbosely so that I can get a better idea of what's going on. Something like authtest for courier? Looking a lot I see that most people are creating a plaintext password field for the mysql database, I assume to get around this exact issue. Is dovecot better in this regard? -- Quis custodiet opsos custodes
Re: cyrus sasl2 and authentication [LONG]
On 18-Mar-2009, at 09:07, Patrick Ben Koetter wrote: testsaslauthd $ testsaslauthd -u u...@mysqlhosted.tld -p password 0: NO authentication failed $ testsaslauthd -u user -p password 0: OK Success. So I can authenticate against the local users with testsaslauth, but I cannot over smtp submit-tls/smtpd[93240]: Anonymous TLS connection established from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: TLSv1 with cipher AES128-SHA (128/128 bits) submit-tls/smtpd[93240]: warning: SASL authentication failure: Password verification failed submit-tls/smtpd[93240]: warning: c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: SASL PLAIN authentication failed: authentication failure (same user and password as in the second testsaslauthd check) Easier, yes. I recommend Dovecot unless there's a feature in Cyrus IMAP you need. OK, ripping out cyrus as soon as I find a good walkthrough for dovecot. Especially if I can find one about ADDING dovecot. -- And the three men I admire most, the father son and the holly ghost they caught the last train for the coast...
cyrus sasl2 and authentication [LONG]
OK, first question is will I be able to setup smtpd.conf so that it will support MULTIPLE authentication methods (sql and PAM)? But first, to get it working. I am running on a custom port right now to avoid mucking with 587 until everything is working: 2525 inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=submit-tls If I authenticate against users in the sasldb file, with a smtpd.conf of: $ cat /usr/local/lib/sasl2/smtpd.conf pwcheck_method: auxprop mech_list: PLAIN LOGIN everything works fine. I authenticate and maillog shows the authentication. No problem at all. If I change smtpd.conf to : pwcheck_method: auxprop mech_list: PLAIN LOGIN auxprop_plugin: sql sql_verbose: yes sql_engine: mysql sql_hostnames: localhost sql_user: *user* sql_passwd: *passwd* sql_database: postfix sql_select: select password from mailbox where username = '%u' authdaemon_path=/var/run/authdaemond/socket $ ls -ls /var/run/authdaemond/socket 0 srwxrwxrwx 1 root courier 0 Mar 17 01:49 /var/run/authdaemond/ socket authentication fails: submit-tls/smtpd[31779]: initializing the server-side TLS engine submit-tls/smtpd[31779]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit-tls/smtpd[31779]: setting up TLS connection from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit-tls/smtpd[31779]: c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: TLS cipher list ALL:+RC4:@STRENGTH submit-tls/smtpd[31779]: SSL_accept:before/accept initialization submit-tls/smtpd[31779]: SSL_accept:SSLv3 read client hello B submit-tls/smtpd[31779]: SSL_accept:SSLv3 write server hello A submit-tls/smtpd[31779]: SSL_accept:SSLv3 write certificate A submit-tls/smtpd[31779]: SSL_accept:SSLv3 write server done A submit-tls/smtpd[31779]: SSL_accept:SSLv3 flush data submit-tls/smtpd[31779]: SSL_accept:SSLv3 read client key exchange A submit-tls/smtpd[31779]: SSL_accept:SSLv3 read finished A submit-tls/smtpd[31779]: SSL_accept:SSLv3 write change cipher spec A submit-tls/smtpd[31779]: SSL_accept:SSLv3 write finished A submit-tls/smtpd[31779]: SSL_accept:SSLv3 flush data submit-tls/smtpd[31779]: c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: save session 7EDABA540FC825A33F40BEC39254E374881EE12B0285025A20F73AF83FB2F4E5 s=2525 to smtpd cache submit-tls/smtpd[31779]: Anonymous TLS connection established from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: TLSv1 with cipher AES128-SHA (128/128 bits) submit-tls/smtpd[31779]: warning: SASL authentication failure: Password verification failed submit-tls/smtpd[31779]: warning: c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]: SASL PLAIN authentication failed: authentication failure submit-tls/smtpd[31779]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] this is what my MUA logs: 220 mail.covisp.net ESMTP Postfix 2.5.6 EHLO cerebus.hsd1.co.comcast.net 250-mail.covisp.net 250-PIPELINING 250-SIZE 15728640 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN STARTTLS 220 2.0.0 Ready to start TLS EHLO cerebus.hsd1.co.comcast.net 250-mail.covisp.net 250-PIPELINING 250-SIZE 15728640 250-ETRN 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN *** 535 5.7.8 Error: authentication failed: authentication failure QUIT Manually, I cannot get that far: $ telnet mail 2525 Trying 75.148.117.93... Connected to akane. Escape character is '^]'. 220 mail.covisp.net ESMTP Postfix 2.5.6 EHLO cerebus.hsd1.co.comcast.net 250-mail.covisp.net 250-PIPELINING 250-SIZE 15728640 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN STARTTLS 220 2.0.0 Ready to start TLS EHLO cerebus.hsd1.co.comcast.net Connection closed by foreign host. I rebuilt cyrus-sasl2 so I'd be sure of exactly what configuration options were used: configure: running /bin/sh './configure' --prefix=/usr/local '-- sysconfdir=/usr/local/etc' '--with-configdir=/usr/local/lib/sasl2:/usr/ local/etc/sasl2' '--with-plugindir=/usr/local/lib/sasl2' '--with- dbpath=/usr/local/etc/sasldb2' '--includedir=/usr/local/include' '-- enable-static' '--enable-auth-sasldb' '--with-rc4=openssl' '--with- saslauthd=/var/run/saslauthd' '--with-dblib=berkeley' '--with-bdb- libdir=/usr/local/lib' '--with-bdb-incdir=/usr/local/include/db41' '-- with-bdb=db41' '--with-mysql=/usr/local' '--without-pgsql' '--without- sqlite' '--enable-sql' '--with-authdaemond=/var/run/authdaemond/ socket' '--enable-login' '--enable-ntlm' '--enable-gssapi' '--disable- krb4' '--with-openssl=/usr/local' '--prefix=/usr/local' '--mandir=/usr/ local/man' '--infodir=/usr/local/info/' '--build=i386-portbld- freebsd6.2' 'CC=cc' 'CFLAGS=-O2 -fno-strict-aliasing -pipe -
Re: cyrus sasl2 and authentication [LONG]
On 17-Mar-2009, at 03:15, Patrick Ben Koetter wrote: * LuKreme krem...@kreme.com: OK, first question is will I be able to setup smtpd.conf so that it will support MULTIPLE authentication methods (sql and PAM)? But first, to get it working. I am running on a custom port right now to avoid mucking with 587 until everything is working: 2525 inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=submit-tls If I authenticate against users in the sasldb file, with a smtpd.conf of: $ cat /usr/local/lib/sasl2/smtpd.conf Path MUST be /usr/lib/sasl2/smtpd.conf. Create a symlink. Authentication works, because sasldb is the default and fallback method. If libsasl can't find a smtpd.conf it will fall back to sasldb. Ok, but then why does it stop working if I change the contents of /usr/ local/lib/sasl2/smtpd.conf? And why are the compile directives set to: --with-configdir=/usr/local/lib/sasl2:/usr/local/etc/sasl2' '--with- plugindir=/usr/local/lib/sasl2' '--with-dbpath=/usr/local/etc/sasldb2' I've made sure that /var/run/saslauthd/ is owned by root:postfix (it was root:mail) and have removed the authdaemon_path line and am trying again. Hopefully this was it. Oh, and since I forgot to mention, Courier-imapd-ssl works fine, it is only the SMTP authentication that is proving cumbersome. pwcheck_method: auxprop mech_list: PLAIN LOGIN everything works fine. I authenticate and maillog shows the authentication. No problem at all. If I change smtpd.conf to : pwcheck_method: auxprop mech_list: PLAIN LOGIN auxprop_plugin: sql sql_verbose: yes sql_engine: mysql sql_hostnames: localhost sql_user: *user* sql_passwd: *passwd* sql_database: postfix sql_select: select password from mailbox where username = '%u' authdaemon_path=/var/run/authdaemond/socket $ ls -ls /var/run/authdaemond/socket 0 srwxrwxrwx 1 root courier 0 Mar 17 01:49 /var/run/authdaemond/ socket Which do you want authdaemond or sql? That's a good question. These were the instructions given with postfixadmin, but I did try this without the authdaemon_path line as well. Still, made a few changes and am giving it another go. -- This story shall the good man teach his son; And Crispin Crispian shal ne'er go by, From this day to the ending of the world, But we in it shall be remember'd;
Re: address rewriting with pcre?
On 17-Mar-2009, at 04:24, Robert Brooks wrote:
So, what I'd like to do if it's possible, is rewrite f...@bar.example.com
to bar+...@example.com.
I rewrite foo_...@example.com to foo+...@example.com
virtaul.pcre:
/^(.*)_(.*)@example.com$/${1}+$...@example.com
virtual_alias_maps =
hash:$config_directory/virtual
pcre:$config_directory/virtual.pcre,
mysql:$config_directory/mysql_virtual_alias_maps.cf
your line would look like
/^(.*)@(.*)\.example.com$/${1}+$...@example.com
In fact, I like that idea, I might implement it.
--
Beware of the Leopard!
Re: address rewriting with pcre?
On 17-Mar-2009, at 05:01, Charles Marcus wrote: (not sure if using the 'or' vertical bar will work as expected here) It's a PCRE. As long as the PCRE is valid it should work. -- RTFM replies are great, but please specify exactly which FM to R
Re: address rewriting with pcre?
On 17-Mar-2009, at 06:09, Erwan David wrote:
I would fear it breaks recipient validation, accepting mail for eavery
address with a _ as valid.
That is a drawback. The other choice is to change the delimiter in
postfix to _ and rewrite it to accept all '+' addresses to '_'. The
trouble is the huge mass of ignorant websites that refuse to accept a
'+' and don't even care that they are wrong.
And since we've been using plus addressing for over 10 years, simply
switching to '_' (or '.' which at least one IMAP server uses) is just
not realistic.
The good thing is, it hasn't been much of a problem. In the last 30
days I've gotten exactly one address that was invalid and had a '_' in
it, and I'm pretty sure that was a spoof address that the domain owner
handed out.
It appears that, at least now, '_' is not in the spammer's lexicon of
addresses to try.
but yeah, this needs to be monitored as it can be a backscatter source:
Mar 17 07:21:22 mail postfix/smtpd[40467]: C3B7D118B9B7:
client=c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51]
Mar 17 07:21:22 mail postfix/cleanup[40775]: C3B7D118B9B7: message-id=040e794f-40e7-4c23-ac4b-001d5cf24...@kreme.com
Mar 17 07:21:22 mail postfix/qmgr[31772]: C3B7D118B9B7: from=krem...@kreme.com
, size=815, nrcpt=1 (queue active)
Mar 17 07:21:23 mail postfix/error[41241]: C3B7D118B9B7: to=ziggy+t...@kreme.com
, orig_to=ziggy_t...@kreme.com, relay=none, delay=0.3,
delays=0.09/0.14/0/0.07, dsn=5.0.0, status=bounced (User unknown)
Mar 17 07:21:23 mail postfix/bounce[41242]: C3B7D118B9B7: sender non-
delivery notification: 14A1A118BA5C
Mar 17 07:21:23 mail postfix/qmgr[31772]: C3B7D118B9B7: removed
Maybe we'll get support for multiple delimiters in postfix someday?
recipient_mutli_delimiters = {+,_.}
where everything between {} is a valid delimiter?
Not holding my breath though.
--
You and me
Sunday driving
Not arriving
Re: address rewriting with pcre?
On 17-Mar-2009, at 07:30, Charles Marcus wrote: So, is there no way to rewrite the recipient and *then* validate it? Sure, but not until after you've accepted the message. It's not like ziggy_test gets delivered to some random user. It's just that it generates a bounce instead of a reject. -- Fairy Tales are more than true; not because they tell us that dragons exist, but because they tell us that dragons can be beaten.
Re: address rewriting with pcre?
On 17-Mar-2009, at 07:39, Charles Marcus wrote: On 3/17/2009, LuKreme (krem...@kreme.com) wrote: It's not like ziggy_test gets delivered to some random user. It's just that it generates a bounce instead of a reject. Like I said, this is unacceptable (makes you a backscatter source). Then you have to wait and see if FuturePostfix supports multiple delimiters. -- My mind is going. There is no question about it. I can feel it. I can feel it. I can feel it. I'm... afraid.
Re: opinion about my configuration - correct main.cf
On 17-Mar-2009, at 06:29, Stacker Hush wrote: mynetworks = 127.0.0.0/8, 192.0.0.0/8, 10.0.0.0/8, 172.0.0.0/8 That does not mean what I think you think it means. The only class A private IP space is 10/8 and 127/8. The others are 192.168/15 and I think 172.16.0.0/12? However, even this is not a good idea unless you are actually using all of those private IP spaces and your LAN accesses the server from those addresses. For example, even though there is a LAN on the same connection as my servers, the LAN clients access the mailserver via its real IP, so I have none of those CIDR blocks in mynetworks. unknown_local_recipient_reject_code = 450 Why would an unknown local user be a temp fail? -- If I were you boys, I wouldn't talk or even think about women. T'aint good for your health.
Re: address rewriting with pcre?
On 17-Mar-2009, at 08:01, Charles Marcus wrote: On 3/17/2009 9:43 AM, Erwan David wrote: You may generate the pcre file with a line /recipient_([...@_]+)@localdomain/recipient+$...@localdomain for each valid recipient. This would preserve the validation of recipient at RCPT TO stage. Interesting... and maybe a good candidate for my first usable scripting attempt. Let us know what you come up with. -- Critics look at actresses one of two ways: you're either bankable or boinkable.
Re: cyrus sasl2 and authentication [LONG]
On 17-Mar-2009, at 03:49, LuKreme wrote: I've made sure that /var/run/saslauthd/ is owned by root:postfix (it was root:mail) and have removed the authdaemon_path line and am trying again. Hopefully this was it. That wasn't it, and the ownership by root:mail shouldn't matter as the postfix user is part of the mail group. I think I've read everything twice, and am stumped. Should I just start over and install dovecot (cyrus was the only option way back in the day)? -- Rent a flat above a shop, cut your hair and get a job, smoke some fags and play some pool, pretend you never went to school and still you'll never get it right cuz when you're lay'n in bed at night watching roaches climb the wall if you called your dad he could stop it all.
Re: cyrus sasl2 and authentication [LONG]
On 17-Mar-2009, at 11:47, Andreas Winkelmann wrote: On 17-Mar-2009, at 03:49, LuKreme wrote: I've made sure that /var/run/saslauthd/ is owned by root:postfix (it was root:mail) and have removed the authdaemon_path line and am trying again. Hopefully this was it. That wasn't it, and the ownership by root:mail shouldn't matter as the postfix user is part of the mail group. I think I've read everything twice, and am stumped. Should I just start over and install dovecot (cyrus was the only option way back in the day)? Did you check Patrick`s hint about the stored Passwords in your SQL- Server. Cyrus-SASL auxprop is bound to cleartext Passwords. If you have crypted Passwords, you have to patch Cyrus-SASL. Ah... I must have missed that. looks back Oh, well, that must be it then. passwords from postfixadmin are stored in md5crypt. (they look like $1$a28cb10c$wzblsb81Kv.F7vnMtqlEf.) So, more on this patching of Cyrus-SASL? -- I believe you can joke about anything. -- George Carlin
Re: cyrus sasl2 and authentication [LONG]
On 17-Mar-2009, at 13:45, Patrick Ben Koetter wrote: smtpd_sasl_security_options = noplaintext, noanonymous smtpd_sasl_tls_security_options = noanonymous As for the PAM part in the sasl authentication, start saslauthd like this: saslauthd -a pam -m /path/to/the/socket path to which socket there? $ ls -ls /var/run/saslauthd/ total 2 0 srwxrwxrwx 1 root postfix 0 Mar 17 03:52 mux 0 -rw--- 1 root postfix 0 Mar 17 03:52 mux.accept 2 -rw--- 1 root postfix 6 Mar 17 03:52 saslauthd.pid /var/run/saslauthd/mux ?? I found some info and came up with this in pam.d/smtp $ cat /etc/pam.d/smtp auth required pam_mysql.so user=postfix passwd=*** host=localhost \ db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1 account sufficient pam_mysql.so user=postfix passwd=*** host=localhost \ db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1 smtpd.conf is now simply: pwcheck_method: pam mech_list: plain login postfix/smtpd[66096]: initializing the server-side TLS engine postfix/smtpd[66096]: warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms postfix/smtpd[66096]: fatal: no SASL authentication mechanisms -- ++?++ Out of Cheese Error. Redo From Start.
Re: modify incoming mail
On 17-Mar-2009, at 17:18, Cedric Zeline wrote: I need some help. I would like to modify incoming emails. I need to add a link at top of the incoming mail body, in order to allow employees that received their email to click on this link and connect directly to our data base to check the client's data. I need to add a link that will pass the client's email as parameters (should be something like http://192.168.0.2/client.php?client=em...@domaine.com) . I was thinking to do this job with postfix body_checks features by using body rewritting but I can't find the way to do it because I can't find a way to identify the begining of the mail body. I don't know if you can identify the beginning of the body reliably, but if you use a mail client for your employees that allows you to customise the headers that are displayed, you could do this with a prepend action in the headers. Still, *I* would do it with procmail. -- And the three men I admire most, the father son and the holly ghost they caught the last train for the coast...
Re: smtpd_tls_session_cache_database
On 15-Mar-2009, at 14:25, Victor Duchovni wrote: On Sun, Mar 15, 2009 at 12:27:37PM -0400, Wietse Venema wrote: smtpd_tls_session_cache_database = btree:$data_directory/ smtpd_sessions postfix/smtpd[67779]: fatal: open database /var/db/postfix/ smtpd_sessions.db: No such file or directory smtpd never uses the smtpd_tls_session_cache_database setting. You have that file configured via some other main.cf parameter. Indeed this file is managed by trivial-rewrite(8), not smtpd(8). Perhaps the OP is trying to this file as access table? In any case no official Postfix release with TLS (2.2 or later) has smtpd(8) accessing the cache directly. There was a leading space on the smtpd_tls* lines, so they got glommed onto the previous statement (smtpd_sender_restrictions). I can connect now to the submission port from my MUA (mail.app) as long as I authenticate against the sasldb. I cannot connect from the command-line with openssl s_client: $ openssl s_client -connect mail.covisp.net:587 CONNECTED(0003) 4001:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:601: but from Mail.app: CONNECTED Mar 15 15:21:03.180 [kCFStreamSocketSecurityLevelNone] -- host:mail.covisp.net -- port:587 -- socket:0x30226650 -- thread: 0x326adb70 READ Mar 15 15:21:03.247 [kCFStreamSocketSecurityLevelNone] -- host:mail.covisp.net -- port:587 -- socket:0x30226650 -- thread: 0x326adb70 220 mail.covisp.net ESMTP Postfix 2.5.6 etc. I wonder at the SecurityLevelNone, but there is: WROTE Mar 15 15:22:03.909 [kCFStreamSocketSecurityLevelNegotiatedSSL] -- host:mail.covisp.net -- port:993 -- socket:0x1eb59230 -- thread: 0x3542dc40 1.251 LOGIN user READ Mar 15 15:22:03.951 [kCFStreamSocketSecurityLevelNegotiatedSSL] -- host:mail.covisp.net -- port:993 -- socket:0x1eb59230 -- thread: 0x3542dc40 1.251 OK LOGIN Ok. with submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=submit Also, changing the password or login causes it to fail, so it is working from the MUA, just not from the CLI. Of course, I need it to authenticate against the postfixadmin sql database instead (and PAM), but that is an issue for a different list. -- I do believe Marsellus Wallace, my husband, your boss, told you to take *me* out and do *whatever I wanted*. Now I wanna dance, I wanna win. I want that trophy, so dance good.
Re: smtpd_tls_session_cache_database
On 15-Mar-2009, at 17:08, mouss wrote: LuKreme a écrit : I can connect now to the submission port from my MUA (mail.app) as long as I authenticate against the sasldb. I cannot connect from the command-line with openssl s_client: no you can't. which is why Noel added connectivity to his recommendation. only use openssl to see what postfix would do for a STARTTLS. nothing more. Figured that out right after sending last. Everything works in postfix right now as it is. I am only able to auth against the salsdb with $ cat smtpd.conf pwcheck_method: auxprop mech_list: PLAIN LOGIN Any changes I've tried to make to that file so far have failed, so I need to read up on cyrus-sasl-2.1.22 and figure out why it doesn't work for... Oh, hang on, I think cyrus-sasl was not built with mysql support. Recompiling now, I bet that will sort it. -- Well I've seen the Heart of Darkness/Read the writing on the wall/an the voice out in the desert/Was the voice out in the hall
Re: non-alpha HELO
On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: lost connection after EHLO from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: timeout after UNKNOWN from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard. Appears so. Its default setting is Use default ports (25, 465, 587) -- There is a tragic flaw in our precious Constitution, and I don t know what can be done to fix it. This is it: Only nut cases want to be president.
Re: non-alpha HELO
On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: lost connection after EHLO from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: timeout after UNKNOWN from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard. Appears so. Its default setting is Use default ports (25, 465, 587) -- There is a tragic flaw in our precious Constitution, and I don t know what can be done to fix it. This is it: Only nut cases want to be president.
Re: non-alpha HELO
On 14-Mar-2009, at 13:02, mouss wrote: test the connection manually: $ telnet yourserv 587 ... EHLO yourclienthostname ... QUIT Right, I do know that. Sorry if I wasn't clear, my only point was that what was actaully logged under submit was not useful and expressing disappointment that there wasn't something like TLS failed AUTH failed or Hey, dumbass, you forgot to create a valid cert. Something along those lines. Appears so. Its default setting is Use default ports (25, 465, 587) this would be only at setup time (when you add an account...). No, that is the setting, unless you change it, for the outgoing server (outgoing servers in Mail.app are separate from accounts), but it does appear to actaully default to the first one that succeeds, and doesn't like if if taht port (25) stops working. or maybe if connection to the configured port doesn't work anymore. otherwise, it would be a nuisance. Yes, it can be a nuisance... Oh, and someone asked what ISPs would ever block p587? I had a user who was unable to access the mail server from Darfur until I opened up a port above 1024 to SMTP. He was able to CHECK mail, but not send on either 25 or 587. I think I setup 2025 for him and everything worked fine, albeit at glacial speed. Then he discovered Squirrelmail and it's not been a problem since. It was almost like the Sudan had a single 128K DSL connection to the rest of the world -- Incredible! One of the worst performances of my career and they never doubted it for a second.
smtpd_tls_session_cache_database
In reading http://www.postfix.org/TLS_README.html and all the posts in the last 15 months with 'smtpd_tls_session_cache_database' in the subject (all 7 of them!), it is not clear to me how the smtpd_tls_session_cache_database file is created, or what exactly it contains. If the file is not present, postfix doesn't create it, but logs a fatal error. This is what I have so far: # TLS smtpd_tls_cert_file = /etc/postfix/server.pem smtpd_tls_key_file = $smtpd_tls_cert_file smtpd_tls_loglevel = 2 # will drop to 0 or 1 after setup is complete smtpd_tls_security_level = may # smtpd_tls_session_cache_database = btree:$data_directory/ smtpd_sessions smtpd_tls_session_cache_timeout = 1800s # 30 minutes smtpd_starttls_timeout = 90s As for the pem file, the docs say that the certificate supplied must be usable as an SSL server cert and pass the -purpose test: $ openssl verify -purpose sslserver mail.covisp.net.pem error 18 at 0 depth lookup:self signed certificate OK Is that still considered a pass since it returns OK? (server.pem is a copy of mail.covisp.net.pem) Is there a way to test the /etc/postfix/server.pem file directly to see if it passes muster for postfix's use other than actually trying to connect? $ openssl s_client -starttls smtp -showcerts -connect 127.0.0.1:587 CONNECTED(0003) 69661:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ s23_clnt.c:478: And if the cert is self-signed does any part of: In order to verify a certificate, the CA certificate (in case of a certificate chain, all CA certificates) must be available. You should add these certificates to the server certificate, the server certificate first, then the issuing CA(s). still apply? If so, what is the CA cert for a self-signed cert? -- Charlie don't surf!
non-alpha HELO
I have the following helo restriction in a pcre file:
!/[[:alpha:]]/REJECT helo non-alpha helo not allowed
I ran it with WARN for quite a while and didn't see any legitimate
messages that hit it, so I moved it to REJECT. However, my mailserver
is starting to see more traffic now than it used to, and more varied.
I had to remove my CIDR blocks on china and south korea, for example.
True, most of that mail still hits zen or fails to pass greylisting,
but where there used to be -zero- legit mail from those countries, now
there's a little.
So I thought I'd see if anyone else thought that a helo in the form
[12.34.56.789] SHOULD be allowed. I mean, as far as I recall, this is
still technically allowed, right?
I've thought about simply going back to warn, but when I first
implemented this check it hit a few dozen a day, and now it hits many
hundreds, so searching for legitimate messages among the warnings will
be considerably harder.
My complete helo_checks.pcre looks like this:
!/[[:alpha:]]/REJECT helo non-alpha helo not
allowed to talk to me
!/\.[[:alpha:]]{2,}$/ REJECT helo no TLD, invalid hostname
# Block localhost (unusual in HELO)
/^localhost(\.localdomain)?$/ REJECT helo Unacceptable hostname in helo
/^unknown$/ REJECT helo No unknown hostnames
/^75\.148\.117\.93/ REJECT helo Don't Spoof My IP
/^\[75\.148\.117\.93\]/ REJECT helo Don't Spoof My IP
/^covisp\.net$/ REJECT helo Don't spoof my hostname
/^southgaylord\.com$/ REJECT helo Don't spoof my hostname
/^kreme\.com$/ REJECT helo Don't spoof my hostname
/^example\.com$/ REJECT helo Don't spoof my hostname
/^example\.net$/ REJECT helo Don't spoof my hostname
/\.(dsl|adsl|pool|dynamic|user|hsd|dyn|dial)/ REJECT helo Dynamic .
addresses not allowed
/^(dsl|adsl|pool|dynamic|user|hsd|dyn|dial)/ REJECT helo Dynamic ^
addresses not allowed
--
Cogito cogito, ergo cogito sum, cogito
Re: non-alpha HELO
On 13-Mar-2009, at 10:49, Bill Cole wrote: Hi Bill! Postfix is a little more complicated than SIMS, isn't it :) If you have a good port 587 config in master.cf, you may need no changes there. My submission entry for a server that accepts no port 25 submission from outside the LAN is: submission inetn - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit -o smtpd_milters= (If your main.cf doesn't define smtpd_milters, the last line is unnecessary) That's nice to see. My master.cf is quite old, and the submission port info is... lemme look Oh, my 587 inet n - n - - smtpd That's it. Lemme at least change that. Forcing users into submission (or however you want to phrase that...) is really a main.cf issue, and depending on your network and users it may be more a matter of encouragement than force. Any measure you have in place in main.cf smtpd_*_restrictions entries solely in order to permit your users' initial submissions should be removed from there and instead be in the smtpd_*_restrictions definitions in the submission entry in master.cf. I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. The generalized rule is that main.cf defines a baseline set of definitions, while the -o entries in the master.cf entry for a service replaces definitions as needed. For example, I define my smtpd_sasl_* settings in main.cf because that way they don't clutter master.cf, and without permit_sasl_authenticated in main.cf, those settings are operationally irrelevant to the port 25 smtpd. -- Charlie don't surf!
Re: virtual aliases/mailbox mx records
On Mar 12, 2009, at 9:56, Marc Jauvin m...@r4l.com wrote: So how can we configure postfix so that it will realize that the mail should be routed to the NEW MX host? 1) don't top post. 2) Remove the domain from your maps.
Re: virtual aliases/mailbox mx records
On 12-Mar-2009, at 10:50, Marc Jauvin wrote: Since we have no means to know that the MX records were modified, then we can't remove those virtual mapping rules from our database. $ dig mx example.com | grep -A1 ANSWER SECTION | grep MX I suppose you could run that each day and flag domains in which you are no longer the MX host. Is there something I'm missing? You have a problem with your users chaning MX without notifying you. THAT is your problem, not postfix. -- Personal isn't the same as important
Re: virtual_alias_maps
On 10-Mar-2009, at 21:42, Victor Duchovni wrote: You are supposed to now have just the domains here, and the user mappings in virtual_alias_maps. OK, i thought I tried that when I put the bare domains in virtual_alias_domains but something else must have been mucked up then. I did say multiple times that this setting depends on *ONLY* the domains being listed in this file. Otherwise use two files: /etc/postfix/virtual_alias_domains: example.com virtual alias domain example.net virtual alias domain /etc/postfix/virtual: j...@example.comj...@somewhere f...@example.netf...@somewhere And thus: virtual_alias_domains = hash:/etc/postfix/virtual_alias_domains virtual_alias_maps = hash:/etc/postfix/virtual, ... more tables for virtual(5) rewrites ... Since the domain list is short, I just listed then in virtual_alias_domains, removed them from /etc/postfix/virtual, and left virtual_alias_maps the way it was. (Oh, and postmapped the virtual file as well). Everything (well, everything related to this) looks like it's working now, thanks for your patience. -- We will fight for Bovine Freedom and hold our large heads high We will run free with the Buffalo or die
Re: v2.5.5 showq and postcat date/time stamp discrepancy
On 10-Mar-2009, at 20:43, Glen B wrote: Why no TZ was set in the chroot, I'm clueless Because the chroot jail doesn't have access to read the TMZ information? -- I draw the line at 7 unreturned phone calls.
Re: virtual_alias_maps
On 10-Mar-2009, at 21:48, Sahil Tandon wrote: The lookup key for virtual_alias_DOMAINS should be a domain name, not full address. Are you going to reply with some more sarcastic pedantry? :-) Hey now, there's always room for more sarcastic pedantry! I *think* I have it all straight in my head now. really for sure this time. -- The trouble with being a god is that you've got no one to pray to.
Re: changing sender null address...
On 10-Mar-2009, at 18:15, mme...@gmail.com wrote: when postfix wants to send a bounce message (notifying the rejected message), my mail system will always try to deliver it directly to the recipient server (i'm not using a relayhost)... i think i need to change to _real_send...@realdomain. I played with this parameters, without sucess: NEVER EVER send a bounce message for a message you have accepted. Either reject it during the transaction phase, or accept it and dow what you will with it, but sending a bounce to an almost certainly forged 'From:' address is a sure way to make a lot of sysadmins angry and get you blacklisted. And not in those friendly RBLs you have some hope of getting off of, but in the Black Pits of Calcutta sorts of private blacklists you have no hope of ever removing yourself from. -- I've got Mathematica 2.2 on my Quadra
Rewriting addresses
I have a file /etc/postfix/virtual.pcre that contains lines like this:
/^(.*)_(.*)@example.com$/${1}+$...@example.com
/^(.*)_(.*)@example.org$/${1}+$...@example.org
/^(.*)_(.*)@example.net$/${1}+$...@example.net
etc etc. This is to allow the _ to act as an additional address
extension character to get around the legion of retarded website
admins that reject '+' addresses as invalid.
I would like to have a single line
/^(.*)_(.*)@(.*)$/ ${1}+$...@${3}
since that would mean I would not have to update this file each time I
add a virtual domain; but that won't work as it will rewrite the
addresses on OUTBOUND email as well as inbound email, so if someone
sends an email to first_l...@outboundexample.com it gets rewritten to first+l...@outboundexample.com
and bounces.
So, other than manually listing every virtual domain, is there
something else I could do? Is there a way to use mysql:/usr/local/etc/
postfix/mysql_virtual_domains_maps.cf in some way so that the pcre
expression will only match for those domains that are listed in the map?
--
Criticizing evolutionary theory because Darwin was limited is like
claiming computers don't work because Chuck Babbage didn't
foresee Duke Nukem 3.
Re: Rewriting addresses
On 11-Mar-2009, at 08:27, Charles Marcus wrote:
On 3/11/2009 9:38 AM, LuKreme wrote:
I have a file /etc/postfix/virtual.pcre that contains lines like
this:
/^(.*)_(.*)@example.com$/${1}+$...@example.com
/^(.*)_(.*)@example.org$/${1}+$...@example.org
/^(.*)_(.*)@example.net$/${1}+$...@example.net
etc etc. This is to allow the _ to act as an additional address
extension character to get around the legion of retarded website
admins
that reject '+' addresses as invalid.
It would be better if postfix could natively support multiple
recipient
delimiters...
Yes, well, if wishes were horses beggars would ride. As far as I know
there's no plan to allow multiple delimiters. I'd love to be wrong on
this.
On 11-Mar-2009, at 10:26, Victor Duchovni wrote:
Sorry, not possible. Also the above defeats recipient validation for
email addresses with _ in them, it is not recommended.
Yep, I am aware of that. In this case, however, the ability to use a
second delimiter far outweighs the lack of recipient validation.
--
Mom: There was more than one lobster present at the birth of Jesus?
Daughter: Duh.
Re: Single domain and two destinations via Postfix
On 11-Mar-2009, at 09:14, Noel Jones wrote: You can optionally use a pcre smtp_generic_maps to rewrite the recipient back to the original domain. main.cf smtp_generic_maps = pcre:/etc/postfix/smtp_generic.pcre smtp_generic.pcre: /^(.*)@new\.example\.com$/ $...@example.com This would need to be on new.example.com, right? -- and I lift my glass to the Awful Truth / which you can't reveal to the Ears of Youth / except to say it isn't worth a dime
Re: Single domain and two destinations via Postfix
On 11-Mar-2009, at 14:24, Noel Jones wrote: No, this is on the existing gateway. Generic rewriting is for outgoing mail. http://www.postfix.org/ADDRESS_REWRITING_README.html#generic Ah. Too bad there is not a similar option for local only mail, then I could use it to solve my multiple delimiters issue in the 'Rewriting addresses' thread. -- Incredible! One of the worst performances of my career and they never doubted it for a second.
Re: Ubuntu, dynamicmaps?
On 11-Mar-2009, at 15:40, KLaM Postmaster wrote: I am thinking of switching to Ubuntu 8.10 LTS server, however when I look at the Postfix configuration it seems somewhat odd. Yes, everything in Debian is 'somewhat odd'. It's what makes Deb Deb. I don't want to start a flame war, but I would like to hear what people think about things like dynamicmaps and other oddities of the Ubuntu Postfix configuration. I looked at Debian a long time ago and decided that postfix and SSL and all the services I wanted to run were complex enough that I didn't want to add another layer of complication to that. I don't think anything Debian does is bad per se, but it is different. In my case I decided that different was bad. With a base of FreeBSD I've had a lot less trouble getting help than I think I would have otherwise. I also really like portinstall and portupgrade more than rpm or apt-get. -- Living is easy with eyes closed, misunderstanding all you see
Re: virtual_alias_maps
On 9-Mar-2009, at 15:58, mouss wrote: you must understand the difference between virtual_mailbox_domains and virtual_alias_domains I understand the difference, I have virtual_mailbox_domains assigned and I don't have virtual_alias_domains :) Actually, isn't virtual_mailbox_domains default value ($virtual_maps) built from the contents of $config_directory/virtual? -- Ah, you're a Penguin too? Pilgrim, my son. Pilgrim. Yes, of the Hare Krishnas. Hairy Fishnuts.
Re: virtual_alias_maps
On 10-Mar-2009, at 06:44, Sahil Tandon wrote: On Mar 10, 2009, at 4:29 AM, LuKreme krem...@kreme.com wrote: On 9-Mar-2009, at 15:58, mouss wrote: you must understand the difference between virtual_mailbox_domains and virtual_alias_domains I understand the difference, I have virtual_mailbox_domains assigned and I don't have virtual_alias_domains :) Ok let's try this again. As a few people on this list have politely indicated, you *DO* have virtual_alias_domains set unless you explicitly unset it in main.cf. See the default value for further enlightenment. Yes, you obviously missed the smilie at the end. But to be pedantic, I do *not* have virtual_alias_domains set at all, and it does not show up in postconf -n because I've never changed its default value ($virtual_alias_maps). From ADDRESS_CLASS_README For backwards compatibility with Postfix version 1.1, the new virtual_alias_maps parameter defaults to $virtual_maps, and the new virtual_alias_domains parameter defaults to $virtual_alias_maps. % postconf -n | grep ^virtual virtual_alias_maps = hash:$config_directory/virtual,pcre: $config_directory/virtual.pcre,mysql:$config_directory/ mysql_virtual_alias_maps.cf virtual_gid_maps = static:89 virtual_mailbox_base = /usr/local/virtual virtual_mailbox_domains = mysql:$config_directory/ mysql_virtual_domains_maps.cf virtual_mailbox_maps = mysql:$config_directory/ mysql_virtual_mailbox_maps.cf virtual_minimum_uid = 89 virtual_transport = procmail virtual_uid_maps = static:89 If you're saying that I don't understand why I would have a different virtual_alias_domains value to the existing virtual_alias_maps, then you're right. virtual_alias_domains appears to be an alternate way of listing the domains that I would list in the $config_directory/virtual file. WHY you would do it this way I have no idea. I suppose if you had virtual domains that were not in mysql... even then, not sure what the advantage would be. Could I simply change my virtual_alias_maps definition above to virtual_alias_domains? I don't think so. At least how this is setup, the mysql_virtual_alias.maps.cf returns the alias (forwarding alias) of accounts that have an alias set in postfix admin, which is (at least technically) what hash:($config_directory/virtual returns as well. The actual problem was one of simple memory failure. I forgot that ALL of southgaylord.com was setup at a virtual domain and that two specific email addresses then pointed back to local users via aliases defined in postfixadmin. When I tried to add back southgaylord.com into $config_directory/virtual then everything failed because I was showing the same domain in two disparate locations. Once I figured out what I'd done previously, I was then able to restore everything to the way it was. This never had anything at all to do with virtual_alias_domains versus virtual_alias_maps, though it *was* a logical place to look. -- I AM ZOMBOR! (kelly) ZOMBOR!
Re: smtpd_recipient_restrictions Check
On 10-Mar-2009, at 09:59, Linux Addict wrote: smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, I have reject_invalid_hostname here as well (before permit_mynetworks) permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unlisted_recipient, I have reject_unlisted_sender instead, followed by: check_client_access cidr:/var/db/dnswl/postfix-dnswl-permit check_helo_access pcre:$config_directory/helo_checks.pcre, check_sender_access pcre:$config_directory/sender_access.pcre, check_client_access pcre:$config_directory/check_client_fqdn.pcre, check_recipient_access pcre:$config_directory/recipient_checks.pcre, check_client_access hash:$config_directory/access, reject_invalid_hostname, reject_invalid_helo_hostname These are redundant reject_non_fqdn_helo_hostname reject_unauth_pipelining, Why? reject_unknown_reverse_client_hostname You might want reject_unknown_client_hostname instead. Either way, this is probably not the best thing if you are accepting mail for others. You WILL lose email that they will consider to be legitimate. While it is nice to be able to say Your network is misconfigured the truth is, if you're handling mail for anyone else you need to be as accepting as is reasonably possible. reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, I would be very very careful about using spamcop if you are accepting mail for others. permit In general you want to structure the order from 'cheapest' to most 'expensive'. Everything before permit_myneworks is stuff that should be rejected no matter who is sending it, which is why I have invalid_hostname there. Then any other checks that are cheap, followed by any checks that requires has/mysql/cidr/pcre lookups because these are slightly more expensive. Last of all is the RBLs (well, RBL in my case, I only use zen). -- Growing up leads to growing old, and then to dying/And dying to me don't sound like all that much fun.
Re: virtual_alias_maps
On 10-Mar-2009, at 12:41, Victor Duchovni wrote:
On Tue, Mar 10, 2009 at 12:33:52PM -0600, LuKreme wrote:
Could I simply change my virtual_alias_maps definition above to
virtual_alias_domains? I don't think so. At least how this is
setup, the
mysql_virtual_alias.maps.cf returns the alias (forwarding alias) of
accounts that have an alias set in postfix admin, which is (at least
technically) what hash:($config_directory/virtual returns as well.
The recommended approach for those ready to move beyond 1.1 compatible
settings is:
virtual_alias_domains = ... explicit list of domains or tables ...
virtual_alias_maps = ... tables ...
if the number of virtual alias domains is small (1-10) and stable,
avoid tables entirely just list them in main.cf. Yes you can rely
on the backwards compatible interface, but it is more confusing and
in many cases less efficient.
Well, more confusing is relative. The old way is less confusing *to
me* because I'm familiar with it.
I could certainly
# grep DOMAIN virtual | awk '{print $1}'
and put that list into main.cf in a virtual_alias_domains declaration.
In fact, there's probably no reason NOT to do this, as most of my
domains have been moved over to mysql virtual mailboxes -- other than
not being sure what other impact this might have (that is, what other
settings I might need to change).
I'm willing to be convinced though, I don't foresee any reason why the
number of virtual_alias_domains would ever increase.
--
Hey, how come Andrew gets to get up? If he gets up, we'll all get
up! It'll be anarchy!
Re: Mac OSX error logs
On 10-Mar-2009, at 13:37, Rupert Reid wrote: Hello All, I am running postfix (apple version) with MAC OSX10.4.11 client. I found the following entries in the Console/501/console.log. I am concerned but do not know what it means. The var/log/mail.log does not show any errors and seem to be sending/receiving mail without problem. Below is the output of postconf -n. I would be grateful if anyone could: a. Tell me what the console.log means the permissions on /var/mail/ are wrong b. Should I be concerened and what should I do about it sudo chmod 1777 /var/mail/ it should look like this: $ ls -lsd /var/mail/ 2 drwxrwxrwt 2 root mail 1536 Mar 10 14:58 /var/mail/ (note the 't') Also, you might want to man chmod and man 2 chmod and look for sticky If mode ISVTX (the `sticky bit') is set on a directory, an unprivileged user may not delete or rename files of other users in that directory. The sticky bit may be set by any user on a directory which the user owns or has appropriate permissions. For more details of the properties of the sticky bit, see sticky(8). -- All our loves are first loves
Re: virtual_alias_maps
On 10-Mar-2009, at 15:22, Victor Duchovni wrote: None, but the trivial-rewrite service will be saddled with one less MySQL lookup to determine the address class of a domain. Ideally you also move virtual_mailbox_domains to its own parameter also, and don't rely on implicit lookups of that in virtual_mailbox_maps, and avoid tables when possible. OK OK, so I go from this: virtual_alias_maps = hash:$config_directory/virtual, pcre:$config_directory/virtual.pcre, mysql:$config_directory/mysql_virtual_alias_maps.cf to this: virtual_alias_maps = pcre:$config_directory/virtual.pcre, mysql:$config_directory/mysql_virtual_alias_maps.cf virtual_alias_domains=[list of domains extracted from virtual] (That is to say, i add the domains to the v_a_d declaration and remove the hash lookup for the maps from the v_a_m declaration) -- I can't die, I haven't seen The Jolson Story - Jetboy
Re: virtual_alias_maps
On 10-Mar-2009, at 16:06, Victor Duchovni wrote: On Tue, Mar 10, 2009 at 03:57:04PM -0600, LuKreme wrote: virtual_alias_domains=[list of domains extracted from virtual] Yes, provided the latter contains only domain anything entries and no address rewrite-address entries. virtual_alias_domains=virtual.tld, mydomain,tld, johndoe.tld ...enabling soft-bounce... :) (That is to say, i add the domains to the v_a_d declaration and remove the hash lookup for the maps from the v_a_m declaration) Yes, provided of course the hash table only contained domains. Or could just set: virtual_alias_domains = hash:$config_directory/virtual Ah... er... OK, now you lost me again. What in $DEITY's name would be the point of that? Wouldn't I still have to then have domain.tld anything in $config_directory/virtual? -- Maybe I should have seen it as some kind of sign, except I don't believe in them no more; no no, but I believe these things I can't forget, tho I don't see you anymore.
Re: virtual_alias_maps
On 10-Mar-2009, at 15:57, LuKreme wrote: virtual_alias_maps = pcre:$config_directory/virtual.pcre, mysql:$config_directory/mysql_virtual_alias_maps.cf virtual_alias_domains=[list of domains extracted from virtual] Ugh! Seems $config_directory/ is not liked by mysql: whew, it's always something :) -- Satan oscillate my metallic sonatas
Re: virtual_alias_maps
With these settings virtual_alias_maps = pcre:$config_directory/virtual.pcre, mysql:$config_directory/mysql_virtual_alias_maps.cf virtual_alias_domains = hash:/usr/local/etc/postfix/virtual I get mail postfix/smtpd[36156]: NOQUEUE: reject: RCPT from lists.php.net[216.92.131.4]: 450 4.1.1 krem...@kreme.com: Recipient address rejected: User unknown; from=php-general-return-289813-kremels=kreme@lists.php.net to=krem...@kreme.com proto=ESMTP helo=lists.php.net $ postmap -q krem...@kreme.com hash:/usr/local/etc/postfix/virtual krem...@covisp.net with THESE settings, all mail is delivered properly: virtual_alias_maps = hash:/usr/local/etc/postfix/virtual pcre:$config_directory/virtual.pcre, mysql:$config_directory/mysql_virtual_alias_maps.cf #virtual_alias_domains = No changes to any files other than that one change to main.cf. -- The Germans wore gray, you wore blue.
Re: virtual_alias_maps
On 9-Mar-2009, at 06:31, Noel Jones wrote: LuKreme wrote: On 8-Mar-2009, at 19:39, Sahil Tandon wrote: What happens if you set: virtual_alias_domains = in main.cf? Then all mail to local (non virtual) users bounces with a Relay access denied error. Sounds as if you have (unintentionally)? defined all your local domains as virtual_alias_domains. virtual_alias_maps = hash:/usr/local/etc/postfix/virtual, pcre:/usr/local/etc/postfix/virtual.pcre, mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf this has been working for a year until 2.5.6 Just to be clear, the only thing that is not working is .. oh wait Never mind. Everything is working 100%, I simply forgot how I configured everything. The domain 'southgaylord.com' *IS* a virtual domain. I have two legacy email addresses in that domain that were setup to deliver, via an alias in the virtual domain, to local user accounts. All fixed now. -- Nihil est--in vita priore ego imperator Romanus fui.
virtual_alias_maps
I have: virtual_alias_maps = hash:/usr/local/etc/postfix/virtual, pcre:/usr/local/etc/postfix/virtual.pcre, mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf testing: $ postmap -q li...@southgaylord.com hash:/etc/postfix/virtual $ postmap -q li...@southgaylord.com pcre:/etc/postfix/virtual.pcre $ postmap -q li...@southgaylord.com mysql:/usr/local/etc/postfix/ mysql_virtual_alias_maps.cf li...@southgaylord.com but: 2178F118BA6B: to=li...@southgaylord.com, orig_to=krem...@kreme.com, relay=none, delay=0.77, delays=0.6/0.1/0/0.07, dsn=5.0.0, status=bounced (User unknown) This was working before I upgrade to postix 2.5.6, so something I did before reloading postfix must have gotten it confused. (messages to krem...@kreme.com get a copy forwarded to li...@southgaylord.com from with my procmailrc. Both domains are local, so perhaps something earlier in the chain than virtual_alias_maps is returning the no user error?) -- A man, in a word, who should never have been taught to write and whom if unhappily gifted with that ability, should have been restrained by a Act of Parliament from writing Reminiscences. - PG Wodehouse
Re: virtual_alias_maps
On 8-Mar-2009, at 18:18, Victor Duchovni wrote: On Sun, Mar 08, 2009 at 06:05:19PM -0600, LuKreme wrote: I have: virtual_alias_maps = hash:/usr/local/etc/postfix/virtual, pcre:/usr/local/etc/postfix/virtual.pcre, mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf testing: $ postmap -q li...@southgaylord.com hash:/etc/postfix/virtual $ postmap -q li...@southgaylord.com pcre:/etc/postfix/virtual.pcre $ postmap -q li...@southgaylord.com mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf li...@southgaylord.com but: Chopping off the most important information, which is the name of the delivery agent (presumably local(8)). postfix/error, didn't seem relevant. /etc/postfix/virtual is (well, WAS) set to krem...@kreme.com krem...@covisp.net, li...@southgaylord.com here;s the entire maillog: -- A man, in a word, who should never have been taught to write and whom if unhappily gifted with that ability, should have been restrained by a Act of Parliament from writing Reminiscences. - PG Wodehouse
Re: virtual_alias_maps
On 8-Mar-2009, at 18:47, Victor Duchovni wrote: You probably have an unintential match for the domain in $virtual_alias_domains. Here's my postconf: $ postconf -n alias_database = hash:/usr/local/etc/postfix/aliases alias_maps = hash:/usr/local/etc/postfix/aliases allow_percent_hack = no bounce_size_limit = 10240 broken_sasl_auth_clients = yes command_directory = /usr/local/sbin config_directory = /usr/local/etc/postfix daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 disable_vrfy_command = yes header_checks = regexp:/usr/local/etc/postfix/header_checks header_size_limit = 10240 home_mailbox = Maildir/ html_directory = no inet_interfaces = all mail_owner = postfix mailbox_command = /usr/local/bin/procmail -t -a $EXTENSION mailbox_size_limit = 52428800 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man message_size_limit = 15728640 mime_header_checks = pcre:/usr/local/etc/postfix/mime_headers.pcre mydestination = $myhostname, localhost.$mydomain, $mydomain, localhost, ns1.$mydomain, ns2.$mydomain, mail.$mydomain, www. $mydomain, webmail.$mydomain mydomain = covisp.net myhostname = mail.covisp.net mynetworks = 75.148.117.88/29, 127.0.0.0/8 myorigin = $mydomain newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no recipient_delimiter = + sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop show_user_unknown_table_name = no smtpd_banner = $myhostname ESMTP $mail_name $mail_version smtpd_error_sleep_time = 28 smtpd_hard_error_limit = 8 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, permit smtpd_recipient_limit = 25 smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_invalid_hostname, permit_mynetworks, check_client_access hash: $config_directory/pbs, permit_sasl_authenticated, reject_unauth_destination, reject_unlisted_sender, check_client_access cidr:/var/db/dnswl/postfix-dnswl-permit check_helo_access pcre: $config_directory/helo_checks.pcre, check_sender_access pcre: $config_directory/sender_access.pcre, check_client_access pcre: $config_directory/check_client_fqdn.pcre, check_recipient_access pcre: $config_directory/recipient_checks.pcre, check_client_access hash: $config_directory/access, reject_rbl_client zen.spamhaus.org permit smtpd_restriction_classes = check_greylist smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous smtpd_sender_restrictions = check_client_access hash:/usr/local/etc/ postfix/pbs, permit_sasl_authenticated, permit_mynetworks smtpd_soft_error_limit = 4 soft_bounce = no swap_bangpath = no undisclosed_recipients_header = To: List of Bcc addresses:; unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/usr/local/etc/postfix/virtual,pcre:/usr/ local/etc/postfix/virtual.pcre,mysql:/usr/local/etc/postfix/ mysql_virtual_alias_maps.cf virtual_gid_maps = static:89 virtual_mailbox_base = /usr/local/virtual virtual_mailbox_domains = mysql:/usr/local/etc/postfix/ mysql_virtual_domains_maps.cf virtual_mailbox_maps = mysql:/usr/local/etc/postfix/ mysql_virtual_mailbox_maps.cf virtual_minimum_uid = 89 virtual_transport = procmail virtual_uid_maps = static:89 -- I can't die, I haven't seen The Jolson Story - Jetboy
Re: virtual_alias_maps
On 8-Mar-2009, at 19:22, Victor Duchovni wrote: On Sun, Mar 08, 2009 at 07:19:32PM -0600, LuKreme wrote: I don't have virtual_alias_domains defined at all, only virtual_mailbox_maps: This means that you do. See the default value. To really not have it set, set it empty! Is this a change between 2.5.1 and 2.5.6, because it WAS working. $ postmap -q southgaylord.com mysql:/usr/local/etc/postfix/mysql_virtual_domains_maps.cf southgaylord.com That's the problem. What is the problem? -- I can't die, I haven't seen The Jolson Story - Jetboy
Re: virtual_alias_maps
On 8-Mar-2009, at 19:29, Victor Duchovni wrote: On Sun, Mar 08, 2009 at 07:24:54PM -0600, LuKreme wrote: On 8-Mar-2009, at 19:22, Victor Duchovni wrote: On Sun, Mar 08, 2009 at 07:19:32PM -0600, LuKreme wrote: $ postmap -q southgaylord.com mysql:/usr/local/etc/postfix/mysql_virtual_domains_maps.cf southgaylord.com That's the problem. What is the problem? The match, you have a virtual alias domain that you don't want. Er... no, I DO want it. li...@southgaylord.com is a virtual mailbox /usr/local/virtual/li...@southgaylord.com / -- I can't die, I haven't seen The Jolson Story - Jetboy
Re: virtual_alias_maps
On 8-Mar-2009, at 19:39, Sahil Tandon wrote: What happens if you set: virtual_alias_domains = in main.cf? Then all mail to local (non virtual) users bounces with a Relay access denied error. -- Incredible! One of the worst performances of my career and they never doubted it for a second.
Re: Plus addressing not delivering to folder
On 7-Mar-2009, at 08:11, Charles Marcus wrote:
On 3/7/2009, mouss (mo...@ml.netoyen.net) wrote:
if all extensions are acceptable (not very recommended),
Ok, this caught my attention...
Yes, I was planning on allowing any extension to be used/made up on
the
fly... thje purpose for using the extension will be for signing up for
different sites/lists/things, so I can use the same address, but be
able
to distinguish mail that comes to me via that service...
Yep, that's what I do, and I've yet to hear a valid security concern
other than user could create a lot of folders in their Maildir.
It's very easy to do in /etc/procmailrc though
:0
* ! ? test -f $HOME/.procmailrc
{
ARG=$1
LOG=User has no procmailrc logname=$logn...@$host HOME=$HOME$NL
:0 fw
| /usr/local/bin/spamc -u $LOGNAME
DROPPRIVS=YES
DEFAULT=$HOME/Maildir
:0
* ! ARG
.$ARG/
:0
* ^X-Spam-Status:(.*\)?Yes
.SPAM/
:0
$DEFAULT/
}
LOG=User $logn...@$host has a .procmailrc, processing...$NL
If the user does not have a .procmailrc, get teh extension and save it
in ARG, check the message against SA, and then, if there was an
extension. Save the file in that folder. If the message is spam,
save it in .Spam, else save it in DEFAULT. (Some people will want to
put the spamcheck BEFORE the ARG check.
So, is there maybe some kind of regex that could be used to make this
safer? Ie, only allow safe characters, or something?
What unsafe characters are allowed in a username portion of the email
address?
--
if you ever get that chimp of your back, if you ever find the thing
you lack, ah but you know you're only having a laugh. Oh, oh
here we go again -- until the end.
Re: Plus addressing not delivering to folder
On 7-Mar-2009, at 08:39, Noel Jones wrote:
Postfix does not allow $1 etc. substitution in virtual_mailbox_maps.
http://www.postfix.org/postconf.5.html#virtual_mailbox_maps
It is pretty easy to set up a procmail transport to be used by postfix:
procmail unix - n n - - pipe
-o flags=uhFORD user=vpopmail argv=/usr/local/bin/procmail -t -m
USER=${recipient} EXTENSION=${extension} /usr/local/etc/
procmailrc.common
--
if you ever get that chimp of your back, if you ever find the thing
you lack, ah but you know you're only having a laugh. Oh, oh
here we go again -- until the end.
Re: Plus addressing not delivering to folder
On 7-Mar-2009, at 12:13, Charles Marcus wrote:
As I said in an earlier mail, I do NOT want the folder auto-created
- if
it doesn't exist, I want the message deliver to fall back to the
Inbox...
Is there a way to tweak the above to accomplish this?
Sure, you can do most anything in procmail. Let me see, something
like this:
ARV=$1
:0
* ! ? test -d .$ARG
{ $DEFAULT }
:0E
.$ARV/
(if the directory .ARG does no exist, save in $DEFAULT, else save in
$.ARG/)
--
if you ever get that chimp of your back, if you ever find the thing
you lack, ah but you know you're only having a laugh. Oh, oh
here we go again -- until the end.
Re: Plus addressing not delivering to folder
On 6-Mar-2009, at 12:27, Charles Marcus wrote:
Hmmm... I'm now wondering if ${extension} can somehow be used with the
virtual_mailbox_maps query to accomplish what I want?
Yes, but you need procmail (or, I assume, Maildrop)
in a procmail file you would have:
# based on the procmail pipe in master.cf
ARG=$EXTENSION
# For non virtual users
# ARG=$1
:0
* ! ARG
.$ARG/
as the simplest example. Getting procmail working with virtual users
is a little tricky. Here's what I have:
/etc/postfix/main.cf
virtual_transport = procmail
/etc/postfix/master.cf
procmail unix - n n - - pipe
-o flags=uhFORD user=vpopmail argv=/usr/local/bin/procmail -t -m
USER=${recipient} EXTENSION=${extension} /usr/local/etc/
procmailrc.common
--
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Re: rewriting sender address
On Mar 5, 2009, at 7:14, ghe g...@slsware.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barney Desmond wrote: This is a little unclear. I interpret that to mean mail sent from your server, from u...@a.com, should appear to come from u...@b.com, so that the return-path will be at b.com - is this correct? You then said you want to rewrite the destination address on its way out, but that'd be inconsistent. Not quite. I want the recipient's Reply button to send to u...@b.com when replying to mail received from u...@a.com. But a.com is not you, so how do you intend to control that? What you want is for user to add a reply-to header to their outbound mail.. I suppose there must be a way to create a filter to add that header (formail?)
Re: Questions regarding Backup MX and Postfix's Queue.
On Mar 5, 2009, at 7:33, du...@linuxgeek.org.uk wrote: Hi guys, I have a couple of quick questions: 1) How long does a message sit in the postfix queue for before it attempts a redeliver (a deffered message sat in the deffered queue)? 2) If you have a mailserver (postfix, dovecot, virtual users/domains mysql) and you have a back-up MX record set if the main mailserver goes down (reboot) and a mail gets sent to a domain hosted on the server, it gets no response from the main mailserver so reverts to the backup. It delivers the mail to the backup and then defers it Your backup MX is deferring the message? As far as the sender is concerned, once the message is accepted by your server, it should be considered delivered, no? because it cannot be sent to the main mailserver, it then sits in the deferred queue until the main mailserver is back and gets delivered. wonderfull... the question is, if the server is down due to a reboot for whatever reason so say 5 - 10 minute downtime. The original message will be sent, goto the backup mx, it will get deferred until mailserver is backup then delivered... BUT I tested this with hotmail, and what I get is, hotmail defers the message as well as sending it to the backup mx, so that when the backup mx delivers the mail which goes through fine, hotmail are retrying as well, and you end up with two of the same message? How do you overcome this? Um, hosts.deny hotmail? ;)
Re: Accept undeliverable mails and send NDR
On Mar 5, 2009, at 7:50, Terry Carmen te...@cnysupport.com wrote: ram wrote: One of my clients sends mail using a custom application which *cannot* recognize a smtpd error message .. like user-not-found, or invalid-domain etc Now they want our postfix server to accept all mails without checks and send NDR's for undeliverable mails. Even if you can make this work, it's still a bad idea, since the outbound SMTP server will be blacklisted for sending to too many invalid addresses. Because it ignores bounces, the mailing list will never be updated to remove invalid recipients. Spammers don't care. I mean, come on, a custom SMTP that ignores errors? SPAMMER ALERT.
Re: root delivery for monitoring services
On 5-Mar-2009, at 11:03, Cameron Camp wrote: ad...@domain.com (expanded from r...@localhost): host mail.domain.com[1.2.3.4] said: 504 5.5.2 nob...@localhost: Sender address rejected: need fully-qualified address (in reply to RCPT TO command) Is domain.com your attempt to obfuscate the real domain? If so, use example.com or example.org or domain.tld instead of using someone else's domain. ESPECIALLY when the problem is related to the domain name! -- Strange things are afoot at the Circle K
Re: Do not include first 'Received' header when received via 465/587?
On 5-Mar-2009, at 19:15, Noel Jones wrote: Oh, and recent postfix marks authenticated headers; note the ESTMPSA. S = StartTLS, A = Authenticated Received: from [192.168.5.108] (adsl-19-247-14.bna.bellsouth.net [68.19.247.14]) by mgate2.vbhcs.org (Postfix) with ESMTPSA id BAF4A797A6A; Thu, 5 Mar 2009 20:09:39 -0600 (CST) That is very cool, I didn't know that. Of course in my case we're not using TLS, so the header has ESMTPA, but still, quite useful. a regexp something like /^(Received: .* myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-$1 should do the trick. I really like that, there's all sorts of possibilities here. Would it be bad to strip out the IPs (usually local/private) from these headers? /^(Received: from )\[\d\d?\d?\.d\d?\d?\.d\d?\d?\.d\d?\d?\](.* myhostname \(Postfix\) with ESMTPS?A .)$/ REPLACE X-$1[internal LAN]$2 /^(Received: from [^\[].* myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-$1 ?? I'm thinking that cleanup is called for all messages, which is why you would only want this on a submission port and not just on the regular cleanup service. Although the Received: from [ip.ip.ip.ip] form never shows up on external mail since bare-ip mailservers are banned anyway. -- Athene we all have our moments when we lose it Slyspy the key is though, to conceal the evidence before the police arrive
Re: postconf -n suggestion
On 4-Mar-2009, at 09:22, Wietse Venema wrote: Charles Marcus: Dovecot has added two lines of text to the beginning output of dovecot -n that could possibly save some time with troubleshooting... It adds the version on the first line, and OS/platform info on the second line, like so: # 1.1.11: /etc/dovecot/dovecot.conf # OS: Linux 2.6.23-gentoo-r9 x86_64 Gentoo Base System release 1.12.11.1 Maybe postfix could do the same with postconf -n output? No. The output has a defined name = value format. Adding cruft would break bazillions of scripts that rely on it. version=2.4.2 uname=FreeBSD 6.2-RELEASE ?? -- Hey, baby, I've got just the cure for that penis envy back at m apartment...
Re: postconf -n suggestion
On 4-Mar-2009, at 11:54, Wietse Venema wrote: postconf -n does not list parameters unless they are set in main.cf. The simplicity of the tool makes it useful for building into other tools. If we start making random exceptions then we get on a slippery slope (why stop with mail_version? why not also include SASL and TLS, chroot stuff, and so on). I do agree in principle with this, but I think that for version at least, an exception should be made. (OS is largely irrelevant, but version is pretty much critical all the time). -- I've always had a flair for stage directions.
escape ^From
What controls escaping From in the body of a mail message if it's at the start of a line? Since I've switched everyone over to Maildir, it seems silly to do this anymore, but I can't find the setting. In fact, I'm not even sure it's in postfix at all. RTFM replies preferred, just say with FM to R, please. -- Bowling scores are way up, minigolf scores are way down, and we have more excellent waterslides than any other planet we communicate with
Re: Question about how Postfix sends the EHLO/HELO
On 4-Mar-2009, at 12:33, Rob Tanner wrote: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on microthunder.com They really *really* need to update their two-year old SA install. X-Spam-Level: X-Spam-Status: Yes, score=4.4 required=4.0 They really *REALLY* need to understand the consequences of lowering the threshold, as this is nearly always a very very bad idea. SA does not think your message is spamish, their mailadmin does. RCVD_NUMERIC_HELO Well, that one is possibly your fault, and you should certainly fix it if it is. What I don’t get is the first test in the X-Spam-Report header which received a 2.6. Does postfix strictly send the IP address on the HELO/EHLO? Only if it has no choice. If so, what parameter to I need to set to $myhostname? Or, am I entirely misunderstanding what that test tests for? # INTERNET HOST AND DOMAIN NAMES # # The myhostname parameter specifies the internet hostname of this # mail system. The default is to use the fully-qualified domain name # from gethostname(). $myhostname is used as a default value for many # other configuration parameters. # #myhostname = host.domain.tld #myhostname = virtual.domain.tld However, your headers to the list look perfectly fine. My suspicion, irrational without the full headers you sent them and the full message they sent back, is that they screwed something up on their end with the RCVD_NUMERIC_HELO test and that some eager-beaver sysadmin changed something they didn't understand to get better results. I base this on the evidence that some eager-beaver sysadmin lowered the threshold to 4.0 without understanding the consequences to get better results. Feel free to forward my comments along to David Sosnowski @ microthunder@gmail.com -- What the hell's goin' on in the engine room? Were there monkeys? Some terrifying space monkeys maybe got loose?
Re: submission port requiring starttls even when set not to
On 4-Mar-2009, at 13:08, J.P. Trosclair wrote: submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt Why? -- If I were you boys, I wouldn't talk or even think about women. T'aint good for your health.
Re: Blocking a domain and user
On 4-Mar-2009, at 13:32, Jim McIver wrote: they just pile up in the postqueue and I'd like to keep the postqueue -p cleaned out. Snippet from maillog: Mar 4 00:09:21 mail postfix/smtpd[36633]: NOQUEUE: reject: RCPT from unknown[89.218.164.251]: 554 u...@domain.com: Sender address rejected: Access denied; from=u...@domain.com to=ob...@lmtribune.com proto=SMTP helo=89.218.164.251.metro.online.kz How are they piling up in postqueue when the connection is being rejected? -- This is our music from the bachelor's den, the sound of loneliness turned up to ten. A harsh soundtrack from a stagnant waterbed and it sounds just like this. This is the sound of someone losing the plot making out that they're OK when they're not. You're gonna like it, but not a lot. And the chorus goes like this...
Re: submission port requiring starttls even when set not to (Resolved)
On 4-Mar-2009, at 14:33, Jorey Bump wrote: smtpd_tls_security_level should be used instead. Not if you don't want to force TLS on the submission port it shouldn't. On 4-Mar-2009, at 13:21, Brian Evans - Postfix List wrote: *encrypt* Mandatory TLS encryption: announce STARTTLS support to SMTP clients, and require that clients use TLS encryption. According to RFC 2487 http://tools.ietf.org/html/rfc2487 this MUST NOT be applied in case of a publicly-referenced SMTP server. Instead, this option should be used only on dedicated servers. This is wrong too (not he quote, but Brian's missaplication of it). From RFC287 A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. So far so good, but keep reading: This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. ***A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address***. So that has nothing to do with the submission port. -- When the routine bites hard / and ambitions are low And the resentment rides high / but emotions won't grow And we're changing our ways, / taking different roads Then love, love will tear us apart again
to/orig_to control
when you have to=j...@example.net, orig_to=j...@example.com in the maillog file, that translation is handled by /etc/postfix/virtual, isn't it? If j...@example.com is not in /etc/postfix/virtual, where else could this be controlled? I did grep -ir jo...@example.com /etc/postfix/ and got 0 hits, so it's not in virtual or virtual.db. I also went ahead and did grep -ir john \...@example.com /etc/ and still got 0 hits. other virtual addresses in example.com show up in both /etc/postfix/virtual and /etc/postfix/ virtual.db and yet mail to 'john' is getting translated and delivered. -- So now you know the words to our song, pretty soon you'll all be singing along, when you're sad, when you're lonely and it all turns out wrong...
Re: escape ^From
On 4-Mar-2009, at 15:28, mouss wrote: LuKreme a écrit : What controls escaping From in the body of a mail message if it's at the start of a line? Since I've switched everyone over to Maildir, it seems silly to do this anymore, but I can't find the setting. In fact, I'm not even sure it's in postfix at all. look at what you use to deliver mail. the LDA? that's procmail, but it knows it's delivering to Maildir/ also. Hmm -- These budget numbers are not just estimates, these are the actual results for the fiscal year that ended February the 30th. - GWB
Re: That Relay Access Denied Thing (Solved, no, Really!)
On 4-Mar-2009, at 15:18, Robert A. Ober wrote: Thanks to Brian and others for hanging in there with me! I think you owe everyone on this thread (which I was not part of, so no self-interest) a beer. :) -- #27794 Vellius ... I wonder if the really nerdy Klingons learn how to speak english
Re: submission port requiring starttls even when set not to (Resolved)
On 4-Mar-2009, at 19:12, Jorey Bump wrote: LuKreme wrote, at 03/04/2009 05:24 PM: On 4-Mar-2009, at 14:33, Jorey Bump wrote: smtpd_tls_security_level should be used instead. Not if you don't want to force TLS on the submission port it shouldn't. The context is irrelevant. Of course the context is relevant since the original poster did not want TLS *AT ALL* on the submission port. Which syntax is right for enabling a feature he DOESN'T WANT is silliness. -- In my world there are people in chains and you can ride them like ponies
Re: to/orig_to control
On 4-Mar-2009, at 17:13, Victor Duchovni wrote:
On Wed, Mar 04, 2009 at 05:07:44PM -0700, LuKreme wrote:
If j...@example.com is not in /etc/postfix/virtual, where else
could this
be controlled?
See above. Consider also that the rewrite could be based on a partial
match of either the domain or a bare user name (if the domain is
local).
I am REALLY confused then:
$ grep -ir john /etc/postfix
/etc/postfix/dist-postgrey_whitelist_clients:# messagelabs.com (big
pool, reported by John Tobin)
$ grep -ir nutters2-admin /etc/postfix
/etc/postfix/aliases:nutters2-admin:|/usr/local/mailman/mail/
mailman admin nutters2
/etc/postfix/virtual:nutters2-ad...@southgaylord.com
nutters2-ad...@covisp.net
/etc/postfix/postgrey_whitelist_recipients:nutters2-admin@
Binary file /etc/postfix/aliases.db matches
Binary file /etc/postfix/virtual.db matches
$ grep southgaylord.com /var/log/maillog| grep orig_to | grep john |
awk '{print $7 $8}'
to=j...@covisp.net, orig_to=j...@southgaylord.com,
to=j...@covisp.net, orig_to=j...@southgaylord.com,
--
Generalizations are always inaccurate. -Mugsy
Re: to/orig_to control
On 4-Mar-2009, at 19:37, Victor Duchovni wrote:
On Wed, Mar 04, 2009 at 07:26:34PM -0700, LuKreme wrote:
$ grep southgaylord.com /var/log/maillog| grep orig_to | grep john
| awk
'{print $7 $8}'
to=j...@covisp.net, orig_to=j...@southgaylord.com,
to=j...@covisp.net, orig_to=j...@southgaylord.com,
hiding the full logging for the message in question is not helpful. Do
ditch the awk script and report all other entries for the same queue-
id.
Sorry, I wasn't trying to hide it, just paste the relvenat parts and
the rest didn't look useful to me, but perhaps you can glean more from
it:
Mar 4 06:02:13 mail postfix/local[89354]: E3A33118AE0A: to=j...@covisp.net
, orig_to=j...@southgaylord.com, relay=local, delay=6.4,
delays=0.84/0.02/0/5.5, dsn=2.0.0, status=sent (delivered to command: /
usr/local/bin/procmail -t -a $EXTENSION)
Mar 4 07:50:52 mail postfix/local[95833]: DA587118B79F: to=j...@covisp.net
, orig_to=j...@southgaylord.com, relay=local, delay=6.5,
delays=0.36/0/0/6.2, dsn=2.0.0, status=sent (delivered to command: /
usr/local/bin/procmail -t -a $EXTENSION)
and
Mar 4 06:02:06 mail postfix/smtpd[89239]: E3A33118AE0A: client=mm-
retail-out-174-146.amazon.com[207.171.174.146]
Mar 4 06:02:07 mail postfix/cleanup[89353]: E3A33118AE0A: message-id=7604183.429751236171663751.javamail.em-bu...@na-mm2-relay.amazon.com
Mar 4 06:02:07 mail postfix/qmgr[1026]: E3A33118AE0A: from=emailsenderapp+correios-rtfm-0emjhnw...@bounces.amazon.com
, size=44613, nrcpt=1 (queue active)
Mar 4 06:02:13 mail postfix/local[89354]: E3A33118AE0A: to=j...@covisp.net
, orig_to=j...@southgaylord.com, relay=local, delay=6.4,
delays=0.84/0.02/0/5.5, dsn=2.0.0, status=sent (delivered to command: /
usr/local/bin/procmail -t -a $EXTENSION)
Mar 4 06:02:13 mail postfix/qmgr[1026]: E3A33118AE0A: removed
Mar 4 07:50:45 mail postfix/smtpd[95626]: DA587118B79F:
client=ccm29.constantcontact.com[208.75.123.225]
Mar 4 07:50:46 mail postfix/cleanup[95831]: DA587118B79F: message-
id=1102486963097.1102192950259.179872.8.10083...@scheduler
Mar 4 07:50:46 mail postfix/qmgr[1026]: DA587118B79F: from=esc1102486963097_1102192950259_179...@in.constantcontact.com
, size=14146, nrcpt=1 (queue active)
Mar 4 07:50:52 mail postfix/local[95833]: DA587118B79F: to=j...@covisp.net
, orig_to=j...@southgaylord.com, relay=local, delay=6.5,
delays=0.36/0/0/6.2, dsn=2.0.0, status=sent (delivered to command: /
usr/local/bin/procmail -t -a $EXTENSION)
Mar 4 07:50:52 mail postfix/qmgr[1026]: DA587118B79F: removed
and the first message quite happily went off to live in /home/john/
Maildir/new/ and the second I believe went to /dev/null as Spam.
--
if you ever get that chimp of your back, if you ever find the thing
you lack, ah but you know you're only having a laugh. Oh, oh
here we go again -- until the end.
Re: to/orig_to control
On 4-Mar-2009, at 20:29, Victor Duchovni wrote:
On Wed, Mar 04, 2009 at 08:17:27PM -0700, LuKreme wrote:
On 4-Mar-2009, at 19:37, Victor Duchovni wrote:
On Wed, Mar 04, 2009 at 07:26:34PM -0700, LuKreme wrote:
$ grep southgaylord.com /var/log/maillog| grep orig_to | grep
john | awk
'{print $7 $8}'
to=j...@covisp.net, orig_to=j...@southgaylord.com,
to=j...@covisp.net, orig_to=j...@southgaylord.com,
hiding the full logging for the message in question is not
helpful. Do
ditch the awk script and report all other entries for the same
queue-id.
Sorry, I wasn't trying to hide it, just paste the relvenat parts
and the
rest didn't look useful to me, but perhaps you can glean more from
it:
Yes, and where are the other log entries for this queue-id?
I pasted them below the two log entries:
Mar 4 06:02:06 mail postfix/smtpd[89239]: E3A33118AE0A: client=mm-
retail-out-174-146.amazon.com[207.171.174.146]
Mar 4 06:02:07 mail postfix/cleanup[89353]: E3A33118AE0A: message-id=7604183.429751236171663751.javamail.em-bu...@na-mm2-relay.amazon.com
Mar 4 06:02:07 mail postfix/qmgr[1026]: E3A33118AE0A: from=emailsenderapp+correios-rtfm-0emjhnw...@bounces.amazon.com
, size=44613, nrcpt=1 (queue active)
Mar 4 06:02:13 mail postfix/local[89354]: E3A33118AE0A: to=j...@covisp.net
, orig_to=j...@southgaylord.com, relay=local, delay=6.4,
delays=0.84/0.02/0/5.5, dsn=2.0.0, status=sent (delivered to command: /
usr/local/bin/procmail -t -a $EXTENSION)
Mar 4 06:02:13 mail postfix/qmgr[1026]: E3A33118AE0A: removed
Mar 4 07:50:45 mail postfix/smtpd[95626]: DA587118B79F:
client=ccm29.constantcontact.com[208.75.123.225]
Mar 4 07:50:46 mail postfix/cleanup[95831]: DA587118B79F: message-
id=1102486963097.1102192950259.179872.8.10083...@scheduler
Mar 4 07:50:46 mail postfix/qmgr[1026]: DA587118B79F: from=esc1102486963097_1102192950259_179...@in.constantcontact.com
, size=14146, nrcpt=1 (queue active)
Mar 4 07:50:52 mail postfix/local[95833]: DA587118B79F: to=j...@covisp.net
, orig_to=j...@southgaylord.com, relay=local, delay=6.5,
delays=0.36/0/0/6.2, dsn=2.0.0, status=sent (delivered to command: /
usr/local/bin/procmail -t -a $EXTENSION)
Mar 4 07:50:52 mail postfix/qmgr[1026]: DA587118B79F: removed
That is everything there is for those two messages.
Add -v to the cleanup(8) service to see where the change was made.
I'll do that now
--
The quality of our thoughts and ideas can only be as good as the quality
of our language.
Re: to/orig_to control
On 4-Mar-2009, at 20:29, Victor Duchovni wrote: Add -v to the cleanup(8) service to see where the change was made. cleanup unix n - n - 0 cleanup -v that REALLY broke things. Lots of stuff, ending with: Mar 4 20:58:22 mail postfix/cleanup[55873]: cleanup socket: wanted attribute: flags Mar 4 20:58:22 mail postfix/cleanup[55873]: input attribute name: flags Mar 4 20:58:22 mail postfix/cleanup[55873]: input attribute value: 178 Mar 4 20:58:22 mail postfix/cleanup[55873]: cleanup socket: wanted attribute: (list terminator) Mar 4 20:58:22 mail postfix/cleanup[55873]: input attribute name: (end) Mar 4 20:58:22 mail postfix/cleanup[55873]: panic: cleanup_strflags: unrecognized flag value(s) 0x80 Mar 4 20:58:23 mail postfix/master[1001]: warning: process /usr/local/ libexec/postfix/cleanup pid 55873 killed by signal 6 Mar 4 20:58:23 mail postfix/master[1001]: warning: /usr/local/libexec/ postfix/cleanup: bad command startup -- throttling I turned off -v and the crashing stopped. I see Weitse posted a fix to this in March of last year. *cough* I'm thinking it's time to upgrade postfix (Postfix 2.5.1 20080216) anyway... 2.5.6 coming up, I think. -- I'm no psychologist (although I play one when I'm picking up chicks over by the asylum)
virtual_mailbox_limit
The postfix docs say: virtual_mailbox_limit (default: 5120) The maximal size in bytes of an individual mailbox or maildir file, or zero (no limit) but since a maildir is a directory, does this limit apply to an individual email (a file in the maildir) or to the directory size of the entire maildir? -- How do you feel? I'm lonely What do you think? Cant take it all Whatcha gonna do? Gonna live my life
Re: smtpd_recipient_restrictions suddenly stopping mail
On 3-Mar-2009, at 11:48, Wietse Venema wrote: host -t a 27a28250f4b7c74acc01d042687e2273.com Perhaps they are using OpenDNS? -- Hamburgers. The cornerstone of any nutritious breakfast.
Re: smtpd_recipient_restrictions suddenly stopping mail
On Mar 3, 2009, at 15:21, Charles Marcus cmar...@media-brokers.com wrote: On 3/3/2009 2:17 PM, LuKreme wrote: host -t a 27a28250f4b7c74acc01d042687e2273.com Perhaps they are using OpenDNS? opendns works very well, as long as you disable the helper crap, so, no, has nothing to do with opendns. Since one of the features of OpenDNS Is the so-called helper crap, and is enabled by default, this can easily be a problem.
Re: sending email with Gnus
On 1-Mar-2009, at 18:55, Byung-Hee HWANG wrote: Postfix does not support GNU TLS. Postfix does not 'support' TLS at all. It should work with Gnu TLS as well as with any other TLS library. -- Beware of the Leopard!
Re: Plus addressing not delivering to folder
On 27-Feb-2009, at 15:48, Charles Marcus wrote:
I'm sure this is something I'm totally missing but I have a system I'm
trying to get plus addressing working, and not having any luck. The
email is delivered, but just to the Inbox, not to the folder...
It is not postfix's job to deliver to the folder, you would need to
use procmail or maildrop or something like that. Postfix is
delivering to the user correctly.
This is my setup:
master.cf:
procmail unix - n n - - pipe
-o flags=uhFORD user=vpopmail argv=/usr/local/bin/procmail -t -m
USER=${recipient} EXTENSION=${extension} /usr/local/etc/
procmailrc.common
main.cf:
virtual_transport = procmail
procmailrc.common:
:0
* ! EXTENSION ??
{
:0
* $ USER ?? $\EXTENSION@
{
:0
* USER ?? ^\/[^+]+
{ SHORTU = $MATCH }
:0
* USER ?? @\/.*
{ SHORTD = $MATCH }
:0
{ USER = ${shor...@${shortd} }
}
}
:0
* ! EXTENSION ??
.$EXTENSION/
YMMV. The last part is what delivers user+test to .test/ I honestly
cannot remember why I needed the first recipe, but I did.
BTW, since so many brain dead web monkeys insist that '+' is an
invalid character in an email address, I decided to use TWO recipient
delimiters, + and _ and I've only come across one site that refused to
accept a username with an _
--
This story shall the good man teach his son; And Crispin Crispian shal
ne'er go by, From this day to the ending of the world, But we in it
shall be remember'd;
Re: header check for '.com' blocks non-exec with url in file name
On 25-Feb-2009, at 15:59, Voytek Eymont wrote:
[1]# grep hc2 *
header_checks:/^Content-(Disposition|Type):\s+.+?(file)?name=?.+?
\.com(\.\S{2,4})?(\?=)??(;|$)/
REJECT hc2 .com file attachment types not allowed
First off, i think you want mime_header_checks
main.cf:
mime_header_checks = pcre:$config_directory/mime_headers.pcre
mime_headers.pcre:
/^\s*Content-(Disposition|Type).*name\s*=\s*?(.*\.(ade|adp|bas|bat|
chm|cmd|com|cpl|crt|dll|exe|hlp|hta|inf|ins|isp|js|jse|lnk|mdb|mde|mdt|
mdw|msc|msi|msp|mst|nws|ops|pcd|pif|prf|reg|scf|scr\??|sct|shb|shs|shm|
swf|vb[esx]?|vxd|wsc|wsf|wsh))(\?=)??\s*(;|$)/x REJECT Attachment
name $2 may not end with .$3
--
One by one the bulbs burned out, like long lives come to their
expected ends.
Re: smtps and sent mail
On 25-Feb-2009, at 16:25, gianluca...@interfree.it wrote: ok, i have configured postfix to sent mail trhough the smtp of my internet service provider. Now one user have a certified email account and he wants to sent mail by my server trhough the smtps. I have seen that with postfix is possible to use two different smtp but is possible to use a smtps? If user sent mail trhough outlook with smtps and pop3 certified account, without using my server, doesn't sa ve mail on my server how can i do??? Why isn't he sending his outbound email via the certified email account's mailservers? I don't understand why your server is involved at all. -- Cogito cogito, ergo cogito sum, cogito
Re: header check for '.com' blocks non-exec with url in file name
On 25-Feb-2009, at 16:31, LuKreme wrote: /^\s*Content-(Disposition|Type).*name\s*=\s*?(.*\.(ade|adp|bas|bat| chm|cmd|com|cpl|crt|dll|exe|hlp|hta|inf|ins|isp|js|jse|lnk|mdb|mde| mdt|mdw|msc|msi|msp|mst|nws|ops|pcd|pif|prf|reg|scf|scr\??|sct|shb| shs|shm|swf|vb[esx]?|vxd|wsc|wsf|wsh))(\?=)??\s*(;|$)/x REJECT Attachment name $2 may not end with .$3 Oh, I do want to add that while this check used to hit a lot of messages, it almost never hits anymore. Here is one of the 6 times it's matched in the last 31 days: Jan 30 22:30:11 mail postfix/cleanup[83067]: 69524118B5D7: reject: header Content-Type: application/octet-stream;??name=stmarysca...@ncentral.com from smtp.usol.com[64.18.225.12]; from= to=kr...@kreme.com proto=ESMTP helo=smtp.usol.com: 5.7.1 Attachment name stmarysca...@ncentral.com may not end with .com Of course, since we reject about 90% of the connection attempts before the DATA phase, our numbers on this might be artificially low. -- The older you get the more you need the people you knew when you were young.
Re: Reject/Discard mails to a Receipient
On 23-Dec-2008, at 17:06, Sahil Tandon wrote: Linux Addict wrote: Hello, I have clients sending mails to an non-existent email address/domain, emailerm...@exchange.example.net. I want to discard any mail sent to this address. I looked at smtpd_recipient_restrictions, but cant figure out how to get this done. Please help me!! Why not simply reject such messages? What is the reason you want to accept but silently discard messages to that non-existent user? Well, if you can delete the entire message to a specific user, including any CC or Bcc copies of it, then you could use this as a spamtrap... for that 1% of spam that still comes to multiple recipients... -- http://en.wikipedia.org/wiki/TOFU
Re: hitting greylist after pop-before-smtp 'pass'
On 23-Dec-2008, at 00:50, LuKreme wrote:
helo_checks.pcre:
/(dsl|pool|dynamic|user|hsd|dyn|dial)/ WARN helo Dynamic addresses
not allowed
Sorry, meant to include the check_client_fqdn.pcre, not the
(irrelevant) helo_checks
$ cat /etc/postfix/check_client_fqdn.pcre
/\.?(dhcp|dialup|dynamic|ppp|pool|dsl)\.?/ REJECT Dynamic
addresses must use a real mailserver
/^unknown$/ check_greylist
/^[^\.]*[0-9][^0-9\.]+[0-9]/ check_greylist
/^[^\.]*[0-9]{5}/check_greylist
/^([^\.]+\.)?[0-9][^\.]*\.[^\.]+\..+\.[a-z]/ check_greylist
/^[^\.]*[0-9]\.[^\.]*[0-9]-[0-9]/check_greylist
/^[^\.]*[0-9]\.[^\.]*[0-9]\.[^\.]+\..+\./check_greylist
--
And, while it was regarded as pretty good evidence of criminality
to be living in a slum, for some reason owning a whole street
of them merely got you invited to the very best social
occasions.
Re: hitting greylist after pop-before-smtp 'pass'
On 23-Dec-2008, at 01:17, Magnus Bäck wrote: The configuration as listed above will not greylist clients for which $config_directory/pbs returns OK. OK. It hasn't happened since I properly turned on logging for pbs (of course not, I'm watching it now) so I'm going to write it off to some temporary pop-before-smtp aberration. Thanks. -- A: You can never go too far. B: If I'm gonna get busted, it is *not* gonna be by a guy like *that*.
hitting greylist after pop-before-smtp 'pass'
I have the following: smtpd_restriction_classes = check_greylist check_greylist = check_policy_service inet:127.0.0.1:10023 smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_invalid_hostname, permit_mynetworks, check_client_access hash:$config_directory/pbs, permit_sasl_authenticated, reject_unauth_destination, reject_unlisted_sender, check_client_access cidr:/var/db/dnswl/postfix-dnswl-permit check_helo_access pcre:$config_directory/helo_checks.pcre, check_sender_access pcre:$config_directory/sender_access.pcre, check_client_access pcre:$config_directory/check_client_fqdn.pcre, check_recipient_access pcre:$config_directory/recipient_checks.pcre, check_client_access hash:$config_directory/access, reject_rbl_client zen.spamhaus.org permit helo_checks.pcre: /(dsl|pool|dynamic|user|hsd|dyn|dial)/ WARN helo Dynamic addresses not allowed and the following in the logs: Dec 23 00:17:59 mail postfix/smtpd[81378]: connect from c-12-34-56-789.comcast.net[12.34.56.789] Dec 23 00:17:59 mail postgrey[937]: action=greylist, reason=new, client_name=c-12-34-56-789.hsd1.co.comcast.net, client_address=12.34.56.789, sender=*mung...@*munged*.com, recipient=fam...@*munged*.com Dec 23 00:18:00 mail postfix/smtpd[81378]: NOQUEUE: reject: RCPT from c-12-34-56-789..comcast.net[12.34.56.789]: 554 5.7.1 Service unavailable; Client host [12.34.56.789] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=12.34.56.789; from=*mung...@*munged*.com to=fam...@*munged*.com proto=ESMTP helo=cerebus.hsd1.co.comcast.net But checking the pbs database with pop-before-smtp --list the IP address is listed. (pbs is the pop-before-smtp database). After the greylisting period expires, then the message goes through, but the greylist check is way down in check_client_fqdn.pcre so it seems the message should be getting a pass on the pbs long before it gets to the check_greylist in the pcre. The pbs info should not be expiring as I check mail every 5-10 minutes, so my IP should always be 'fresh'. I do have a pop-before-smtp.log, but it was not actually logging (fixed now). (The listing in zen is correct, as I am in a dynamic comcast pool. The IP never changes, but I do not add myself to $mynetworks specifically to keep track of this kind of stuff. So, is the smtpd_restriction_class somehow applying to ALL connections, even those that should be passing, say, permit_mynetworks or permit_sasl_authenticated? Or am I missing something else? -- You think you can catch Keyser Soze? You think a guy like that comes this close to getting caught, and sticks his head out? If he comes up for anything it'll be to get rid of me. After that my guess is you'll never hear from him again.
Re: RBL
Won't that still break thunderbird? Or did mozilla finally fix that? -- Sent from my iTouch On Dec 7, 2008, at 14:41, Geert Hendrickx [EMAIL PROTECTED] wrote: As well as your own IP, hostname and domain(s).
Re: RBL
The iPhone and itouch are maniacal about forcing top posting. -- Sent from my iTouch On Dec 7, 2008, at 16:30, Sahil Tandon [EMAIL PROTECTED] wrote: On Sun, Dec 07, 2008 at 04:24:48PM -0700, LuKreme wrote: Won't that still break thunderbird? Or did mozilla finally fix that? It won't. And please stop top-posting.
Installing DKIM
In looking for methods to install DKIM with postfix I am running into some old info and some new info. It looks like the best way to handle DKIM is using the plugin feature of postfix and use the sendmail milters. The other question is what do most people do with the check on the DKIM if a message fails, reject outright? Won't this mess up any forwarded mail? -- I can't die, I haven't seen The Jolson Story - Jetboy
Re: Installing DKIM
On 7-Dec-2008, at 18:50, Victor Duchovni wrote: Do NOT use DKIM to reject unsigned mail or mail with a broken signature. If you don't intend to whitelist any DKIM senders, don't both validating DKIM signatuers, there is little point in doing so. My main intent is to try to flag mails claiming to be from paypal that aren't, so I think maybe just DKIM support in SpamAssassin is the way to go. -- Heisenberg's only uncertainty was what pub to vomit in next and Jung fancied Freud's mother too. -- Jared Earle
Re: Avoiding (trivial) spoofed mail from
On 3-Dec-2008, at 15:44, DJ Lucas wrote: LuKreme wrote: On 2-Dec-2008, at 20:21, DJ Lucas wrote: I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? Sure there is. No there isn't. AFAIK, unless I'm misunderstanding something, the rest of your message simply puts what I said above in different terms and agrees entirely. **my mom** was in the From header...nowhere else. The From header can be changed up to say that it came from somebody else. I don't care about that. The check in question is in the smtp transaction, not the data. Ah, I thought you were complaining about mismatches in the From_ and the From: rereading Yes, we agree entirely. -- Dinosaurs are attacking! Throw a barrel!
Re: Avoiding (trivial) spoofed mail from
On 3-Dec-2008, at 16:53, mouss wrote: DJ Lucas a écrit : LuKreme wrote: On 2-Dec-2008, at 20:21, DJ Lucas wrote: I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? Sure there is. No there isn't. Yes. there is;-p can we agree to disagree or do we need to contact the UNO? Maybe. The FROM_ (the envelope from, the SMTP transaction from, etc) should always be the actual source of the message. If acme.tld is sending a message on behalf of [EMAIL PROTECTED] then the FROM_ has to be acme.tld. The From: should be [EMAIL PROTECTED] there is no reason to lie in the SMTP transaction about who you are, and spoofing that is going to be a spam-tag to many servers. I touched on this in a previous message, the FROM_ and the Received headers should match up in some way, even if 'matched up' is simply an SPF match for the FROM_ -- Well I've seen the Heart of Darkness/Read the writing on the wall/an the voice out in the desert/Was the voice out in the hall
Re: Domain emails from outside
On 4-Dec-2008, at 08:18, Brian Evans - Postfix List wrote: Add 'check_sender_access pcre:/path/to/config/ restrict_internal_domain' to the end of smtpd_sender_restrictions /path/to/config/restrict_internal_domain: /.*\.example.com/REJECT external email with an internal sender address You would need to list all the domains you process mail for here, right? And this is a check against the envelope from, right? (From_ and not From:) -- Rincewind had always been happy to think of himself as a racist. The One Hundred Meters, the Mile, the Marathon -- he'd run them all.
Re: Avoiding (trivial) spoofed mail from
On 2-Dec-2008, at 20:21, DJ Lucas wrote: I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? Sure there is. First off, the envelope from is not FOR the user, it's for the mailserver. This address should always be where the 'physical' delivery of the message is originating. The From header is the PERSON that initiated the message. These are often the same, but not always. A perfect example is my mom sends out electronic cards from Jacquie Lawson1 which arrive with headers like this: Return-Path: [EMAIL PROTECTED] Received: from iport3.jacquielawson.com (iport3.jacquielawson.com [64.14.122.52]) by mail.covisp.net (Postfix) with ESMTP id D4AD9118B83F for [EMAIL PROTECTED]; Thu, 27 Nov 2008 02:27:05 -0700 (MST) Date: Thu, 27 Nov 2008 04:27:02 -0500 X-AG-MIPS: ag867 Sender: [EMAIL PROTECTED] From: **my mom** This is perfectly OK. In fact, this is exactly how this should be handled. This method is also used when someone is sending, for example, a petition request where they've 'signed' and want to let others know to sign also. Many pages (particularly political ones) have these sorts of tell your friends links and they to will use the person's email/name as the from and their own server info for the envelope. I would be far more likely to take a look at the FROM_ and compare it to the Received header than with the From: header, as I think that is far more likely to spot spam. Extending this to a physical letter situation it would be like Barack Obama's campaign sending me a letter that was signed by, say, my mom. She wrote the letter and signed it, but the campaign office mailed it in their own envelope. Seems fine to me. If they don't like my policy, they can find another place to put their mail. Others may not be lucky enough to be able to enforce such a policy, as the counter argument would be to find a less rigid admin. ;-) What is 'acceptable' has to be determined on a site by site basis. If it works for this site...great! If it doesn't, then get rid of it. Just so you know that there are common and legitimate uses for this, and that you will lose valid emails that, presumably, your users actually want. And if you are rejecting them, do your users know they are missing those emails? I mean, are they informed enough that they can make a real choice about getting MOST of their email from you or getting ALL of their email from someone else? 1 I have no connection with Jacquie Lawson. I'm not even a customer, I am merely a recipient. I do like the cards though. -- [TN]FBMachine i got kicked out of Barnes and Noble once for moving all the bibles into the fiction section
Re: postfix-policyd-spf
On 21-Aug-2008, at 11:26, mouss wrote: Erm... at least that was in postfix22, not sure if it's in 2.5.x That's the third-party spf patch. It's still available in the ports. I don't see it. must be an old ports tree? # cd /usr/ports/mail/postfix; make config Options for postfix 2.5.1_2,1 As I said, that was 2.2 where I saw it. /usr/ports/mail/postfix22 $ make configure │ │ [ ] NOPCRE DISABLE Perl Compatible Regular Expressions │ │ │ │ [ ] SASL2Cyrus SASLv2 (Simple Authentication and Security Layer) │ │ │ │ [ ] SASLKRB If your SASL requires Kerberos select this option │ │ │ │ [ ] SASLKRB5 If your SASL requires Kerberos5 select this option│ │ │ │ [ ] SASLKRB5MIT If your SASL requires MIT Kerberos5 select this option│ │ │ │ [ ] SPF SPF support │ │ │ │ [ ] TLS SSL and TLS │ │ │ │ [ ] BDB Berkeley DB (select version using WITH_BDB_VER variable) │ │ │ │ [ ] MySQLMySQL map lookups (choose version with WITH_MYSQL_VER)│ │ │ │ [ ] PgSQLPostgreSQL map lookups (choose with DEFAULT_PGSQL_VER)│ │ │ │ [ ] OpenLDAP OpenLDAP map lookups (choose ver. with WITH_OPENLDAP_VER) │ │ │ │ [ ] CDB CDB map lookups │ │ │ │ [ ] NIS NIS map lookups │ │ │ │ [ ] VDA VDA (Virtual Delivery Agent) │ │ │ │ [ ] Test SMTP/LMTP test server and generator │ │ -- Athene we all have our moments when we lose it Slyspy the key is though, to conceal the evidence before the police arrive
Re: rbl / rhsbl services?
On 28-Aug-2008, at 08:15, Stefan Palme wrote: reject_rbl_client reject_rbl_client zen.spamhaus.org That's it, all you need. -- Woof bloody woof.
