Reliably distinguishing authorized vs unauthorized users
I am working on a spam filter. I want both incoming and outgoing messages to go through the filter, not because the outgoing messages need to be filtered, but because I want the filter to know who my authorized users have sent messages to because that is a very reliable indicator of non-spam. My setup requires users to authenticate, so postfix knows who they are. My question is: is there a reliable way to pass this information to a filter? I can't find anything about this in the documentation. Reverse engineering indicates that postfix puts an "Authenticated sender" note in the received-from header, but that can be forged. Is there a reliable way for a filter to tell if a message is from an authenticated user? Thanks, rg
Re: Reliably distinguishing authorized vs unauthorized users
On Jan 19, 2011, at 12:06 PM, John Adams wrote: > Am 19.01.2011 21:03, schrieb Ron Garret: >> I am working on a spam filter. I want both incoming and outgoing messages >> to go through the filter, not because the outgoing messages need to be >> filtered, but because I want the filter to know who my authorized users have >> sent messages to because that is a very reliable indicator of non-spam. My >> setup requires users to authenticate, so postfix knows who they are. My >> question is: is there a reliable way to pass this information to a filter? >> I can't find anything about this in the documentation. Reverse engineering >> indicates that postfix puts an "Authenticated sender" note in the >> received-from header, but that can be forged. Is there a reliable way for a >> filter to tell if a message is from an authenticated user? >> >> Thanks, >> rg >> > > Yes, spamassassin+amavisd-new. > spamassassin recognizes the authentication header put there by postfix. > There's plenty of documentation around how to do this kind of setup. Indeed there is a lot of info out there if you know where to look, I just wasn't looking in the right places. Thanks! rg
Relay host auth not working
I'm trying to set up a relay host with authentication according to these
instructions:
http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/
but it's not working. I know my SMTP server is set up properly because I can
send mail using various other clients, but postfix is apparently not even
attempting to authorize. Here are the relevant lines from main.cf:
relayhost = secure.genesisgroup.info
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
Here is a log excerpt from my server from a successful login from a different
client (python smtplib):
Jul 11 17:59:57 vm01 postfix/smtpd[812]: connect from
ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]
Jul 11 17:59:58 vm01 postfix/smtpd[812]: A567C4CA949:
client=ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10],
sasl_method=LOGIN, sasl_username=XXX
and here's the same thing when Postfix tries to connect between the same two
machines:
Jul 11 18:00:26 vm01 postfix/smtpd[820]: connect from
ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]
Jul 11 18:00:26 vm01 postfix/smtpd[820]: NOQUEUE: reject: RCPT from
ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]: 554 5.7.1
: Relay access denied; from=
to= proto=ESMTP helo=
As you can see, postfix is not even attempting to authorize.
What am I doing wrong? This postfix is running on EC2 using one of their stock
images. A full postconf dump is attached.
Thanks,
rg
---
$ postconf
2bounce_notice_recipient = postmaster
access_map_defer_code = 450
access_map_reject_code = 554
address_verify_default_transport = $default_transport
address_verify_local_transport = $local_transport
address_verify_map =
address_verify_negative_cache = yes
address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 3h
address_verify_poll_count = ${stress?1}${stress:3}
address_verify_poll_delay = 3s
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d
address_verify_relay_transport = $relay_transport
address_verify_relayhost = $relayhost
address_verify_sender = $double_bounce_sender
address_verify_sender_dependent_relayhost_maps =
$sender_dependent_relayhost_maps
address_verify_service_name = verify
address_verify_transport_maps = $transport_maps
address_verify_virtual_transport = $virtual_transport
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_mail_to_commands = alias, forward
allow_mail_to_files = alias, forward
allow_min_user = no
allow_percent_hack = yes
allow_untrusted_routing = no
alternate_config_directories =
always_add_missing_headers = no
always_bcc =
anvil_rate_time_unit = 60s
anvil_status_update_time = 600s
append_at_myorigin = yes
append_dot_mydomain = yes
application_event_drain_time = 100s
authorized_flush_users = static:anyone
authorized_mailq_users = static:anyone
authorized_submit_users = static:anyone
backwards_bounce_logfile_compatibility = yes
berkeley_db_create_buffer_size = 16777216
berkeley_db_read_buffer_size = 131072
best_mx_transport =
biff = yes
body_checks =
body_checks_size_limit = 51200
bounce_notice_recipient = postmaster
bounce_queue_lifetime = 5d
bounce_service_name = bounce
bounce_size_limit = 5
bounce_template_file =
broken_sasl_auth_clients = no
canonical_classes = envelope_sender, envelope_recipient, header_sender,
header_recipient
canonical_maps =
cleanup_service_name = cleanup
command_directory = /usr/sbin
command_execution_directory =
command_expansion_filter =
1234567890!@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
command_time_limit = 1000s
config_directory = /etc/postfix
connection_cache_protocol_timeout = 5s
connection_cache_service_name = scache
connection_cache_status_update_time = 600s
connection_cache_ttl_limit = 2s
content_filter =
cyrus_sasl_config_path =
daemon_directory = /usr/libexec/postfix
daemon_timeout = 18000s
data_directory = /var/lib/postfix
debug_peer_level = 2
debug_peer_list =
default_database_type = hash
default_delivery_slot_cost = 5
default_delivery_slot_discount = 50
default_delivery_slot_loan = 3
default_destination_concurrency_failed_cohort_limit = 1
default_destination_concurrency_limit = 20
default_destination_concurrency_negative_feedback = 1
default_destination_concurrency_positive_feedback = 1
default_destination_rate_delay = 0s
default_destination_recipient_limit = 50
default_extra_recipient_limit = 1000
default_minimum_delivery_slots = 3
default_privs = nobody
default_process_limit = 100
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what]
blocked using $rbl_domain${rbl_reason?; $rbl_reason}
default_recipient_limit = 2
default_recipient_refill_delay = 5s
default_recipient_refill_limit = 100
default_transport = smtp
default_verp_delimiters = +=
defer_code = 450
defer_service_name = defer
defer_transports =
delay_logging_resolution_limit = 2
delay_notice_recipient = postmaster
delay_wa
Re: Relay host auth not working
On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: > On 7/11/2011 8:12 PM, Ron Garret wrote: >> I'm trying to set up a relay host with authentication according to these >> instructions: >> >> http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ >> >> but it's not working. I know my SMTP server is set up properly because I >> can send mail using various other clients, but postfix is apparently not >> even attempting to authorize. Here are the relevant lines from main.cf: >> >> relayhost = secure.genesisgroup.info >> smtp_sasl_auth_enable = yes >> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >> smtp_sasl_security_options = >> >> Here is a log excerpt from my server from a successful login from a >> different client (python smtplib): >> >> Jul 11 17:59:57 vm01 postfix/smtpd[812]: connect from >> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >> Jul 11 17:59:58 vm01 postfix/smtpd[812]: A567C4CA949: >> client=ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10], >> sasl_method=LOGIN, sasl_username=XXX >> >> and here's the same thing when Postfix tries to connect between the same two >> machines: >> >> Jul 11 18:00:26 vm01 postfix/smtpd[820]: connect from >> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >> Jul 11 18:00:26 vm01 postfix/smtpd[820]: NOQUEUE: reject: RCPT from >> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]: 554 5.7.1 >> : Relay access denied; from= >> to= proto=ESMTP helo= >> >> As you can see, postfix is not even attempting to authorize. >> >> What am I doing wrong? > > You're not telling us what you're attempting to accomplish for starters. Sorry, I thought that would be clear from the context. I'm trying to do exactly what you say: > When you specify relayhost you're telling Postfix to forward all non > local outbound mail to a gateway instead of delivering it directly to > internet MX destinations. Yes, that is exactly what I'm trying to do. The reason is that mail sent directly from an EC2 instance is usually flagged as spam by many mail recipients because the reverse DNS doesn't resolve properly. > You're showing smtpd logging, but the relayhost parameter applies to > smtp, not smtpd. Your logging shows a host connecting to your Postfix > server, not your Postfix server connecting to secure.genesisgroup.info. The log excerpts are taken from the postfix server on secure.genesisgroup.info, which is the machine I want to use to relay outbound mail from the EC2 instance. Sorry that wasn't clear. > Either you don't understand the relayhost parameter, or I simply don't > understand your goal here, or probably both. Well, I'm clearly missing something. But I don't think it's the relayhost parameter. rg
Re: Relay host auth not working
On Jul 11, 2011, at 11:03 PM, Jeroen Geilman wrote: > On 2011-07-12 07:12, Ron Garret wrote: >> On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: >> >>> On 7/11/2011 8:12 PM, Ron Garret wrote: >>>> I'm trying to set up a relay host with authentication according to these >>>> instructions: >>>> >>>> http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ >>>> >>>> but it's not working. I know my SMTP server is set up properly because I >>>> can send mail using various other clients, but postfix is apparently not >>>> even attempting to authorize. Here are the relevant lines from main.cf: > > No. > Include the FULL output from postconf -n, [ron@domU-12-31-39-00-E6-ED:~]$ postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 html_directory = no inet_interfaces = localhost inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost mydomain = sunfire-offices.com myhostname = mail.sunfire-offices.com myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES relayhost = secure.genesisgroup.info sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = unknown_local_recipient_reject_code = 550 > or, even better, the postfinger tool. Postfinger - Postfix Configuration on Tue Jul 12 06:08:45 UTC 2011 $Revision: 1.25 $ Warning: Postfinger output may show private configuration information, such as ip addresses and/or domain names which you do not want to show to the public. If this is the case it is your responsibility to modify the output to hide this private information. [Remove this warning with the --nowarn option.] --System Parameters-- mail_version = 2.6.6 hostname = domU-12-31-39-00-E6-ED uname = Linux domU-12-31-39-00-E6-ED 2.6.35.11-83.9.amzn1.x86_64 #1 SMP Sat Feb 19 23:42:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux --Packaging information-- looks like this postfix comes from a RPM package: postfix-2.6.6-2.8.amzn1.x86_64 --main.cf non-default parameters-- alias_maps = hash:/etc/aliases inet_interfaces = localhost inet_protocols = all mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydomain = sunfire-offices.com myhostname = mail.sunfire-offices.com myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES relayhost = secure.genesisgroup.info sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail.postfix smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = --master.cf-- smtp inet n - n - - smtpd pickupfifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgrunix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounceunix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verifyunix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp -o smtp_fallback_relay= 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 scacheunix - - n - 1 scache -- end of Postfinger output -- > We can only guess what you're doing wrong now. I did include the output from postconf at the end of my original message. rg
Re: Relay host auth not working
On Jul 11, 2011, at 11:07 PM, Stan Hoeppner wrote: > On 7/12/2011 12:12 AM, Ron Garret wrote: >> >> On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: >> >>> On 7/11/2011 8:12 PM, Ron Garret wrote: >>>> I'm trying to set up a relay host with authentication according to these >>>> instructions: >>>> >>>> http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ >>>> >>>> but it's not working. I know my SMTP server is set up properly because I >>>> can send mail using various other clients, but postfix is apparently not >>>> even attempting to authorize. Here are the relevant lines from main.cf: >>>> >>>> relayhost = secure.genesisgroup.info >>>> smtp_sasl_auth_enable = yes >>>> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >>>> smtp_sasl_security_options = >>>> >>>> Here is a log excerpt from my server from a successful login from a >>>> different client (python smtplib): >>>> >>>> Jul 11 17:59:57 vm01 postfix/smtpd[812]: connect from >>>> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >>>> Jul 11 17:59:58 vm01 postfix/smtpd[812]: A567C4CA949: >>>> client=ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10], >>>> sasl_method=LOGIN, sasl_username=XXX >>>> >>>> and here's the same thing when Postfix tries to connect between the same >>>> two machines: >>>> >>>> Jul 11 18:00:26 vm01 postfix/smtpd[820]: connect from >>>> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >>>> Jul 11 18:00:26 vm01 postfix/smtpd[820]: NOQUEUE: reject: RCPT from >>>> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]: 554 5.7.1 >>>> : Relay access denied; >>>> from= to= proto=ESMTP >>>> helo= >>>> >>>> As you can see, postfix is not even attempting to authorize. >>>> >>>> What am I doing wrong? >>> >>> You're not telling us what you're attempting to accomplish for starters. >> >> Sorry, I thought that would be clear from the context. I'm trying to do >> exactly what you say: >> >>> When you specify relayhost you're telling Postfix to forward all non >>> local outbound mail to a gateway instead of delivering it directly to >>> internet MX destinations. >> >> Yes, that is exactly what I'm trying to do. The reason is that mail sent >> directly from an EC2 instance is usually flagged as spam by many mail >> recipients because the reverse DNS doesn't resolve properly. >> >>> You're showing smtpd logging, but the relayhost parameter applies to >>> smtp, not smtpd. Your logging shows a host connecting to your Postfix >>> server, not your Postfix server connecting to secure.genesisgroup.info. >> >> >> The log excerpts are taken from the postfix server on >> secure.genesisgroup.info, which is the machine I want to use to relay >> outbound mail from the EC2 instance. Sorry that wasn't clear. > > Ok, now the logging snippets make sense. I'm guessing you simply need > to add permit_sasl_authenticated to your smtpd_client_restrictions on > host secure.genesisgroup.info, or if you use the "everything under > smtpd_recipient_restrictions" main.cf style you'd do: > > smtpd_recipient_restrictions = >permit_mynetworks > permit_sasl_authenticated >reject_unauth_destination > ... No, that's not the problem. I already have exactly that on secure.genesisgroup.info. (See below.) And I have multiple clients successfully using that host for authenticated SMTP, including a python client running on the same machine that the non-working (in this respect) postfix is running on. > You provided 'postconf -d' instead of 'postconf -n', so it's impossible > for me to tell what your parameters actually are. "-d" simply shows the > Postfix defaults. Please provide 'postconf -n' so we can wrap this > thread up, assuming permit_sasl_authenticated doesn't fix the problem. Actually, it was postconf with no arguments. Here is postconf -n: [ron@domU-12-31-39-00-E6-ED:~]$ postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 html_dire
Re: Relay host auth not working
On Jul 11, 2011, at 11:17 PM, Mike Morris wrote: > On 07/11/2011 10:12 PM, Ron Garret wrote: >> >> On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: >> >>> On 7/11/2011 8:12 PM, Ron Garret wrote: >>>> I'm trying to set up a relay host with authentication according to these >>>> instructions: >>>> >>>> http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ >>>> >>>> but it's not working. I know my SMTP server is set up properly because I >>>> can send mail using various other clients, but postfix is apparently not >>>> even attempting to authorize. Here are the relevant lines from main.cf: >>>> >>>> relayhost = secure.genesisgroup.info >>>> smtp_sasl_auth_enable = yes >>>> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >>>> smtp_sasl_security_options = >>>> >>>> Here is a log excerpt from my server from a successful login from a >>>> different client (python smtplib): >>>> >>>> Jul 11 17:59:57 vm01 postfix/smtpd[812]: connect from >>>> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >>>> Jul 11 17:59:58 vm01 postfix/smtpd[812]: A567C4CA949: >>>> client=ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10], >>>> sasl_method=LOGIN, sasl_username=XXX >>>> >>>> and here's the same thing when Postfix tries to connect between the same >>>> two machines: >>>> >>>> Jul 11 18:00:26 vm01 postfix/smtpd[820]: connect from >>>> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >>>> Jul 11 18:00:26 vm01 postfix/smtpd[820]: NOQUEUE: reject: RCPT from >>>> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]: 554 5.7.1 >>>> : Relay access denied; >>>> from= to= proto=ESMTP >>>> helo= >>>> >>>> As you can see, postfix is not even attempting to authorize. >>>> >>>> What am I doing wrong? >>> >>> You're not telling us what you're attempting to accomplish for starters. >> >> Sorry, I thought that would be clear from the context. I'm trying to do >> exactly what you say: >> >>> When you specify relayhost you're telling Postfix to forward all non >>> local outbound mail to a gateway instead of delivering it directly to >>> internet MX destinations. >> >> Yes, that is exactly what I'm trying to do. The reason is that mail sent >> directly from an EC2 instance is usually flagged as spam by many mail >> recipients because the reverse DNS doesn't resolve properly. >> >>> You're showing smtpd logging, but the relayhost parameter applies to >>> smtp, not smtpd. Your logging shows a host connecting to your Postfix >>> server, not your Postfix server connecting to secure.genesisgroup.info. >> >> >> The log excerpts are taken from the postfix server on >> secure.genesisgroup.info, which is the machine I want to use to relay >> outbound mail from the EC2 instance. Sorry that wasn't clear. >> >>> Either you don't understand the relayhost parameter, or I simply don't >>> understand your goal here, or probably both. >> >> >> Well, I'm clearly missing something. But I don't think it's the relayhost >> parameter. >> >> rg >> > > As stated by Jeroen, supplying the list with the output of 'postconf -n' > would be much more preferred than sending the entire output of > 'postconf'. There is no need for people to wade through hundreds of > lines that are configured for default values. Sorry, I'm still kinda new at this. > The server at secure.genesisgroup.info only advertises AUTH support > after STARTTLS. Therefore, in order to successfully authenticate with > that server from the client at 184.73.65.10, the following configuration > changes will need to be made on 184.73.65.10: > > Configure smtp_tls_security_level and/or smtp_tls_policy_maps, using at > least a setting of 'may'. This will allow the SMTP client to attempt > STARTTLS connections with remote hosts. Ah. I thought SASL implied TLS, but I guess it doesn't. So I tried adding: smtp_sasl_security_options = auth smtp_tls_security_level = may And now I get "unknown mail transport error" on the client side, and this on the server side: Jul 11 23:30:51 vm01 postfix/smtpd[22169]: connect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 23:30:52 vm01 postfix/smtpd[22169]: lost connection after EHLO from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] Jul 11 23:30:52 vm01 postfix/smtpd[22169]: disconnect from ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] > Set smtp_sasl_security_options = noanonymous (or whatever is > appropriate). The remote server at secure.genesisgroup.info advertises > the following: AUTH PLAIN DIGEST-MD5 CRAM-MD5 LOGIN > > Read the TLS_README and SASL_README files for more information. Will do. At least now I know where to look to make further progress. Thanks! rg
Re: Relay host auth not working
On Jul 12, 2011, at 12:13 AM, Stan Hoeppner wrote: > On 7/12/2011 1:37 AM, Ron Garret wrote: >> >> On Jul 11, 2011, at 11:17 PM, Mike Morris wrote: > >>> Configure smtp_tls_security_level and/or smtp_tls_policy_maps, using at >>> least a setting of 'may'. This will allow the SMTP client to attempt >>> STARTTLS connections with remote hosts. >> >> Ah. I thought SASL implied TLS, but I guess it doesn't. >> >> So I tried adding: >> >> smtp_sasl_security_options = auth >> smtp_tls_security_level = may >> >> And now I get "unknown mail transport error" on the client side, and this on >> the server side: >> >> Jul 11 23:30:51 vm01 postfix/smtpd[22169]: connect from >> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >> Jul 11 23:30:52 vm01 postfix/smtpd[22169]: lost connection after EHLO from >> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >> Jul 11 23:30:52 vm01 postfix/smtpd[22169]: disconnect from >> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >> >>> Set smtp_sasl_security_options = noanonymous (or whatever is >>> appropriate). The remote server at secure.genesisgroup.info advertises >>> the following: AUTH PLAIN DIGEST-MD5 CRAM-MD5 LOGIN >>> >>> Read the TLS_README and SASL_README files for more information. >> >> Will do. At least now I know where to look to make further progress. >> Thanks! > > Since this is a server to server relay of known/trusted systems, and > assuming that 184.73.65.10 is static and won't change any time soon, why > not simply add 184.73.65.10 to $mynetworks on secure.genesisgroup.info > and forget the sasl auth junk? This should get the relaying working > instantly with little or no pitfalls. That's a good idea. The reason I didn't do it this way is that I can't count on the client IP remaining static. Also, I like to understand how things work, and I don't like to admit defeat :-) rg
Re: Relay host auth not working
On Jul 11, 2011, at 11:37 PM, Ron Garret wrote: > > On Jul 11, 2011, at 11:17 PM, Mike Morris wrote: > >> On 07/11/2011 10:12 PM, Ron Garret wrote: >>> >>> On Jul 11, 2011, at 9:31 PM, Stan Hoeppner wrote: >>> >>>> On 7/11/2011 8:12 PM, Ron Garret wrote: >>>>> I'm trying to set up a relay host with authentication according to these >>>>> instructions: >>>>> >>>>> http://anothersysadmin.wordpress.com/2009/02/06/postfix-as-relay-to-a-smtp-requiring-authentication/ >>>>> >>>>> but it's not working. I know my SMTP server is set up properly because I >>>>> can send mail using various other clients, but postfix is apparently not >>>>> even attempting to authorize. Here are the relevant lines from main.cf: >>>>> >>>>> relayhost = secure.genesisgroup.info >>>>> smtp_sasl_auth_enable = yes >>>>> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >>>>> smtp_sasl_security_options = >>>>> >>>>> Here is a log excerpt from my server from a successful login from a >>>>> different client (python smtplib): >>>>> >>>>> Jul 11 17:59:57 vm01 postfix/smtpd[812]: connect from >>>>> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >>>>> Jul 11 17:59:58 vm01 postfix/smtpd[812]: A567C4CA949: >>>>> client=ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10], >>>>> sasl_method=LOGIN, sasl_username=XXX >>>>> >>>>> and here's the same thing when Postfix tries to connect between the same >>>>> two machines: >>>>> >>>>> Jul 11 18:00:26 vm01 postfix/smtpd[820]: connect from >>>>> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10] >>>>> Jul 11 18:00:26 vm01 postfix/smtpd[820]: NOQUEUE: reject: RCPT from >>>>> ec2-184-73-65-10.compute-1.amazonaws.com[184.73.65.10]: 554 5.7.1 >>>>> : Relay access denied; >>>>> from= to= proto=ESMTP >>>>> helo= >>>>> >>>>> As you can see, postfix is not even attempting to authorize. >>>>> >>>>> What am I doing wrong? >>>> >>>> You're not telling us what you're attempting to accomplish for starters. >>> >>> Sorry, I thought that would be clear from the context. I'm trying to do >>> exactly what you say: >>> >>>> When you specify relayhost you're telling Postfix to forward all non >>>> local outbound mail to a gateway instead of delivering it directly to >>>> internet MX destinations. >>> >>> Yes, that is exactly what I'm trying to do. The reason is that mail sent >>> directly from an EC2 instance is usually flagged as spam by many mail >>> recipients because the reverse DNS doesn't resolve properly. >>> >>>> You're showing smtpd logging, but the relayhost parameter applies to >>>> smtp, not smtpd. Your logging shows a host connecting to your Postfix >>>> server, not your Postfix server connecting to secure.genesisgroup.info. >>> >>> >>> The log excerpts are taken from the postfix server on >>> secure.genesisgroup.info, which is the machine I want to use to relay >>> outbound mail from the EC2 instance. Sorry that wasn't clear. >>> >>>> Either you don't understand the relayhost parameter, or I simply don't >>>> understand your goal here, or probably both. >>> >>> >>> Well, I'm clearly missing something. But I don't think it's the relayhost >>> parameter. >>> >>> rg >>> >> >> As stated by Jeroen, supplying the list with the output of 'postconf -n' >> would be much more preferred than sending the entire output of >> 'postconf'. There is no need for people to wade through hundreds of >> lines that are configured for default values. > > Sorry, I'm still kinda new at this. > >> The server at secure.genesisgroup.info only advertises AUTH support >> after STARTTLS. Therefore, in order to successfully authenticate with >> that server from the client at 184.73.65.10, the following configuration >> changes will need to be made on 184.73.65.10: >> >> Configure smtp_tls_security_level and/or smtp_tls_policy_maps, using at >> least a setting of 'may'. This will allow the SMTP client to attempt >> STARTTLS connections with remote hosts. > > Ah. I thought SASL implied TLS, but I guess it doesn't. > > So I tried adding: > > smtp_sasl_security_options = auth > smtp_tls_security_level = may > > And now I get "unknown mail transport error" on the client side, and this on > the server side: Just for the record, this worked: smtp_sasl_security_options = noanonymous smtp_tls_security_level = may Thanks for all the responses! rg
Stopping backscatter spam to a specific domain
I have recently come under a backscatter spam attack from one specific domain. This domain has blacklisted my server’s IP address, and so bounce replies sent to this domain are piling up in my mail queue and I have to go through periodically and manually delete them. I don’t want to disable bounce messages in general because I don’t want incoming messages with typos in the destination address to just vanish into the cosmic void. Is there a way to disable bounce replies for a specific domain? Thanks, rg
Re: Stopping backscatter spam to a specific domain
On Jul 11, 2021, at 9:58 AM, Wietse Venema wrote: > Ron Garret: >> I have recently come under a backscatter spam attack from one >> specific domain. This domain has blacklisted my server?s IP >> address, and so bounce replies sent to this domain are piling up >> in my mail queue and I have to go through periodically and manually >> delete them. I don?t want to disable bounce messages in general >> because I don?t want incoming messages with typos in the destination >> address to just vanish into the cosmic void. Is there a way to >> disable bounce replies for a specific domain? > > Why is your server sending bounces (or any other email) to that > domain? Because spammers are sending messages with forged return-path headers to invalid addresses on my server. It’s called backscatter: https://en.wikipedia.org/wiki/Backscatter_(email) It’s actually possible that I’m sending backscatter spam to other domains, but only one has blacklisted me so far. rg
Re: Stopping backscatter spam to a specific domain
On Jul 11, 2021, at 10:12 AM, Wietse Venema wrote: > Ron Garret: > [ Charset windows-1252 converted... ] >> >> On Jul 11, 2021, at 9:58 AM, Wietse Venema wrote: >> >>> Ron Garret: >>>> I have recently come under a backscatter spam attack from one >>>> specific domain. This domain has blacklisted my server?s IP >>>> address, and so bounce replies sent to this domain are piling up >>>> in my mail queue and I have to go through periodically and manually >>>> delete them. I don?t want to disable bounce messages in general >>>> because I don?t want incoming messages with typos in the destination >>>> address to just vanish into the cosmic void. Is there a way to >>>> disable bounce replies for a specific domain? >>> >>> Why is your server sending bounces (or any other email) to that >>> domain? >> >> Because spammers are sending messages with forged return-path headers to >> invalid addresses on my server. It?s called backscatter: > > You must reject mail for invalid recipient addresses. Otherwise, > you deserve by 100% the problem that you experience. AFAIK, I am: smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, permit The problem is that a rejected recipient produces a mailer-daemon reply. rg
Re: Stopping backscatter spam to a specific domain
Yes, I looked at that, but AFAICT that is all about blocking INBOUND backscatter spam, not stopping outbound messages. On Jul 11, 2021, at 10:15 AM, Kevin N. wrote: > This might help: http://www.postfix.org/BACKSCATTER_README.html > > Cheers, > > K. > > >> On Jul 11, 2021, at 9:58 AM, Wietse Venema wrote: >>> Ron Garret: >>>> I have recently come under a backscatter spam attack from one >>>> specific domain. This domain has blacklisted my server?s IP >>>> address, and so bounce replies sent to this domain are piling up >>>> in my mail queue and I have to go through periodically and manually >>>> delete them. I don?t want to disable bounce messages in general >>>> because I don?t want incoming messages with typos in the destination >>>> address to just vanish into the cosmic void. Is there a way to >>>> disable bounce replies for a specific domain? >>> >>> Why is your server sending bounces (or any other email) to that >>> domain? >> Because spammers are sending messages with forged return-path headers to >> invalid addresses on my server. It’s called backscatter: >> https://en.wikipedia.org/wiki/Backscatter_(email) >> It’s actually possible that I’m sending backscatter spam to other domains, >> but only one has blacklisted me so far. >> rg
Re: Stopping backscatter spam to a specific domain
On Jul 11, 2021, at 12:22 PM, Matus UHLAR - fantomas wrote: > >> The problem is that a rejected recipient produces a mailer-daemon reply. > > only if you accept mail for such recipient. Ah. That may be my problem then. I’m using Dovecot via LMTP for local delivery. I thought that postfix would receive information about non-existent users via that protocol, but I guess it doesn’t and ends up just accepting everything. So… is dovecot actually the thing that is generating the emails from mailer-daemon? Is there a way to get this setup to do the Right Thing? If not, why is LMTP even supported, because it seems to me that anyone who uses it will have this problem. (FYI, the reason I want to use LMTP is that I’m using sqlite for my user db, but postfix does not play well with sqlite when other programs are trying to access the same DB. I didn’t want to duplicate the user DB (I’m a big believer in the DRY principle) so I wanted to localize DB access to a single process, and that process has to be Dovecot.) rg
Re: Stopping backscatter spam to a specific domain
Thanks, that was very helpful.
This has me wondering: if a message is sent to multiple recipients and some are
valid and others are not, what is the Right Thing to do?
rg
P.S. Just FYI:
> I'm not sure what the problem is with Postfix and sqlite
See
http://postfix.1071664.n5.nabble.com/What-is-the-right-way-to-update-a-postfix-sqlite-database-td109636.html#a109659
if you really want to know. The TL;DR is that postfix does not set a non-zero
value for pragma busy_timeout and so any simultaneous access results in an
immediate fatal error in postfix.
On Jul 11, 2021, at 1:54 PM, Bill Cole
wrote:
> On 2021-07-11 at 15:46:45 UTC-0400 (Sun, 11 Jul 2021 12:46:45 -0700)
> Ron Garret
> is rumored to have said:
>
>> On Jul 11, 2021, at 12:22 PM, Matus UHLAR - fantomas
>> wrote:
>>
>>>
>>>> The problem is that a rejected recipient produces a mailer-daemon reply.
>>>
>>> only if you accept mail for such recipient.
>>
>> Ah. That may be my problem then. I’m using Dovecot via LMTP for local
>> delivery. I thought that postfix would receive information about
>> non-existent users via that protocol, but I guess it doesn’t and ends up
>> just accepting everything.
>
> Postfix doesn't know about non-existent users that are relayed via LMTP until
> it has queued and accepted the message. Postfix's SMTP/LMTP client program
> picks up the queued message, tries to deliver it to Dovecot's LMTP server,
> and fails. That's when the Postfix bounce daemon takes over, constructing and
> queueing a bounce message.
>
>> So… is dovecot actually the thing that is generating the emails from
>> mailer-daemon?
>
> No. Dovecot is the thing telling Postfix that the address is bad.
>
>> Is there a way to get this setup to do the Right Thing? If not, why is LMTP
>> even supported, because it seems to me that anyone who uses it will have
>> this problem.
>
> 1. Use {local,relay}_recipient_maps and/or virtual_{mailbox,alias}_maps and
> reject_unlisted_recipients. You can either talk directly to the DB for the
> map or at smaller scales you could just periodically generate a static list
> for Postfix to check at SMTP time.
>
> 2. Use reject_unverified_recipients. This is a generally bad idea on
> submission servers (port 465/587) unless you do something to limit it to
> recipients in local, virtual, and relay classes. Since that's all you should
> be seeing on a true SMTP (port 25) server, it's fine to apply it to all
> messages on your inbound mail stream.
>
>> (FYI, the reason I want to use LMTP is that I’m using sqlite for my user db,
>> but postfix does not play well with sqlite when other programs are trying to
>> access the same DB. I didn’t want to duplicate the user DB (I’m a big
>> believer in the DRY principle) so I wanted to localize DB access to a single
>> process, and that process has to be Dovecot.)
>
> I'm not sure what the problem is with Postfix and sqlite, but extracting a
> suitable static map from the DB periodically should be a SMOP with one SELECT
> and some trivial formatting, if you don't want Postfix contending with
> Dovecot synchronously.
>
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
Re: Stopping backscatter spam to a specific domain
For the record: On Jul 11, 2021, at 1:06 PM, Claus R. Wickinghoff wrote: > I think this can be achieved with reject_unverified_recipient to query > dovecot via lmtp but I've no practical experience with this. Probably you've > to do some googling... That turned out to be the Right Answer. I simply added reject_unverified_recipient to smtpd_recipient_restrictions and that fixed the problem. The chain of events that led to this problem is kind of interesting. What happened was that I migrated my email server from one machine, where it had been running with no problem for many years, to a new machine at a new provider. I had simply copied the main.cf file from the old machine to the new one, but changed the delivery mechanism from direct delivery (i.e. postfix as LDA) to LMTP (i.e. dovecot as LDA). So what was happening before (I think) is that postfix was looking up users in the user DB, not because of smtpd_recipient_restrictions (because I didn’t have that set) but because it had to in order to deliver local messages. When I switched to LMTP that was no longer the case. Postfix now thought it was possible to deliver to non-existent users, and that’s what resulted in the backscatter. Now I understand why the conventional wisdom is not to run your own email server :-) Thanks to all who responded! rg
Re: Stopping backscatter spam to a specific domain
On Jul 13, 2021, at 2:15 AM, Matus UHLAR - fantomas wrote: >> On Jul 11, 2021, at 1:06 PM, Claus R. Wickinghoff >> wrote: >>> I think this can be achieved with reject_unverified_recipient to query >>> dovecot via lmtp but I've no practical experience with this. Probably >>> you've to do some googling... > > On 12.07.21 10:19, Ron Garret wrote: >> That turned out to be the Right Answer. I simply added >> reject_unverified_recipient to smtpd_recipient_restrictions and that fixed >> the problem. >> >> The chain of events that led to this problem is kind of interesting. What >> happened was that I migrated my email server from one machine, where it >> had been running with no problem for many years, to a new machine at a new >> provider. I had simply copied the main.cf file from the old machine to >> the new one, but changed the delivery mechanism from direct delivery (i.e. >> postfix as LDA) to LMTP (i.e. dovecot as LDA). So what was happening >> before (I think) is that postfix was looking up users in the user DB, not >> because of smtpd_recipient_restrictions (because I didn’t have that set) >> but because it had to in order to deliver local messages. When I switched >> to LMTP that was no longer the case. Postfix now thought it was possible >> to deliver to non-existent users, and that’s what resulted in the >> backscatter. > > it MAY still be possible to set up postfix to read local recipients from > database dovecot uses. > Look at local_recipient_maps directive if it's possible, depends on your > dovecot setup. > > reject_unverified_recipient requires verifying each recipient and keep track > of them (deliverable or not) which is useful for cases where you can not use > local_recipient_maps Yes, it is certainly possible to set up postfix to read local recipients from the same DB that dovecot uses. And in fact that is how I had it set up on my previous server. However, on my previous server I was using MySQL and when I switched to the new server I decided to try switching to SQLite3. That turned out to be a very fateful decision because of how SQLite handles simultaneous access from multiple processes to the same DB. It’s a long story, but the upshot is that setting up Postfix and Dovecot to use the same DB causes intermittent errors which in turn cause Postfix to lose mail, which is Bad. That was the problem that originally caused me to move to LMTP in the first place. See this thread: http://postfix.1071664.n5.nabble.com/What-is-the-right-way-to-update-a-postfix-sqlite-database-td109636.html If you want the gory details. rg
How to set up a shadow server
Is there an easy way to tell postfix to send a copy of every message it receives to a “shadow server” in a way that preserves the SMTP envelope? I’m trying to tune a spam filter on actual data, but I don’t want to do it on my production server because the tuning is likely to break things. Thanks, rg
Re: Logging - Handling of Aliases
On Aug 18, 2021, at 11:55 AM, Viktor Dukhovni wrote: > If you want different processing for inbound and outbound mail, > use separate Postfix instances configured appropriately to the > task at hand. There is a useful distinction to be made between mail that is injected into the system by an authorized user and mail that is not. I think of the former as “outbound” even though that is not technically correct. And it is possible to handle these two kinds of messages differently by using a milter (there may be other ways as well, but I know for sure that a milter can do it). This may not be a smart thing to do, but it is possible. rg
Re: Logging - Handling of Aliases
On Aug 18, 2021, at 12:13 PM, Viktor Dukhovni wrote: >> On 18 Aug 2021, at 3:07 pm, Ron Garret wrote: >> >>> If you want different processing for inbound and outbound mail, >>> use separate Postfix instances configured appropriately to the >>> task at hand. >> >> There is a useful distinction to be made between mail that is injected into >> the system by an authorized user and mail that is not. I think of the >> former as “outbound” even though that is not technically correct. And it is >> possible to handle these two kinds of messages differently by using a milter >> (there may be other ways as well, but I know for sure that a milter can do >> it). This may not be a smart thing to do, but it is possible. > > Milters are primarily for content filtering, Sure, but... > they don't or shouldn’t affect address rewriting and message routing. That doesn’t make sense to me. One of the main uses of a milter is to sequester mail with questionable content and prevent it from being delivered to an end user. I don’t see how it can do that without affecting message routing. (Also, just because milters are primarily used for content filtering doesn’t mean that they can’t or shouldn’t be used for other things as well. It may well be the case that they should not be used for other things, but the mere fact that they are not is not in and of itself a good argument that they should not.) rg
HELO and nothing else
Hello (not helo :-) I am working on a spam filter and so I find myself spending a lot more quality time with mail logs than I used to. One of the things I have noticed is that I will get a lot of connections that send a HELO command and then disconnect. Sometimes I get this repeated several times a minute from the same IP for hours on end. What is going on here? Should I block these IPs? Am I being scanned? By what? To what end? Thanks, rg
What is the right way to update a postfix sqlite database?
I ran into the sqlite locked database problem discussed in these threads: https://marc.info/?l=postfix-users&m=160096626120296&w=2 https://marc.info/?l=postfix-users&m=151561295721906&w=2 The problem occurs (AFAICT) because the database file was shared with a spam filter which was writing to the db. But that raises the following question: what is the right way to update a sqlite db used by postfix? The only safe way I can think of doing it is to actually shut down postifx, update the db, and then start postfix back up again. But that feels like an overly brutal solution. Is there a better way? Even a non-shared db needs to be updated now and then. I can guarantee that all writes will complete within a short time, so what I would really like to do is to get postfix to issue a “PRAGMA busy_timeout = …” command before doing the query, but I don’t want to have to rebuild postfix from source in order to do this. Is this possible? How? Thanks, rg
Re: What is the right way to update a postfix sqlite database?
On Feb 22, 2021, at 4:56 PM, Ron Garret (gmail) wrote: > > On Feb 22, 2021, at 2:57 PM, Wietse Venema wrote: > >> Ron Garret: >> [ Charset windows-1252 converted... ] >>> I ran into the sqlite locked database problem discussed in these threads: >>> >>> https://marc.info/?l=postfix-users&m=160096626120296&w=2 >>> >>> https://marc.info/?l=postfix-users&m=151561295721906&w=2 >>> >>> The problem occurs (AFAICT) because the database file was shared with a >>> spam filter which was writing to the db. But that raises the following >>> question: what is the right way to update a sqlite db used by postfix? The >>> only safe way I can think of doing it is to actually shut down postifx, >>> update the db, and then start postfix back up again. But that feels like >>> an overly brutal solution. Is there a better way? Even a non-shared db >>> needs to be updated now and then. >>> >>> I can guarantee that all writes will complete within a short time, so what >>> I would really like to do is to get postfix to issue a ?PRAGMA busy_timeout >>> = ?? command before doing the query, but I don?t want to have to rebuild >>> postfix from source in order to do this. Is this possible? How? >>> >> >> Isn't SQLite supposed to deal with concurrent access? >> https://sqlite.org/lockingv3.html > > Yes, it does, but the way it “deals” with it is to throw an error if one > connection tried to read while another is writing. The net result of this is > that if Postfix tries to read during a concurrent update from somewhere else, > it fails catastrophically (mail is actually lost). Just for the record: I spent some more time groveling around in the docs and source code and AFAICT it is actually not possible to safely update a sqlite DB that is in use by postfix. The only safe way to do it is to make a copy of the DB, update that, and then mv it to the active path. This is according to both the docs and the code. It would be nice if postfix would set a non-zero busy timeout. It’s a simple code change, just a call to sqlite3_busy_timeout. That would not be a guarantee, but it would at least make it *possible* to safely update a sqliite database in-place. I’m going to head on over to the postfix-dev list to see if it’s possible to get this done. rg
Re: What is the right way to update a postfix sqlite database?
On Feb 23, 2021, at 10:19 AM, Wietse Venema wrote: > Ron Garret: >>>> Isn't SQLite supposed to deal with concurrent access? >>>> https://sqlite.org/lockingv3.html >>> >>> Yes, it does, but the way it ?deals? with it is to throw an error >> if one connection tried to read while another is writing. The net > > Bleh, it does not retry the operation? Nope. See postfix-3.5.9/src/global/dict_sqlite.c. It’s not clear that retrying would even be the right thing to do because you could just get unlucky again. The failure can happen in three different places: the query itself (obviously) but also statement preparation and finalization. I’ve seen all three actually happen in practice. So you really want it to wait. That’s a lot simpler, and it guarantees success as long as there are no slow writers (which is a reasonable constraint). > What happens when you update the table while some Postfix code is > READING from the DB? Does the writer also fail? No idea, but because I control all the writers that would be easy for me to fix. In any event I don’t think that’s something postfix should be worried about. >> result of this is that if Postfix tries to read during a concurrent >> update from somewhere else, it fails catastrophically (mail is >> actually lost). > > Losing mail would be a bug in the sending program. Postfix never > loses mail because of a fatal error. What can I say? When this happens, I can’t find the message that was being processed anywhere. It is not delivered (obviously) and it is not bounced. The way I first found out this was happening was an error notification in the root mailbox of the machine where postfix is running. >> It would be nice if postfix would set a non-zero busy timeout. >> It?s a simple code change, just a call to sqlite3_busy_timeout. > > What about https://www.sqlite.org/pragma.html#pragma_busy_timeout ? > I don't know if that is a DB property or a session property. It’s a session/connection property. The problem with trying to use a pragma in the config file is that the C interface to sqlite does not allow multiple semicolon-separated statements in a call to sqlite3_prepare_v2, so just putting the pragma in the postfix sql config as part of the query with a semicolon after will not work. Postfix would have to know to separate multiple statements and prepare them separately. Since a source code change would be needed anyway, a much simpler solution is just to call sqlite3_busy_timeout directly. >> That would not be a guarantee, but it would at least make it >> *possible* to safely update a sqliite database in-place. I?m going >> to head on over to the postfix-dev list to see if it?s possible >> to get this done. > > If we take this route, then there needs to be a new field in the > Postfix sqlite config file that controls the time limit. Not necessarily. You could just hard-code a reasonable value (like 1 second), or make it a #define so you need a recompile to change it. That’s sub-optimal, obviously, but still a major improvement over the current situation for very little effort and no down-side that I can see. rg
Re: What is the right way to update a postfix sqlite database?
On Feb 23, 2021, at 11:41 AM, Richard Damon wrote: > On 2/23/21 2:18 PM, Wietse Venema wrote: >> Ron Garret: >>>> If we take this route, then there needs to be a new field in the >>>> Postfix sqlite config file that controls the time limit. >>> Not necessarily. You could just hard-code a reasonable value (like >>> 1 second), or make it a #define so you need a recompile to change >>> it. That?s sub-optimal, obviously, but still a major improvement >>> over the current situation for very little effort and no down-side >>> that I can see. >> The limit should be configurable. It takes: >> >> - one line of code to define a C variable, >> >> - one line of code to read its value from an sqlite_table configuration >> file (or to use a documented default value), >> >> - a few lines of text to document the new field in the sqlite_table manpage. >> >> Wietse > > One thng to look at is WAL mode. WAL mode increases the cost of writes > to the database, as all writes become two stage, first to the WAL > journal, and then flushed to the main database (called A checkpoint), > and reads reads can get a bit more expensive if the second stage of the > write gets delayed by long accesses (but that may not be an issue with > postfix). > > In exchange, the database allows for simultaneous reads and writes, > except possibly for the period when the second phase of the writes are > occurring, and it will try to allow as much overlap there as possible, > and try to find a time when no readers are active to do this operation. > > Without a busy timeout being set, the reader should only get a busy in > fairly rare conditions, the main one being if the last connection to the > database is closing, then SQLite does some cleanup that locks the > database for just a little bit, or if the last connection 'crashes' than > the next connection will do some cleanup. Even a fairly short busy wait > should handle these cases most of the time. WAL mode was previously discussed here: https://marc.info/?l=postfix-users&m=160096626120296&w=2 The upshot appears to be this, at least as things currently stand: > DO NOT use SQLite as a Postfix backend database updated live while > Postfix is running. rg
Spawning milter processes
Hello, What is the usual way to start a milter process? Can postfix be configured to spawn it automatically, or does the milter have to be set up as a separate service? If the former, how do you do it? Thanks, rg
Re: Spawning milter processes
On Jan 31, 2016, at 1:28 AM, Robert Schetterer wrote: > Am 31.01.2016 um 09:56 schrieb Ron Garret: >> Hello, >> >> What is the usual way to start a milter process? Can postfix be configured >> to spawn it automatically, or does the milter have to be set up as a >> separate service? If the former, how do you do it? >> >> Thanks, >> rg >> > > milters are usually seperate services OK, but is there any way to get Postfix to restart a milter if it goes down? By default, if a milter goes down, it takes postfix down with it. Also, why did you hedge with “usually”? What other possibilities are there? rg
Re: Spawning milter processes
OK, that’s exactly what I needed to know. Thanks! On Jan 31, 2016, at 9:16 AM, Steve Jenkins wrote: > On Sun, Jan 31, 2016 at 9:04 AM, Ron Garret wrote: > OK, but is there any way to get Postfix to restart a milter if it goes down? > By default, if a milter goes down, it takes postfix down with it. > > The usual way to start a milter service is to have it autostart when the > server boots, just as you would with any service. For example, if you're > using systemd, you'd have a miltername.service unit file to fire it up. > > I don't know of any way for Postfix itself to then monitor the running milter > service to respawn if it fails, but the two milters I'm most familiar with -- > OpenDKIM and OpenDMARC -- both have "AutoRestart=yes" configuration options > in their conf files to respawn themselves in the event they fail. I assume > they're monitoring their own PID file, or something to that effect, but I'm > not a programmer, so I don't know what's under-the-hood to enable that. I > have Nagios configured to regularly check that Postfix is up, and separately > monitor my important milters. > > If you're looking to write your own milter service, I'd join the dev > discussion list for one of the milters that supports AutoRestart (such as > OpenDKIM) and ask about it there. A good number of guys on this Postfix list > are also on that list. > > Or you could look through the source code on SourceForge and find the > AutoRestart stuff: > > http://sourceforge.net/projects/opendkim/ > > SteveJ
[pfx] Postfix as an SMTP front end
I am running postfix on the same machine as my IMAP server, but this is a security risk because having two different services on the same machine increases the attack surface. My IMAP server doesn't need to be publicly visible, so I would like to move that service to a separate machine, and have the public-facing postfix just forward all incoming mail (modulo some basic spam filtering) to that server (which would also be running its own copy of postfix). Is there a concise set of instructions somewhere on how to configure postfix for this use case? I can't be the first person who has wanted to do this. Thanks, rg ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
