Re: Queue directories on faster media?
* Ori Bani orib...@gmail.com: Hello, I'm curious to get feedback on the idea of mounting all the postfix queue directories on a faster media (SSD drive in this case). In my case, I have virtual maildirs under /var/spool/postfix and those would be relocated to elsewhere (onto slower normal media) because the faster (SSD) media isn't in a RAID configuration (slower media is). Why are you storing maildirs in the queue directory? Does that make any sense? Is there adverse risk putting the queue directories on non-RAID fast media? Am I right to think that that's where the most performance is to be gained? Yep. I guess you could put some queue directories in tmpfs, but that seems even more risky, a little too risky. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: Queue directories on faster media?
On Mon, Jan 30, 2012 at 12:42 AM, Ralf Hildebrandt ralf.hildebra...@charite.de wrote: * Ori Bani orib...@gmail.com: Hello, I'm curious to get feedback on the idea of mounting all the postfix queue directories on a faster media (SSD drive in this case). In my case, I have virtual maildirs under /var/spool/postfix and those would be relocated to elsewhere (onto slower normal media) because the faster (SSD) media isn't in a RAID configuration (slower media is). Why are you storing maildirs in the queue directory? I think it is a legacy thing from a very old how-to. Note it's for virtual accounts, so no /home directories. What's the more standard place to put them if I may ask? Does that make any sense? Is there adverse risk putting the queue directories on non-RAID fast media? Am I right to think that that's where the most performance is to be gained? Yep. Thanks. Would it be OK to put everything in /var/spool/postfix on fast media or do only some directories benefit from the speed increase?
Success DSNs From Come to Postmaster
Is it a bug or a feature that success DSNs requested for the null sender come to the postmaster? I vote bug. :-) Any workarounds to prevent this in the meantime? Cheers, Sabahattin
Outlook 2003 Client SASL Login Problem?
Hi All, Just upgraded our mailserver. Thought I had everything set the same as I did with the old one. Nonetheless, of all the people who *can't* send email, it would have to be the President of the company. I do have broken_sasl_auth_clients = yes. Postfix version is 2.7.0, running on an Ubuntu 10.04.3 LTS. Dovecot is version 1.2.9. Other SASL parameters from postconf -n ... smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot Relevant master.cf config smtps inet n - - - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/smtps The only difference between the old master.cf and the new is the addition of the smtpd_client_restrictions line and the syslog_name line. The Outlook 2007 client I used to test Outlook functionality with the new server works fine. The Outlook 2003 client acts like it's not logging in. I verified it *is* set to login to SMTPS using the same login information as the POP3S login (which works fine). I even manually configured-in the user's logname and password separately, to no avail. Google searches thus far have not been helpful. Thanks, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at http://jimsun.LinxNet.com/contact/scform.php.
Re: Outlook 2003 Client SASL Login Problem?
Am 30.01.2012 14:47, schrieb James Seymour: Hi All, Just upgraded our mailserver. Thought I had everything set the same as I did with the old one. Nonetheless, of all the people who *can't* send email, it would have to be the President of the company. I do have broken_sasl_auth_clients = yes. Postfix version is 2.7.0, running on an Ubuntu 10.04.3 LTS. Dovecot is version 1.2.9. Other SASL parameters from postconf -n ... smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot Relevant master.cf config smtps inet n - - - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/smtps The only difference between the old master.cf and the new is the addition of the smtpd_client_restrictions line and the syslog_name line. The Outlook 2007 client I used to test Outlook functionality with the new server works fine. The Outlook 2003 client acts like it's not logging in. I verified it *is* set to login to SMTPS using the same login information as the POP3S login (which works fine). I even manually configured-in the user's logname and password separately, to at least show some parts of the logfile but i guess it is a dovecot/outlook-problem if you enable SPA in outlook 2003 you MUST support NTLM auth outlook = 2007 can also use CRAM-MD5 so consider TLS/SSL and do NOT activate SPA in Outlook signature.asc Description: OpenPGP digital signature
Re: Outlook 2003 Client SASL Login Problem?
On 1/30/2012 7:47 AM, James Seymour wrote: Hi All, Just upgraded our mailserver. Thought I had everything set the same as I did with the old one. Nonetheless, of all the people who *can't* send email, it would have to be the President of the company. I do have broken_sasl_auth_clients = yes. Postfix version is 2.7.0, running on an Ubuntu 10.04.3 LTS. Dovecot is version 1.2.9. Other SASL parameters from postconf -n ... smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot Relevant master.cf config smtps inet n - - - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/smtps The only difference between the old master.cf and the new is the addition of the smtpd_client_restrictions line and the syslog_name line. The Outlook 2007 client I used to test Outlook functionality with the new server works fine. The Outlook 2003 client acts like it's not logging in. I verified it *is* set to login to SMTPS using the same login information as the POP3S login (which works fine). I even manually configured-in the user's logname and password separately, to no avail. Google searches thus far have not been helpful. Thanks, Jim Are others able to use SASL? Are they using the smtps service? Please show all logging when the client tries to send mail, from connect to disconnect and everything in between. Please show postconf -n output. -- Noel Jones
Re: Outlook 2003 Client SASL Login Problem?
James Seymour: Hi All, Just upgraded our mailserver. Thought I had everything set the same as I did with the old one. Nonetheless, of all the people who *can't* send email, it would have to be the President of the company. Have you compared the SMTP server EHLO replies (with openssl s_client)? Wietse
Re: Outlook 2003 Client SASL Login Problem?
On Mon, 30 Jan 2012 14:51:51 +0100
Reindl Harald h.rei...@thelounge.net wrote:
[snip]
at least show some parts of the logfile
Very well. Not much to see...
Jan 29 20:42:26 mail postfix/smtps/smtpd[7781]: connect from
c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106] Jan 29 20:42:27 mail
postfix/smtps/smtpd[7781]: NOQUEUE: reject: RCPT from
c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]: 554 5.7.1
c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]: Client host
rejected: Access denied; from=elided
to=elided proto=ESMTP helo=cswin0035 Jan 29
20:42:32 mail postfix/smtps/smtpd[7781]: disconnect from
c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]
but i guess it is a dovecot/outlook-problem
if you enable SPA in outlook 2003 ...
[snip]
It is not enabled.
On Mon, 30 Jan 2012 07:57:27 -0600
Noel Jones njo...@megan.vbhcs.org wrote:
[snip]
Are others able to use SASL? Are they using the smtps service?
Yes and yes.
Please show all logging when the client tries to send mail, from
connect to disconnect and everything in between.
Above.
Please show postconf -n output.
As you wish...
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
body_checks = pcre:/etc/postfix/body_checks
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = mail/inbox
inet_interfaces = all
mailbox_size_limit = 25600
masquerade_domains = elided
message_size_limit = 2048
mydestination = elided
myhostname = mail
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
recipient_delimiter = +
relayhost = elided
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_sender,reject_unknown_sender_domain,check_client_access
hash:/etc/postfix/client_checks,permit_sasl_authenticated,
reject_unauth_destination,reject
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
smtpd_tls_cert_file = /etc/ssl/certs/server.crt
smtpd_tls_key_file = /etc/ssl/private/myserver.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
soft_bounce = no
Thanks,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at http://jimsun.LinxNet.com/contact/scform.php.
Re: Outlook 2003 Client SASL Login Problem?
On Mon, 30 Jan 2012 09:08:55 -0500 (EST) Wietse Venema wie...@porcupine.org wrote: [snip] Have you compared the SMTP server EHLO replies (with openssl s_client)? No. That'd be difficult, tho not impossible, to do at this point, as the old server is up in storage. But this is certainly an Outlook 2003 -specific problem. Claws-Mail works fine, Thunderbird works fine, and Outlook 2007 works fine. All were tested against both submission and smtps. Thanks, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at http://jimsun.LinxNet.com/contact/scform.php.
Re: Outlook 2003 Client SASL Login Problem?
Am 30.01.2012 15:16, schrieb James Seymour: On Mon, 30 Jan 2012 14:51:51 +0100 Reindl Harald h.rei...@thelounge.net wrote: [snip] at least show some parts of the logfile Very well. Not much to see... Jan 29 20:42:26 mail postfix/smtps/smtpd[7781]: connect from c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106] Jan 29 20:42:27 mail postfix/smtps/smtpd[7781]: NOQUEUE: reject: RCPT from c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]: 554 5.7.1 c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]: Client host rejected: Access denied; from=elided to=elided proto=ESMTP helo=cswin0035 Jan 29 20:42:32 mail postfix/smtps/smtpd[7781]: disconnect from c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106] enough to see what happens or not! if there is no SASL attempt if you get connect followed directly by NOQUEUE the was no attempt verify this with | grep -i sasl | grep 68.43.238.106 to your logfile postfix will log a sasl login (also if it has failed): Jan 30 15:14:13 mail postfix/smtpd[21979]: 941D791: client=chello084112016179.9.11.vie.surfer.at[84.112.16.179], sasl_method=CRAM-MD5, sasl_username=* signature.asc Description: OpenPGP digital signature
RE: Indiscriminate maildir processing
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. Thanks, Eric
Re: Outlook 2003 Client SASL Login Problem?
On 1/30/2012 8:16 AM, James Seymour wrote: On Mon, 30 Jan 2012 14:51:51 +0100 Reindl Harald h.rei...@thelounge.net wrote: [snip] at least show some parts of the logfile Very well. Not much to see... Jan 29 20:42:26 mail postfix/smtps/smtpd[7781]: connect from c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106] Jan 29 20:42:27 mail postfix/smtps/smtpd[7781]: NOQUEUE: reject: RCPT from c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]: 554 5.7.1 c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]: Client host rejected: Access denied; from=elided to=elided proto=ESMTP helo=cswin0035 Jan 29 20:42:32 mail postfix/smtps/smtpd[7781]: disconnect from c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106] If the client attempts SASL, postfix will log either success or failure. Looks as if the client didn't even try. Maybe client didn't like any of the AUTH methods offered. Now would be a good time to connect to postfix/smtps with openssl s_client and see what AUTH mechanisms are being offered. I'm pretty sure Outlook 2003 needs either PLAIN or LOGIN (and no reason to not offer both). Please show postconf -n output. Thanks, no glaring errors here. -- Noel Jones
Re: Indiscriminate maildir processing
On 1/30/2012 9:10 AM, Eric Chandler wrote: 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 Creating wildcard users is more complicated. You can easily wildcard virtual domains with virtual_mailbox_domains = static:all but wildcarding virtual users is trickier since you can't use $N substitution in virtual_mailbox_maps. I expect you could use a *sql map for the mailbox maps and structure your query so it returns an answer for every user, but I can't help with that. imap in as whatever userid they want (another area for me to figure out - passwordless-imapd) and see those emails. dovecot master user feature, or a sql query in the auth backend that uses the same password for everybody. -- Noel Jones
Re: Outlook 2003 Client SASL Login Problem?
On Mon, 30 Jan 2012 09:21:36 -0600 Noel Jones njo...@megan.vbhcs.org wrote: [snip] If the client attempts SASL, postfix will log either success or failure. Looks as if the client didn't even try. Exactly. And that should've been my clue that the mechanism(s) offered weren't to the client's liking. Wietse picked up on it, right off, tho. But I kept screwing-around, looking elsewhere, until you also suggested... Maybe client didn't like any of the AUTH methods offered. Now would be a good time to connect to postfix/smtps with openssl s_client and see what AUTH mechanisms are being offered. I'm pretty sure Outlook 2003 needs either PLAIN or LOGIN (and no reason to not offer both). [snip] LOGIN was what it wanted. PLAIN was all that was being offered. Changed dovecot.com, restarted dovecot and postfix, and all's well. Thanks for your help, everybody! Regards, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at http://jimsun.LinxNet.com/contact/scform.php.
Re: Queue directories on faster media?
On Mon, Jan 30, 2012 at 01:09:29AM -0800, Ori Bani wrote: On Mon, Jan 30, 2012 at 12:42 AM, Ralf Hildebrandt ralf.hildebra...@charite.de wrote: * Ori Bani orib...@gmail.com: I'm curious to get feedback on the idea of mounting all the postfix queue directories on a faster media (SSD drive in this case). In my case, I have virtual maildirs under /var/spool/postfix and those would be relocated to elsewhere (onto slower normal media) because the faster (SSD) media isn't in a RAID configuration (slower media is). Why are you storing maildirs in the queue directory? I think it is a legacy thing from a very old how-to. Having recently written a Postfix howto, I reviewed quite a few others in the process. With few exceptions I found that they were written by people with a poor understanding of Postfix. This was especially true of the old, unmaintained howto documents. Note it's for virtual accounts, so no /home directories. A virtual user should have a $HOME, but perhaps that is not what you're talking about. In my own system I happen to use virtual_mailbox_base = /home because that filesystem has the most room for storage. What's the more standard place to put them if I may ask? There is no standard, as shown by the default postconf(5) value of $virtual_mailbox_base. However there is the official Postfix VIRTUAL_README.html#virtual_mailbox document, which uses this: virtual_mailbox_base = /var/mail/vhosts As hinted above, I suggest sticking with the official Postfix documentation. Look at third-party howtos for ideas, but you shouldn't rely on them for exact guidance. When their ideas don't mesh with what is in Postfix documentation, consider the entire document to be of dubious quality. Does that make any sense? Is there adverse risk putting the queue directories on non-RAID fast media? Am I right to think that that's where the most performance is to be gained? Yep. Thanks. Would it be OK to put everything in /var/spool/postfix on fast media or do only some directories benefit from the speed increase? I wouldn't think it worth the trouble to try to separate actual queues from the few other files under /var/spool/postfix/. But then, I am not sure that there is an actual problem that this idea will solve. :) We here tend to want to focus on real problems. If everything is working well, don't tinker. Postfix default settings generally are good; a competently-managed system's postconf -n should typically be very short. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
RE: Indiscriminate maildir processing
Ok, I think for me the easiest way will be to simply port it out to a milter to do the job and simply discard the message. I'm very good a milter code, so that will probably allow me to do all sorts of special stuff on top of what I would eventually get out of postfix configuration magic, given the oddball task I'm trying to accomplish. Thanks for everyone's help. Eric Chandler Systems Architect -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones Sent: Monday, January 30, 2012 10:34 AM To: postfix-users@postfix.org Subject: Re: Indiscriminate maildir processing On 1/30/2012 9:10 AM, Eric Chandler wrote: 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 Creating wildcard users is more complicated. You can easily wildcard virtual domains with virtual_mailbox_domains = static:all but wildcarding virtual users is trickier since you can't use $N substitution in virtual_mailbox_maps. I expect you could use a *sql map for the mailbox maps and structure your query so it returns an answer for every user, but I can't help with that. imap in as whatever userid they want (another area for me to figure out - passwordless-imapd) and see those emails. dovecot master user feature, or a sql query in the auth backend that uses the same password for everybody. -- Noel Jones
Re: Queue directories on faster media?
On 30 January 2012 12:49, /dev/rob0 r...@gmx.co.uk wrote: On Mon, Jan 30, 2012 at 01:09:29AM -0800, Ori Bani wrote: On Mon, Jan 30, 2012 at 12:42 AM, Ralf Hildebrandt ralf.hildebra...@charite.de wrote: * Ori Bani orib...@gmail.com: I'm curious to get feedback on the idea of mounting all the postfix queue directories on a faster media (SSD drive in this case). In my case, I have virtual maildirs under /var/spool/postfix and those would be relocated to elsewhere (onto slower normal media) because the faster (SSD) media isn't in a RAID configuration (slower media is). Why are you storing maildirs in the queue directory? I think it is a legacy thing from a very old how-to. Having recently written a Postfix howto, I reviewed quite a few URL please? :) Simon
Re: Queue directories on faster media?
On Sun, Jan 29, 2012 at 11:47:39PM -0800, Ori Bani wrote: I'm curious to get feedback on the idea of mounting all the postfix queue directories on a faster media (SSD drive in this case). The answer depends on your real goals. Mounting the spool on an SSD is only your real goal if you're are a compulsive tinkerer. Otherwise, you're trying to solve some problem that's motivating this question, so state that instead. In my case, I have virtual maildirs under /var/spool/postfix This is a bad idea. The /var/spool/postfix directory is just for the Postfix queue (messages in transit). Do not deliver mail there. Ideally deliver mail into a separate file-system that does not compete for space with the Postfix queue. Does that make any sense? Not without a reason to consider SSD. Do however avoid using /var/spool/postfix for user maildirs, that's a mistake. -- Viktor.
Re: Behavior of postscreen_access_list = static:retry
On Mon, Jan 30, 2012 at 09:03:39PM +, Mark Alan wrote: Regarding the config option: postscreen_access_list = static:retry Where is retry documented as a valid access list keyword? 3) the similar syntax of 'transport_maps = static:retry' The transport table is not access(5) table, and retry is a transport, not an access keyword. Shouldn't: postconf -e 'postscreen_access_list = static:retry' ; postfix reload immediately make postscreen defer all incoming email? It should probably cause postscreen to log warnings about misconfiguration. Is there any other way to make the postscreen/postfix combination temporarily defer all incoming emails with '450 4.3.2 Service currently unavailable' (in order to give us some time to migrate the postfix server to some other IP) ? The documentation for the postscreen_access_list parameter. -- Viktor.
Re: Success DSNs From Come to Postmaster
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. 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. 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. Wietse
Re: Mail stuck (Connection Timed-Out)
On 1/30/2012 5:07 PM, Gonzo Fernandez wrote: Hi All, My relay servers have mail being received but unable to send. When I type mailq I see: Delivery temporarily suspended….Connection timed out. I also noticed this line: Tarpitting active for [1.2.3.4) I restarted postfix, flushed mailq and still everything is stuck. Now the mail is building up and I don't know what else to do. I'm still continuing to work on it but I figure I might as well ask the postfix team members. Can anyone help me figure this thing out please? mailq: Jan 30 13:53:27 mx-ca4-01 postfix/qmgr[26443]: BC535E8264: from=m...@example.com mailto:m...@example.com, size=805, nrcpt=1 (queue active) Jan 30 13:53:55 mx-ca4-01 postfix/qmgr[26443]: BC535E8264: to=m...@example.com mailto:m...@example.com, relay=none, delay=357647, delays=357619/28/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to example.com http://example.com[1.2.3.4]: Connection timed out) (please post in plain-text only) (please use example.com rather than real domain names. thanks) Looks as if the destination 1.2.3.4 doesn't like your server. You'll need to check with them about why. One possibility is that you've been flooding them with backscatter and they've blacklisted you for that. If that's the problem, the solution is to not accept mail you can't deliver. Or maybe you've got a spam-bot on your network that's spewing stuff they don't like. But that's just speculation... Only they know the reason. -- Noel Jones
Re: Behavior of postscreen_access_list = static:retry
On Mon, 30 Jan 2012 21:50:52 +, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Mon, Jan 30, 2012 at 09:26:42PM +, Mark Alan wrote: Is there any other way to make the postscreen/postfix combination temporarily defer all incoming emails with '450 4.3.2 Service currently unavailable' (in order to give us some time to migrate the postfix server to some other IP) ? Just turn off the SMTP listener. This functionally identical to a 4.X.X reject and saves resources on both client and server. Thank you Viktor, In this particular setup I really need to have the server answering: Don't worry, I am alive but right now I am not able to accept your email, i.e., 450 Service currently unavailable The documentation for the postscreen_access_list parameter. 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: Jan 30 23:12:36 mx postfix/postscreen[11975]: CONNECT from [74.125.82.181]:61868 Jan 30 23:12:36 mx postfix/postscreen[11975]: BLACKLISTED [74.125.82.181]:61868 Jan 30 23:12:42 mx postfix/tlsproxy[11978]: CONNECT from [74.125.82.181]:61868 Jan 30 23:12:42 mx postfix/tlsproxy[11978]: setting up TLS connection from [74.125.82.181]:61868 Jan 30 23:12:42 mx postfix/tlsproxy[11978]: Anonymous TLS connection established from [74.125.82.181]:61868: TLSv1 with cipher RC4-SHA (128/128 bits) This said, it is far simpler to turn off SMTP service. # postconf -e 'master_service_disable = inet' # postfix reload That is true. I too prefer to keep setups simpler (and near to the default configuration). But in this particular setup it does not help at making my server send, to every connection attempt, a 450 Service currently unavailable . Again, thank you Viktor for your time. M.
Re: Behavior of postscreen_access_list = static:retry
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
SASL authentication and Windows Live Mail
I'll keep this short for now in case it's a known problem but if more logs are required let me know. I've configured postfix to allow SASL authenticated users (dovecot sasl) to relay. I've tested this and confirmed it works from within Outlook 2007 and 2010. However trying the same account details from Windows Live Mail throws up a: 554 Relay Access denied error message. Is this a known problem with the Windows Live Mail client or do I need to dig deeper? Kind regards, James Day
Re: Mail stuck (Connection Timed-Out)
Hi it seems to be a layer 3 issue, according to the description I will check any firewall or router at the perimeters end. Have you checked that? Have you tried tcpdump to check if those packets are leaving the box? Thats just a thought, I hope it helps. Regards. Saludos Ing. Alfonso Alejandro Reyes Jimenez Coordinador de Seguridad - SASI E-mail: aare...@scitum.com.mx Telefono: 91507489 Movil: (044) 55 85 81 04 62 De: Gonzo Fernandez [mailto:go...@usaepay.com] Enviado: Monday, January 30, 2012 06:46 PM Para: postfix users postfix-users@postfix.org Asunto: Re: Mail stuck (Connection Timed-Out) Thank you Noel. Our server sends out copies of email confirmations to our clients and if the client decides to make a large order they end up pushing our volume up and we end up getting blocked by their mail server. I seem to be getting connection timed out on a lot of the hosts. I even try to telnet to ip and port 25 but it keeps timing out. I used grep to search in /var/log/maillog and I got this. Any ideas? [root@mx-server ~]# cat /var/log/maillog | grep B0847E8491 Jan 30 08:44:38 mx-server postfix/cleanup[24478]: B0847E8491: message-id=20120130164438.B0847E8491@mxser...@example.com Jan 30 08:44:38 mx-server postfix/qmgr[16186]: B0847E8491: from=, size=3456, nrcpt=1 (queue active) Jan 30 08:44:38 mx-server postfix/bounce[24473]: 2604BE84D6: sender non-delivery notification: B0847E8491 Jan 30 08:45:01 mx-server postfix/smtp[24278]: B0847E8491: to=m...@example.com, relay=none, delay=23, delays=0.03/0/23/0, dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed out) Jan 30 09:08:09 mx-server postfix/qmgr[16186]: B0847E8491: from=, size=3456, nrcpt=1 (queue active) Jan 30 09:08:32 mx-server postfix/smtp[24522]: B0847E8491: to=m...@example.com, relay=none, delay=1434, delays=1411/0/23/0, dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed out) Jan 30 09:41:31 mx-server postfix/qmgr[16186]: B0847E8491: from=, size=3456, nrcpt=1 (queue active) Jan 30 09:41:52 mx-server postfix/smtp[24793]: B0847E8491: to=m...@example.com, relay=none, delay=3434, delays=3412/0.1/21/0, dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed out) Jan 30 10:48:09 mx-server postfix/qmgr[16186]: B0847E8491: from=, size=3456, nrcpt=1 (queue active) Jan 30 10:48:15 mx-server postfix/smtp[25097]: B0847E8491: to=m...@example.com, relay=none, delay=7417, delays=7411/0.06/5.9/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=example.com type=A: Host not found, try again) Jan 30 12:11:30 mx-server postfix/qmgr[16186]: B0847E8491: from=, size=3456, nrcpt=1 (queue active) Jan 30 12:11:53 mx-server postfix/smtp[25539]: B0847E8491: to=m...@example.com, relay=none, delay=12435, delays=12411/0.05/23/0, dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed out) Jan 30 13:22:45 mx-server postfix/qmgr[26236]: B0847E8491: from=, size=3456, nrcpt=1 (queue active) Jan 30 13:23:12 mx-server postfix/smtp[26261]: B0847E8491: to=m...@example.com, relay=none, delay=16713, delays=16687/0.56/26/0, dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed out) Jan 30 13:53:27 mx-server postfix/qmgr[26443]: B0847E8491: from=, size=3456, nrcpt=1 (queue active) Jan 30 13:53:55 mx-server postfix/smtp[26593]: B0847E8491: to=m...@example.com, relay=none, delay=18556, delays=18529/6.5/21/0, dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed out) Jan 30 15:14:54 mx-server postfix/qmgr[27600]: B0847E8491: from=, size=3456, nrcpt=1 (queue active) Jan 30 15:15:21 mx-server postfix/smtp[27790]: B0847E8491: to=m...@example.com, relay=none, delay=23443, delays=23416/5.9/21/0, dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed out) [root@mx-server ~]# telnet 1.2.3.4 25 Trying 1.2.3.4... telnet: connect to address 1.2.3.4: Connection timed out telnet: Unable to connect to remote host: Connection timed out Gonzo Fernandez On Jan 30, 2012, at 3:36 PM, Noel Jones wrote: On 1/30/2012 5:07 PM, Gonzo Fernandez wrote: Hi All, My relay servers have mail being received but unable to send. When I type mailq I see: Delivery temporarily suspended….Connection timed out. I also noticed this line: Tarpitting active for [1.2.3.4) I restarted postfix, flushed mailq and still everything is stuck. Now the mail is building up and I don't know what else to do. I'm still continuing to work on it but I figure I might as well ask the postfix team members. Can anyone help me figure this thing out please?
Re: SASL authentication and Windows Live Mail
On Tue, 31 Jan 2012 00:30:33 + James Day james@ontraq.com wrote: [snip] ... trying the same account details from Windows Live Mail throws up a: 554 Relay Access denied error message. [snip] IIRC, Relay access denied is a symptom of a non-SSL attempted connection/login when disable_plaintext_auth = yes in dovecot.conf. Regards, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at http://jimsun.LinxNet.com/contact/scform.php.
Re: SASL authentication and Windows Live Mail
On 1/30/2012 9:32 PM, Jim Seymour wrote: On Tue, 31 Jan 2012 00:30:33 + James Day james@ontraq.com wrote: [snip] ... trying the same account details from Windows Live Mail throws up a: 554 Relay Access denied error message. [snip] IIRC, Relay access denied is a symptom of a non-SSL attempted connection/login when disable_plaintext_auth = yes in dovecot.conf. The error message means the mail was rejected by reject_unauth_destination, and that means the client didn't authenticate (or tried and failed). If AUTH was tried and failed, it will be noted in the postfix and dovecot logs. If no failures are logged, AUTH wasn't attempted. This may or may not have anything to do with SSL/TLS. Another good guess is that dovecot needs to offer LOGIN and/or PLAIN mechanisms. But we're just guessing here. We need more details of the connection and configuration to give more concrete advice. http://www.postfix.org/DEBUG_README.html#mail -- Noel Jones
Re: Mail stuck (Connection Timed-Out)
On 1/30/2012 6:46 PM, Gonzo Fernandez wrote: Thank you Noel. Our server sends out copies of email confirmations to our clients and if the client decides to make a large order they end up pushing our volume up and we end up getting blocked by their mail server. I seem to be getting connection timed out on a lot of the hosts. I even try to telnet to ip and port 25 but it keeps timing out. I used grep to search in /var/log/maillog and I got this. Any ideas? This isn't a postfix problem. If you can't telnet to any client port 25, then you have a connectivity problem; maybe your ISP is blocking that port, or some firewall has been misconfigured. Contact your networking team or your ISP. If you can't telnet to this one destination port 25, they're blocking you. You'll need to contact them to get this resolved. Good luck. -- Noel Jones
Re: Mail stuck (Connection Timed-Out)
On 1/30/2012 10:30 PM, Noel Jones wrote: On 1/30/2012 6:46 PM, Gonzo Fernandez wrote: Thank you Noel. Our server sends out copies of email confirmations to our clients and if the client decides to make a large order they end up pushing our volume up and we end up getting blocked by their mail server. I seem to be getting connection timed out on a lot of the hosts. I even try to telnet to ip and port 25 but it keeps timing out. I used grep to search in /var/log/maillog and I got this. Any ideas? This isn't a postfix problem. If you can't telnet to any client port 25, then you have a connectivity problem; maybe your ISP is blocking that port, or some firewall has been misconfigured. Contact your networking team or your ISP. If you can't telnet to this one destination port 25, they're blocking you. You'll need to contact them to get this resolved. Good luck. -- Noel Jones If the destination can't handle the load you're sending it, you can slow postfix down. Details here: http://www.postfix.org/QSHAPE_README.html#active_congestion Of course, this won't help until they stop blocking you. -- Noel Jones
Re: Mail stuck (Connection Timed-Out)
I was reading about Defferred queue full of dictionary attack bounces which I think might be an issue here. So i performed a qshape analysis and I got this: command: qshape deferred | head T 5 10 20 40 80 160 320 640 1280 1280+ TOTAL 583 0 0 0 0 0 1 8 47 25 502 adbaa.org 214 0 0 0 0 0 0 0 00 214 onramp.bz 191 0 0 0 0 0 1 6 26 10 148 unitedimagingpartners.com 62 0 0 0 0 0 0 0 7550 mmvacations.com 26 0 0 0 0 0 0 0 1025 fishwindowcleaning.com 12 0 0 0 0 0 0 0 31 8 warrensouth.com 5 0 0 0 0 0 0 0 10 4 ecodiscoverypark.com 5 0 0 0 0 0 0 1 00 4 pfg.com 4 0 0 0 0 0 0 0 12 1 Luckily the active and and incoming queues aren't showing any signs of backscatter. I'm going to be checking firewall tomorrow to see if there's an issue there. Thanks for your help. Gonzo Fernandez On Jan 30, 2012, at 9:09 PM, Noel Jones wrote: On 1/30/2012 10:30 PM, Noel Jones wrote: On 1/30/2012 6:46 PM, Gonzo Fernandez wrote: Thank you Noel. Our server sends out copies of email confirmations to our clients and if the client decides to make a large order they end up pushing our volume up and we end up getting blocked by their mail server. I seem to be getting connection timed out on a lot of the hosts. I even try to telnet to ip and port 25 but it keeps timing out. I used grep to search in /var/log/maillog and I got this. Any ideas? This isn't a postfix problem. If you can't telnet to any client port 25, then you have a connectivity problem; maybe your ISP is blocking that port, or some firewall has been misconfigured. Contact your networking team or your ISP. If you can't telnet to this one destination port 25, they're blocking you. You'll need to contact them to get this resolved. Good luck. -- Noel Jones If the destination can't handle the load you're sending it, you can slow postfix down. Details here: http://www.postfix.org/QSHAPE_README.html#active_congestion Of course, this won't help until they stop blocking you. -- Noel Jones
RE: SASL authentication and Windows Live Mail
Thanks for your input guys. As I suspected I need to dig a bit deeper. Here is the relevant portion of my mail log using Windows Live Mail to send: [...snip] Jan 31 07:27:51 vps03 postfix/smtpd[3923]: connect from unknown[IP_REMOVED] Jan 31 07:27:51 vps03 postfix/smtpd[3923]: NOQUEUE: reject: RCPT from unknown[IP_REMOVED]: 554 5.7.1 user@remotedomain: Relay access denied; from=dovecotuser@trusteddomain to=user@remotedomain proto=ESMTP helo=HOSTNAME Jan 31 07:27:51 vps03 postfix/smtpd[3923]: disconnect from unknown[IP_REMOVED] Jan 31 07:27:54 vps03 dovecot: imap-login: Login: user= dovecotuser@trusteddomain , method=PLAIN, rip=IP_REMOVED, lip=IP_REMOVED, TLS Jan 31 07:27:54 vps03 dovecot: IMAP(dovecotuser@trusteddomain): Disconnected: Logged out bytes=712/6487 [...snip] It seems to me that authentication isn't attempted until after the attempt to send fails. ...HOLD THE PRESS I added the LOGIN auth mechanism to my dovecot.conf and reloaded the service, the above was my first attempt to send this message again after doing so (which failed). Something must have taken some time to propagate because as I was typing this message the client connected again and sent successfully. Looks as though you were spot on Noel. Here is the log snipped for the successful send: Jan 31 07:35:47 vps03 postfix/smtpd[4049]: connect from unknown[IP_REMOVED] Jan 31 07:35:47 vps03 postfix/smtpd[4049]: BC1A1152601B2: client=unknown[IP_REMOVED], sasl_method=LOGIN, sasl_username= dovecotuser@trusteddomain Jan 31 07:35:48 vps03 postfix/cleanup[4052]: BC1A1152601B2: message-id=FDCB00758C7446F28A755733616C9E39@remotedomain Jan 31 07:35:48 vps03 postfix/qmgr[26598]: BC1A1152601B2: from= dovecotuser@trusteddomain , size=1261, nrcpt=1 (queue active) Jan 31 07:35:48 vps03 postfix/smtpd[4049]: disconnect from unknown[IP_REMOVED] Jan 31 07:35:48 vps03 dovecot: imap-login: Login: user=dovecotuser@trusteddomain, method=PLAIN, rip= IP_REMOVED, lip= IP_REMOVED, TLS Jan 31 07:35:48 vps03 postfix/smtp[4053]: BC1A1152601B2: to=user@remotedomain, relay=remote_mx_address[IP_REMOVED]:25, delay=0.79, delays=0.27/0/0.14/0.37, dsn=2.6.0, status=sent (250 2.6.0 FDCB00758C7446F28A755733616C9E39@remotedomain Queued mail for delivery) Jan 31 07:35:48 vps03 postfix/qmgr[26598]: BC1A1152601B2: removed 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. Kind regards, James Day -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones Sent: 31 January 2012 04:22 To: postfix-users@postfix.org Subject: Re: SASL authentication and Windows Live Mail On 1/30/2012 9:32 PM, Jim Seymour wrote: On Tue, 31 Jan 2012 00:30:33 + James Day james@ontraq.com wrote: [snip] ... trying the same account details from Windows Live Mail throws up a: 554 Relay Access denied error message. [snip] IIRC, Relay access denied is a symptom of a non-SSL attempted connection/login when disable_plaintext_auth = yes in dovecot.conf. The error message means the mail was rejected by reject_unauth_destination, and that means the client didn't authenticate (or tried and failed). If AUTH was tried and failed, it will be noted in the postfix and dovecot logs. If no failures are logged, AUTH wasn't attempted. This may or may not have anything to do with SSL/TLS. Another good guess is that dovecot needs to offer LOGIN and/or PLAIN mechanisms. But we're just guessing here. We need more details of the connection and configuration to give more concrete advice. http://www.postfix.org/DEBUG_README.html#mail -- Noel Jones
