Lost connection
Hi,
It seems my service provider's network has been blocked by Hotmail.
After many correspondences, I was mailed by Hotmail that the issue was
cleared for one IP, however I gave them wrong one. So, I edited main.cf
and replaced inet_interfaces = all with inet_interfaces = the.ip.I.gave,
and restarted postfix. However, I'm now getting (connect to
127.0.0.1[127.0.0.1]:10024: Connection refused). I did a grep in the
logs and the output was Feb 27 09:48:17 server postfix/smtp[11674]:
3C361768793: to=to...@ozses.net, relay=127.0.0.1[127.0.0.1]:10024,
delay=0.04, delays=0.03/0.01/0/0, dsn=4.4.2, status=deferred (lost
connection with 127.0.0.1[127.0.0.1] while receiving the initial server
greeting)
My postconf -n:
alias_database = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
append_dot_mydomain = no
biff = no
body_checks = regexp:/etc/postfix/body_checks
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = amavis:[127.0.0.1]:10024
header_checks = regexp:/etc/postfix/header_checks
html_directory = /usr/share/doc/postfix/html
inet_interfaces = 5.9.235.23
mailbox_size_limit = 0
message_size_limit = 0
mime_header_checks = regexp:/etc/postfix/mime_header_checks
mydestination = server.ommuse.com, localhost, localhost.localdomain
myhostname = server.ommuse.com
mynetworks = 127.0.0.0/8 [::1]/128
myorigin = /etc/mailname
nested_header_checks = regexp:/etc/postfix/nested_header_checks
owner_request_special = no
proxy_read_maps = $local_recipient_maps $mydestination
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps
$virtual_mailbox_domains $relay_recipient_maps $relay_domains
$canonical_maps $sender_canonical_maps $recipient_canonical_maps
$relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps
readme_directory = /usr/share/doc/postfix
receive_override_options = no_address_mappings
recipient_delimiter = +
relay_domains = mysql:/etc/postfix/mysql-virtual_relaydomains.cf
relay_recipient_maps =
mysql:/etc/postfix/mysql-virtual_relayrecipientmaps.cf
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_message_rate_limit = 100
smtpd_client_restrictions = check_client_access
mysql:/etc/postfix/mysql-virtual_client.cf
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, check_recipient_access
mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = check_sender_access
mysql:/etc/postfix/mysql-virtual_sender.cf
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
virtual_alias_domains =
virtual_alias_maps =
proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf,
proxy:mysql:/etc/postfix/mysql-virtual_email2email.cf,
hash:/var/lib/mailman/data/virtual-mailman
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/vmail
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_transport = dovecot
virtual_uid_maps = static:5000
What to do?
Regards,
Re: Running namecache service on postfix server?
On 02/27/2013 01:21 AM, Viktor Dukhovni wrote: On Tue, Feb 26, 2013 at 08:57:51PM -0500, b...@bitrate.net wrote: When Postfix support for DANE (RFC 6698) is introduced, there will be a requirement to operate a local nameserver that is DNSSEC aware on any machine that wants to take advantage of peer certificate details published via DNSSEC to scalably deliver verified TLS email to many sites without the overhead of local per-site configuration. Why must the nameserver be local? Very easy. If the server is *not* local, you should not trust the AD-bit in its responses without authenticating the nameserver via something like TSIG. I am not going to bloat Postfix with TSIG support, this would be really silly, when a local cache can take care of that. A fortiori I am not going to bloat Postfix with its own RRSIG-validing DNSSEC support. Therefore, Postfix support for DANE will be sensibly predicated on a *local* DNSSEC verifying cache. Unless we add code to check that the resolv.conf in fact only contains local servers (I am disinclined to do that also), you will be able to break the warranty and trust the AD-bit from non-local nameservers by telling Postfix to enable DANE even with a resolv.conf that points to remote servers. If you do that, you only have yourself to blame when lack of TSIG, ... makes it possible to MITM your server's ostensibly secure email deliveries. Ah, thought there was a MITM lurking around the corner if DNS server not local. Thank you for the details. All, I can say (and will say in the documentation) is that you've been warned. Since the fields of _res other than _res.options are not generally documented, there is no reasonable way to perform a run-time check that the configured nameservers consist of just 127.0.0.1 and/or ::1. I had to add listen on the server's IP addresses. Some services require that. So the plan is to document the warning clearly in all the relevant documents, and leave the rest to the administrator's ability to restrain himself from folly. Perhaps postfix check could generate a warning if DANE is enabled and non-local nameservers are found in /etc/resolv.conf (or and/or its chroot-jail version). My main DNS server is no longer chrooted, as selinux is claimed to be better protection. And people better at OS security than I have vetted it. But with this, I realize that I have had to turn off selinux on my mail server. Or rather I have not found selinux assistance for all the services needed on a mail server that 'does it all'. Therefore got to add chroot for bind.
Re: Running namecache service on postfix server?
Viktor Dukhovni: Perhaps postfix check could generate a warning if DANE is enabled and non-local nameservers are found in /etc/resolv.conf (or and/or its chroot-jail version). I think it would be entirely reasonable to share a DNS cache among multiple systems within the same trusted perimeter. One DNS server per host in a farm of mail servers may not be practical. Wietse
Re: Lost connection
Muzaffer Tolga ?zses: Hi, It seems my service provider's network has been blocked by Hotmail. After many correspondences, I was mailed by Hotmail that the issue was cleared for one IP, however I gave them wrong one. So, I edited main.cf and replaced inet_interfaces = all with inet_interfaces = the.ip.I.gave, and restarted postfix. However, I'm now getting (connect to 127.0.0.1[127.0.0.1]:10024: Connection refused). I did a grep in the logs and the output was Feb 27 09:48:17 server postfix/smtp[11674]: 3C361768793: to=to...@ozses.net, relay=127.0.0.1[127.0.0.1]:10024, delay=0.04, delays=0.03/0.01/0/0, dsn=4.4.2, status=deferred (lost connection with 127.0.0.1[127.0.0.1] while receiving the initial server greeting) http://www.postfix.org/DEBUG_README.html#logging When Postfix does not receive or deliver mail, the first order of business is to look for errors that prevent Postfix from working properly: % egrep '(warning|error|fatal|panic):' /some/log/file | more Note: the most important message is near the BEGINNING of the output. Error messages that come later are less useful. The nature of each problem is indicated as follows: * panic indicates a problem in the software itself that only a programmer can fix. Postfix cannot proceed until this is fixed. * fatal is the result of missing files, incorrect permissions, incorrect configuration file settings that you can fix. Postfix cannot proceed until this is fixed. * error reports an error condition. For safety reasons, a Postfix process will terminate when more than 13 of these happen. * warning indicates a non-fatal error. These are problems that you may not be able to fix (such as a broken DNS server elsewhere on the network) but may also indicate local configuration errors that could become a problem later.
Re: Lost connection
On 02/27/2013 02:04 PM, Wietse Venema wrote: egrep '(warning|error|fatal|panic): Unfortunately, all I get was these and similar, and the most recent one is from 2 days ago. egrep '(warning|error|fatal|panic):' /var/log/mail.log | head Feb 25 01:56:26 server postfix/smtpd[10324]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:28 server postfix/smtpd[10353]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:30 server postfix/smtpd[10354]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:32 server postfix/smtpd[10355]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:34 server postfix/smtpd[10356]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:36 server postfix/smtpd[10357]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:38 server postfix/smtpd[10358]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:40 server postfix/smtpd[10359]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:41 server postfix/smtpd[10360]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:42 server postfix/smtpd[10361]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Regards,
Re: Lost connection
Am 27.02.2013 13:14, schrieb Muzaffer Tolga Özses: On 02/27/2013 02:04 PM, Wietse Venema wrote: egrep '(warning|error|fatal|panic): Unfortunately, all I get was these and similar, and the most recent one is from 2 days ago. egrep '(warning|error|fatal|panic):' /var/log/mail.log | head Feb 25 01:56:26 server postfix/smtpd[10324]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:28 server postfix/smtpd[10353]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 well, is 213.165.85.151 the IP of a customer? has someone troubles? if not - ignore it because it's mostly some bad guy trying tu misuse your machine and looking at the short interval it seems that it is the case signature.asc Description: OpenPGP digital signature
Re: Lost connection
On 27 February 2013 13:16, Reindl Harald h.rei...@thelounge.net wrote: Am 27.02.2013 13:14, schrieb Muzaffer Tolga Özses: On 02/27/2013 02:04 PM, Wietse Venema wrote: egrep '(warning|error|fatal|panic): Unfortunately, all I get was these and similar, and the most recent one is from 2 days ago. egrep '(warning|error|fatal|panic):' /var/log/mail.log | head Feb 25 01:56:26 server postfix/smtpd[10324]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Feb 25 01:56:28 server postfix/smtpd[10353]: warning: s15313432.onlinehome-server.info[213.165.85.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 well, is 213.165.85.151 the IP of a customer? has someone troubles? if not - ignore it because it's mostly some bad guy trying tu misuse your machine and looking at the short interval it seems that it is the case UGFzc3dvcmQ6 is the hash for password. I have hundred of attempts like this on a daily basis. But as Wietse will point out, this is not his problem. Simon
Getmail
i am using virtual users and domains, where i have 2 virtual domains and few users in both. i would like getmail to fetch email via pop3 from our hosting servers and copy it directly to our Maildir Base, here is the path of my virtual users mailbox base. /maildb/vmail/$domain/$user/Maildir is there anyone can guide me with the getmail settings. Thanks, MYK
Re: Getmail
Am 27.02.2013 13:51, schrieb Muhammad Yousuf Khan: i am using virtual users and domains, where i have 2 virtual domains and few users in both. i would like getmail to fetch email via pop3 from our hosting servers and copy it directly to our Maildir Base, here is the path of my virtual users mailbox base. /maildb/vmail/$domain/$user/Maildir is there anyone can guide me with the getmail settings. Thanks, MYK http://pyropus.ca/software/getmail/getmailrc-examples Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: Lost connection
Wietse Venema: and restarted postfix. However, I'm now getting (connect to 127.0.0.1[127.0.0.1]:10024: Connection refused). I did a grep in the logs and the output was Feb 27 09:48:17 server postfix/smtp[11674]: 3C361768793: to=to...@ozses.net, relay=127.0.0.1[127.0.0.1]:10024, delay=0.04, delays=0.03/0.01/0/0, dsn=4.4.2, status=deferred (lost connection with 127.0.0.1[127.0.0.1] while receiving the initial server greeting) You have a service on 127.0.0.1 port 10024 that isn't receiving mail as it should. If that is not a Postfix service, then my trouble shooting egrep pattern will not apply. Wietse
smtpd_recipient_limit and the corresponding error pop up on secure smtp
Hi, The number of phishing or otherwise compromised accounts is needing an automation to manage it. Last night the spammers waited until the evening and simultaneously used 3 compromised accounts to send spam over secure smtp. A nagios alert on number of messages in the queue was our only alarm, and in only a couple of hours the reputation of the server and domain is damaged for awhile (both in and out). I added smtpd_recipient_limit=20 to the options for secured SMTP. The error it produced when tested (with Thunderbird) is confusing: The size of the message you are trying to send exceeds a temporary size limit of the server. The message was not sent; try to reduce the message size or wait some time and try again. The server responded: 4.5.3 Error: too many recipients. If the user patiently reads to the end, the last statement is the only thing they need to know. However, the previous statements are wrong and misleading. How can this error be made better?
Re: Lost connection
On 02/27/2013 04:04 PM, Wietse Venema wrote: Wietse Venema: and restarted postfix. However, I'm now getting (connect to 127.0.0.1[127.0.0.1]:10024: Connection refused). I did a grep in the logs and the output was Feb 27 09:48:17 server postfix/smtp[11674]: 3C361768793: to=to...@ozses.net, relay=127.0.0.1[127.0.0.1]:10024, delay=0.04, delays=0.03/0.01/0/0, dsn=4.4.2, status=deferred (lost connection with 127.0.0.1[127.0.0.1] while receiving the initial server greeting) You have a service on 127.0.0.1 port 10024 that isn't receiving mail as it should. If that is not a Postfix service, then my trouble shooting egrep pattern will not apply. Wietse I had stopped amavis while trying to debug. I now started it again, and now I am getting Feb 27 16:13:51 server postfix/smtp[18445]: 71D347687A4: to=to...@ozses.net, relay=127.0.0.1[127.0.0.1]:10024, delay=0.02, delays=0/0.01/0.01/0, dsn=4.4.2, status=deferred (lost connection with 127.0.0.1[127.0.0.1] while receiving the initial server greeting) M.
Re: smtpd_recipient_limit and the corresponding error pop up on secure smtp
On Wed, Feb 27, 2013 at 10:11:08AM -0400, francis picabia wrote: Hi, The number of phishing or otherwise compromised accounts is needing an automation to manage it. Last night the spammers waited until the evening and simultaneously used 3 compromised accounts to send spam over secure smtp. A nagios alert on number of messages in the queue was our only alarm, and in only a couple of hours the reputation of the server and domain is damaged for awhile (both in and out). I added smtpd_recipient_limit=20 to the options for secured SMTP. The error it produced when tested (with Thunderbird) is confusing: The size of the message you are trying to send exceeds a temporary size limit of the server. The message was not sent; try to reduce the message size or wait some time and try again. The server responded: 4.5.3 Error: too many recipients. If the user patiently reads to the end, the last statement is the only thing they need to know. However, the previous statements are wrong and misleading. How can this error be made better? Hi Francis, The error from postfix is very clear: 4.5.3 Error: too many recipients. The remaining exposition is from Thunderbird so you may want to take this question up with their developers. Cheers, Ken
Re: smtpd_recipient_limit and the corresponding error pop up on secure smtp
Am 27.02.2013 15:11, schrieb francis picabia: The size of the message you are trying to send exceeds a temporary size limit of the server. The message was not sent; try to reduce the message size or wait some time and try again. The server responded: 4.5.3 Error: too many recipients. If the user patiently reads to the end, the last statement is the only thing they need to know. However, the previous statements are wrong and misleading. How can this error be made better? and the last statement is the only ony which comes from postfix as the server responded: indicates, so you can only patch the mail client or live with it signature.asc Description: OpenPGP digital signature
Re: Lost connection
Wietse: You have a service on 127.0.0.1 port 10024 that isn't receiving mail as it should. If that is not a Postfix service, then my trouble shooting egrep pattern will not apply. Muzaffer Tolga ?zses: I had stopped amavis while trying to debug. I now started it again, and now I am getting Feb 27 16:13:51 server postfix/smtp[18445]: 71D347687A4: to=to...@ozses.net, relay=127.0.0.1[127.0.0.1]:10024, delay=0.02, delays=0/0.01/0.01/0, dsn=4.4.2, status=deferred (lost connection with 127.0.0.1[127.0.0.1] while receiving the initial server greeting) Apparently, Amavis isn't receiving mail as it should. That is outside my area of support. Wietse
Re: Running namecache service on postfix server?
On Feb 27, 2013, at 12:58, Wietse Venema wie...@porcupine.org wrote: Viktor Dukhovni: Perhaps postfix check could generate a warning if DANE is enabled and non-local nameservers are found in /etc/resolv.conf (or and/or its chroot-jail version). I think it would be entirely reasonable to share a DNS cache among multiple systems within the same trusted perimeter. One DNS server per host in a farm of mail servers may not be practical. A local cache on each, forwarding to two or three resolvers that are nearby? Local for DNSSEC verification, nearby cache for performance reasons? Am I missing something that would make that impractical? Cya, Jona
Re: Running namecache service on postfix server?
On 02/27/2013 06:58 AM, Wietse Venema wrote: Viktor Dukhovni: Perhaps postfix check could generate a warning if DANE is enabled and non-local nameservers are found in /etc/resolv.conf (or and/or its chroot-jail version). I think it would be entirely reasonable to share a DNS cache among multiple systems within the same trusted perimeter. One DNS server per host in a farm of mail servers may not be practical. In such a case I would run IPsec between them with a policy for only DNS traffic through the tunnel. ESP encapsulation is rather cheap and assures you the traffic is going where you want it. Or if you have very good VLAN control, you could run 802.1AE, but the app space cannot tell (typically) if MACsec is working.
Re: Running namecache service on postfix server?
On 02/27/2013 09:25 AM, DTNX Postmaster wrote: On Feb 27, 2013, at 12:58, Wietse Venema wie...@porcupine.org wrote: Viktor Dukhovni: Perhaps postfix check could generate a warning if DANE is enabled and non-local nameservers are found in /etc/resolv.conf (or and/or its chroot-jail version). I think it would be entirely reasonable to share a DNS cache among multiple systems within the same trusted perimeter. One DNS server per host in a farm of mail servers may not be practical. A local cache on each, forwarding to two or three resolvers that are nearby? Local for DNSSEC verification, nearby cache for performance reasons? Am I missing something that would make that impractical? Lots of cat skinners out here.
Re: Running namecache service on postfix server?
On Wed, Feb 27, 2013 at 03:25:41PM +0100, DTNX Postmaster wrote: I think it would be entirely reasonable to share a DNS cache among multiple systems within the same trusted perimeter. One DNS server per host in a farm of mail servers may not be practical. A local cache on each, forwarding to two or three resolvers that are nearby? Local for DNSSEC verification, nearby cache for performance reasons? Am I missing something that would make that impractical? No, and that's pretty much what my original post suggests: On Tue, Feb 26, 2013 at 04:51:22PM +, Viktor Dukhovni wrote: On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote: Setting up DNSSEC on a local unbound cache that forwards all queries to an upstream server boils down to: /etc/unbound/unbound.conf server: ... trust-anchor: . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 # Forward all requests to upstream server at 192.0.2.1 forward-zone: name: . forward-addr: 192.0.2.1 As you say, one would typically add a couple of additional upstream caches: forward-addr: 192.0.2.2 forward-addr: 192.0.2.3 -- Viktor.
Re: Running namecache service on postfix server?
DTNX Postmaster: On Feb 27, 2013, at 12:58, Wietse Venema wie...@porcupine.org wrote: Viktor Dukhovni: Perhaps postfix check could generate a warning if DANE is enabled and non-local nameservers are found in /etc/resolv.conf (or and/or its chroot-jail version). I think it would be entirely reasonable to share a DNS cache among multiple systems within the same trusted perimeter. One DNS server per host in a farm of mail servers may not be practical. A local cache on each, forwarding to two or three resolvers that are nearby? Local for DNSSEC verification, nearby cache for performance reasons? Am I missing something that would make that impractical? I think it would be helpful to give examples of how secure DNS caches can be shared, instead of outright banning this. On non-trivial deployments, DNS and MAIL are managed by different people. Wietse
Re: reject empty sender address for authenticated users
* Piotr Rotter piotr.rot...@active24.pl: I want to disallow this because is rarely (probably poor mail clients) and make more difficult to automatic parsing amavis logs like this 2013-02-25T04:29:47+01:00 kurier4 amavis[20204]: (20204-10) Passed CLEAN, - u...@domain.tld, Hits: -2.56, tag=-999, tag2=5, kill=10, queued_as: 3ZDpYl5C4Tz7Cm, L/Y/0/0 Please be aware that these might be: * out of office messages * read notifications -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: smtpd_recipient_limit and the corresponding error pop up on secure smtp
On Wed, Feb 27, 2013 at 10:11:08AM -0400, francis picabia wrote: The number of phishing or otherwise compromised accounts is needing an automation to manage it. Last night the spammers waited until the evening and simultaneously used 3 compromised accounts to send spam over secure smtp. A nagios alert on number of messages in the queue was our only alarm, and in only a couple of hours the reputation of the server and domain is damaged for awhile (both in and out). You need to deploy a policy service that rate limits the total number of recipients a customer account can reach in any suitable time interval. I added smtpd_recipient_limit=20 to the options for secured SMTP. The error it produced when tested (with Thunderbird) is confusing: RFC 5321 requires support for at least 100 recipients per message. https://tools.ietf.org/html/rfc5321#section-4.5.3.1.10 If at all possible allow a single mailing at least that large in by setting the time interval long enough that it is reasonable to let users send mail to at least 100 recipients in that time. The size of the message you are trying to send exceeds a temporary size limit of the server. The message was not sent; try to reduce the message size or wait some time and try again. The server responded: 4.5.3 Error: too many recipients. Actually the Postfix error response is: 452 4.5.3 Error: too many recipients while the 452 SMTP response is potentially ambiguous, and can mean message temporary lack of storage, the 4.5.3 is unambiguous: https://tools.ietf.org/html/rfc3463#section-3.6 X.5.3 Too many recipients More recipients were specified for the message than could have been delivered by the protocol. This error should normally result in the segmentation of the message into two, the remainder of the recipients to be delivered on a subsequent delivery attempt. It is included in this list in the event that such segmentation is not possible. If the user patiently reads to the end, the last statement is the only thing they need to know. However, the previous statements are wrong and misleading. How can this error be made better? The mail user-agent needs to implement RFC 3463, and only fall back on RFC 5321 when the server does not support ENHANCEDSTATUSCODES. https://tools.ietf.org/html/rfc2034#section-3 https://tools.ietf.org/html/rfc2034#section-6 -- Viktor.
Re: Running namecache service on postfix server?
On Wed, Feb 27, 2013 at 10:20:50AM -0500, Wietse Venema wrote: I think it would be entirely reasonable to share a DNS cache among multiple systems within the same trusted perimeter. One DNS server per host in a farm of mail servers may not be practical. A local cache on each, forwarding to two or three resolvers that are nearby? Local for DNSSEC verification, nearby cache for performance reasons? Am I missing something that would make that impractical? I think it would be helpful to give examples of how secure DNS caches can be shared, instead of outright banning this. On non-trivial deployments, DNS and MAIL are managed by different people. This was the intent of my original example, I guess I did not draw sufficient attention to the: forward-zone: name: . forward-addr: 192.0.2.1 stanza at the bottom of the unbound.conf example. We'll need to provide a similar configuration example for BIND, and explain the rationale for both, so other local nameservers could also be supported by an MTA administrator who understands the requirements. -- Viktor.
Re: Running namecache service on postfix server?
On 02/27/2013 10:20 AM, Wietse Venema wrote: DTNX Postmaster: On Feb 27, 2013, at 12:58, Wietse Venema wie...@porcupine.org wrote: Viktor Dukhovni: Perhaps postfix check could generate a warning if DANE is enabled and non-local nameservers are found in /etc/resolv.conf (or and/or its chroot-jail version). I think it would be entirely reasonable to share a DNS cache among multiple systems within the same trusted perimeter. One DNS server per host in a farm of mail servers may not be practical. A local cache on each, forwarding to two or three resolvers that are nearby? Local for DNSSEC verification, nearby cache for performance reasons? Am I missing something that would make that impractical? I think it would be helpful to give examples of how secure DNS caches can be shared, instead of outright banning this. On non-trivial deployments, DNS and MAIL are managed by different people. True, but we are talking about a namecaching server here, not your standard fare for DNS support people. Or rather they are old hands at deploying caching servers where appropriate and could well supply standard templates for them. RHEL/Centos bind installs as a caching server, requiring very little in edits, though as I pointed out in an earlier message I need to add chroot since I have selinux off on the mail server (I don't think it was postfix, but rather dovecot that forced this). Also I think if I change my DNS address in ifcfg-eth0 to 127.0.0.1 and ::1 I can stop bind listening on the local addresses so even less added to named.conf. But to share a single DNS among a number of mail servers, say in a mail farm that probably has lots of other types of servers running with questionable content, I would want secure tunnels from the mail server to the DNS server and that no longer is a non-trivial exercise. Now you can always use my HIP protocol instead of IKEv2 for keying ESP, but people doing this may want distro provided tunneling. How much resources does a local caching server demand? I would think it is mostly memory for the cache. You may have to throw a couple more Gb at loaded server.
Re: Running namecache service on postfix server?
On Wed, Feb 27, 2013 at 10:53:58AM -0500, Robert Moskowitz wrote: But to share a single DNS among a number of mail servers, say in a mail farm that probably has lots of other types of servers running with questionable content, I would want secure tunnels from the mail server to the DNS server and that no longer is a non-trivial exercise. Nothing of the sort, just enable validation of outside domains and exempt local domains if unsigned. TSIG configuration is must more complex and is both beyond our reasonable ability to document with specificity (too many variants between GSSAPI, and other security mechanisms) and the ability of most administrators to configure. The same goes for IPSEC, ... How much resources does a local caching server demand? I would think it is mostly memory for the cache. You may have to throw a couple more Gb at loaded server. GB is the wrong order of magnitude. A megabyte of RAM should be more than enough for local cache on most mail servers. Just need room in the cache for the MX, A, TLSA and RRSIG of the 10 highest volume destination domains and the A and PTR records of the 10 highest volume clients. The purpose of the local cache (before DANE support) is to reduce latency for the highest volume requests and to give the MTA administrator the flexibility to craft custom local MX RRsets in suitable local zones: example.net.localhost. IN MX 0 internal-mx1.example.net. example.net.localhost. IN MX 0 internal-mx2.example.net. example.com.localhost. IN MX 0 gw1.localhost. example.com.localhost. IN MX 0 gw2.localhost. gw1.localhost. IN A 192.0.2.1 gw2.localhost. IN A 192.0.2.2 Then one can add transport table entries: example.net smtp:example.net.localhost example.com smtp:example.com.localhost these won't break DNSSEC zone validation since localhost would be a local unsigned zone. With DANE + DNSSEC the local cache also makes it possible to trust the AD-bit without jumping through hoops with TSIG or implementing DNSSEC validation in Postfix. I think we've beaten this thread to death, I'm done for now. -- Viktor.
Re: Running namecache service on postfix server?
On 02/27/2013 11:10 AM, Viktor Dukhovni wrote: I think we've beaten this thread to death, I'm done for now. And I thank you for all you have said.
Re: Connection caching/SMTP piggybacking and postfix?
Wietse Venema wietse at porcupine.org writes: deliveries. Proper SMTP connection caching is not done by the SMTP clients but by a separate process that is queried by SMTP clients. If you don’t manage to do that with TLS, this statement is plainly wrong. Connection caching is a matter of also being nice to the recipient, who doesn’t have to spawn many sendmail processes in parallel to handle the roughly 500 mails that piled up on the Postfix side, right now. If Postfix were able to do proper connection reuse (WITH TLS, of course!) the mail delivery wouldn’t stop after the first couple of messages was submitted (because sendmail stops listening when the load reaches 8) and wouldn’t need to be retried (manually using postqueue -f once the sendmail load is down again, because the sending box is too busy to ever empty this queue with the default retry times). So I request of Postfix to implement connection reuse, supporting TLS (that means with*out* the separate dæmon unless you manage to be able to do that and still use TLS), by default. Thanks. Sorry for my tone, I’m a tad disgruntled right now *and* under pressure from my cow-orkers to get the pile of mails delivered.
Re: Running namecache service on postfix server?
On 02/27/2013 10:43 AM, Viktor Dukhovni wrote:
On Wed, Feb 27, 2013 at 10:20:50AM -0500, Wietse Venema wrote:
I think it would be entirely reasonable to share a DNS cache among
multiple systems within the same trusted perimeter. One DNS server
per host in a farm of mail servers may not be practical.
A local cache on each, forwarding to two or three resolvers that are
nearby? Local for DNSSEC verification, nearby cache for performance
reasons? Am I missing something that would make that impractical?
I think it would be helpful to give examples of how secure DNS
caches can be shared, instead of outright banning this. On non-trivial
deployments, DNS and MAIL are managed by different people.
This was the intent of my original example, I guess I did not draw
sufficient attention to the:
forward-zone:
name: .
forward-addr: 192.0.2.1
stanza at the bottom of the unbound.conf example. We'll need to
provide a similar configuration example for BIND, and explain the
rationale for both, so other local nameservers could also be
supported by an MTA administrator who understands the requirements.
On Centos 6.3 (bind 9.8.2 with security patches) I did:
yum install bind bind-chroot
In /etc/sysconfig/network-scripts/ifcfg-eth0 set:
DNS1=127.0.0.1
DNS2=::1
ifdown eth0; ifup eth0
Add to /var/named/chroot/etc/named.conf options section:
forward only;
forwarders {
'IPv4 addr of forwarded server';
'IPv6 addr of forwarded server';
'etc.';
};
service bind start
chkconfig bind on
You CAN use 'forward first' and then if your forward server is
unreachable, your caching server will go out on the net to the '.'
servers and walk down from there. Look at 'first' as opportunistic local
forwarding and 'only' as forced local forwarding.
Re: Running namecache service on postfix server?
Am 27.02.2013 17:42, schrieb Robert Moskowitz:
On Centos 6.3 (bind 9.8.2 with security patches) I did:
yum install bind bind-chroot
In /etc/sysconfig/network-scripts/ifcfg-eth0 set:
DNS1=127.0.0.1
DNS2=::1
ifdown eth0; ifup eth0
Add to /var/named/chroot/etc/named.conf options section:
forward only;
forwarders {
'IPv4 addr of forwarded server';
'IPv6 addr of forwarded server';
'etc.';
};
hopefully to your own TRSUTABLE forwarders and not
to ISP resolvers which all of their mangeling and
the problems if you use spamhaus.org and such blacklists
that you get blocked
signature.asc
Description: OpenPGP digital signature
Re: Connection caching/SMTP piggybacking and postfix?
On Wed, Feb 27, 2013 at 01:45:04PM +, Thorsten Glaser wrote: deliveries. Proper SMTP connection caching is not done by the SMTP clients but by a separate process that is queried by SMTP clients. If you don't manage to do that with TLS, this statement is plainly wrong. If you don't understand what you're talking about, you're liable to say things that are plainly wrong. Connection caching is a matter of also being nice to the recipient, who doesn't have to spawn many sendmail processes in parallel to handle the roughly 500 mails that piled up on the Postfix side, right now. No, connection caching has nothing to do with concurrency. Whether connections are cached, or not, Postfix will attempt parallel delivery up to the configured concurrency limit: http://www.postfix.org/postconf.5.html#transport_destination_concurrency_limit http://www.postfix.org/postconf.5.html#smtp_destination_concurrency_limit http://www.postfix.org/postconf.5.html#relay_destination_concurrency_limit ... Connection caching is a latency reduction optimization on the SMTP client to reduce the impact of TCP connect timeouts when a subset of the MX hosts for a destination is unreachable. The load on the remote server is identical with and without connection caching. If Postfix were able to do proper connection reuse (WITH TLS, of course!) the mail delivery wouldn't stop after the first couple of messages was submitted (because sendmail stops listening when the load reaches 8) Don't blame Sendmail design flaws on Postfix. The RefuseLA and QueueLA features are fundamentally broken. Set these sufficiently high that you never hit these in practice, an MTA should never suspend delivery under high load, that just leads to even higher load later. Sendmail lacks a queue-manager, if you really want to avoid Sendmail melt-downs under load, deploy Postfix. So I request of Postfix to implement connection reuse, supporting TLS (that means with*out* the separate d?mon unless you manage to be able to do that and still use TLS), by default. Connection caching without the ability to re-use the connection in a different delivery-agent process *is* abusive of the remote system, since you're keeping a remote process occupied and idle, while making new connections. This will not be implemented. Migrating TLS sessions between processes is non-trivial due to understandablel limitations in the OpenSSL API (it is not easy to completely serialize the cryptographic state of an established SSL connection). Thanks. Sorry for my tone, I'm a tad disgruntled right now *and* under pressure from my cow-orkers to get the pile of mails delivered. When disgruntled, especially due to problems with system A, don't rant on the mailing list for system B. -- Viktor.
Re: Running namecache service on postfix server?
On 02/27/2013 11:47 AM, Reindl Harald wrote:
Am 27.02.2013 17:42, schrieb Robert Moskowitz:
On Centos 6.3 (bind 9.8.2 with security patches) I did:
yum install bind bind-chroot
In /etc/sysconfig/network-scripts/ifcfg-eth0 set:
DNS1=127.0.0.1
DNS2=::1
ifdown eth0; ifup eth0
Add to /var/named/chroot/etc/named.conf options section:
forward only;
forwarders {
'IPv4 addr of forwarded server';
'IPv6 addr of forwarded server';
'etc.';
};
hopefully to your own TRSUTABLE forwarders and not
to ISP resolvers which all of their mangeling and
the problems if you use spamhaus.org and such blacklists
that you get blocked
Yes, you ONLY forward to servers where there is agreement that you MAY
use them as forwarders. This is typically your own main DNS servers.
Otherwise, it runs 'out-of-the-box' as a caching server using the
regular '.' hints to find things.
Another tidbit is you should firewall access to port 53. Your caching
server is only for you. It is listening only on localhost, but why open
up a port not needed.
Re: Running namecache service on postfix server?
On Wed, Feb 27, 2013 at 05:47:28PM +0100, Reindl Harald wrote: ... more DNS related suggestions ... Perhaps Postfix could benefit from a DNS_README.html, with examples tuning a local cache for MX overrides, RBLDNSD integration using an internal RBL zone, DNSSEC support, and any other DNS-related best-practices for an MTA. Anyone care to volunteer an initial draft? Use one of the existing documents in the proto/ directory of the Postfix source distribution as a starting point. -- Viktor.
Re: Running namecache service on postfix server?
On Feb 27, 2013, at 18:05, Robert Moskowitz r...@htt-consult.com wrote: Another tidbit is you should firewall access to port 53. Your caching server is only for you. It is listening only on localhost, but why open up a port not needed. Review the examples given again, please. Why would you need to firewall a local nameserver that ONLY listens on the localhost interface? Cya, Jona
Re: Running namecache service on postfix server?
On 02/27/2013 12:26 PM, DTNX Postmaster wrote: On Feb 27, 2013, at 18:05, Robert Moskowitz r...@htt-consult.com wrote: Another tidbit is you should firewall access to port 53. Your caching server is only for you. It is listening only on localhost, but why open up a port not needed. Review the examples given again, please. Why would you need to firewall a local nameserver that ONLY listens on the localhost interface? I would hope you are running local firewall, and only opening what is needed. Just pointing out that there is no need to open port 53 as it is only used local. Also about chroot. Only needed if you disable selinux.
Re: Connection caching/SMTP piggybacking and postfix?
Thorsten Glaser: Wietse Venema wietse at porcupine.org writes: deliveries. Proper SMTP connection caching is not done by the SMTP clients but by a separate process that is queried by SMTP clients. If you don?t manage to do that with TLS, this statement is plainly wrong. Well, how does one migrate **AN OPEN TLS SESSION** from one process into the other? I am not aware an OpenSSL API for doing that. Wietse
Re: possible localhost dns spoof attack
On Tue, Feb 26, 2013 at 05:16:20PM +0200, Jamie wrote: I unblocked the IP and the problem came back. In another mail you said you'd used tcpdump. Why don't you set tcpdump to record everything from that IP address, unblock the IP address, wait faor a few spams to go through, block the IP address, and analyze the tcpdump to see exactly what is happening? This should do it: tcpdump -i $INTERFACE -s 0 -w /tmp/spammer.tcpdump host 113.167.239.162
Re: possible localhost dns spoof attack
If you would send postfix logs and current postconf -n to the list as requested several times, we could likely clear this all up pretty quickly. On 2/27/2013 1:43 PM, Jamie wrote: Thanks Lorens. I'll consider that. On 2013/02/27 9:29 PM, Lorens Kockum wrote: On Tue, Feb 26, 2013 at 05:16:20PM +0200, Jamie wrote: I unblocked the IP and the problem came back. In another mail you said you'd used tcpdump. Why don't you set tcpdump to record everything from that IP address, unblock the IP address, wait faor a few spams to go through, block the IP address, and analyze the tcpdump to see exactly what is happening? This should do it: tcpdump -i $INTERFACE -s 0 -w /tmp/spammer.tcpdump host 113.167.239.162
Building el6 RPMs for v2.10
Hello, I have been building el6 (CentOS 6, RHEL 6) RPMs using J. Mudd's SRPMs (http://ftp.wl0.org/official/2.9/SRPMS/). Does anyone have experience on building v2.10.x RPMs using the same SRPMs? Are these safe, or has anyone adjusted the above v2.9.x SRPMs properly so that they can be used for building v2.10.x ? (Of course, I can test, but it's better to avoid reinventing the wheel.) Thanks and Regards, Nick
Re: possible localhost dns spoof attack
Noel On 2013/02/27 9:48 PM, Noel Jones wrote: If you would send postfix logs and current postconf -n to the list as requested several times, we could likely clear this all up pretty quickly. If you look back earlier in the thread, you will see that I had posted it already.
Re: possible localhost dns spoof attack
On 2/27/2013 2:01 PM, Jamie wrote: Noel On 2013/02/27 9:48 PM, Noel Jones wrote: If you would send postfix logs and current postconf -n to the list as requested several times, we could likely clear this all up pretty quickly. If you look back earlier in the thread, you will see that I had posted it already. I apologize if I missed where you posted the requested information in a single mail. Can you send a link to the archive or kindly resend? -- Noel Jones
Re: possible localhost dns spoof attack
On Wed, Feb 27, 2013 at 10:01:27PM +0200, Jamie wrote: On 2013/02/27 9:48 PM, Noel Jones wrote: If you would send postfix logs and current postconf -n to the list as requested several times, we could likely clear this all up pretty quickly. If you look back earlier in the thread, you will see that I had posted it already. I only saw main.cf and some largely irrelevant logs. Do note that your system is ipso facto compromised. We know this because it is being used by a spammer to send spam. Stop saying you're not compromised, when we know that you are. Here is what you need to do. Please pay attention. Find one or two of the spams in your logs. Trace all references therein to that queue ID. Trace it further back through the content_filter, to the original queue ID. Find how and where that original queue ID was first submitted. grep(1) won't do. Use less(1) or other pager, because the initial connection likely won't show up in a grep for the queue ID. Show all those logs, at least through the initial round of smtp(8) rejections and deferrals. Include postconf -n and master.cf (all comments removed) in the same post. I can offer a WAG here, which would explain why blocking some seemingly random IP address would stop the spamming: perhaps that's the IP address of the command and control node of your malware. I can also repeat what others have told you: the Subject: is wrong; this is not a localhost dns spoof attack. This is some other, more mundane and ordinary, attack. You're going to have to cooperate if you want help in solving it. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Building el6 RPMs for v2.10
On 27/02/2013 21:54, Nikolaos Milas wrote: Hello, I have been building el6 (CentOS 6, RHEL 6) RPMs using J. Mudd's SRPMs (http://ftp.wl0.org/official/2.9/SRPMS/). Does anyone have experience on building v2.10.x RPMs using the same SRPMs? Are these safe, or has anyone adjusted the above v2.9.x SRPMs properly so that they can be used for building v2.10.x ? (Of course, I can test, but it's better to avoid reinventing the wheel.) Thanks and Regards, Nick I use it on 2 small servers in production. No problem here. Levi
Re: smtpd_recipient_limit and the corresponding error pop up on secure smtp
On Wed, Feb 27, 2013 at 10:11 AM, francis picabia fpica...@gmail.comwrote: Hi, The number of phishing or otherwise compromised accounts is needing an automation to manage it. Last night the spammers waited until the evening and simultaneously used 3 compromised accounts to send spam over secure smtp. A nagios alert on number of messages in the queue was our only alarm, and in only a couple of hours the reputation of the server and domain is damaged for awhile (both in and out). I added smtpd_recipient_limit=20 to the options for secured SMTP. The error it produced when tested (with Thunderbird) is confusing: The size of the message you are trying to send exceeds a temporary size limit of the server. The message was not sent; try to reduce the message size or wait some time and try again. The server responded: 4.5.3 Error: too many recipients. If the user patiently reads to the end, the last statement is the only thing they need to know. However, the previous statements are wrong and misleading. How can this error be made better? Thanks for the answers everyone. Crystal clear the vagueness is all Thunderbird's. I had a set of cascading iptables rules to rate limit new connections, but they circumvented this as well. Based on the IP, there were 5 connections per minute and 15 connections per 5 minutes. If those were exceeded, iptables would block that IP for 20 minutes. Here is what they did: Over 390 unique IPs simultaneously sent email at a gradual rate using 3 sets of compromised credentials. I looked at one IP, and it connected 59 times over 2 hours, sending one recipient per email. If that is indicative, then 59 * 390 = 23128 email. It looks like we need something which limits based on the authenticating sender connection counts, not IP or recipient count.
Re: smtpd_recipient_limit and the corresponding error pop up on secure smtp
Am 27.02.2013 21:45, schrieb francis picabia: I had a set of cascading iptables rules to rate limit new connections, but they circumvented this as well. Based on the IP, there were 5 connections per minute and 15 connections per 5 minutes. If those were exceeded, iptables would block that IP for 20 minutes. this is bullshit if you where my mail-admin i would call you something not friendly - 15 connections and so 15 messages per 5 minutes thank you if i check my mails in the morning and reply to at least 50 of them due my first coffee things like the follwoing are working much better because a average over 30 minutes allows natural peaks anvil_rate_time_unit = 1800s smtpd_client_connection_rate_limit = 80 Over 390 unique IPs simultaneously sent email at a gradual rate using 3 sets of compromised credentials. I looked at one IP, and it connected 59 times over 2 hours, sending one recipient per email. If that is indicative, then 59 * 390 = 23128 email. It looks like we need something which limits based on the authenticating sender connection counts, not IP or recipient count or get rid of users which are compromised signature.asc Description: OpenPGP digital signature
Server found while in construction - beware
Lesson here about how open you make a new server while under construction. Fortunately for me, my first step before starting postfix was to apply my 'recipe' of postconf commands? Anyway the system is publicly addressed, but on a different subnet than the production box it will replace. I am running this way, as this time if all goes right (and this is my 5th build test), I drain the old box, change the addresses on this new one and swap them out. Public DNS for this is its IPaddr.domain so it shows how the robots look for any working address with port 25 available: Feb 27 03:57:23 klovia postfix/smtpd[7677]: connect from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78] Feb 27 03:57:24 klovia postfix/smtpd[7677]: NOQUEUE: reject: RCPT from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]: 554 5.7.1 1...@k888.tw: Relay access denied; from=a...@hotmail.com to=1...@k888.tw proto=SMTP helo=208.83.67.180 Feb 27 03:57:24 klovia postfix/smtpd[7677]: lost connection after RCPT from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78] Feb 27 03:57:24 klovia postfix/smtpd[7677]: disconnect from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78] Feb 27 04:00:44 klovia postfix/anvil[7679]: statistics: max connection rate 1/60s for (smtp:36.231.85.78) at Feb 27 03:57:23 Feb 27 04:00:44 klovia postfix/anvil[7679]: statistics: max connection count 1 for (smtp:36.231.85.78) at Feb 27 03:57:23 Feb 27 04:00:44 klovia postfix/anvil[7679]: statistics: max cache size 1 at Feb 27 03:57:23 Feb 27 08:11:07 klovia postfix/smtpd[8254]: connect from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78] Feb 27 08:11:08 klovia postfix/smtpd[8254]: NOQUEUE: reject: RCPT from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]: 554 5.7.1 1...@k888.tw: Relay access denied; from=a...@hotmail.com to=1...@k888.tw proto=SMTP helo=208.83.67.180 Feb 27 08:11:08 klovia postfix/smtpd[8254]: lost connection after RCPT from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78] Feb 27 08:11:08 klovia postfix/smtpd[8254]: disconnect from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78] Feb 27 08:14:28 klovia postfix/anvil[8256]: statistics: max connection rate 1/60s for (smtp:36.231.85.78) at Feb 27 08:11:07 Feb 27 08:14:28 klovia postfix/anvil[8256]: statistics: max connection count 1 for (smtp:36.231.85.78) at Feb 27 08:11:07 Feb 27 08:14:28 klovia postfix/anvil[8256]: statistics: max cache size 1 at Feb 27 08:11:07 Feb 27 12:26:46 klovia postfix/smtpd[9705]: connect from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78] Feb 27 12:26:47 klovia postfix/smtpd[9705]: NOQUEUE: reject: RCPT from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]: 554 5.7.1 1...@k888.tw: Relay access denied; from=a...@hotmail.com to=1...@k888.tw proto=SMTP helo=208.83.67.180 Feb 27 12:26:47 klovia postfix/smtpd[9705]: lost connection after RCPT from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78] Feb 27 12:26:47 klovia postfix/smtpd[9705]: disconnect from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78] Feb 27 12:30:07 klovia postfix/anvil[9707]: statistics: max connection rate 1/60s for (smtp:36.231.85.78) at Feb 27 12:26:46 Feb 27 12:30:07 klovia postfix/anvil[9707]: statistics: max connection count 1 for (smtp:36.231.85.78) at Feb 27 12:26:46 Feb 27 12:30:07 klovia postfix/anvil[9707]: statistics: max cache size 1 at Feb 27 12:26:46
Re: possible localhost dns spoof attack
On 2/27/2013 2:33 PM, /dev/rob0 wrote: I only saw main.cf and some largely irrelevant logs. I was trying to be polite. That's all I saw too. Do note that your system is ipso facto compromised. We know this because it is being used by a spammer to send spam. Stop saying you're not compromised, when we know that you are. But we don't know that his system is sending spam; another reason we need to see logs. There is enough conflicting information here that everything should be verified by evidence. I'm inclined to think this is something mundane, such as an NDR/bounce triggered by spam from some rDNS localhost client or maybe a phished local account. Once those are eliminated as possible explanations, we can look for more interesting problems. But now I'm guessing, which I berated others for earlier. -- Noel Jones
Re: is possible to use different SSL certificates for different domains?
On Mon, Feb 25, 2013 at 04:59:37PM +, Viktor Dukhovni wrote: I see negligible benefit from an SNI implementation for Postfix. Is it time to add an anti-SNI rationale section to TLS_README? This would set a bad precedent, there is no limit to the number of non-features we could document. Rather than putting it in TLS_README, I think a FAQ would be more fitting. I know we used to have a FAQ document, but it has long ago been abandoned. We get a lot of the same questions here, and some ardent Googlers still stumble upon the old faq.html page. Perhaps rather than a DNS_README as you suggested in another thread, that could be worked into a FAQ? I agree, DNS is a vital subject to most MTA administrators, but here too it's not going to cover actual Postfix features, for the most part. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Public free (libre) mailbox hosting service for everybody!
Am 27.02.2013 22:11, schrieb אנטולי קרסנר: But I couldn't find a replacement to mailbox hosting. Hi Anatoly, I am quite sure there are a ton of professional email services that use only free (libre) software. The company I work for provides email services (among other things) which are based on Postfix, Dovecot, Roundcube and other free software. As the operation of such a system for a large number of users is quite resource intensive, there may be not as much free (as in beer) services be available as one would like to have. But you are always free to start your own. :) Kindest Regards -- Robert Sander -- Treffen Sie uns auf der CeBIT vom 5.-9. März 2013! Sie finden uns in Halle 6, Open Source Park (F16), Stand 310 -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin
Re: smtpd_recipient_limit and the corresponding error pop up on secure smtp
On 2/27/2013 2:45 PM, francis picabia wrote: Over 390 unique IPs simultaneously sent email at a gradual rate using 3 sets of compromised credentials. Use postfwd or similar policy service to rate-limit the total recipients per account over some period of time. http://www.postfix.org/SMTPD_POLICY_README.html http://www.postfix.org/addon.html#policy http://postfwd.org/ -- Noel Jones
Re: Server found while in construction - beware
Am 27.02.2013 22:08, schrieb Robert Moskowitz: Lesson here about how open you make a new server while under construction. Fortunately for me, my first step before starting postfix was to apply my 'recipe' of postconf commands? Anyway the system is publicly addressed, but on a different subnet than the production box it will replace. I am running this way, as this time if all goes right (and this is my 5th build test), I drain the old box, change the addresses on this new one and swap them out. Public DNS for this is its IPaddr.domain so it shows how the robots look for any working address with port 25 available: 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]: 554 5.7.1 1...@k888.tw: Relay access denied; from=a...@hotmail.com to=1...@k888.tw proto=SMTP helo=208.83.67.180 Feb 27 03:57:24 klovia postfix/smtpd[7677]: lost connection after RCPT from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78] ah hinet.net - as far as i remember this is the asian large crap provider where you get FIVE biubces as response to a abuse-mail and i temprary blocked aroubd 1 Mio. IP addresses from them in iptables in fact, what you are showing is the sad truth making any machine public and not secured and it may lead to intrusions within minutes or sometimes seconds, that is why all the but who is interested in me carells hobbiests are completly wrong nearly ten years ago a simple test and 10 years ago was virtually notihing compared to now in context of attacks and intrusions * samba on the WAN * a completly fresh ip-address * guest account enabled * voila, a collection of all known and unknown malwares from a to z in the share * timeframe: 10 minutes up to an hour signature.asc Description: OpenPGP digital signature
Re: possible localhost dns spoof attack
On Wed, Feb 27, 2013 at 03:10:38PM -0600, Noel Jones wrote: On 2/27/2013 2:33 PM, /dev/rob0 wrote: I only saw main.cf and some largely irrelevant logs. I was trying to be polite. That's all I saw too. I tried to be polite also, but perhaps putting a little less effort into it than you did. ;) Just a note for the archives and for those who tend to fuss with us when our replies don't seem sugar-coated enough for your tastes: we really DO want to help this poster, and especially to help the Internet be rid of some more spam. Jamie is not following directions and is wasting our time. This thread has gone on for days, but if proper information had been available we would have solved it long ago. Do note that your system is ipso facto compromised. We know this because it is being used by a spammer to send spam. Stop saying you're not compromised, when we know that you are. But we don't know that his system is sending spam; another reason we need to see logs. There is enough conflicting information here that everything should be verified by evidence. I was going on the reply to Tom Hendrikx: Message-ID: 512ca32d.8030...@mailarchiva.com Date: Tue, 26 Feb 2013 13:57:33 +0200 The logs therein looked decidedly spammy, unlike the other normal delivery logs shown. I'm inclined to think this is something mundane, such as an NDR/bounce triggered by spam from some rDNS localhost client or maybe a phished local account. Once those are eliminated as possible explanations, we can look for more interesting problems. Another thing which might help isolate this, which was missing from the master.cf in the above-referenced post, would be to use -o syslog_name=postfix/... on any smtpd instance other than *:smtp. Jamie only had a post-amavisd reinjection smtpd, no submission. (Another good suggestion would be to isolate submission from MX mail, but that goes beyond the original problem somewhat.) But now I'm guessing, which I berated others for earlier. :) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Getmail
On Wed, Feb 27, 2013 at 05:51:08PM +0500, Muhammad Yousuf Khan wrote: i am using virtual users and domains, where i have 2 virtual domains and few users in both. i would like getmail to fetch email via pop3 First, I'll note that this is mostly off topic. Postfix has little to do with this, only incidentally. Second, why are you using POP3? Surely your provider offers IMAP? If not, it's a good sign that you need a different provider. :) Third, this would have been better with system users rather than virtual(8). from our hosting servers and copy it directly to our Maildir Base, here is the path of my virtual users mailbox base. /maildb/vmail/$domain/$user/Maildir is there anyone can guide me with the getmail settings. You'll have to run getmail as the system user/group who owns the mailbox. The Postfix settings which might apply are virtual_uid_maps and virtual_gid_maps. This user (or users, as the case may be) must have a valid shell (which you generally would not want in the case of virtual delivery.) It looks like you made a $HOME for your virtual users; that's good. You can keep your files in /maildb/vmail/$domain/$user/.getmail, or perhaps even in /maildb/vmail/.getmail if it's all one user, as it is in almost every case. You can make a cron job for the user[s] to getmail. Refer to the examples as provided by Robert. You have weakened the security of your virtual system by providing this user a real shell and having it call out to the Internet. Thus why I say this should be done by a system user. If your virtual user is compromised, all your mail might be at stake. If a system user is compromised, only that user's mail (and other files) is at risk. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Command piping virtual domains
I have the need to pipe commands for a few virtual domains. I understand that the /etc/aliases is usually used for this but the problem I will be running into is needing more than one local user with the same name. Example requirement: supp...@domain1.com support: | /var/www/domain1/support/support.php supp...@domain2.com support: | /var/www/domain2/support/support.php If there was just 1 domain this would not be an issue. Can piping commands be placed in the virtual domain config? What would be the best way to make this happen?
Re: Command piping virtual domains
On Wed, Feb 27, 2013 at 03:42:36PM -0700, Joshua Hopkins wrote: I have the need to pipe commands for a few virtual domains. I understand that the /etc/aliases is usually used for this but the problem I will be running into is needing more than one local user with the same name. Example requirement: supp...@domain1.com support: | /var/www/domain1/support/support.php supp...@domain2.com support: | /var/www/domain2/support/support.php If there was just 1 domain this would not be an issue. Can piping commands be placed in the virtual domain config? No. What would be the best way to make this happen? I'd use virtual(5) aliases, perhaps in conjunction with a $recipient_delimiter, to alias each one to a system user. main.cf : mydestination = localhost, localhost.$mydomain[, ... ] ### I use - if planning to use delimited addresses in the real ### world, because a lot of stupid web forms reject + in email ### addresses recipient_delimiter = + virtual_alias_maps = hash:/etc/postfix/virtual [ ... ] /etc/postfix/virtual : supp...@example.com support+example.com@localhost supp...@example.net support+example.net@localhost supp...@example.org support+example.org@localhost [ ... ] Create a system user, support, and use .forward files: ~support/.forward+example.com : | /var/www/bin/support/support.php example.com ~support/.forward+example.net : | /var/www/bin/support/support.php example.net ~support/.forward+example.org : | /var/www/bin/support/support.php example.org Refer to: http://www.postfix.org/virtual.5.html http://www.postfix.org/aliases.5.html http://www.postfix.org/local.8.html http://www.postfix.org/postconf.5.html#recipient_delimiter http://www.postfix.org/postconf.5.html#virtual_alias_maps Other choices include pipe(8) and transport(5) maps, but this seems simpler to me. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Enforced TLS per MX
Am 22.02.2013 17:06, schrieb Viktor Dukhovni: On Fri, Feb 22, 2013 at 08:48:31AM -0500, Wietse Venema wrote: We are trying to establish enforced TLS with a partner that hosts about 2000 recipient domains. All of these point to the same four MX records: host[1-4].example.com As I did not want to specify all of these domains in our tls_policy file, I wanted to ask if there is any option to enforce TLS by those MX addresses. Surely, the policy table is indexed by MX hostname as well as recipient domain. No, it is not. Only the nexthop domain is used since the MX host is derived from unauthenicated MX lookups and is trivially subject to MITM attacks. So it would have the same quality as the encrypt action, no? Something between 0 and 100, that could be explicitly mentioned in the docs. Doesn't help with a MITM but keeps out the firewall/provider guy with debug/snoop/tcpdump - and your idp of course :-( But I understand the point and agree with it although it doesn't make me very happy. We are replacing an interconnection between some companies with several 1000s of domains (actively used, frequently enhanced) via leased lines. This required (and unfortunately still requires) a database for domain exchange and some kind of 'administrative discipline' to keep it updated in time. My expectation is that DNSSEC will be globally used before the last point is going to function properly ;)
Re: Public free (libre) mailbox hosting service for everybody!
The operational cost is non-zero. Besides hardware, which must include backups, and enough physical diversity to offer availability, an email server is an attractive nuisance; spammers and other criminals constantly attempt sabotage and burglary, and it takes ongoing manpower to attempt to hold them temporarily at bay. And unless you put hard caps on message sizes, people will use their mailboxes as backup drives, or just email their vacation movies to family, and you'll be buying drives, and hence replacing them, often. I love the idea, I'm fond of running mailservers myself. But I've gone Google. As for software, I won't pitch my favorite components to this wide list, but I know how to find all the pieces I'd need except the webmail front-end for the utterly non-technical. If you limited the scope to IMAP and SMTP, both SSL authenticated, it wouldn't be too hard to spec out. Host on AWS EC3 or the like, then find an affordable solution to spam, and you can sell to anyone who doesn't expect their email to be private from governments. Anybody know of a well-engineered and maintained SSL library?
Re: Enforced TLS per MX
On Thu, Feb 28, 2013 at 12:25:53AM +0100, Jan P. Kessler wrote: Am 22.02.2013 17:06, schrieb Viktor Dukhovni: Surely, the policy table is indexed by MX hostname as well as recipient domain. No, it is not. Only the nexthop domain is used since the MX host is derived from unauthenicated MX lookups and is trivially subject to MITM attacks. So it would have the same quality as the encrypt action, no? Yes. -- Viktor.
Re: smtpd_recipient_limit and the corresponding error pop up on secure smtp
On Wed, Feb 27, 2013 at 4:52 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 27.02.2013 21:45, schrieb francis picabia: I had a set of cascading iptables rules to rate limit new connections, but they circumvented this as well. Based on the IP, there were 5 connections per minute and 15 connections per 5 minutes. If those were exceeded, iptables would block that IP for 20 minutes. this is bullshit Thanks for the technical expose. if you where my mail-admin i would call you something not friendly - 15 connections and so 15 messages per 5 minutes The fact is, those rules have been in place for over a year without any grief for the users (and they would complain quite liberally). This only impacts roaming users, and the count on new connections. You don't have enough information to understand our set up, nor do you have a right to complain! thank you if i check my mails in the morning and reply to at least 50 of them due my first coffee things like the follwoing are working much better because a average over 30 minutes allows natural peaks anvil_rate_time_unit = 1800s smtpd_client_connection_rate_limit = 80 This would have done nothing to address the situation I explained. Each IP connects about once every 2 minutes. Over 390 unique IPs simultaneously sent email at a gradual rate using 3 sets of compromised credentials. I looked at one IP, and it connected 59 times over 2 hours, sending one recipient per email. If that is indicative, then 59 * 390 = 23128 email. It looks like we need something which limits based on the authenticating sender connection counts, not IP or recipient count or get rid of users which are compromised You are funny. They pay the bills.
Re: smtpd_recipient_limit and the corresponding error pop up on secure smtp
On Wed, Feb 27, 2013 at 5:22 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 2/27/2013 2:45 PM, francis picabia wrote: Over 390 unique IPs simultaneously sent email at a gradual rate using 3 sets of compromised credentials. Use postfwd or similar policy service to rate-limit the total recipients per account over some period of time. http://www.postfix.org/SMTPD_POLICY_README.html http://www.postfix.org/addon.html#policy http://postfwd.org/ Thanks for the pointer. Another swiss army knife to learn about. I'll take a look.
Re: possible localhost dns spoof attack
The output of postconf -n was submitted in an earlier post (on Tuesday). it is archived here http://archives.neohapsis.com/archives/postfix/2013-02/0523.html. Its difficult to obtain more information now, since the spamming has stopped after I blocked the offenders IP's. Re-enabling the IP's hasn't Frankly at this stage, I'd rather leave a gaping hole in Postfix, than put up with further abuse from the veteran members of this forum. On 2013/02/27 11:41 PM, /dev/rob0 wrote: On Wed, Feb 27, 2013 at 03:10:38PM -0600, Noel Jones wrote: On 2/27/2013 2:33 PM, /dev/rob0 wrote: I only saw main.cf and some largely irrelevant logs. I was trying to be polite. That's all I saw too. I tried to be polite also, but perhaps putting a little less effort into it than you did. ;) Just a note for the archives and for those who tend to fuss with us when our replies don't seem sugar-coated enough for your tastes: we really DO want to help this poster, and especially to help the Internet be rid of some more spam. Jamie is not following directions and is wasting our time. This thread has gone on for days, but if proper information had been available we would have solved it long ago.
Re: possible localhost dns spoof attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/27/2013 8:37 PM, Jamie wrote: The output of postconf -n was submitted in an earlier post (on Tuesday). it is archived here http://archives.neohapsis.com/archives/postfix/2013-02/0523.html. The useful information gained from your postconf is: a) It's very unlikely postfix is an open relay b) you're using a content_filter, so that may explain the connect from [127.0.0.1] log snippit. Its difficult to obtain more information now, since the spamming has stopped after I blocked the offenders IP's. Re-enabling the IP's hasn't I was hoping to see logs of the original incident. Frankly at this stage, I'd rather leave a gaping hole in Postfix, than put up with further abuse from the veteran members of this forum. I'm sorry if this feels like abuse; that's not the intent. A few of us here wanted to see evidence before sending you on wild goose chase. You'll just have to trust me when I tell you the people who made a diagnosis without evidence weren't doing you any favors - -- they wasted a lot of your time looking for problems that didn't exist, and drowned out the few posts that were actually useful. Peace, -- Noel Jones -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLsvrAAoJEJGRUHb5Oh6gKQsH/1HT2f+E4Jx2jYPmMib/oDGe 2qFZ7LM6b4rpQE5FIcxkM8DDtwoDhiDMTKswt90R06HXdo3u2kSQSs88pjBVTz2X wv1apq6u3kDOwde/WUGCFxPhsH6fl9/mhvPD2aI5EGzahusW54BJebFW4d4t7ocj vG/IivFzZiJspcyI7AKw3H/8g8UL9v/zB6QgpEmraHsv7dkxEtr1XiKPqwNka/Ux Xc+UZoEHuHh1uKhvNUqDPec9gt/lxKs4aLj1H2/sAopTVoPHTEwk5iov2d/fs0X8 h3j9pLZyuS26ediOefRcOpHUeYUXM2Ahkz9pp35iIlKbO9Xl38HsIoRJXLbVAZU= =rrEy -END PGP SIGNATURE-
Re: possible localhost dns spoof attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/27/2013 8:37 PM, Jamie wrote: The useful information gained from your postconf is: a) It's very unlikely postfix is an open relay b) you're using a content_filter, so that may explain the connect from [127.0.0.1] log snippit. I was hoping to see logs of the original incident. I'm sorry if this feels like abuse; that's not the intent. A few of us here wanted to see evidence before sending you on wild goose chase. You'll just have to trust me when I tell you the people who made a diagnosis without evidence weren't doing you any favors - -- they wasted a lot of your time looking for problems that didn't exist, and drowned out the few posts that were actually useful. Peace, -- Noel Jones -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLsvVAAoJEJGRUHb5Oh6gWK0H/jSMfezlcobnuWqsb/6uL7Re D3mMhAGHaBZx+ZVznGwvgflJmyM9k1UuQbcKreKuc1KNKdWIw/ZCcjmbAhKw3ndt v1pRf0SumI8nSfLY6pPoabzkYrn5jjzEgeRLp92oI8UgASI0mkXXaJDkaYFjIe3b ejX6SmilhNAis6OqykEHCZ8VVHehvDEnTMIsD04aZG/S4WkOSyYgJwGsf+9GoCOH 5kVdLT9gMEdoSAvYkhqen9LBIy2aQM0in04n1Mneqjjhe0wrcJAvMw+tdJKAup1x 7cC/mHqMHNTxTGQjz5x5mAQef1Lt6X8b10FnVDg3UZbGeQLosKPG7SAGyYO0Xr4= =nOaT -END PGP SIGNATURE-
Re: Public free (libre) mailbox hosting service for everybody!
Hi John and all recipients, I agree offering such a service without charging for it is impossible without funding. But free means free like in freedom, not free beer. The idea is to respect user freedom, and it has nothing to do with money. I personally will not mind paying for a hosted mailbox. Maybe now it's difficult because I'm a student and all my money goes to the university, but in general, people who have full-time jobs can easily pay just a small amount every month, and it should be enough to cover the expenses, if enough people use the new server. But there's a chance we won't need to charge: we can get funding. There are SO many organizations which help free software projects, and social initiatives in general. If we get their support and funding, all we need is people who can work on that server and maintain it technically. People already do the same for many other services. It's possible with e-mail too. As for size limits, attack attempts and anti-spam: * size limit: It's okay to limit message size because it doesn't limit user freedom: mail is for text, not for sending movies. There are free and open source replacements for Dropbox, and large files can be shared using free (libre) p2p sharing tools, such as bittorent clients. I actually encourage people not to send large files. Want to share a mmovie clip? A photo album? Music? No problem, use the best tool for it. Share large files using Transmission. Upload albums to social networks or photo-sharing sites. Upload music to a SparkleShare shared folder or to a audio/video sharing website. All solutions exist. Otherwise, mail is great for text and documents. And a picture or two are fine too... * attack attemps: this is a security issue. Be aware that many crackers want to hurt organizations and cause anarchism, but we're not a software company. Many hackers and crackers are in fact on our side... and for the others, we'll setup defenses for the servers. I don't know much about securing a server, but some people here do, so we have the knowledge. * spam - I disagree to charge an extra free for spam filtering. Either the users sets up rules for filtering messages, or the server uses a mailbox-wide filter for any incoming messages, but there's no extra fee. The whole service should be available to every user, or not at all. All extra services, e.g. contact list and calendar, would come together with the mailbox. No extra fee for any service. If people need to pay for usage, they get the whole service for the money they pay. Anatoly Krasner On ד', 2013-02-27 at 18:23 -0500, John Hudak wrote: To answer your question: I don't know of any. To offer some observations: Assembling 'free software' is only part of the solution. Acquiring servers+associated hw, shelter, and power sources takes CASH. Keeping the service running takes CASH. There is no 'free' business model. I hate the term 'free software'people invested their time/energy, it takes power to run their machines (which is not free), the distribution/bugtracking/documentation is not free. The soft drinks/pizza/name your favorite work food is not free. Security and anonymity - how good is it going to be? With the entire network being a drawing card for people wanting to steal something, how is security and anonymity going to be preserved, for free??? If people only knew what is being harvested about them from 'free' services, there would be a revolt. I even hate using gmail, and use it sparingly. Free mail server - great idea, Implementing it - priceless! -John On Wed, Feb 27, 2013 at 4:11 PM, אנטולי קרסנר tomback...@gmail.com wrote: Hello e-mail software developers and users! I'd like to ask all of you a question. And of course hear relevant opinion. I've been using free software happily for a few years, and I found free/open source alternatives for many popular proprietary tools such as Facebook, Dropbox, Micro$oft Windows Office, Youtube, Skype and many many others. Some of the alternatives are probably known to some of you, while others are still unknown to many. But I couldn't find a replacement to mailbox hosting. I'm using a Gmail mailbox and I hate it. So many free and open source mail servers and I still use Gmail, a closed-source service (which also probably tracks all my data, including Google searches I do, and uses it for all kinds of statistics and advertising, but that's another issue). So I asked myself, why is there no mailbox hosting service which respects user freedom? I sent an e-mail to the Free Software Foundation, and got a suggestion to ask all of you: do you know any free (libre) mail server out there?
Re: Public free (libre) mailbox hosting service for everybody!
I've written a response to someone else, explaining some issues you mention here. A little note on UI: we don't need web UI. It's a good addition but unnecessary for the beginning. There are many free-software desktop mail clients. Some are big and complicated, but some are very simple and very easy to use, just like Gmail is. So UI is not a critical issue right now, we just need to be able to easily configure a mail client, e.g. Evolution, to work with the server. And it's great to hear people like the idea and want to help! With hard work and cooperation, everything is possible! - Anatoly Krasner On ד', 2013-02-27 at 18:39 -0500, Bennett Todd wrote: The operational cost is non-zero. Besides hardware, which must include backups, and enough physical diversity to offer availability, an email server is an attractive nuisance; spammers and other criminals constantly attempt sabotage and burglary, and it takes ongoing manpower to attempt to hold them temporarily at bay. And unless you put hard caps on message sizes, people will use their mailboxes as backup drives, or just email their vacation movies to family, and you'll be buying drives, and hence replacing them, often. I love the idea, I'm fond of running mailservers myself. But I've gone Google. As for software, I won't pitch my favorite components to this wide list, but I know how to find all the pieces I'd need except the webmail front-end for the utterly non-technical. If you limited the scope to IMAP and SMTP, both SSL authenticated, it wouldn't be too hard to spec out. Host on AWS EC3 or the like, then find an affordable solution to spam, and you can sell to anyone who doesn't expect their email to be private from governments. Anybody know of a well-engineered and maintained SSL library?
