Re: Impossible to send mail using SSL for SMTP connection.
* Patrick Ben Koetter wrote: > * mouss : >> and please remove the >> smtpd_banner = The eMail Service >> because it is invalid. The banner must contain the hostname... etc. > > and it must contain "ESMTP" or the client will not know the server can speak > EXTENDED SMTP, which includes the capability "STARTTLS", which is the > startpoint for TLS ... Now, maybe I'm blind, but I don't see that requirement in RFC 2821 or 5321. And Postfix's SMTP client's default behaviour is: $ postconf -d smtp_always_send_ehlo mail_version smtp_always_send_ehlo = yes mail_version = 2.5.5 I think an initial greeting of 220 fully.qualified.hostname is pretty common this days - especially with so called "anti spam, anti malware" appliances. Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 "UNIX *is* user-friendly; it's just picky about its friends."
Re: LDAP Email Recipients Query Script - Feedback Appreciated
* James Robertson wrote: > I decided to write a bash script for extracting recipients from Windows > Active Directory for a Postfix box in front of Exchange. [...] > $LDAPSEARCH -x -h $LDAPHOST -D $LDAPUSER -w $LDAPPASS -b $LDAPBASE \ > '(proxyAddresses=*)' 2>$ERRORLOG | $GREP -f $RELAYDOMAINS | $GREP -Fi While this will almost certainly work for smaller networks, you are in serious trouble if you have more than 1000 recipients. To work around this issue from the Linux side, consider using "-E pr=100/(no)prompt". As for the Exchange side, I really don't know, but I know for sure that there is a LDAP protocol settings dialogue in the Exchange server administration GUI. Perhaps someone else can shed some light on this one. Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 FdI #54: Jetzt mit neuem, umfangreichem Softwarepaket. - Treiber liegt bei. (Kristian Köhntopp)
Re: Virtual accounts.
Hallo Gerard, * Gerard wrote: > Running postfix 2.6 > > I have mail accounts at 'hotmail' and 'yahoo'. I would like to use > fetchmail to retrieve mail from those accounts and relay it to postfix. > > Now, I was thinking that I could use 'virtual' for that. You can do this with fetchmail. "user foo there with password bar is baz here". > virtual_alias_domains = hotmail.com yahoo.com Don't do that. It basically tells your Postfix to lookup all mails for hotmail/yahoo in this table, and if the receiver is not found, the mail is rejected/bounced. Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 Someone had to put all that chaos there!
Re: How do I deliver to a program using a wild card
* Rob Tanner wrote:
> I get email forwarded to me from a FAX server that I need to process and
> then forward to a different server. The ³to² email address is always in the
> form of @send.fax. The FAX number could be the phone number for
> any FAX machine in the country and only the �...@send.fax² is a constant.
> Right now, I¹ve set up an alias that looks like ³*.send.fax
> ³/opt/local/adm/aliasFilters/FAX.filter faxfilter² which seems like it
> should work. When I point alias_maps to that file, and include the
> send.fax domain in mydestination, the message bounces because it doesn¹t
> recognize the user (which is simply one of an infinite possible phone
> numbers). When I move the send.fax domain to relay_domains and point
> virtual_alias_maps to the alias file, Postfix happily forward the message on
> to the regilar mail server, substituting the file path for the ³to² address.
> In no case does the message ever get delivered to the program.
>
> Can someone please tell me what I need to do to get this to work right? I¹m
> running this in a separate instance of Postfix, so no matter what I do, I
> won¹t screw up the main mail system.
Set up "fax.send" in virtual_alias_domains. In a PCRE map referenced by
"virtual_alias_maps", add an entry like:
/(.*)@fax.send/ local...@my.domain,${1}final.mailserver
This will redirect the message to @final.mailserver and to
the alias "localfax" (given that you substitue "my.domain" with a
domain which is part of mydestination).
In /etc/aliases, add
localfax: |/path/to/program
and issue "newaliases".
Cheers
Stefan
Re: How do I deliver to a program using a wild card
* Stefan Förster wrote:
> /(.*)@fax.send/ local...@my.domain,${1}final.mailserver
/(.*)@fax.send/ local...@my.domain,$...@final.mailserver
The "@" was missing.
Re: sieve instead procmail?
* Michael Monnerie wrote: > I currently have postfix -> procmail -> zarafa, and would like to have > postfix -> sieve -> zarafa. Is that possible via a milter maybe? The > sieve implementation would need to be able to call an external program > to deliver mail, but the rest is standard. Since you mentioned procmail, my buest guess is that your Postfix/Zarafa integration is similar to the wiki page at http://zarafa.com/wiki/index.php/MTA_integration This leaves me slightly puzzled, because I can't imagine where you'd want to plug in a Sieve filter: The setup describe above looks like the program "zarafa-agent" is doing the final delivery (as far as Postfix is concerned), which means that ultimately, the decisions on things like the destination mailbox are made by Zarafa, and not any intermediate MDA (mail delivery agent). What excatly are you trying to do with Sieve filtering? Cheers Stefan
Re: sieve instead procmail?
* Michael Monnerie wrote: > On Mittwoch 22 Juli 2009 Stefan Förster wrote: > > What excatly are you trying to do with Sieve filtering? > > Yes, zarafa-dagent delivers, but you can tell it where: > See http://forums.zarafa.com/viewtopic.php?f=11&t=2759 > Example procmail: > :0w > * ^X-Original-To: spam-t...@otherdomain.example > | /usr/bin/zarafa-dagent $USER -CF Inbox\\SPAM_trapped > EXITCODE=$? > > Maybe I can do the same with dovecot-deliver as Ralf suggested. I'll try > this tonight. You should be aware of http://wiki.dovecot.org/LDA/Sieve. Quote: "Note that Sieve doesn't support running external programs." Cheers Stefan
Re: postfix strip æø å (highbit chars)
* Benny Pedersen wrote: > On Wed, July 22, 2009 17:50, Noel Jones wrote: >> You could configure postfix to reject such mail, but then >> you'll lose otherwise legit mail. > > yes legit problem also This is probably a stupid question, but are those characters really allowed in email headers? Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 I'm not evil, I'm ... differently motivated!
"Received:" headers and mail forwarding loops
When I submit a mail to my Postfix server (using SASL auth over a TLS connection), Postfix adds the following received header: Received: from aletheia.cite.lan (33.33.33.333.dynamic.cablesurf.de [33.33.33.333]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.incertum.net (Postfix) with ESMTPSA for ; Fri, 31 Jul 2009 23:42:33 +0200 (CEST) This is working as expected. If I create a new mail and forcibly insert the above header before I submit it, I get a NDR saying that there is a mail forwarding loop for c...@example.net - which is exactly what I expected, but I'm not 100% sure how this mechanism works. So my question is: Does Postfix compare both the sending host _and_ the recipient address in "Received:" headers? If not, with regard to "Received:" headers, which (if any) information is compared to detect a mail forwarding loop? Cheers Stefan
Re: "Received:" headers and mail forwarding loops
* Wietse Venema wrote: > Stefan Förster: > > This is working as expected. If I create a new mail and forcibly > > insert the above header before I submit it, I get a NDR saying that > > there is a mail forwarding loop for c...@example.net - which is > > As documented, Postfix uses Delivered-To: headers for loop detection. I am very sorry - I had indeed pasted too many lines into my test email. Cheers Stefan
Re: Delivery failure for one recipient results in re-delivery for all
* Karl-Johan Karlsson : > On Tuesday 04 August 2009, Ralf Hildebrandt wrote: >>> Thanks! That (or, rather, "owner-root: somebody") gives the result I >>> want. I only wonder... why? I can't find much documentation on the >>> "owner-"-aliases, and none of it manages to explain this behaviour. >> >> http://www.postfix.org/aliases.5.html >> >> In addition, when an alias exists for owner-name, delivery diagnostics >> are directed to that address, instead of to the originator of the >> message. This is typically used to direct delivery errors to the >> maintainer of a mailing list, who is in a better position to deal with >> mailing list delivery problems than the originator of the undeliv- ered >> mail. > > Yes, I've seen that, and it makes no sense to me, since no delivery diagnostic > mails are ever produced, neither with nor without the owner-root alias. I know that if a "owner-" alias is present, alias expansion isn't done on every delivery attempt but instead the alias is expanded and the result of that expansion is saved, at least according to this thread: http://archives.neohapsis.com/archives/postfix/2009-06/0396.html I could be terribly wrong, though. Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 FdI #147: Fortran - Makrosprache für ein I/O-Verhinderungssystem (Arno Eigenwillig)
Re: Understanding rate limiting with anvil.
* Jaroslaw Grzabel : > I had a problem with rate limiting in postfix in last week, and I had to > disable it. I don't know why but I set up rate limiting per IP and it > looks like it didn't count rates correctly. Let me shed a lit a bit for > my problem. > > My company decided to limit a number of messages per day per IP. That's > why we run anvil and limit 1000msg/24h/IP, so I put into main.cf: > > smtpd_client_event_limit_exceptions = /etc/postfix/ratelimiting "Clients that are excluded from connection count, connection rate, or"... "excluded". > !aaa.bbb.ccc.ddd/29 This means: Don't exclude aaa.bbb.ccc.ddd/29 from rate limiting, i.e. enforce rate limiting for aaa.bbb.ccc.ddd/29. > 0.0.0.0/0 This means: Exclude the whole world from rate limiting. > I presume syntax in exclude list is incorrect or I don't understand how > anvil works at all. I think you need Postfix 2.4 or later to work with that bang-style notation. Cheers Stefan
Improper command pipelining after QUIT
Dear members of postfix-users, can anyone of you please explain to me what the following log entry means: postfix/smtpd[8558]: improper command pipelining after QUIT from unknown[64.8.20.35] I do know what command PIPELINING is, that it is offered in response to an EHLO and that Postfix 2.6 keeps track of improper pipelining on a per session basis (see release notes, feature 20090228). But I am not sure how a client can transmit additional commands after it sent a QUIT to the server. Is that some kind of timing issue, my hardware perhaps being too slow? FWIW, the only restriction I have that mentions pipelining is: smtpd_data_restrictions = reject_multi_recipient_bounce reject_unauth_pipelining I will happily provide all of postconf -n and any lookup tables as per DEBUG_README if that should be necessary. Cheers Stefan
Re: Improper command pipelining after QUIT
* Wietse Venema : > Stefan Förster: > > Dear members of postfix-users, > > > > can anyone of you please explain to me what the following log entry > > means: > > > > postfix/smtpd[8558]: improper command pipelining after QUIT from > > unknown[64.8.20.35] > > This means that the client sent "QUIT" followed by something > else; a sign of poor software at work. I see, so that additional text was received before the "QUIT" statement was actually evaluated and acted upon. Thank you. > Perhaps Postfix should log pipelining violations with a fragment > of the bits that were sent in error. I don't think this could do much harm. Thanks again Stefan
Re: Looking for opinions on FreeBSD OS for Postfix
* Guy : > I'm considering FreeBSD as an alternative, but I was wondering what > people think of FreeBSD as a platform for Postfix. It's obviously not > as easy to maintain as Ubuntu, but it does have a reputation for > stability. Any thoughts, recommendations or experiences would be > appreciated. The documentation at http://www.postfix.org/INSTALL.html#4 mentions that earlier versions of Postfix were supported on FreeBSD 2.x to 5.x. I think it's very likely that you can run recent Postfix versions on newer FreeBSD releases, too. Cheers Stefan
Re: Postfix queue problem?
Hallo Junior, * Junior Tux : > Dear all , i have a big problem with postfx queue. I'm using postfix > amavis spamassain. But queue has 5 mails. it's sending very slow. > What Can i do ? Thanks. There are various ways to debug this problem and improve performance. A first stop should be http://www.postfix.org/QSHAPE_README.html which describes not only how the various queues work together, but does also give valuable hints on solving some of the problems which one might encounter. General hints on performance tuning can be found at http://www.postfix.org/TUNING_README.html - those documents together should provide you with a reasonable start. > smtp-amavis unix - - n - 40 smtp > -o smtp_data_done_timeout=1200 > -o smtp_send_xforward_command=yes Can your server really handle 40 content filter processes (assuming that $max_servers in amavisd is set to 40, too)? You might want to look at your servers memory ressources and see if it startet swapping. You should also provide logging output of messages which are processed slowly - please note that you will need to track two queue IDs, one before it enters the content_filter and one after the reinjection. Cheers Stefan
Re: Postfix queue problem?
On second thought, * Junior Tux : > qmgr_clog_warn_time = 0 you might want to leave that at the default value to get helpful information. > smtpd_milters = inet:localhost:10026 This milter could be a problem if it is slow. > soft_bounce = yes On a prodcution machine, this will increase the load in most cases (senders retrying instead of giving up). > virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf > virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf If your database is slow or overloaded with connections, this might could slow down mail delivery. Postfix logs lookup problems, so you can verify that quite easily. Cheers Stefan
Re: openldap-2.3.39 crash
Hello 承磊, * 承磊 wrote: > I have been using postfix since a few weeks. The setup is currently: Redhat > As4.4 (Linux 2.6.9-42 SMP), Postfix 2.3.39, openldap-2.3.39, BerkeleyDB 4.5. > 20 , courier-authlib-0.56. > Now, the ldap service crashes frequently once the ldap connection raises > about 300(the database engine is bdb). you can try whether using the proxymap(8) service to access you LDAP lookup tables (with an appropriate process limit defined in master.cf) solves your problem: http://www.postfix.org/proxymap.8.html Cheers Stefan
Re: rbl checks, best place
* /dev/rob0 : > On Friday 21 August 2009 00:23:07 Olivier Nicole wrote: > > > > This is a difficult question. > > > > > > I disagree. > > > > Just that because you disagree makes the question not simple :) > > Perhaps you didn't understand. I tried to explain why the choice of > pre-DATA reject_rbl_client lookups should be preferred to doing them > through content filters. Yes, I made the exception of untrustworthy > lists. If you look back, you'll possibly see that I was proposing > responsible, informed use of DNSBLs. I have to disagree here. For me it would simply be unacceptable to reject a mail based on only _one_ criterion. As you said, if e.g. gmail get's listed on any DNSBL, this might not be a false positive, but OTOH, it's highly undesireable to block the dozillions of other legitimate customer mail originating from gmail. Nowadays, I'd always favour computing a score for every incoming email as soon as we know the HELO/EHLO, (r)DNS data and MAIL FROM. With Postfix's "smtpd_delay_reject", this is easily realized by calling a policy service at an appropriate place in smtpd_recipient_restrictions. While I know that the original reason to introduce the delayed rejects was not to make more data available, rejection at the "rcpt to" stage allows for making much more comprehensive decisions about the fate of an email. You could, for example, make it easier to contact "postmaster" - because that's where third parties will seek help if they are blocked by your system. It's only logical to extend this conception when it comes to other, sender/sending host specific criteria: Instead of evaluating one criterion at a time, basing a rejection decision on the one currently being examined, you should use _all_ the data you have about an incoming message to decide on that message's fate. > I think blind reliance on content filtering is ill-advised, based on > poor logic and lack of understanding of the nature of spam. SA and > other content filters will be checking the same DNSBL as I am, with > addition of some that I'd consider less trustworthy. Furthermore, by > virtue of having accepted the DATA, a MTA assumes responsibility for > these few messages amidst all the spam garbage. Actually (that's for the archives only, I know you are well aware of that), my server only accepted a message after giving a 2xx to the DATA-DOT. > I'm not opposed to content filtering; on the contrary, I know it's > an important third or fourth line of defense for many sites. Those > sites which are using it as the first line get what they deserve. I have to disagree here, again. From your description, I think that when you are talking about "content filtering", you are referring to a post queue filter setup. There are a million sites out there using a post queue setup, and IMNSHO, they should all die in a fire for torturing their users with ancient technology like that. About 14 months ago, I switched to a pre queue setup. The main reason for this was that even with Nazi style rejection rules (that's one Godwin for me, please!) at the SMTP level, there were still mailboxes for which our content_filter quarantined (rerouted to plus'd addresses, $WHATEVER) about 30 messages per day - while killing another 50 ones silently. And no, there wasn't any chance we could have set the "kill" level even lower. C'mon. We are living in the 21st century. Why on earth should anyone have to look through a folder/quarantine with 30 messages per day? We are humans, not machines. I know that there are many concerns regarding the use of smtpd_proxy_filter - many of them having to do with the lack of scalability. So what? Buy more hardware. Or buy better hardware. If you are worried about rejecting mailing list mails, learn how to use your filter framework. But, for God's sake, step into the 21st century, finally! Postfix could easily help this if it supported the same kind of "routing" it does with a content_filter (where you can specify "content_filter = smtp-foo:filter.domain.com:10024" and it will lookup the MX records for filter.domain.com) to faciliate load balancing and increase robustness, but we probably won't see that too soon. Cheers Stefan
Re: Reverse DNS fails with "cannot find your hostname" when forward IP is wrong
* Michael Monnerie : > I've just had a very strange bug which cost me an hour to find. > > mailserver: postfix-2.5.1-28.5 > > On the mailserver, I should receive mail from 212.69.162.205. > > # dig -x 212.69.162.205 > showed me a correct, existing PTR: > 205.192-28.162.69.212.in-addr.arpa. 3600 IN PTR protegate5.zmi.at. > > Just the forward request doesn't fit the IP: > # dig +short protegate5.zmi.at > 212.69.164.56 > > and postfix refused to take the e-mail with this message: > 450 4.7.1 Client host rejected: cannot find your hostname, > [212.69.162.205] As documented in http://www.postfix.org/postconf.5.html#smtpd_client_restrictions reject_unknown_client_hostname is triggered if 1) the client IP address->name mapping fails[, or] 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address This is often reffered to as "forward confirmed reverse DNS": http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS > The log text is not correct, it should say "your PTR 212.69.162.205 > doesn't fit the forward IP of protegate5.zmi.at". The log text ist correct. A host with an IP resolved to "protegate5.zmi.at" connected, but the host with that name has a different IP. So Postfix was not able to find a host name that resolved to that IP address. > I changed the PTR to now be > 205.192-28.162.69.212.in-addr.arpa. 3600 IN PTR protegate5old.zmi.at. > and this fits the forward: > # dig +short protegate5old.zmi.at > 212.69.162.205 > > and then the e-mail passes through. I don't know if that has already > been fixed, but it really should as the log messages suggests that we > had a DNS issue while it really only was the misfit of forward/reverse > lookups. This kind of "misfit" is commonly referred to as a "DNS issue" when postmasters talk to each other ;-) Cheers Stefan > I also looked at > http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname > but found no mentioning of the message that's logged. But a "cannot find > your hostname" is really not a good answer here. > > mfg zmi > -- > // Michael Monnerie, Ing.BSc- http://it-management.at > // Tel: 0660 / 415 65 31 .network.your.ideas. > // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" > // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 > // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 >
Re: warning: SASL authentication failure: No worthy mechs found
* Dan Winchester <2...@dan.co.uk>:
> I am new to Postfix.
>
> I am trying to get Postfix to relay via mail.authsmtp.com.
>
> I have added the following lines to main.cf
>
> relayhost = [mail.authsmtp.com]
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_sasl_security_options = noanonymous
>
> I get the following errors:
>
> warning: SASL authentication failure: No worthy mechs found
>
> SASL authentication failed; cannot authenticate to server
> mail.authsmtp.com[62.13.128.189]: no mechanism available
>
> I have run saslfinger -c (as advised in a previous post to this list), and
> have copied the output below this email.
>
> Any help would be gratefully received!
>
> Cheers
> Dan
>
> # saslfinger -c
> saslfinger - postfix Cyrus sasl configuration Thu Aug 27 06:23:33 EDT 2009
> version: 1.0.2
> mode: client-side SMTP AUTH
>
> -- basics --
> Postfix: 2.3.3
> System: CentOS release 5.3 (Final)
>
> -- smtp is linked to --
> libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x7fd1b846e000)
>
> -- active SMTP AUTH and TLS parameters for smtp --
> relayhost = [mail.authsmtp.com]
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_sasl_security_options = noanonymous
>
>
> -- listing of /usr/lib64/sasl2 --
> total 2712
> drwxr-xr-x 2 root root 4096 Aug 5 05:55 .
> drwxr-xr-x 39 root root 20480 Aug 6 04:02 ..
> -rwxr-xr-x 1 root root890 Jan 7 2007 libanonymous.la
> -rwxr-xr-x 1 root root 15880 Jan 7 2007 libanonymous.so
> -rwxr-xr-x 1 root root 15880 Jan 7 2007 libanonymous.so.2
> -rwxr-xr-x 1 root root 15880 Jan 7 2007 libanonymous.so.2.0.22
> -rwxr-xr-x 1 root root936 Jan 7 2007 libsasldb.la
> -rwxr-xr-x 1 root root 892920 Jan 7 2007 libsasldb.so
> -rwxr-xr-x 1 root root 892920 Jan 7 2007 libsasldb.so.2
> -rwxr-xr-x 1 root root 892920 Jan 7 2007 libsasldb.so.2.0.22
> -rw-r--r-- 1 root root 26 Aug 14 2008 smtpd.conf
>
> -- listing of /usr/lib/sasl2 --
> total 68
> drwxr-xr-x 2 root root 4096 Aug 3 06:16 .
> drwxr-xr-x 22 root root 12288 Aug 5 05:55 ..
> -rwxr-xr-x 1 root root 884 Jan 7 2007 libanonymous.la
> -rwxr-xr-x 1 root root 14372 Jan 7 2007 libanonymous.so
> -rwxr-xr-x 1 root root 14372 Jan 7 2007 libanonymous.so.2
> -rwxr-xr-x 1 root root 14372 Jan 7 2007 libanonymous.so.2.0.22
I don't see any SASl modules for AUTH PLAIN or AUTH LOGIN here. You
should use "yum" to search for packages like "cyrus-sasl",
"sasl-modules" and similar.
Cheers
Stefan
> -- listing of /etc/sasl2 --
> total 8
> drwxr-xr-x 2 root root 4096 Jan 7 2007 .
> drwxr-xr-x 58 root root 4096 Aug 27 04:02 ..
>
>
> -- permissions for /etc/postfix/sasl_passwd --
> -rw--- 1 root root 37 Aug 18 08:08 /etc/postfix/sasl_passwd
>
> -- permissions for /etc/postfix/sasl_passwd.db --
> -rw--- 1 root root 12288 Aug 18 08:10 /etc/postfix/sasl_passwd.db
>
> /etc/postfix/sasl_passwd.db is up to date.
>
> -- active services in /etc/postfix/master.cf --
> # service type private unpriv chroot wakeup maxproc command + args
> # (yes) (yes) (yes) (never) (100)
> smtp inet n - n - - smtpd
> pickupfifo n - n 60 1 pickup
> cleanup unix n - n - 0 cleanup
> qmgr fifo n - n 300 1 qmgr
> tlsmgrunix - - n 1000? 1 tlsmgr
> rewrite unix - - n - - trivial-rewrite
> bounceunix - - n - 0 bounce
> defer unix - - n - 0 bounce
> trace unix - - n - 0 bounce
> verifyunix - - n - 1 verify
> flush unix n - n 1000? 0 flush
> proxymap unix - - n - - proxymap
> smtp unix - - n - - smtp
> relay unix - - n - - smtp
> -o fallback_relay=
> showq unix n - n - - showq
> error unix - - n - - error
> discard unix - - n - - discard
> local unix - n n - - local
> virtual unix - n n - - virtual
> lmtp unix - - n - - lmtp
> anvil unix - - n - 1 anvil
> scacheunix - - n - 1 scache
> maildrop unix - n n - - pipe
> flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
> old-cyrus unix - n n - - pipe
> flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension}
> ${user}
> cyrus unix - n n - - pipe
> user=cyrus a
Re: warning: SASL authentication failure: No worthy mechs found
* Dan Winchester <2...@dan.co.uk>: > > I don't see any SASl modules for AUTH PLAIN or AUTH LOGIN > > here. You should use "yum" to search for packages like > > "cyrus-sasl", "sasl-modules" and similar. > > I have a number of cyrus-sasl packages installed: > > # yum list installed | grep sasl > cyrus-sasl.x86_642.1.22-4 > installed > cyrus-sasl-lib.i386 2.1.22-4 > installed > cyrus-sasl-lib.x86_642.1.22-4 > installed > > Are these sufficient for AUTH PLAIN or AUTH LOGIN? Obviously, they are not, are they? I think you might want to install cyrus-sasl-plain.x86_64. Cheers Stefan
Are queue IDs unique within a sinlge instance?
Given no external interference, are queue IDs unique within a single instance for the whole span a message stays within qmgr's control, or can a mail in e.g. the deferred queue, share an ID with a message in the active queue? Cheers Stefan
rbl_reply_maps - specify OK/ACCEPT/220?
rbl_reply_maps overrides default_rbl_reply for blacklist/response code pairs listed in the referenced lookup tables. Is it possible to specify a numeric code which is NOT a reject code, thereby realizing a DNS whitelist? Stefan
Re: rbl_reply_maps - specify OK/ACCEPT/220?
* Stefan Förster : > rbl_reply_maps overrides default_rbl_reply for blacklist/response code > pairs listed in the referenced lookup tables. > > Is it possible to specify a numeric code which is NOT a reject code, > thereby realizing a DNS whitelist? Clarifying: I know I cannot return "accept", "defer_if_permit" or something like that - but what about "250 2.1.5 Ok"? Stefan
Re: rbl_reply_maps - specify OK/ACCEPT/220?
Hallo postfix-users, * Stefan Förster : > * Stefan Förster : >> rbl_reply_maps overrides default_rbl_reply for blacklist/response code >> pairs listed in the referenced lookup tables. >> >> Is it possible to specify a numeric code which is NOT a reject code, >> thereby realizing a DNS whitelist? > > Clarifying: I know I cannot return "accept", "defer_if_permit" or > something like that - but what about "250 2.1.5 Ok"? Doesn't work: postfix/smtpd[1100]: warning: rbl response code configuration error: 250 2.1.5 Ok - in dsbl.org Stefan
Re: Configuring Two Postfix mail servers behind HA Proxy load balancer.
* Manoj Burande : > I am trying to setup a Postfix Mail Server on Fedora10. I am trying > to learn the basic process of setting up and manage a Postfix Mail > Server. Trying to learn Postfix by implementing a HA solution is not really a suitable way, IMHO. In case nobody else is going to post those links: http://www.postfix.org/BASIC_CONFIGURATION_README.html http://www.postfix.org/STANDARD_CONFIGURATION_README.html Perhaps you might want to set up a standard Postfix mailserver before you work on an HA setup. > Also trying to build a High-Available Postfix Mail Server > set. I have already configured HA Proxy load balancer servers. I just > wanted to place my two postfix mail server behind it. > > Is there ANYBODY help me to accomplish the same. Or please provide me > online stuff to set up mail servers behind load balancer. The way the SMTP protocl is designe, load balancers are almost always unnecessary - even HA loadbalancers might reduce availability (if your only MX entry points to the LB and the receiving Postfix server dies mid-transaction). What you want to look at when talking about a HA setup is the availability to continuously process a mail queue even if one node dies. You should have a very good reason to invest in such a setup, for example, sending out large newsletters. If your mailservers typically run with very small queues and a loss/delay of a single mail is not a big deal, simply configure two mail servers (and make your IMAP server/$WHATEVER clustered). If you absolutely need to make sure that queued mails will be processed even if the node that "owned" the queue dies, then - and only then - try to setup a cluster. So, a quick list of things you should get accomplished: 1. Get a HA storage solution. If e.g. it is some SAN/iSCSI stuff, get it connected to you two nodes and configure a cluster filesystem (someone might comment on why a queue on NFS is not a good idea). Whatever you do, make sure both nodes can access the same filesystem. 2. Get a clustering software working and installed on your nodes. Pacemaker/Corosync should do the job. 3. Configure two Postfix instances, each with it's own queue directory. If you don't want to store it's binaries/configuration files on the clustered filesystem, figure out a way to keep them in sync on both nodes. 4. Write yourself a resource agent which is capable of stopping and starting an instance. 5. In your clustering software, configure a "mailserver" resource using the resource agents from the previous step, and add other cluster resources (stonith devices, virtual IP addresses) as needed. Once you are finished, when one of your nodes dies, the Postfix instance will be started on the remaining node. Since the queue directory will still be available (clustered filesystem, you remember?), processing of the queue will continue. All of this of course doesn't guarantee your users will have access to your mails - you'll basically need to repeat the above steps for your IMAP/POP3 server. Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 Tapferkeit ist ein Anfall, der bei den meisten Menschen schnell vorübergeht.
Snapshot 20091109, queue disk partition sizing
If I understood the release notes correctly, with "smtpd_proxy_options = speed_adjust", each smtpd process will keep the message it's currently receiving in a temporary file. That seems to imply that there could be (number of smtpd processes) * message_size_limit bytes of queue space allocated in temporary files. I _think_ that this is not different from a setup without a content filter which would mean I don't have to increase the disk partition keeping the queue - is that assumption correct? Stefan
Re: Snapshot 20091109, queue disk partition sizing
* Wietse Venema : > Stefan Förster: > > (number of smtpd processes) * message_size_limit > > > > bytes of queue space allocated in temporary files. > > By default, the Postfix requires 1.5*message_size_limit of free > space before it accepts mail. > > Right now, the before-proxy scratch files are put in the incoming > queue, but that may still chnage. > > I didn't change the formula (to 2.5*message_size_limit) for that > reason. Thank you for that clarification. Now, about logging - I'd be really grateful if the existing logging functionality could be extended in a way so that the pre-queue content filter's response is logged. I know that it is actually the content filter's job to log what it did during an ESMTP transaction, but I think if Postfix logged the filter's response, correlating logs would be much easier. Stefan
Re: whitelisting problem
* Stan Hoeppner : > smtpd_helo_required = yes > smtpd_helo_restrictions = > check_recipient_access hash:/etc/postfix/access Did you mean "check_helo_access"? Stefan > reject_non_fqdn_helo_hostname > reject_invalid_helo_hostname > reject_unknown_helo_hostname > > smtpd_recipient_restrictions = > permit_mynetworks > reject_unauth_destination > reject_unlisted_recipient > check_recipient_access hash:/etc/postfix/access > reject_rbl_client zen.spamhaus.org > check_policy_service inet:127.0.0.1:6 > > /etc/postfix/access > ... > 66.135.197 OK > 168.100.1 OK > 204.238.179 OK > spam-l-boun...@spam-l.com OK > owner-postfix-us...@cloud9.net OK > majordomo-ow...@cloud9.net OK > owner-postfix-us...@postfix.org OK > ... > > Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from > unknown[204.238.179.8]: 450 4.7.1 : Helo command rejected: > Host not found; from= > to= proto=ESMTP helo= > > Any clues as to what's wrong? > > -- > Stan
Re: whitelisting problem
Hallo Stan, * Stan Hoeppner : > Stefan Förster put forth on 12/5/2009 5:46 AM: > > * Stan Hoeppner : > >> smtpd_helo_required = yes > >> smtpd_helo_restrictions = > >> check_recipient_access hash:/etc/postfix/access > > > > Did you mean "check_helo_access"? > > What does this have to do with the question I asked? How would this > cause the problem I'm inquiring about? Why have two members now > completely missed the problem? Rejection message: | Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from | unknown[204.238.179.8]: 450 4.7.1 : Helo command rejected: | Host not found; from= | to= proto=ESMTP helo= Obviously triggered by the "reject_unknown_helo_hostname" in: |smtpd_helo_restrictions = |check_recipient_access hash:/etc/postfix/access |reject_non_fqdn_helo_hostname |reject_invalid_helo_hostname |reject_unknown_helo_hostname Whitelist doesn't trigger because you are performing a check for the value of the "RCPT TO" parameter, not the "HELO" or "EHLO". If this isn't what you were looking for I don't have any idea what your question is. Stefan
Re: whitelisting problem
* Stefan Förster : > Rejection message: > > | Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from > | unknown[204.238.179.8]: 450 4.7.1 : Helo command rejected: > | Host not found; from= > | to= proto=ESMTP helo= > > Obviously triggered by the "reject_unknown_helo_hostname" in: > > |smtpd_helo_restrictions = > |check_recipient_access hash:/etc/postfix/access > |reject_non_fqdn_helo_hostname > |reject_invalid_helo_hostname > |reject_unknown_helo_hostname > > Whitelist doesn't trigger because you are performing a check for the > value of the "RCPT TO" parameter, not the "HELO" or "EHLO". Addendum: You can use check_client_access here. Stefan
Re: whitelisting problem
* Stan Hoeppner : > Two classes before smtpd_helo_restrictions should have triggered > accepting the email. The message should have never made it to the HELO > checks. It should have been accepted in smtpd_client_restrictions or > smtpd_sender_restrictions. Both classes come before > smtpd_helo_restrictions in my main.cf. The order in which checks are evaluated is the one in which the criterion to be checkd is made available to Postfix: 1. client IP address 2. HELO hostname 3. MAIL FROM aka "sender" 4. RCPT TO, aka "recipient(s)" 5. DATA 6. . > How is everyone missing this? You're fixated on the darn error message. > We all know what caused the error, a DNS lookup failure. That's not > rocket science and has nothing to do with the problem. The problem is > that the restriction processing order isn't being followed for some > reason. Why isn't it? _THAT_ is the problem I'm asking for help with. > That was clear in my first email, was it not? Postfix behaves according to the documentation. The documentation doesn't say that an OK from a check_client_access results in an OK for the HELO restrictions. And no, it was not clear from your first posting that you had a serious misunderstanding of how Postfix access control works. Your first posting simply suggested that you worked a whole night, couldn't barely keep your eyes open (5:46am) and therefore mixed "check_recipient_access" with "check_client_access" in your smtpd_helo_restrictions. Stefan
Re: PATCH: smtpd_proxy logging
* Mark Martinec : > On Sunday 06 December 2009 13:11:16 Stefan Foerster wrote: >> 2. The number of SMTP proxy processes busy talking to Postfix went >> down from 16.44 to 8.73 (5s resolution) - that's a completely >> unexpected result, possibly flawed by the small data sample. >> I'll verify this again once I got a full month's data. > > A drop in the number of necessary content filtering processes > is to be expected, and is in fact the main reason for the > smtpd_proxy_options=speed_adjust feature. Very useful / indispensable > in the pre-queue filtering setup. Of course - but not by this magnitude. As I said, I'll verify mid-December (or perhaps around Christmas). Stefan
ps_dict_put: /var/lib/postfix/ps_cache.db update took X ms
While I certainly like the fact that Postfix becomes more and more "admin friendly" in that it now also logs warnings about performance issues, I'd like to know how many milliseconds a single request to update the temporary whitelist may take before a warning is emitted. Is it 100ms? I got exactly 882 messages like postscreen[5486]: warning: ps_dict_put: /var/lib/postfix/ps_cache.db update took 108 ms with values ranging from 101 to 147 within the last 24 hours on a moderately busy system. Probably unrelated: When does postscreen(8) clean up it's database? Periodically? Every X connections? Never? What database sizes are to be expected? Stefan
Re: Code burn-in: postscreen/verify cache cleanup
* Wietse Venema : > I'm burning in some new code that I wrote over the past week to > periodically remove old entries from postscreen(8) and verify(8) > caches. This is not a sexy topic, but it helps to keep database > sizes in check, it speeds up database access, and it was time. > > If you're courageous you can try postfix-2.7-20091227-nonprod. If I had some problems integrating the Debian patches which support dynamic loading of map types (worse, I don't even understand why), so I went for a traditional compile and install. It's working as expected, I didn't see any adverse side effects so far. OTOH, the servers where I deployed the code have almost no real workload at this time between the years, possibly rendering my observations flawed. What kind of data could we provide to help you with this? Stefan > you have used postscreen(8) or verify(8) before, you will notice > that they weed out lots and lots of expired entries from the > databases while reporting their progress along the way. > > The cache cleaning code runs while a postscreen(8) or verify(8) > process is waiting for real work. Cache cleaning suspends when the > process does no real work for $max_idle seconds, and resumes when > there is a request for postscreen(8) or verify(8) service. After > a cache cleanup run is completed, no cleanup happens for 12 hours. > > Right now, cache cleaning cannot be disabled, so the postscreen(8) > or verify(8) cache databases MUST support the "delete" and "sequence" > operations. For backwards compatibility sake I may add a non-cleaning > option but it won't be the default setting. > > Wietse
Re: Code burn-in: postscreen/verify cache cleanup
* Ralf Hildebrandt : > * Wietse Venema : > > Dec 29 04:20:17 spike postfix/postscreen[44900]: cache > > /var/lib/postfix/ps_cache.db full cleanup: retained=134 dropped=19 entries > > Dec 29 06:19:33 spike postfix/verify[46072]: cache > > /var/lib/postfix/verify.db full cleanup: retained=1726 dropped=28 entries > > The initial cleanup: > Dec 29 10:16:35 mail postfix/postscreen[12078]: cache > /var/lib/postfix/ps_cache.db full cleanup: retained=8460 dropped=274056 > entries > Dec 29 10:17:13 mail postfix/verify[12105]: cache /var/lib/postfix/verify.db > full cleanup: retained=109892 dropped=648105 entries Not using verify here, for postscreen, the number of entries retained settled itself between 2500 and 2900, the number of dropped entries varies around 300 and 500. I've noticed a vast deterioration of the databases's performance, though. 20091209 only emitted some timing warnings for updates from time to time (database rotated every Saturday as per your recommendation). With the new code, lookup timing warnings are emitted frequently for approximately 30 minutes after every cache cleanup. Guess I need a better database library. Stefan
Re: Code burn-in: postscreen/verify cache cleanup
* Victor Duchovni : > On Wed, Dec 30, 2009 at 08:26:45AM +0100, Stefan F??rster wrote: > > I've noticed a vast deterioration of the databases's performance, > > though. 20091209 only emitted some timing warnings for updates from > > time to time (database rotated every Saturday as per your > > recommendation). With the new code, lookup timing warnings are emitted > > frequently for approximately 30 minutes after every cache cleanup. > > Guess I need a better database library. > > What database type are you using? Berkeley DB 4.6.21-11 from libdb4.6_4.6.21-11_amd64.deb. Stefan
Re: System stressed
* Joey <[EMAIL PROTECTED]> wrote: > I see several of these when watching top. > > smtpd -n smtp -t inet -u -o stress If Postfix was operating in stress mode, you would see "-o stress=yes". Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 25 Zeichen, daß Du erwachsen bist, Nummer 17: Essen gehen und Kino ist die ganze Verabredung, nicht erst der Anfang.
Re: Which FileSystem do you use on your postfix server?
* Simone Felici <[EMAIL PROTECTED]> wrote: > I know, there is enough written on the net and on the mailinglist too, but > have found only old results, maybe the meanwhile something is different, > also I would ask you... > Which filesystem do you use on your mailserver? > I'm going to migrate a mailserver with EXT3 (and qmail) to a new postfix > mailserver (virtual domains on mysql, ...). > I would create the system on EXT3 (RHES) and the following partitions on > rieserfs: > /var/spool/postfix AND the partition that will contain all mails in MailDir > format. Postfix works perfectly with it's spool on an ext3 filesystem - or rather, the list of Linux specific issues at http://www.postfix.org/LINUX_README.html does not mention ext3. Given this and the fact that a lot of people are running Postfix with it's spool on an ext3 filesystem suggests that there are no fundamental problems with this setup (well, there is one gotcha: At least on i386, ext3 can only handle 32k inodes per directory). Since some point during development of the 2.4 kernel, ext3 got the ability to use htree hashing for direcotry indexing. I don't know whether the Orlov allocator ever made it to the official kernel, but nevertheless, an ext3 filesystem initialized for storing a lot of small files (inode_ratio = 4096) and htree inidces (-O dir_index) is perfectly capable of dealing with the requirements that mail handling imposes. That said, although I personally never had any issues with ReiserFS, there are really tons of problem reports out there on the net - so I'd never use ReiserFS for any data I care for - though it might be perfectly fine for things like a proxy cache. Besides, I never saw any real performance gains (see below). > At the moment the server has ~100.000 mailboxes and more or less 120.000 > mails stored per day (already filtered trought spam filters from frontend > servers). If directory access times really become an issue, you can always work around that: The configuration parameter virtual_mailbox_maps allows you to store incoming mail in a directory structure of several levels instead of a flat hierarchy. For example: [EMAIL PROTECTED] -> $virtual_mailbox_base/incertum.invalid/cite could also become [EMAIL PROTECTED] -> $virtual_mailbox_base/i/incertum.net/c/cite We cannot give you any advice on a possible way to organize your mail storage without knowing some real data on the number of domains and localparts per domain involved. > Any suggestions? Any test results on both FS to compare with mine I'll > create? Back in 2004, during my time at university, me and some friends performed some quick tests, which you can find at: http://tinyurl.com/6bb3q4 It's in German, but perhaps you can find an online service to translate it - though I seriously doubt it's worth the trouble: Old kernel and we didn't really put that much effort into the tests we performed. There are a number of performance related docs in the Postfix website: http://www.postfix.org/TUNING_README.html http://www.postfix.org/QSHAPE_README.html As a last remark: IMAP servers typically impose a greater I/O load on a system than the MTA itself. There are massive performance differences betweens Cyrus, Courier, uw-imapd and Dovecot, so perhaps you might want to search for a benchmark on those programs. Conclusion: Don't put valuable data on ReiserFS. Don't do premature optimization. You can always change filesystems if your tests show performance gains and you run into performance shortages. Cheers Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9
Re: Remote delivery concurrency
* "Samy Ascha, Xel Media B.V." <[EMAIL PROTECTED]> wrote: > Do you guyz have any smart ideas on how to treat mail for this domain > a little different from other mail, so I don't have to change our mail- > setup globally? The document available at http://www.postfix.org/QSHAPE_README.html#backlog shows how to define a dedicated transport for one specific destination, how to play around with concurrency and the number of smtp delivery agents available, makes remarks about the use of static connection caching and so on. You cannot copy/paste the example given there, but it should show you how you can approach this problem. > What's also baking my noodle, is whether the remote party might have > an issue with connections hanging around.. For all I know, I'm making > only one connection, but they are screwing something up on their side > by not closing them down. The problems started few days ago and, > although they have not confirmed this, I must conclude that they only > recently made this cripled MTA cluster. Postfix supports the smtp_data_done_timeout, though this might not exactly be what you are lokking for: Postfix will try to deliver "at least once", not "exactly one". If you do not receive a server response on a hanging connection and smtp_data_done_timeout kicks in, the mail might be delivered multiple times. Cheers Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9
Re: Remote delivery concurrency
* "Samy Ascha, Xel Media B.V." <[EMAIL PROTECTED]> wrote: > I added a [chello.nl -> chello:] mapping to the SQL back-end and a > [EMAIL PROTECTED] -> @chello.nl] virtual mapping to fix the unknown local > user (550) error. I don't understand exactly. What you need is a transport_maps entry (i.e. an entry in one of the maps specified by transport_maps) pointing to the newly created transport - I assume that's the first part of your statement above. I don't know, though, why you went through the trouble of adding a virtual user mapping like above: Wildcard mapping like you presented it will likely result in a broken recipient validation. Furthermore, when relaying a mail to a remote destination, you should never get a "550 User unknown" referring to a local destination. > After a 'postsuper -r ALL deferred' I still don't see any evidence in > the logs of the transport being used. I feel there is a solutino here, > but postfix just isn't using it ;) If you issue the command "postmap -q chello.nl " (replace "" with the actual transport map!), does it say "chello:"? At this point, I'm almost about to ask you for output of "postconf -n" and the content of any relevant maps involved in the relay attempt and the relevant log entries, because I suspect a mis-use of the different Postfix address classes (see: http://www.postfix.org/ADDRESS_CLASS_README.html). Please do obfuscate any logs you post here as needed to protect your user's privacy. Cheers Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9
Re: authentication failed
* Rocco Scappatura <[EMAIL PROTECTED]> wrote: > After connection, in mail log, I get: > > postfix/smtpd[19545]: warning: unknown[xxx.yyy.www.zzz]: SASL LOGIN > authentication failed: authentication failure I do get those all the time. Users mistyping their passwords, usernames, client's getting AUTH all wrong and so on. > then > > postfix/smtpd[19545]: lost connection after AUTH from > unknown[xxx.yyy.www.zzz] The client disconnects. Add that particular client to debug_peer_list to see what's going on, but this is not a Postfix problem, it's the client which disconnects after authentication doesn't succeed. > But I think that - being "authentication failure" a warning, the smtp > dialog shoulnt be broken. Seen from an smtpd's point of view, failure to authenticate is not fatal, so it is logged as a warning. > Then I ask why the connection with the client is lost? Go ask the client's programmers ;-) Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 FdI #132: Plug and Play - Kondome. (Rolf Siebrecht)
Re: Backscatter issues with non-delivery notifications
* "Dave Buchanan (Abo Ltd)" <[EMAIL PROTECTED]> wrote: > This is what happens to an e-mail that has spam / virus etc from > > Mail is accepted by our servers for delivery and then passed on to [EMAIL > PROTECTED] > The demon.net mailserver rejects this mail with a 550 error > our mailserver then sends a non-delivery notification to the sender > > If the sender has been dreamed up by the spammer etc then they receive > unwanted mail > > I would like to know how to turn these non-delivery e-mails off in postfix Recommended documentation: http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient http://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup http://www.postfix.org/postconf.5.html#relay_recipient_maps Cheers Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9
Re: How to run patch file making correction
* Stephen Liu <[EMAIL PROTECTED]> wrote: > I'm following this howto; > > POSTFIX > http://www.postfixvirtual.net/postfixvirtual.html#postfix > > CYRUS_SASL > http://www.postfixvirtual.net/postfixvirtual.html#cyrussasl > > > building the mail server. All packages were compiled from sources. > > > Version; > postfix-2.5.5.tar.gz > > > I have tried building Postfix Virtual by following other 3 howtos > before, all packages download on Debian repo. After finish all servers > can't work properly. This is my 4th round. There is no reason to build your own packages when using Debian/stable. Backports include Postfix 2.5.5. To use them, simply add to your /etc/apt/sources.list: deb http://www.backports.org/debian etch-backports main contrib non-free Run aptitude update, then aptitude -t etch-backports install postfix You might want to include more packages in the command line above, like for example postfix-pcre, postfix-mysql or postfix-cdb, depending on your need. Make sure you carefully read (and understand) http://www.backports.org/dokuwiki/doku.php?id=instructions Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 "One World, one Web, one Program" - Microsoft promotional ad "Ein Volk, ein Reich, ein Fuhrer" - Adolf Hitler
Re: [OT] postmaster@ for customers' domains?
* Martin Strand <[EMAIL PROTECTED]> wrote: > Now one of these customers wants to create a > [EMAIL PROTECTED] account and use it for his personal > email... I just want to ask what you guys think about this policy, > am I just being silly when reserving these addresses in the > customer's own domain? Should I drop that restriction and leave > their domains alone? Apart from the workarounds and valid concers which were already pointed out, for me, the main reason to avoid using the postmaster localpart for personal mail is the special treatment it receives at many sites: I've made it a habit for systems I set up to drastically lower the amount of filtering, both in terms of smtpd_mumble_restrictions and content filtering, that postmaster and abuse addresses receive. After all, postmaster is the address that other admins will use to contact you if they have problems receiving mail from or sending it to your system, so you don't want that address to receive your usual filtering. This has never been a problem for me because the amount of junk email sent to postmaster and abuse is absolutely negligible. I don't want to know what happens, though, if that address was used every day... Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 FdI #181: Internet - Das Internet ist durch die preußische Landordnung vorhergesagt worden. (BMJ-Mitarbeiter Dr. Matthias Korte interpretiert Bundesverwaltungsrichter Prof. Dr. Dr. Jörg Berkemann)
Re: [OT] postmaster@ for customers' domains?
* Neil <[EMAIL PROTECTED]> wrote: > On 8 Nov 2008, at 03:46, Stefan Förster wrote: >> This has never been a problem for me because the amount of junk email >> sent to postmaster and abuse is absolutely negligible. I don't want to >> know what happens, though, if that address was used every day... > > I've noticed the same in the past, and it always puzzled me a > little... I suppose spamming the abuse/postmaster is a somewhat > faster way to find oneself blacklisted; but on the other hand, I don't > really understand why spammers would take the effort to avoid those > addresses...afterall, it's easier to guess "postmaster" and "abuse" > than the random letter/number strings I'm seeing in my mail logs. I think that most of the poeple out there sending UBE/UCE want to make money, but the folks reading postmaster@ and abuse@ are in general not the ones who buy anything from spammers or get easily fooled by some Nigerian scam. From a spammers point of view, there is nothing to gain by sending UBE/UCE to abuse@ and [EMAIL PROTECTED] Cheers Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 25 Zeichen, daß Du erwachsen bist, Nummer 24: Du trinkst nicht mehr zu Hause, um Geld zu sparen, bevor Du ausgehst.
Re: [OT] postmaster@ for customers' domains?
* "Daniel V. Reinhardt": > Stefan Förster: >> I think that most of the poeple out there sending UBE/UCE want to >> make money, but the folks reading postmaster@ and abuse@ are in >> general not the ones who buy anything from spammers or get easily >> fooled by some Nigerian scam. From a spammers point of view, there >> is nothing to gain by sending UBE/UCE to abuse@ and [EMAIL PROTECTED] > > If a spammer can successfully send enough spam to system aliases, > then they can effectively cause a system wide denial of service for > email and other logging function as /var would be at capacity. So > spammers do have a lot to gain by spamming those mail boxes which is > why you set up an email address to forward those emails too so your > /var or your /mail/spool directories dont get full. Your logic is flawed: Causing a denial of service against your MTA deters them from spamming your users. Besides, the RFCs which require us to have postmaster and abuse addresses don't require storage of those mails on the same filesystem that holds our syslog data. Cheers Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 Servicepack 5 für Windows NT wurde erfolgreich deinstalliert. Stand ist jetzt Servicepack 5.
Re: TLS Logging
Hello Mark, please take the following with a grain of salt, it's 4am here, so I might be seriously wrong: * Mark Watts <[EMAIL PROTECTED]> wrote: > > I'm in the process of setting up TLS on a number of servers. > I have two servers, both running Postfix, one an smtp client and the other an > smtpd server, using a self-signed SSL certificate. > > Sending messages, I get the following in the log on the sender: > > Nov 19 10:05:01 mailr postfix/smtp[22688]: setting up TLS connection to > mail.linux-corner.info > Nov 19 16:05:01 mailr postfix/smtp[22688]: TLS connection established to > mail.linux-corner.info: TLSv1 with cipher ADH-AES256-SHA (256/256 bits) ADH-AES256-SHA is a certificate less cipher. Without a certificate, teher is nothing to verify. > However, the same server sending to another TLS-enabled server (I believe its > qmail), I get this: > > Nov 19 10:09:09 mailr postfix/smtp[25134]: setting up TLS connection to > burn.qinetiq.com > Nov 19 10:09:09 mailr postfix/smtp[25134]: certificate verification failed > for burn.qinetiq.com: num=18:self signed certificate > Nov 19 10:09:09 mailr postfix/smtp[25134]: Unverified: > subject_CN=burn.qinetiq.com, issuer=burn.qinetiq.com > Nov 19 10:09:09 mailr postfix/smtp[25113]: TLS connection established to > burn.qinetiq.com: TLSv1 with cipher AES256-SHA (256/256 bits) I don't know what exactly AES256-SHA is, but obviously, it is not a null cipher, so there is a certificate to verify, and verification fails. Cheers Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 FdI #266: Allradantrieb - Allradantrieb bedeutet, dass man dort stecken bleibt, wo der Abschleppwagen nicht hinkommt.
attempt to open lmdb:postscreen_cache with both "open" lock and "access" lock
Hello World,
I'm running Postfix 3.6.4 in a container on Alpine 3.15 main. After
a bit of time, I'm starting to get error messages like that:
#v+
Mar 17 13:24:40 servername postfix/postscreen[164]: CONNECT from
[167.248.133.120]:52756 to [172.17.13.3]:25
Mar 17 13:24:40 servername postfix/proxymap[166]: panic: dict_open: attempt to open
lmdb:/var/lib/postfix/postscreen_cache with both "open" lock and "access" lock
Mar 17 13:24:41 servername postfix/master[1]: warning: process
/usr/libexec/postfix/proxymap pid 166 killed by signal 6
Mar 17 13:24:41 servername postfix/master[1]: warning:
/usr/libexec/postfix/proxymap: bad command startup -- throttling
Mar 17 13:24:48 servername postfix/postscreen[164]: fatal: watchdog timeout
#v-
I verified that these are the first messages since container startup
that indicate a problem by using:
#v+
journalctl CONTAINER_NAME=postfix_postfix_1 -o cat | egrep
'(warning|error|fatal|panic):'
#v-
Output of postconf -n is below - I'll happily provide further details.
I'm not running any of the postfix programs in a chroot, so I guess
I can simply drop the access by proxy. I also believe that I might be
fine without persistence for the postscreen cache.
However, if there is another fix, I'd be glad to hear about that.
Thanks,
Stefan
address_verify_map = proxy:lmdb:${data_directory}/verify_cache
alias_database = lmdb:/etc/postfix/maps/aliases
alias_maps = lmdb:/etc/postfix/maps/aliases
allow_percent_hack = no
biff = no
compatibility_level = 3.6
confirm_delay_cleared = yes
delay_warning_time = 1h
general_smtpd_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient,
reject_unlisted_sender, reject_unlisted_recipient,
reject_unknown_sender_domain, reject_unknown_recipient_domain,
check_recipient_access lmdb:${maps_dir}/verify_recipients, check_sender_access
lmdb:${maps_dir}/verify_senders, check_policy_service inet:dovecot:25001
header_checks = pcre:${maps_dir}/header_checks.pcre
inet_interfaces = all
maillog_file = /dev/stdout
maps_dir = /etc/postfix/maps
maximal_queue_lifetime = 14d
message_size_limit = 26214400
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_protocol = 6
myhostname = servername.example.com
parent_domain_matches_subdomains =
postscreen_access_list = permit_mynetworks, cidr:${maps_dir}/relay_clients.cidr
postscreen_cache_map = proxy:lmdb:$data_directory/postscreen_cache
postscreen_greet_action = enforce
proxy_interfaces = 65.108.140.253, [2a01:4f9:1a:90c5::2]
recipient_delimiter = +
relayhost =
smtp_address_preference = ipv6
smtp_dns_support_level = dnssec
smtp_generic_maps = regexp:${maps_dir}/smtp_generic.regexp
smtp_sasl_tls_security_options = noanonymous
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_loglevel = 1
smtp_tls_security_level = dane
smtp_tls_session_cache_database = lmdb:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_client_connection_count_limit = 20
smtpd_client_restrictions = ${stress?reject_unknown_client_hostname}
smtpd_data_restrictions = reject_multi_recipient_bounce,
reject_unauth_pipelining
smtpd_discard_ehlo_keywords = silent-discard, dsn
smtpd_helo_required = yes
smtpd_milters = inet:rspamd:11332
smtpd_recipient_restrictions = check_client_access
cidr:${maps_dir}/hard_blacklist.cidr, check_recipient_access
lmdb:${maps_dir}/recipient_access, $general_smtpd_restrictions
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
check_client_access cidr:${maps_dir}/relay_clients.cidr,
reject_unauth_destination
smtpd_sasl_path = inet:dovecot:12345
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /srv/ssl/live/servername.example.com-rsa/fullchain.pem
smtpd_tls_dh1024_param_file = /srv/dh/dh_4096.pem
smtpd_tls_dh512_param_file = /srv/dh/dh_512.pem
smtpd_tls_eccert_file = /srv/ssl/live/servername.example.com-ecdsa/fullchain.pem
smtpd_tls_eckey_file = /srv/ssl/live/servername.example.com-ecdsa/privkey.pem
smtpd_tls_key_file = /srv/ssl/live/servername.example.com-rsa/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtputf8_enable = yes
submission_hostname = mail.example.com
submission_smtpd_recipient_restrictions = check_sasl_access
lmdb:${maps_dir}/sasl_access, $general_smtpd_restrictions
submission_tls_preempt_cipherlist = yes
swap_bangpath = no
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_domains = example.net
virtual_alias_maps = lmdb:${maps_dir}/virtual_aliases
virtual_mailbox_domains = lmdb:${maps_dir}/virtual_mailbox_domains
virtual_transport = lmtp:inet:dovecot:10025
Re: difference between /var/spool/postfix/etc/hosts and /etc/hosts
* Paul Martin : on debian , i am running postfix. I changed my IP ldap server in /etc/hosts but /var/spool/postfix/etc/hosts is different. What shoud I do to make postfix using the new IP ldap? This Debian-specific issue can be solved by restarting the Postfix service (e.g. "service postfix restart") or calling the configuration script for each instance, e.g.: /usr/lib/postfix/configure-instance.sh /etc/postfix HTH, Stefan
Re: Question about disabling SSLv2 and SSLv3 and Opportunistic TLS
* Dirk Stöcker : On Mon, 28 May 2018, Viktor Dukhovni wrote: It might be useful, but probably not, to have a version of postconf -n that showed the default value along sinde the changed value: join <(postconf -n) <(postconf -d | sed 's/=/(default:/; s/$/)/') Do you maybe also have a command to show only changed parameters? Something like postconf -n, but dropping everything identical to default. You can get changed parameters that are at their default value with: comm -1 -2 <(postconf -n) <(postconf -d)
