Loading ...
Sorry, an error occurred while loading the content.
 

Would somebody let me know what I need to do to improve this setup.

Expand Messages
  • John Allen
    root@bilbo:~# postconf -nf alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no bounce_size_limit = 65536 broken_sasl_auth_clients = yes
    Message 1 of 16 , Aug 6, 2013
      root@bilbo:~# postconf -nf
      alias_maps = hash:/etc/aliases
      append_dot_mydomain = no
      biff = no
      bounce_size_limit = 65536
      broken_sasl_auth_clients = yes
      config_directory = /etc/postfix
      content_filter = smtp-amavis:[127.0.0.1]:10024
      default_process_limit = 20
      delay_warning_time = 12h
      disable_vrfy_command = yes
      header_size_limit = 32768
      home_mailbox = Maildir/
      html_directory = /usr/share/doc/postfix/html
      mailbox_transport = lmtp:unix:private/dovecot-lmtp
      message_size_limit = 34359738368
      mydestination = localhost, localhost.localdomain, localdomain
      mydomain = klam.ca
      myhostname = smtp.$mydomain
      mynetworks = 127.0.0.0/8, 192.168.0.0/16, [::1]/128, [2001:470:b2e1:30::/64]
      myorigin = $mydomain
      readme_directory = /usr/share/doc/postfix
      recipient_delimiter = +
      relocated_maps = hash:/etc/postfix/maps/relocated
      smtp_sasl_security_options = noanonymous
      smtp_sasl_tls_security_options = noanonymous
      smtp_tls_cert_file = /root/ssl/certs/KLaM_Mail.pem
      smtp_tls_enforce_peername = no
      smtp_tls_key_file = /root/ssl/private/KLaM_Mail.key
      smtp_tls_loglevel = 0
      smtp_tls_note_starttls_offer = yes
      smtp_tls_security_level = may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      smtpd_banner = $myhostname ESMTP
      smtpd_client_restrictions =
      smtpd_data_restrictions = reject_multi_recipient_bounce,
      reject_unauth_pipelining
      smtpd_delay_reject = yes
      smtpd_error_sleep_time = 5s
      smtpd_etrn_restrictions = reject
      smtpd_helo_required = yes
      smtpd_helo_restrictions =
      smtpd_recipient_limit = 128
      smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
      reject_unauth_destination, reject_invalid_hostname,
      reject_non_fqdn_hostname, reject_non_fqdn_sender,
      reject_non_fqdn_recipient,
      reject_unknown_sender_domain, reject_unknown_recipient_domain,
      check_recipient_access pcre:/etc/postfix/maps/recipient_checks.pcre,
      check_helo_access hash:/etc/postfix/maps/helo_checks, check_helo_access
      pcre:/etc/postfix/maps/helo_checks.pcre, check_sender_access
      hash:/etc/postfix/maps/auto_whitelist, check_sender_access
      hash:/etc/postfix/maps/sender_checks, check_sender_access
      pcre:/etc/postfix/maps/sender_checks.pcre, check_client_access
      hash:/etc/postfix/maps/client_checks, check_client_access
      pcre:/etc/postfix/maps/client_checks.pcre, reject_rbl_client
      zen.spamhaus.org, reject_rbl_client bl.spamcop.net,
      check_policy_service
      inet:127.0.0.1:10023
      smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
      defer_unauth_destination
      smtpd_sasl_auth_enable = yes
      smtpd_sasl_authenticated_header = yes
      smtpd_sasl_local_domain = $mydomain
      smtpd_sasl_path = private/dovecot-auth
      smtpd_sasl_security_options = noanonymous
      smtpd_sasl_type = dovecot
      smtpd_sender_restrictions =
      smtpd_tls_ask_ccert = yes
      smtpd_tls_auth_only = yes
      smtpd_tls_cert_file = /root/ssl/certs/KLaM_Mail.pem
      smtpd_tls_key_file = /root/ssl/private/KLaM_Mail.key
      smtpd_tls_loglevel = 0
      smtpd_tls_mandatory_ciphers = medium
      smtpd_tls_mandatory_protocols = SSLv3, TLSv1
      smtpd_tls_received_header = yes
      smtpd_tls_req_ccert = no
      smtpd_tls_security_level = may
      smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
      smtpd_tls_session_cache_timeout = 3600s
      strict_rfc821_envelopes = yes
      virtual_alias_maps = hash:/etc/postfix/maps/valiases
      virtual_mailbox_domains = /etc/postfix/maps/vdomains
      virtual_mailbox_maps = hash:/etc/postfix/maps/vmailbox
      virtual_transport = lmtp:unix:private/dovecot-lmtp


      root@bilbo:~# postconf -Mf
      smtp inet n - n - - smtpd
      -o cleanup_service_name=pre-cleanup
      pickup fifo n - n 60 1 pickup
      -o cleanup_service_name=pre-cleanup
      submission inet n - n - 30 smtpd
      -o syslog_name=submit -o smtpd_client_connection_count_limit=15
      -o smtpd_client_connection_rate_limit=80
      -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes
      -o smtpd_delay_reject=yes
      -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
      -o cleanup_service_name=pre-cleanup
      qmgr fifo n - n 300 1 qmgr
      tlsmgr unix - - n 1000? 1 tlsmgr
      rewrite unix - - n - - trivial-rewrite
      bounce unix - - n - 0 bounce
      defer unix - - n - 0 bounce
      trace unix - - n - 0 bounce
      verify unix - - n - 1 verify
      flush unix n - n 1000? 0 flush
      proxymap unix - - n - - proxymap
      proxywrite unix - - n - 1 proxymap
      smtp unix - - n - - smtp
      relay unix - - n - - smtp
      showq unix n - n - - showq
      error unix - - n - - error
      retry unix - - n - - error
      discard unix - - n - - discard
      local unix - n n - - local
      virtual unix - n n - - virtual
      lmtp unix - - n - - lmtp
      anvil unix - - n - 1 anvil
      scache unix - - n - 1 scache
      smtp-amavis unix - - n - 4 smtp
      -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes
      -o disable_dns_lookups=yes -o smtp_tls_note_starttls_offer=no -o
      max_use=20
      127.0.0.1:10025 inet n - n - - smtpd
      -o content_filter= -o smtpd_delay_reject=no
      -o smtpd_client_restrictions=permit_mynetworks,reject
      -o smtpd_helo_restrictions= -o smtpd_sender_restrictions=
      -o smtpd_recipient_restrictions=permit_mynetworks,reject
      -o smtpd_data_restrictions=reject_unauth_pipelining
      -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes=
      -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0
      -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000
      -o smtpd_client_connection_count_limit=0
      -o smtpd_client_connection_rate_limit=0 -o
      local_header_rewrite_clients=
      -o local_recipient_maps=
      -o
      receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
      -o smtpd_tls_security_level=none -o local_recipient_maps=
      -o relay_recipient_maps=
      pre-cleanup unix n - n - 0 cleanup
      -o virtual_alias_maps=
      cleanup unix n - n - 0 cleanup
      -o mime_header_checks= -o nested_header_checks= -o header_checks=
      -o body_checks= -o sender_bcc_maps=hash:/etc/postfix/maps/sender_bcc
    • DTNX Postmaster
      ... [snip] ... Compare this to ours; == $ /usr/sbin/postconf -nf |grep message_size_limit message_size_limit = 31457280 == And the default;
      Message 2 of 16 , Aug 6, 2013
        On Aug 7, 2013, at 02:32, John Allen <john@...> wrote:

        > root@bilbo:~# postconf -nf

        [snip]

        > message_size_limit = 34359738368

        Compare this to ours;

        ==
        $ /usr/sbin/postconf -nf |grep message_size_limit
        message_size_limit = 31457280
        ==

        And the default;

        http://www.postfix.org/postconf.5.html#message_size_limit

        Is there any particular reason you need to accept messages 32 GB in size?

        Mvg,
        Joni
      • DTNX Postmaster
        ... [snip] ... http://www.postfix.org/postconf.5.html#smtp_tls_cert_file Are you sure you need those there? Have a look at your own config, and look up every
        Message 3 of 16 , Aug 6, 2013
          On Aug 7, 2013, at 02:32, John Allen <john@...> wrote:

          > root@bilbo:~# postconf -nf

          [snip]

          > smtp_tls_cert_file = /root/ssl/certs/KLaM_Mail.pem
          > smtp_tls_key_file = /root/ssl/private/KLaM_Mail.key

          http://www.postfix.org/postconf.5.html#smtp_tls_cert_file

          Are you sure you need those there?

          Have a look at your own config, and look up every setting in the
          documentation. Ask yourself if there are good reasons you are
          overriding the default, and whether your custom setting still makes
          sense given the recommendations from the documentation.

          Mvg,
          Joni
        • John Allen
          ... Yes. We support a business that designs and manufactures packaging and displays. The sort of thing you might see in the aisle of a supermarket or store
          Message 4 of 16 , Aug 7, 2013
            On 07/08/2013 1:49 AM, DTNX Postmaster wrote:
            > On Aug 7, 2013, at 02:32, John Allen <john@...> wrote:
            >
            >> root@bilbo:~# postconf -nf
            > [snip]
            >
            >> message_size_limit = 34359738368
            > Compare this to ours;
            >
            > ==
            > $ /usr/sbin/postconf -nf |grep message_size_limit
            > message_size_limit = 31457280
            > ==
            >
            > And the default;
            >
            > http://www.postfix.org/postconf.5.html#message_size_limit
            >
            > Is there any particular reason you need to accept messages 32 GB in size?
            >
            > Mvg,
            > Joni
            >
            Yes. We support a business that designs and manufactures packaging and
            displays. The sort of thing you might see in the aisle of a supermarket
            or store selling gum, personal care products. The graphics, art work
            and design of these need to be sent to the people involved. We have
            looked into using services like Dropbox but the problem with all of
            these is copyright. Our customers legal eagles have advise against such
            services as they may compromise their copyright on anything stored on
            such services.

            OT: It is the same advice and reasoning they gave against using public
            cloud services, some of whose terms of service essentially strip the
            user of all copyright ownership.
          • John Allen
            ... I am not sure. One of the problems we have is that a many of our clients work force are road warriors . While SASL allows us to confirm who is calling it
            Message 5 of 16 , Aug 7, 2013
              On 07/08/2013 2:09 AM, DTNX Postmaster wrote:
              > On Aug 7, 2013, at 02:32, John Allen <john@...> wrote:
              >
              >> root@bilbo:~# postconf -nf
              > [snip]
              >
              >> smtp_tls_cert_file = /root/ssl/certs/KLaM_Mail.pem
              >> smtp_tls_key_file = /root/ssl/private/KLaM_Mail.key
              > http://www.postfix.org/postconf.5.html#smtp_tls_cert_file
              >
              > Are you sure you need those there?
              >
              > Have a look at your own config, and look up every setting in the
              > documentation. Ask yourself if there are good reasons you are
              > overriding the default, and whether your custom setting still makes
              > sense given the recommendations from the documentation.
              >
              > Mvg,
              > Joni
              >
              I am not sure. One of the problems we have is that a many of our clients
              work force are "road warriors". While SASL allows us to confirm who is
              calling it does not protect the content from snooping, whereas TLS does.
              As some of the Far eastern countries are not averse to pilfering ideas
              we think this is worth while. However, suggestions for alternatives are
              welcome.
            • Mikael Bak
              ... I don t recall email being the only alternative to public cloud file storage solutions. Set up a file server of you own and keep copyrights in house. 32GB
              Message 6 of 16 , Aug 7, 2013
                On 08/07/2013 12:03 PM, John Allen wrote:
                >> Is there any particular reason you need to accept messages 32 GB in size?
                >>
                >>
                > Yes. We support a business that designs and manufactures packaging and
                > displays. The sort of thing you might see in the aisle of a supermarket
                > or store selling gum, personal care products. The graphics, art work
                > and design of these need to be sent to the people involved. We have
                > looked into using services like Dropbox but the problem with all of
                > these is copyright. Our customers legal eagles have advise against such
                > services as they may compromise their copyright on anything stored on
                > such services.
                >
                > OT: It is the same advice and reasoning they gave against using public
                > cloud services, some of whose terms of service essentially strip the
                > user of all copyright ownership.
                >
                >

                I don't recall email being the only alternative to public cloud file
                storage solutions.

                Set up a file server of you own and keep copyrights in house.
                32GB sized email messages is a mistake IMO.

                Mikael
              • DTNX Postmaster
                ... Have you read the documentation? I don t think you have. The smtp_tls_cert_file setting is for outgoing connections only, as in, your server sending to
                Message 7 of 16 , Aug 7, 2013
                  On Aug 7, 2013, at 12:15, John Allen <john@...> wrote:

                  > On 07/08/2013 2:09 AM, DTNX Postmaster wrote:
                  >> On Aug 7, 2013, at 02:32, John Allen <john@...> wrote:
                  >>
                  >>> root@bilbo:~# postconf -nf
                  >> [snip]
                  >>
                  >>> smtp_tls_cert_file = /root/ssl/certs/KLaM_Mail.pem
                  >>> smtp_tls_key_file = /root/ssl/private/KLaM_Mail.key
                  >> http://www.postfix.org/postconf.5.html#smtp_tls_cert_file
                  >>
                  >> Are you sure you need those there?
                  >>
                  >> Have a look at your own config, and look up every setting in the
                  >> documentation. Ask yourself if there are good reasons you are
                  >> overriding the default, and whether your custom setting still makes
                  >> sense given the recommendations from the documentation.
                  >>
                  > I am not sure. One of the problems we have is that a many of our clients work force are "road warriors". While SASL allows us to confirm who is calling it does not protect the content from snooping, whereas TLS does. As some of the Far eastern countries are not averse to pilfering ideas we think this is worth while. However, suggestions for alternatives are welcome.

                  Have you read the documentation? I don't think you have. The
                  'smtp_tls_cert_file' setting is for outgoing connections only, as in,
                  your server sending to other servers.

                  Has nothing to do with road warriors, and unless you have an upstream
                  relay that requires a client certificate to send mail, you should
                  probably stick with the recommended defaults.

                  Mvg,
                  Joni
                • Thomas Harold
                  ... Or implement a version control system (such as subversion) that communicates over HTTPS or SSH. We find it works better for road-warriors because only the
                  Message 8 of 16 , Aug 7, 2013
                    On 8/7/2013 7:09 AM, Mikael Bak wrote:
                    >
                    > I don't recall email being the only alternative to public cloud file
                    > storage solutions.
                    >
                    > Set up a file server of you own and keep copyrights in house.
                    > 32GB sized email messages is a mistake IMO.
                    >

                    Or implement a version control system (such as subversion) that
                    communicates over HTTPS or SSH. We find it works better for
                    road-warriors because only the file differences get transmitted and
                    faster because they're working on local copies of the files.
                  • DTNX Postmaster
                    ... And they are regularly sending you files, via e-mail, up to 32 GB in size? Attachments that are larger than, say, 1 GB? Does the sending mail server allow
                    Message 9 of 16 , Aug 7, 2013
                      On Aug 7, 2013, at 12:03, John Allen <john@...> wrote:

                      > On 07/08/2013 1:49 AM, DTNX Postmaster wrote:
                      >> On Aug 7, 2013, at 02:32, John Allen <john@...> wrote:
                      >>
                      >>> root@bilbo:~# postconf -nf
                      >> [snip]
                      >>
                      >>> message_size_limit = 34359738368
                      >> Compare this to ours;
                      >>
                      >> ==
                      >> $ /usr/sbin/postconf -nf |grep message_size_limit
                      >> message_size_limit = 31457280
                      >> ==
                      >>
                      >> And the default;
                      >>
                      >> http://www.postfix.org/postconf.5.html#message_size_limit
                      >>
                      >> Is there any particular reason you need to accept messages 32 GB in size?
                      >>
                      > Yes. We support a business that designs and manufactures packaging and displays. The sort of thing you might see in the aisle of a supermarket or store selling gum, personal care products. The graphics, art work and design of these need to be sent to the people involved. We have looked into using services like Dropbox but the problem with all of these is copyright. Our customers legal eagles have advise against such services as they may compromise their copyright on anything stored on such services.
                      >
                      > OT: It is the same advice and reasoning they gave against using public cloud services, some of whose terms of service essentially strip the user of all copyright ownership.

                      And they are regularly sending you files, via e-mail, up to 32 GB in
                      size? Attachments that are larger than, say, 1 GB? Does the sending
                      mail server allow attachments that big in outgoing mail? Does your
                      queue directory reside on a partition that has that much room?

                      When have you last grepped through your logs to look at the actual
                      sizes of the messages that are coming in? What is the largest message
                      size you have received in, say, the last four weeks?

                      I find it all a wee bit hard to believe. You see, we also support
                      similar businesses, and have for many years. For large files, they are
                      uploaded over SFTP, and downloaded via same, or HTTP. And increasingly,
                      they are using WeTransfer for this. Check their terms, several of our
                      clients have abandoned their local file transfer setups for it.

                      But please, stop abusing e-mail for this. It's insane, and a disaster
                      waiting to happen.

                      Mvg,
                      Joni
                    • Patrick Lists
                      On 08/07/2013 12:03 PM, John Allen wrote: [snip] ... Maybe look into an on-premise dropbox alternative: http://owncloud.org/ Regards, Patrick
                      Message 10 of 16 , Aug 7, 2013
                        On 08/07/2013 12:03 PM, John Allen wrote:
                        [snip]
                        > Yes. We support a business that designs and manufactures packaging and
                        > displays. The sort of thing you might see in the aisle of a supermarket
                        > or store selling gum, personal care products. The graphics, art work
                        > and design of these need to be sent to the people involved. We have
                        > looked into using services like Dropbox but the problem with all of
                        > these is copyright. Our customers legal eagles have advise against such
                        > services as they may compromise their copyright on anything stored on
                        > such services.
                        >
                        > OT: It is the same advice and reasoning they gave against using public
                        > cloud services, some of whose terms of service essentially strip the
                        > user of all copyright ownership.

                        Maybe look into an on-premise dropbox alternative: http://owncloud.org/

                        Regards,
                        Patrick
                      • LuKreme
                        ... Or something like ShareFile. (I ve never used ShareFile, only heard of it).
                        Message 11 of 16 , Aug 7, 2013
                          On 07 Aug 2013, at 06:37 , Patrick Lists <postfix-list@...> wrote:

                          > On 08/07/2013 12:03 PM, John Allen wrote:
                          > [snip]
                          >> Yes. We support a business that designs and manufactures packaging and
                          >> displays. The sort of thing you might see in the aisle of a supermarket
                          >> or store selling gum, personal care products. The graphics, art work
                          >> and design of these need to be sent to the people involved. We have
                          >> looked into using services like Dropbox but the problem with all of
                          >> these is copyright. Our customers legal eagles have advise against such
                          >> services as they may compromise their copyright on anything stored on
                          >> such services.
                          >>
                          >> OT: It is the same advice and reasoning they gave against using public
                          >> cloud services, some of whose terms of service essentially strip the
                          >> user of all copyright ownership.
                          >
                          > Maybe look into an on-premise dropbox alternative: http://owncloud.org/

                          Or something like ShareFile.

                          (I've never used ShareFile, only heard of it).

                          <http://www.sharefile.com/?aid=24499555820&src=google&kw=sharefile&gclid=CNKL3smz67gCFelAMgod6VYAFw>

                          --
                          Ah we're lonely, we're romantic / and the cider's laced with acid / and
                          the Holy Spirit's crying, Where's the beef? / And the moon is swimming
                          naked / and the summer night is fragrant / with a mighty expectation of
                          relief
                        • John Allen
                          ... We have already setup a webdav system for saving large attachments, the in house users are supposed to use this for internal mail. This still leaves the
                          Message 12 of 16 , Aug 7, 2013
                            On 07/08/2013 8:25 AM, DTNX Postmaster wrote:
                            > On Aug 7, 2013, at 12:03, John Allen <john@...> wrote:
                            >
                            >> On 07/08/2013 1:49 AM, DTNX Postmaster wrote:
                            >>> On Aug 7, 2013, at 02:32, John Allen <john@...> wrote:
                            >>>
                            >>>> root@bilbo:~# postconf -nf
                            >>> [snip]
                            >>>
                            >>>> message_size_limit = 34359738368
                            >>> Compare this to ours;
                            >>>
                            >>> ==
                            >>> $ /usr/sbin/postconf -nf |grep message_size_limit
                            >>> message_size_limit = 31457280
                            >>> ==
                            >>>
                            >>> And the default;
                            >>>
                            >>> http://www.postfix.org/postconf.5.html#message_size_limit
                            >>>
                            >>> Is there any particular reason you need to accept messages 32 GB in size?
                            >>>
                            >> Yes. We support a business that designs and manufactures packaging and displays. The sort of thing you might see in the aisle of a supermarket or store selling gum, personal care products. The graphics, art work and design of these need to be sent to the people involved. We have looked into using services like Dropbox but the problem with all of these is copyright. Our customers legal eagles have advise against such services as they may compromise their copyright on anything stored on such services.
                            >>
                            >> OT: It is the same advice and reasoning they gave against using public cloud services, some of whose terms of service essentially strip the user of all copyright ownership.
                            > And they are regularly sending you files, via e-mail, up to 32 GB in
                            > size? Attachments that are larger than, say, 1 GB? Does the sending
                            > mail server allow attachments that big in outgoing mail? Does your
                            > queue directory reside on a partition that has that much room?
                            >
                            > When have you last grepped through your logs to look at the actual
                            > sizes of the messages that are coming in? What is the largest message
                            > size you have received in, say, the last four weeks?
                            >
                            > I find it all a wee bit hard to believe. You see, we also support
                            > similar businesses, and have for many years. For large files, they are
                            > uploaded over SFTP, and downloaded via same, or HTTP. And increasingly,
                            > they are using WeTransfer for this. Check their terms, several of our
                            > clients have abandoned their local file transfer setups for it.
                            >
                            > But please, stop abusing e-mail for this. It's insane, and a disaster
                            > waiting to happen.
                            >
                            > Mvg,
                            > Joni
                            We have already setup a webdav system for saving large attachments, the
                            in house users are supposed to use this for internal mail.
                            This still leaves the problem of contractors and suppliers. The problem
                            here is how to isolate them from each other and the whole from the
                            outsider.
                          • DTNX Postmaster
                            ... It is a solved problem, has been for years. For example, a SFTP or FTPS server; contractors and suppliers each get their own login and are locked into
                            Message 13 of 16 , Aug 7, 2013
                              On Aug 7, 2013, at 16:32, John Allen <john@...> wrote:

                              >>>> Is there any particular reason you need to accept messages 32 GB in size?
                              >>>>
                              >>> Yes. We support a business that designs and manufactures packaging and displays. The sort of thing you might see in the aisle of a supermarket or store selling gum, personal care products. The graphics, art work and design of these need to be sent to the people involved. We have looked into using services like Dropbox but the problem with all of these is copyright. Our customers legal eagles have advise against such services as they may compromise their copyright on anything stored on such services.
                              >>>
                              >>> OT: It is the same advice and reasoning they gave against using public cloud services, some of whose terms of service essentially strip the user of all copyright ownership.
                              >> And they are regularly sending you files, via e-mail, up to 32 GB in
                              >> size? Attachments that are larger than, say, 1 GB? Does the sending
                              >> mail server allow attachments that big in outgoing mail? Does your
                              >> queue directory reside on a partition that has that much room?
                              >>
                              >> When have you last grepped through your logs to look at the actual
                              >> sizes of the messages that are coming in? What is the largest message
                              >> size you have received in, say, the last four weeks?
                              >>
                              >> I find it all a wee bit hard to believe. You see, we also support
                              >> similar businesses, and have for many years. For large files, they are
                              >> uploaded over SFTP, and downloaded via same, or HTTP. And increasingly,
                              >> they are using WeTransfer for this. Check their terms, several of our
                              >> clients have abandoned their local file transfer setups for it.
                              >>
                              >> But please, stop abusing e-mail for this. It's insane, and a disaster
                              >> waiting to happen.
                              >
                              > We have already setup a webdav system for saving large attachments, the in house users are supposed to use this for internal mail.
                              > This still leaves the problem of contractors and suppliers. The problem here is how to isolate them from each other and the whole from the outsider.

                              It is a solved problem, has been for years. For example, a SFTP or FTPS
                              server; contractors and suppliers each get their own login and are
                              locked into their home directory. They only see their own files, no one
                              else's.

                              Or you use one of the several options out there in terms of web based
                              project management and whatnot, such as activeCollab, or one of the
                              suggestions made here on the list. Each user only has access to
                              relevant projects, and you have the advantage of storing file metadata
                              such as description, comments, versioning and so on.

                              And at the very least, review your logs for the actual sizes of
                              incoming messages, and see what usage dictates. I have a hunch it is
                              going to be much lower than your current limit.

                              Mvg,
                              Joni
                            • Sam Flint
                              Try ownCloud, it provides webdav and sharing. ... -- Sam Flint flintfam.org/~swflint
                              Message 14 of 16 , Aug 9, 2013
                                Try ownCloud, it provides webdav and sharing.

                                On Wed, Aug 7, 2013 at 10:17 AM, DTNX Postmaster <postmaster@...> wrote:
                                > On Aug 7, 2013, at 16:32, John Allen <john@...> wrote:
                                >
                                >>>>> Is there any particular reason you need to accept messages 32 GB in size?
                                >>>>>
                                >>>> Yes. We support a business that designs and manufactures packaging and displays. The sort of thing you might see in the aisle of a supermarket or store selling gum, personal care products. The graphics, art work and design of these need to be sent to the people involved. We have looked into using services like Dropbox but the problem with all of these is copyright. Our customers legal eagles have advise against such services as they may compromise their copyright on anything stored on such services.
                                >>>>
                                >>>> OT: It is the same advice and reasoning they gave against using public cloud services, some of whose terms of service essentially strip the user of all copyright ownership.
                                >>> And they are regularly sending you files, via e-mail, up to 32 GB in
                                >>> size? Attachments that are larger than, say, 1 GB? Does the sending
                                >>> mail server allow attachments that big in outgoing mail? Does your
                                >>> queue directory reside on a partition that has that much room?
                                >>>
                                >>> When have you last grepped through your logs to look at the actual
                                >>> sizes of the messages that are coming in? What is the largest message
                                >>> size you have received in, say, the last four weeks?
                                >>>
                                >>> I find it all a wee bit hard to believe. You see, we also support
                                >>> similar businesses, and have for many years. For large files, they are
                                >>> uploaded over SFTP, and downloaded via same, or HTTP. And increasingly,
                                >>> they are using WeTransfer for this. Check their terms, several of our
                                >>> clients have abandoned their local file transfer setups for it.
                                >>>
                                >>> But please, stop abusing e-mail for this. It's insane, and a disaster
                                >>> waiting to happen.
                                >>
                                >> We have already setup a webdav system for saving large attachments, the in house users are supposed to use this for internal mail.
                                >> This still leaves the problem of contractors and suppliers. The problem here is how to isolate them from each other and the whole from the outsider.
                                >
                                > It is a solved problem, has been for years. For example, a SFTP or FTPS
                                > server; contractors and suppliers each get their own login and are
                                > locked into their home directory. They only see their own files, no one
                                > else's.
                                >
                                > Or you use one of the several options out there in terms of web based
                                > project management and whatnot, such as activeCollab, or one of the
                                > suggestions made here on the list. Each user only has access to
                                > relevant projects, and you have the advantage of storing file metadata
                                > such as description, comments, versioning and so on.
                                >
                                > And at the very least, review your logs for the actual sizes of
                                > incoming messages, and see what usage dictates. I have a hunch it is
                                > going to be much lower than your current limit.
                                >
                                > Mvg,
                                > Joni
                                >



                                --
                                Sam Flint
                                flintfam.org/~swflint
                              • John Hudak
                                So the real issue is a concern that one of the customers may gain access to files from another one of your customers and steal some copyright info? So the
                                Message 15 of 16 , Aug 9, 2013
                                  So the real issue is a concern that one of the customers may gain access to files from another one of your customers and steal some copyright info?

                                  So the legal folks want 'proof' that orgs like Dropbox have protections in place to avoid the theft of copyright info?  I doubt that any org will give out that guarantee - but maybe there are....

                                  If data confidentiality is the issue, the use of ownCloud in your organization is going to put that burden of proof on your shoulders, so you will have to deal with all the technical and legal issues.

                                  Why not use the best encryption techniques available e.g. 256 bit AES encryption (?)  to secure the data?



                                  On Fri, Aug 9, 2013 at 10:53 AM, Sam Flint <harmonicnm7h@...> wrote:
                                  Try ownCloud, it provides webdav and sharing.

                                  On Wed, Aug 7, 2013 at 10:17 AM, DTNX Postmaster <postmaster@...> wrote:
                                  > On Aug 7, 2013, at 16:32, John Allen <john@...> wrote:
                                  >
                                  >>>>> Is there any particular reason you need to accept messages 32 GB in size?
                                  >>>>>
                                  >>>> Yes. We support a business that designs and manufactures packaging and displays. The sort of thing you might see in the aisle of a supermarket or store selling gum, personal care products.  The graphics, art work and design of these need to be sent to the people involved. We have looked into using services like Dropbox but the problem with all of these is copyright. Our customers legal eagles have advise against such services as they may compromise their copyright on anything stored on such services.
                                  >>>>
                                  >>>> OT: It is the same advice and reasoning they gave against using public cloud services, some of whose terms of service essentially strip the user of all copyright ownership.
                                  >>> And they are regularly sending you files, via e-mail, up to 32 GB in
                                  >>> size? Attachments that are larger than, say, 1 GB? Does the sending
                                  >>> mail server allow attachments that big in outgoing mail? Does your
                                  >>> queue directory reside on a partition that has that much room?
                                  >>>
                                  >>> When have you last grepped through your logs to look at the actual
                                  >>> sizes of the messages that are coming in? What is the largest message
                                  >>> size you have received in, say, the last four weeks?
                                  >>>
                                  >>> I find it all a wee bit hard to believe. You see, we also support
                                  >>> similar businesses, and have for many years. For large files, they are
                                  >>> uploaded over SFTP, and downloaded via same, or HTTP. And increasingly,
                                  >>> they are using WeTransfer for this. Check their terms, several of our
                                  >>> clients have abandoned their local file transfer setups for it.
                                  >>>
                                  >>> But please, stop abusing e-mail for this. It's insane, and a disaster
                                  >>> waiting to happen.
                                  >>
                                  >> We have already setup a webdav system for saving large attachments, the in house users are supposed to use this for internal mail.
                                  >> This still leaves the problem of contractors and suppliers. The problem here is how to isolate them from each other and the whole from the outsider.
                                  >
                                  > It is a solved problem, has been for years. For example, a SFTP or FTPS
                                  > server; contractors and suppliers each get their own login and are
                                  > locked into their home directory. They only see their own files, no one
                                  > else's.
                                  >
                                  > Or you use one of the several options out there in terms of web based
                                  > project management and whatnot, such as activeCollab, or one of the
                                  > suggestions made here on the list. Each user only has access to
                                  > relevant projects, and you have the advantage of storing file metadata
                                  > such as description, comments, versioning and so on.
                                  >
                                  > And at the very least, review your logs for the actual sizes of
                                  > incoming messages, and see what usage dictates. I have a hunch it is
                                  > going to be much lower than your current limit.
                                  >
                                  > Mvg,
                                  > Joni
                                  >



                                  --
                                  Sam Flint
                                  flintfam.org/~swflint

                                • Saša Babić
                                  ... Or FileSender: https://www.filesender.org/
                                  Message 16 of 16 , Aug 9, 2013
                                    On 07.08.2013. 15:08, LuKreme wrote:
                                    >
                                    > On 07 Aug 2013, at 06:37 , Patrick Lists <postfix-list@...> wrote:
                                    >
                                    >> On 08/07/2013 12:03 PM, John Allen wrote:
                                    >> [snip]
                                    >>> Yes. We support a business that designs and manufactures packaging and
                                    >>> displays. The sort of thing you might see in the aisle of a supermarket
                                    >>> or store selling gum, personal care products. The graphics, art work
                                    >>> and design of these need to be sent to the people involved. We have
                                    >>> looked into using services like Dropbox but the problem with all of
                                    >>> these is copyright. Our customers legal eagles have advise against such
                                    >>> services as they may compromise their copyright on anything stored on
                                    >>> such services.
                                    >>>
                                    >>> OT: It is the same advice and reasoning they gave against using public
                                    >>> cloud services, some of whose terms of service essentially strip the
                                    >>> user of all copyright ownership.
                                    >>
                                    >> Maybe look into an on-premise dropbox alternative: http://owncloud.org/
                                    >
                                    > Or something like ShareFile.

                                    Or FileSender: https://www.filesender.org/
                                  Your message has been successfully submitted and would be delivered to recipients shortly.