Re: Restricting port 25 with cidr table
On 26/1/2012 1:09 πμ, Charles Marcus wrote: However, we could formulate gwservers.cidr as (for example): xxx.xxx.xxx.xxx OK xxx.xxx.xxx.xxx OK 127.0.0.1 OK :::::: OK :::::OK ::1 OK 0.0.0.0/0 reject unauthorized client, please use our MX ::/0 reject unauthorized client, please use our MX Missed this... did you ever get an answer as to whether or not this would work? Since the default 'final action' for postfix is accept not reject, I'd rather not change that if unnecessary. Hi Charles, I missed this mail. I never got any answer, yet I am pretty confident it will work. However, I will opt for the second method: /etc/postfix/gwservers.cidr: xxx.xxx.xxx.xxx OK xxx.xxx.xxx.xxx OK 127.0.0.1 OK :::::: OK :::::OK ::1 OK and smtpd_client_restrictions = check_client_access cidr:/etc/postfix/gwservers.cidr,reject If there is no match in the cidr lookup, there is no default implied accept, but the check moves to the next statement among those in smtpd_client_restrictions which in this case is a reject. I hope someone more experienced here can confirm this. All the best, Nick
Re: Behavior of postscreen_access_list = static:retry
On Mon, 30 Jan 2012 19:17:17 -0500 (EST), Wietse Venema wie...@porcupine.org wrote: Mark Alan: Would the following be an acceptable way to do it? postconf -e 'postscreen_access_list = reject' postconf -e 'soft_bounce = yes' Only if this is documented. The soft_bounce parameter is listed on the postscreen(8) manpage, this is perhaps a sufficient promise to match user expectations and so I would expect it to work. Sadly it does not. Although postscreen marks it as BLACKLISTED, then tlsproxy kicks in and lets the email pass: Only because you failed to configure postscreen_blacklist_action = drop. Wietse Not exactly a failure, as doing so would instruct postscreen to simply DISCONNECT (i.e., drop the connection immediately). In which case a single 'master_service_disable = inet' would be more elegant and similarly effective. My question should have been: Using only the frugal postscreen resources is there a way to achieve something like 'postscreen_blacklist_action = defer' , i.e., to configure it to immediately NOQUEUE all connections with a 450 SMTP reply? Thank you, M.
Re: Indiscriminate maildir processing
On 1/30/2012 9:10 AM, Eric Chandler wrote: The above simple example catches *EVERYTHING* and is suitable to be used in a lab or test setting. This is consistent with the initial request as I understand it. If the request was incomplete, it should be clarified. Yes, I want to catch everything. The dev/qa environments use different MTAs than production. The two environments contain approximately 1,500 linux/solaris hosts and, although they all run postfix, I don't have control over their applications that utilize it. Basically, it's BECAUSE they've had a bad history of flooding our corporate exchange servers with garbage that I want to create a place to store all emails they send, at-least long enough for those who want to see what they created can read them, before they are summarily-deleted automatically. It's partially a punishment to them for their lack of understanding of what emails can do to other systems, and partially to protect Exchange from filling up with garbage. My hope is that I could create a separate maildir for each recipient, no-matter if the recipient has a standard corporate email address, or even r...@postfix.org for all intents and purposes. I could easily write a cron to go down through all the maildirs and cull old stuff older than say a week. People who want to see what the emails contain could then imap in as whatever userid they want (another area for me to figure out - passwordless-imapd) and see those emails. Eric, have you looked at Enkive? It may give you much of what you're looking for, right down to user-less, or single user login, with access to everything. Albeit with a search interface instead of an IMAP MUA, which may actually be better given the test nature of mails being dumped into the sink. Check out the interactive demo and hit the search page to see the search parameter box. http://www.enkive.org/ http://wiki.enkive.org/index.php/Installation_Instructions http://wiki.enkive.org/index.php/GettingMailIntoEnkive I've not used it myself yet but it seems to have some nice features that lend it to uses other than strictly archiving. Uses Postfix as the MTA to get mail dumped into it. -- Stan
Re: SASL authentication and Windows Live Mail
On 1/31/2012 1:44 AM, James Day wrote: The only question that remains for me is, what is the difference between PLAIN and LOGIN mechanisms? I understand from http://wiki.dovecot.org/Authentication/Mechanisms that they are both plain text. Unfortunately google searches for login authentication aren't particularly helpful. The way the username and password are encoded and sent on the wire is slightly different. Biggest visible difference is PLAIN sends the username and password together in the same command; LOGIN sends them separately. Some clients only support one of these methods. Broadly speaking, some Microsoft clients only support LOGIN, some third-party clients only support PLAIN. There's no reason to not offer both. -- Noel Jones
RE: SASL authentication and Windows Live Mail
The only question that remains for me is, what is the difference between PLAIN and LOGIN mechanisms? I understand from http://wiki.dovecot.org/Authentication/Mechanisms that they are both plain text. Unfortunately google searches for login authentication aren't particularly helpful. The way the username and password are encoded and sent on the wire is slightly different. Biggest visible difference is PLAIN sends the username and password together in the same command; LOGIN sends them separately. Some clients only support one of these methods. Broadly speaking, some Microsoft clients only support LOGIN, some third-party clients only support PLAIN. There's no reason to not offer both. -- Noel Jones Thanks Noel, as ever you've provided valuable insight. Your help is very much appreciated. Kind regards, James Day
Re: Behavior of postscreen_access_list = static:retry
On 1/31/2012 4:36 AM, Mark Alan wrote: On Mon, 30 Jan 2012 19:17:17 -0500 (EST), Wietse Venema wie...@porcupine.org wrote: Mark Alan: Would the following be an acceptable way to do it? postconf -e 'postscreen_access_list = reject' postconf -e 'soft_bounce = yes' Only if this is documented. The soft_bounce parameter is listed on the postscreen(8) manpage, this is perhaps a sufficient promise to match user expectations and so I would expect it to work. Sadly it does not. Although postscreen marks it as BLACKLISTED, then tlsproxy kicks in and lets the email pass: Only because you failed to configure postscreen_blacklist_action = drop. Wietse Not exactly a failure, as doing so would instruct postscreen to simply DISCONNECT (i.e., drop the connection immediately). In which case a single 'master_service_disable = inet' would be more elegant and similarly effective. My question should have been: Using only the frugal postscreen resources is there a way to achieve something like 'postscreen_blacklist_action = defer' , i.e., to configure it to immediately NOQUEUE all connections with a 450 SMTP reply? Thank you, M. You need to set both postscreen_blacklist_action = drop and soft_bounce = yes. The soft_bounce changes the 521 hangup into a 421 hangup. Alternately, you can use postscreen_blacklist_action = enforce with soft_bounce = yes. This delays the 450 reject until the client sends recipient information. http://www.postfix.org/postconf.5.html#postscreen_blacklist_action http://www.postfix.org/postconf.5.html#soft_bounce -- Noel Jones
Re: Behavior of postscreen_access_list = static:retry
Mark Alan: On Mon, 30 Jan 2012 19:17:17 -0500 (EST), Wietse Venema wie...@porcupine.org wrote: Mark Alan: Would the following be an acceptable way to do it? postconf -e 'postscreen_access_list = reject' postconf -e 'soft_bounce = yes' Only if this is documented. The soft_bounce parameter is listed on the postscreen(8) manpage, this is perhaps a sufficient promise to match user expectations and so I would expect it to work. Sadly it does not. Although postscreen marks it as BLACKLISTED, then tlsproxy kicks in and lets the email pass: Only because you failed to configure postscreen_blacklist_action = drop. Wietse Not exactly a failure, as doing so would instruct postscreen to simply DISCONNECT (i.e., drop the connection immediately). In which case a According to documentation: drop Drop the connection immediately with a 521 SMTP reply. Set soft_bounce=yes to change the reply into 421. Wietse
Re: Behavior of postscreen_access_list = static:retry
On Tue, 31 Jan 2012 06:17:39 -0600, Noel Jones njo...@megan.vbhcs.org wrote: You need to set both postscreen_blacklist_action = drop and soft_bounce = yes. The soft_bounce changes the 521 hangup into a 421 hangup. Thank you Noel, If we wanted a mere 4.x.x hangup, it would be more elegant to set a single 'master_service_disable = inet' as Viktor Dukhovni pointed out. Alternately, you can use postscreen_blacklist_action = enforce with soft_bounce = yes. This delays the 450 reject until the client sends recipient information. The intention is neither to delay until some other event. The intention is to simply have postscreen immediately answer '450 Service currently unavailable' to all connections (friend or foe) that are presented to it. So, ideally: a) postscreen must answer. It is not enough to simply drop the connection as 421 does; b) it must the answer as it does at every first encounter with a new IP, i.e., with a '450 Service currently unavailable'. It did not imagine that it would be so difficult to configure postscreen/postfix to achieve such a simple specification. Thank you, M.
Local users relay
Hi folks - I'm new to postfix. Been working with sendmail forever but for a new mailserver my boss (actually his boss) has a thing for postfix and against sendmail. So I'm scrambling to learn. One thing that has come up is that in the near future this new server will be the MX for a particular domain. There may be one or two local users but for the vast majority of users I want to be able to forward them to our corporate mailserver (though we are transitioning to google mail, a complication for later). So, can I configure postfix to accept the mail for the defined local users and set up a simple rule to forward all the others? -- Eric Jacobs Thomas Publishing Company Infrastructure and operations Information Technology Group Phone: 215-494-7312 Email: ejac...@thomaspublishing.com
Re: Local users relay
On 1/31/2012 9:54 AM, Eric Jacobs wrote: Hi folks - I'm new to postfix. Been working with sendmail forever but for a new mailserver my boss (actually his boss) has a thing for postfix and against sendmail. So I'm scrambling to learn. One thing that has come up is that in the near future this new server will be the MX for a particular domain. There may be one or two local users but for the vast majority of users I want to be able to forward them to our corporate mailserver (though we are transitioning to google mail, a complication for later). So, can I configure postfix to accept the mail for the defined local users and set up a simple rule to forward all the others? It seems that the official documentation covers this FAQ: http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall http://www.postfix.org/STANDARD_CONFIGURATION_README.html#some_local
Best method for archiving all emails through server
Good day, I would like to know how best to archive all email relayed by a single Postfix server. I have found the `always_bcc` option, but that loses important information such as other BCC recipients, which I want. I would like suggestions on more complete solution. This server is used for semi-automated sending of emails by several in-house web applications.\ Thank you, Arthur Pemberton
Re: Behavior of postscreen_access_list = static:retry
Mark Alan: It did not imagine that it would be so difficult to configure postscreen/postfix to achieve such a simple specification. The hardest part of support on this mailing list is to get a precise spec that does not conflict with itself. Once we have that, configuration is not hard at all. # postconf -n|grep postscreen postscreen_access_list = static:reject postscreen_blacklist_action = enforce postscreen_greet_banner = # telnet 127.0.0.1 smtp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 foo.example.com ESMTP Postfix ehlo foo 250-foo.example.com 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from:me 250 2.1.0 Ok rcpt to:you 450 4.3.2 Service currently unavailable You complained that Postfix would engage into STARTTLS, but that is a requirement if you want it to reject mail EXACTLY as if postscreen talks to a stranger. Wietse
RE: Indiscriminate maildir processing
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Stan Hoeppner Sent: Tuesday, January 31, 2012 6:06 AM To: postfix-users@postfix.org Subject: Re: Indiscriminate maildir processing Eric, have you looked at Enkive? It may give you much of what you're looking for, right down to user-less, or single user login, with access to everything. Albeit with a search interface instead of an IMAP MUA, which may actually be better given the test nature of mails being dumped into the sink. Check out the interactive demo and hit the search page to see the search parameter box. http://www.enkive.org/ Thanks Stan! As it turns out, I've already coded the milter and it works swimmingly. I'm just now to the imap side of things to see what options I have there. I already have a rather-complicated milter system in place that grabs email information/contents for all emails we send and stores them in a massive Oracle database. We send about 40 million emails a month through postfix and these milters, and have over a billion emails saved in the database currently. What I'm doing with this little catch-all system is simply stopping dev/qa emails from getting into inboxes either internally or externally, with the option of people being able to look at the email and headers together in the sent mail, rather than running queries against the database. Looks like I have such a system now. Thanks for all the help everyone.
Re: Success DSNs From Come to Postmaster
On 30 Jan 2012, at 22:20, Wietse Venema wrote: Ralf Hildebrandt: * Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com: Is it a bug or a feature that success DSNs requested for the null sender come to the postmaster? Here's what happens. First, mail to the null address goes to MAILER-DAEMON by default: empty_address_recipient (default: MAILER-DAEMON) The recipient of mail addressed to the null address. Postfix does not accept such addresses in SMTP commands, but they may still be created locally as the result of configuration or software error. Second, it's common to have an alias MAILER-DAEMON - postmaster, so that explains why the mail for ends up there. Right. This makes sense. And the To: field in notifications is empty itself, too. I've set empty_recipient_address to double-bounce, which seems to do what I want, send these to bit heaven. (BTW: it isn't documented anywhere that double-bounce works arbitrarily like this, nor that it's accepted in SMTP as 'double-bounce'.) Postfix sends delivery notifications as mail from . When this first-order notification fails, Postfix will attempt to deliver a second-order notification to the 2bounce_notice_recipient (default: postmaster) as a final attempt to avoid loss of mail. Are these internally-generated bounce messages distinguishable from mail that is actually injected with SMTP or the sendmail command as 'mail from:' or 'sendmail -f '? I assume one of two things must be true in order to receive a double bounce for such mails, either that this is really the case or the bounce handling code follows through, first for a single bounce and then a double bounce, such that a failed message injected with is included directly in the double bounce, rather than inside a single bounce which is included in the double bounce. I never saw the latter, leading me to believe the former assumption, which is that internally generated mail is special. This handling of fail/delay notifications satisfies the RFC's requirement of never responding to the sender address. However, the code that handles NOTIFY=SUCCESS fails to satisfy that RFC requirement. It was written several years earlier to implement support for sendmail -bv and sendmail -v, and was not updated when it was put into service to also handle SUCCESS notifications. I'll make the NOTIFY=SUCCESS handling consistent with fail/delay. Thank you! Cheers, Sabahattin
Re: Success DSNs From Come to Postmaster
Sabahattin Gucukoglu: Postfix sends delivery notifications as mail from . When this first-order notification fails, Postfix will attempt to deliver a second-order notification to the 2bounce_notice_recipient (default: postmaster) as a final attempt to avoid loss of mail. Are these internally-generated bounce messages distinguishable from mail that is actually injected with SMTP or the sendmail command as 'mail from:' or 'sendmail -f '? I assume one of Just like non-bounce messages, internally-generated single-bounce and double-bounce messages are indistinguishable from externally-generated mail except, for programs that make detailed examination of Received: headers, parse DKIM signatures, analyze logfiles, etc. In any case, the success notifier now distinguishes between bounce and non-bounce messages, similar to the fail/warn notifiers. Wietse
bypass content-filter for email sent from localhost
Hi list, I've googled it but am confused by the various responses. What I'd like seems to be pretty simple - to configure content-filter to be bypassed if the message originates from localhost. If anyone has a simple way to achieve this I'd appreciate the advice. Cheers Marc
Outbound RBL
We run a small cluster of postfix servers that are dedicated outbound relayhosts for our customers. Beyond the outbound postfix cluster we have another cluster of mail filtering appliances that have served their purpose very well, but we are starting to get more compromised account due to phishing attempts and some of the spam is getting through the outbound filters due to the volume of new spam messages. I am looking for advice on how to limit our exposure to malicious senders that have access to a users credentials. One method we have zero experience in is using RBLs, which I am hoping to learn more about.
Re: Outbound RBL
On 1/31/2012 8:03 PM, l...@airstreamcomm.net wrote: We run a small cluster of postfix servers that are dedicated outbound relayhosts for our customers. Beyond the outbound postfix cluster we have another cluster of mail filtering appliances that have served their purpose very well, but we are starting to get more compromised account due to phishing attempts and some of the spam is getting through the outbound filters due to the volume of new spam messages. I am looking for advice on how to limit our exposure to malicious senders that have access to a users credentials. One method we have zero experience in is using RBLs, which I am hoping to learn more about. Most people address this with sender rate limits using a policy service such as policyd or postfwd, possibly combined with outbound virus/spam scanning. http://www.postfix.org/addon.html#policy Once the rate limit (or outbound virus/spam limit) is tripped, the account is flagged for an admin to check further, and maybe temporarily disabled depending on site policy. I'm not quite sure how an RBL would be useful here. -- Noel Jones
