Re: Unclear of smtp protocol in a restricted domain
Am 31.03.2014 00:35, schrieb cybermass: Hi. I am a bit unclear about how email works in a closed domain from roaming clients (SASL auth clients). If there is a postfix server that is configured to only accept and send email to users in the same domain, say for example j...@restricted.com can only send to another_u...@restricted.com, does this mean that the client's email never hops through other servers or hops? who knows without the config I would assume it does not hop since the user authenticated, then crafted an email to another user in same domain, using only the mail server IP that is allowed to relay. I would think it would be all encapsulated inside the mail server, never leaving out to the internet, but I do know that the clients have to send via the SMTP protocol, either port 25 or 465 or any other custom port chosen. Can someone please verify if the email travels through hops in this environment or does it remain inside the postfix server? if i understand the question cooecrtly you see the anser below in that case the question could have been one or two lines in any case output of postconf -n instead descriptions would help first lines of main.cf on any of my testing machines: default_transport = error:5.1.2 mail to remote domains not permitted local_transport= error:5.1.2 local transport not permitted relay_transport= error:5.1.2 relay transport not permitted virtual_transport = error:5.1.2 virtual transport not permitted domains are listed in mydestination via mysql local_recipient_maps configured via mysql transport_maps is configured via mysql and points to LMTP on 127.0.0.1:24
Re: Unclear of smtp protocol in a restricted domain
Am 31.03.2014 01:54, schrieb cybermass: Interesting, that is something I never even thought of why should a server hosting example.com relay a to him submitted message from a...@example.com to b...@example.com trough a foreign server? what should that foreign server do with that message other than bounce it back again to the origin which is the MX or throw it way if there is no MX reachable from outside? Yes the clients are configured to only go through our custom smtps port since some ISP's block outgoing 25 and even 465. 587 is dedicated for mail-submission These clients just need to have only one account in their mail client I understand. Is there any other configuration I would need to do on the server side? for the case above - no, mail from one gmail user to another gamil user is not routed trough hotmail and that behavior is logical and as expected
Re: Unclear of smtp protocol in a restricted domain
Am 31.03.2014 02:07, schrieb cybermass: 587 is dedicated for submission but is it any different if I have configured smtps to be port 8809 and just have the clients use that port with STARTTLS instead of 587? technically you can use whatever port but why not use standars and make users life difficult? BTW: don't talk about SMTPS and STARTTLS in conext of the same port especially if you instrcut your users because that leads to non-working configs http://en.wikipedia.org/wiki/STARTTLS Am 31.03.2014 01:54, schrieb cybermass: Interesting, that is something I never even thought of why should a server hosting example.com relay a to him submitted message from [hidden email]http://user/SendEmail.jtp?type=nodenode=66502i=0to [hidden email] http://user/SendEmail.jtp?type=nodenode=66502i=1 trough a foreign server? your node.js application breaks quotes! what should that foreign server do with that message other than bounce it back again to the origin which is the MX or throw it way if there is no MX reachable from outside? Yes the clients are configured to only go through our custom smtps port since some ISP's block outgoing 25 and even 465. 587 is dedicated for mail-submission These clients just need to have only one account in their mail client I understand. Is there any other configuration I would need to do on the server side? for the case above - no, mail from one gmail user to another gamil user is not routed trough hotmail and that behavior is logical and as expected
Re: Unclear of smtp protocol in a restricted domain
Am 31.03.2014 02:35, schrieb Shawn Zaidermann: The way I had assumed it earlier was the client authenticates via 993 (dovecot IMAP in our case), crafts an email to another user and this email is delivered instantly via lmtp (in our case, dovecot LDA), but now I see that in reality, the client sends the email via the smtp port instead making a direct connection with the mail server. Its still secure but the other way sounds more secure. that explains why your posts sounded that weird please do yourself a favour and read some basics about how e-mail works * IMAP/POP3 - receive messages * SMTP - send messages * LMTP - LDA IMAP is *your account* and the only messages which are going through IMAP to the server are sent messages or via IMAP append but they will *never* face LMTP or go to a different user (IMAP append: http://tools.ietf.org/html/rfc3501) http://en.wikipedia.org/wiki/Message_transfer_agent http://en.wikipedia.org/wiki/Mail_delivery_agent http://en.wikipedia.org/wiki/Email_client
Re: Can I reject when sender doesn't appear in from: header?
Am 30.03.2014 01:10, schrieb Peter: On 03/28/2014 10:16 AM, Adam Moffett wrote: I'm seeing messages occasionally where the envelope sender is a verifiable address at someone else's domain, but the from: header contains some non-existent user @ our local domain. This is a very bad idea, to illustrate why here is the envelope sender of your message (that I'm replying to): Return-Path: owner-postfix-us...@postfix.org ...and here is the From: header: From: Adam Moffett adamli...@plexicomm.net Obviously the two don't match, and equally obvious is that your message is not SPAM. while i agree that it is a bad idea to take headers into account as well as Barracuda networks started to do the same with their last firmware and so the spoofing protection kills *any* mailing list you missed contains some non-existent user @ our local domain however, mail is about SMTP and SMTP is about envelopes
Re: Reject client from domains without MX records
Am 28.03.2014 20:33, schrieb Pau Peris: I think everything was working fine but after update main.cf http://main.cf file i'm seeing the following warning for emails incoming outside the box, postfix/smtpd[15455]: warning: restriction `reject_authenticated_sender_login_mismatch' ignored: no SASL support The previous warning is show when i send an email from GMail to a domain whose email is managed by me. Basically what i did is: * Remove permit_mynetworks where i think it shouldn't be. * Disable smtp auth globally and enable it at submission 587 and smtps 465. * Remove the deprecated smtp_use_tls/smtpd_use_tls statements `reject_authenticated_sender_login_mismatch' has a clear context to SASL auth just don't list SASL related params in main.cf if disable smtp auth globally
Re: Warning messages from bad return-path
Am 28.03.2014 22:43, schrieb Bruce Sackett: I am running into a problem where I have a poorly configured SMS system sending through the mail server. The messages are delivered properly, but then the sender receives a warning message: Failed to deliver to ‘email account SMTP module(domain domain) reports: return-path address -6032673_14937_452964_11551.sms@bad crm I unfortunately cannot change the SMS system, so I need to be able to suppress the failure messages. I have strict_rfc821_envelopes = no set in main.cf, and postfix on that server is currently version 2.8.5 if you can't solve the problem and all works just configure your syslog to supress them rsyslog: :msg, contains, whatever-you-do-not-want-to-see ~
Re: Reject client from domains without MX records
sorry, you need to read manuals and try some things at your own if you can't handle it why do you remove auth globally? in general don't change defaults for no good reason Am 29.03.2014 00:21, schrieb Pau Peris: Could you be more explicit or place an example on how should main.cf http://main.cf should stay after removing the sasl params and how should master.cf http://master.cf look please? Thank u so much!! Sent from my Android mobile, excuse the brevity. On Mar 28, 2014 10:21 PM, li...@rhsoft.net mailto:li...@rhsoft.net li...@rhsoft.net mailto:li...@rhsoft.net wrote: Am 28.03.2014 20:33, schrieb Pau Peris: I think everything was working fine but after update main.cf http://main.cf http://main.cf file i'm seeing the following warning for emails incoming outside the box, postfix/smtpd[15455]: warning: restriction `reject_authenticated_sender_login_mismatch' ignored: no SASL support The previous warning is show when i send an email from GMail to a domain whose email is managed by me. Basically what i did is: * Remove permit_mynetworks where i think it shouldn't be. * Disable smtp auth globally and enable it at submission 587 and smtps 465. * Remove the deprecated smtp_use_tls/smtpd_use_tls statements `reject_authenticated_sender_login_mismatch' has a clear context to SASL auth just don't list SASL related params in main.cf http://main.cf if disable smtp auth globally
Re: Reject client from domains without MX records
Am 29.03.2014 00:43, schrieb Pau Peris: I don't think that's about reading but about experise. Which takes time after reading no, it's a matter of read, try and try again, been there done that I will reenable sasl globally again while i try to understand it all I'm unsure if login sender mismatch can have any side effect for incoming email once global sasl auth is activated as said: read the documentation, especially for params you are usinf reject_authenticated_sender_login_mismatch contains the word authenticated http://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch Sent from my Android mobile, excuse the brevity. On Mar 29, 2014 12:30 AM, li...@rhsoft.net mailto:li...@rhsoft.net li...@rhsoft.net mailto:li...@rhsoft.net wrote: sorry, you need to read manuals and try some things at your own if you can't handle it why do you remove auth globally? in general don't change defaults for no good reason Am 29.03.2014 00:21, schrieb Pau Peris: Could you be more explicit or place an example on how should main.cf http://main.cf http://main.cf should stay after removing the sasl params and how should master.cf http://master.cf http://master.cf look please? Thank u so much!! Sent from my Android mobile, excuse the brevity. On Mar 28, 2014 10:21 PM, li...@rhsoft.net mailto:li...@rhsoft.net mailto:li...@rhsoft.net mailto:li...@rhsoft.net li...@rhsoft.net mailto:li...@rhsoft.net mailto:li...@rhsoft.net mailto:li...@rhsoft.net wrote: Am 28.03.2014 20:33, schrieb Pau Peris: I think everything was working fine but after update main.cf http://main.cf http://main.cf http://main.cf file i'm seeing the following warning for emails incoming outside the box, postfix/smtpd[15455]: warning: restriction `reject_authenticated_sender_login_mismatch' ignored: no SASL support The previous warning is show when i send an email from GMail to a domain whose email is managed by me. Basically what i did is: * Remove permit_mynetworks where i think it shouldn't be. * Disable smtp auth globally and enable it at submission 587 and smtps 465. * Remove the deprecated smtp_use_tls/smtpd_use_tls statements `reject_authenticated_sender_login_mismatch' has a clear context to SASL auth just don't list SASL related params in main.cf http://main.cf http://main.cf if disable smtp auth globally
Re: Reject client from domains without MX records
Am 27.03.2014 18:52, schrieb Pau Peris: If i try to spoof email/sender address through Mozilla Thunderbird i get the same error message as the one when relaying u...@example.com mailto:u...@example.com: Sender address rejected: not owned by user us...@example.com mailto:us...@example.com; So it looks like the issue only exists when working locally like through the webmail solution because permit_mynetworks does what it is supposed to do if you don't have mynetworks configured the defaults are applied [root@srv-rhsoft:~]$ postconf -d mynetworks mynetworks = 127.0.0.0/8 62.178.103.0/24 192.168.2.0/24 192.168.10.0/24 192.168.196.0/24 10.0.0.0/24
Re: Reject client from domains without MX records
can you please stop top-posting and using HTML on lists? what is bad with HTML? look at the quote below after convert you message to plain Am 27.03.2014 19:53, schrieb Pau Peris: i didn't configure mynetworks because i mynetworks_style is set to host. I thought it was right thing to do to fit my needs which obviously looks like not. Could you please exaplain me why is it wrong? why should it be right? if you don't want to skip a restriction because the machine is in mynetworks just don't put permit_networks before the restriction or don't put the machine in question in mynetworks i know nobody who changed mynetworks_style and i know a lot of admins On Thu, Mar 27, 2014 at 7:32 PM, Robert Schetterer r...@sys4.de mailto:r...@sys4.de wrote: Am 27.03.2014 18 tel:27.03.2014%2018:52, schrieb Pau Peris: If i try to spoof email/sender address through Mozilla Thunderbird i get the same error message as the one when relaying u...@example.com mailto:u...@example.com mailto:u...@example.com mailto:u...@example.com: Sender address rejected: not owned by user us...@example.com mailto:us...@example.com mailto:us...@example.com mailto:us...@example.com; So it looks like the issue only exists when working locally like through the webmail solution. configure your webmail to use smtp not sendmail binary ( as default in most webmail )
Re: Reject client from domains without MX records
PLEASE LEARN TO USE YOUR MAIL-CLIENT AND HOW TO QUOTE * do not top post * do not post HTML * do not reply only to your own questions while you refer to answers * if you continue that way of posting i just ignore you this is a completly unreadable thread in the meanwhile that below is hardly a response to my last message __ back to topic: * why would you like to spoof root? * mails of cronjobs and such things are using the sendmail binary * the sendmail binary has *no relevance* to SMTP restrictions because it is not SMTP Am 27.03.2014 20:04, schrieb Pau Peris: i understand now the mistake. I'm reviewing the whole restrictions lot to fix permit_mynetworks where it is needed. I'm looking at Postfix site - http://postfix.org/postconf.5.html - for a way to create exceptions as i would like some users like root to be able to spoof their from address but i'm not able to find the right directive. Would you dare pointing me to the right one? Thank you so much. I rally appreciate your help On Thu, Mar 27, 2014 at 7:53 PM, Pau Peris p...@webeloping.es mailto:p...@webeloping.es wrote: Hi, i didn't configure mynetworks because i mynetworks_style is set to host. I thought it was right thing to do to fit my needs which obviously looks like not. Could you please exaplain me why is it wrong? I think i'm not fully understanding why permit_mynetworks is wrong there. Robert, i'm using Roundcube already configured to connect to smtp and not as sendmail. Thanks for your tip. Thanks again, On Thu, Mar 27, 2014 at 7:32 PM, Robert Schetterer r...@sys4.de mailto:r...@sys4.de wrote: Am 27.03.2014 18 tel:27.03.2014%2018:52, schrieb Pau Peris: If i try to spoof email/sender address through Mozilla Thunderbird i get the same error message as the one when relaying u...@example.com mailto:u...@example.com mailto:u...@example.com mailto:u...@example.com: Sender address rejected: not owned by user us...@example.com mailto:us...@example.com mailto:us...@example.com mailto:us...@example.com; So it looks like the issue only exists when working locally like through the webmail solution. configure your webmail to use smtp not sendmail binary ( as default in most webmail )
Re: StartSSL.com SSL Class2 Certificate and Postfix
the problem is that you can't control what the client expects there are a lot of clients, recent and outdated rule of thumbs: avoid all that domain-specific crap in caes of mail and just use and communicate mail.yourdomain.tld indepdendent what domains you are hosting - that scales and works in any case we are hosting some hundret mail-domains and have *one* servername Am 26.03.2014 22:51, schrieb Pau Peris: Are you really sure? I mean, do you know where can i find information about this topic? As i planned to operate that way, buying cheap ssl certs for multiple domains/subdomains i would like to be sure before discarding that procedure. On Mar 26, 2014 9:28 PM, Viktor Dukhovni postfix-us...@dukhovni.org mailto:postfix-us...@dukhovni.org wrote: On Wed, Mar 26, 2014 at 09:13:58PM +0100, Pau Peris wrote: Common Name (CN) we.webeloping.es http://we.webeloping.es X509v3 Subject Alternative Name: DNS:webeloping.com http://webeloping.com, DNS:demo.webeloping.com http://demo.webeloping.com, DNS:imap.webeloping.com http://imap.webeloping.com, DNS:mail.webeloping.com http://mail.webeloping.com, DNS:smtp.webeloping.com http://smtp.webeloping.com, DNS:test.webeloping.com http://test.webeloping.com, DNS:we.webeloping.com http://we.webeloping.com, DNS:*.webeloping.com http://webeloping.com DNS:webeloping.es http://webeloping.es, DNS:*.webeloping.es http://webeloping.es, DNS:demo.webeloping.es http://demo.webeloping.es, DNS:imap.webeloping.es http://imap.webeloping.es, DNS:mail.webeloping.es http://mail.webeloping.es, DNS:smtp.webeloping.es http://smtp.webeloping.es, DNS:test.webeloping.es http://test.webeloping.es, DNS:we.webeloping.es http://we.webeloping.es, By access my server from some-domain I mean: Configuring a desktop email client to access IMAP and SMTP servers. s/from/as/ we.webeloping.es http://we.webeloping.es and we.webeloping.es http://we.webeloping.es respectively work like a charm, while using imap.webeloping.es http://imap.webeloping.es and smtp.webeloping.es http://smtp.webeloping.es makes the email client show the typical SSL warning complaining about the host not being the common name Well, now you know what not to do. :-( The mail client wants the server name in the CN.
Re: Virtualmin + Mailman 5.5.4 Relay denied
Am 25.03.2014 12:48, schrieb Scott Wilcox:
Mar 25 12:32:03 aeson postfix/smtpd[24981]: connect from
mail-wi0-f176.google.com
http://mail-wi0-f176.google.com[209.85.212.176]
Mar 25 12:32:03 aeson milter-greylist: smfi_getsymval failed for
{daemon_port}, using default smtp port
Mar 25 12:32:03 aeson milter-greylist: smfi_getsymval failed for {i}
Mar 25 12:32:03 aeson milter-greylist: (unknown id): skipping greylist
because this is the default action,
(from=sc...@dor.ky mailto:sc...@dor.ky,
rcpt=tweeklyfm-translat...@lists.dor.ky
mailto:tweeklyfm-translat...@lists.dor.ky, addr=mail-wi0-f176.google.com
http://mail-wi0-f176.google.com[209.85.212.176]) ACL 78
Mar 25 12:32:03 aeson postfix/smtpd[24981]: 882AD2301392:
client=mail-wi0-f176.google.com
http://mail-wi0-f176.google.com[209.85.212.176]
Mar 25 12:32:03 aeson postfix/cleanup[24987]: 882AD2301392:
message-id=cabbqdg2vtdzvkh-4_2q4poq8raght0e5o+9xbwhgo_fmd_h...@mail.gmail.com
mailto:cabbqdg2vtdzvkh-4_2q4poq8raght0e5o%2b9xbwhgo_fmd_h...@mail.gmail.com
Mar 25 12:32:03 aeson postfix/qmgr[24979]: 882AD2301392: from=sc...@dor.ky
mailto:sc...@dor.ky, size=1909,
nrcpt=1 (queue active)
Mar 25 12:32:03 aeson postfix/smtpd[24981]: disconnect from
mail-wi0-f176.google.com
http://mail-wi0-f176.google.com[209.85.212.176]
Mar 25 12:32:03 aeson postfix/local[24988]: 882AD2301392:
to=tweeklyfm-translation-lists.dor...@aeson.ssx.io
mailto:tweeklyfm-translation-lists.dor...@aeson.ssx.io,
orig_to=tweeklyfm-translat...@lists.dor.ky
mailto:tweeklyfm-translat...@lists.dor.ky, relay=local, delay=0.27,
delays=0.14/0/0/0.13, dsn=2.0.0, status=sent
(delivered to command: /usr/lib/mailman/mail/mailman post
tweeklyfm-translation)
Mar 25 12:32:03 aeson postfix/qmgr[24979]: 882AD2301392: removed
Mar 25 12:32:05 aeson postfix/smtpd[24981]: connect from localhost[127.0.0.1]
Mar 25 12:32:05 aeson milter-greylist: smfi_getsymval failed for
{daemon_port}, using default smtp port
Mar 25 12:32:05 aeson milter-greylist: smfi_getsymval failed for {i}
Mar 25 12:32:05 aeson postfix/smtpd[24981]: NOQUEUE: reject: RCPT from
localhost[127.0.0.1]: 554 5.7.1
sc...@dor.ky mailto:sc...@dor.ky: Relay access denied;
from=tweeklyfm-translation-boun...@lists.dor.ky
mailto:tweeklyfm-translation-boun...@lists.dor.ky to=sc...@dor.ky
mailto:sc...@dor.ky proto=ESMTP
helo=aeson.ssx.io http://aeson.ssx.io
Mar 25 12:32:05 aeson postfix/smtpd[24981]: disconnect from
localhost[127.0.0.1]
What steps can I run to show you more debug so you can help me rectify this
issue
just start with postconf -n as statet in the welcome message and debug-howto
looks like the client did not use athentication nor is it in mynetworks
or if it is something is configured wrong, who knows without basic infos
Re: Virtualmin + Mailman 5.5.4 Relay denied
why don't you reply to the list and top-post - i continue top-posting now?
smtpd_recipient_restrictions = permit_sasl_authenticated
reject_unauth_destination
permit_inet_interfaces
permit_mynetworks
check_relay_domains
well, you did not set mynetworks but you changed mynetworks_style = host
instead leave the default untouched for no good reason
these would be the postfix defaults (postconf -d)
mynetworks = 127.0.0.0/8 10.0.0.0/24
mynetworks_style = subnet
no idea why you use permit_inet_interfaces
Permit the request when the client IP address matches $inet_interfaces
Am 25.03.2014 12:54, schrieb Scott Wilcox:
Ah, my apologies.
postconf -n
alias_maps = hash:/etc/aliases
allow_percent_hack = no
append_dot_mydomain = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = no
inet_protocols = ipv4
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
milter_default_action = accept
milter_protocol = 2
mydestination = $myhostname, localhost.$mydomain, localhost, aeson.ssx.io
http://aeson.ssx.io, 127.0.0.1
mynetworks_style = host
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = local:/var/run/milter-greylist/milter-greylist.sock
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
relay_domains = $mydestination
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sender_bcc_maps = hash:/etc/postfix/bcc
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_milters = local:/var/run/milter-greylist/milter-greylist.sock
smtpd_recipient_restrictions = permit_sasl_authenticated
reject_unauth_destination permit_inet_interfaces
permit_mynetworks check_relay_domains
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_tls_CAfile = /etc/certs/ssx.io/bundle.crt http://ssx.io/bundle.crt
smtpd_tls_cert_file = /etc/certs/ssx.io/wildcard.crt
http://ssx.io/wildcard.crt
smtpd_tls_key_file = /etc/certs/ssx.io/private.key http://ssx.io/private.key
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual
On Tue, Mar 25, 2014 at 11:52 AM, li...@rhsoft.net mailto:li...@rhsoft.net
li...@rhsoft.net
mailto:li...@rhsoft.net wrote:
Am 25.03.2014 12 tel:25.03.2014%2012:48, schrieb Scott Wilcox:
Mar 25 12:32:03 aeson postfix/smtpd[24981]: connect from
mail-wi0-f176.google.com
http://mail-wi0-f176.google.com
http://mail-wi0-f176.google.com[209.85.212.176]
Mar 25 12:32:03 aeson milter-greylist: smfi_getsymval failed for
{daemon_port}, using default smtp port
Mar 25 12:32:03 aeson milter-greylist: smfi_getsymval failed for {i}
Mar 25 12:32:03 aeson milter-greylist: (unknown id): skipping greylist
because this is the default action,
(from=sc...@dor.ky mailto:sc...@dor.ky mailto:sc...@dor.ky
mailto:sc...@dor.ky,
rcpt=tweeklyfm-translat...@lists.dor.ky
mailto:tweeklyfm-translat...@lists.dor.ky
mailto:tweeklyfm-translat...@lists.dor.ky
mailto:tweeklyfm-translat...@lists.dor.ky,
addr=mail-wi0-f176.google.com http://mail-wi0-f176.google.com
http://mail-wi0-f176.google.com[209.85.212.176]) ACL 78
Mar 25 12:32:03 aeson postfix/smtpd[24981]: 882AD2301392:
client=mail-wi0-f176.google.com
http://mail-wi0-f176.google.com
http://mail-wi0-f176.google.com[209.85.212.176]
Mar 25 12:32:03 aeson postfix/cleanup[24987]: 882AD2301392:
message-id=cabbqdg2vtdzvkh-4_2q4poq8raght0e5o+9xbwhgo_fmd_h...@mail.gmail.com
mailto:cabbqdg2vtdzvkh-4_2q4poq8raght0e5o%2b9xbwhgo_fmd_h...@mail.gmail.com
mailto:cabbqdg2vtdzvkh-4_2q4poq8raght0e5o%2b9xbwhgo_fmd_h...@mail.gmail.com
mailto:cabbqdg2vtdzvkh-4_2q4poq8raght0e5o%252b9xbwhgo_fmd_h...@mail.gmail.com
Mar 25 12:32:03 aeson postfix/qmgr[24979]: 882AD2301392:
from=sc...@dor.ky mailto:sc...@dor.ky
mailto:sc...@dor.ky mailto:sc...@dor.ky, size=1909,
nrcpt=1 (queue active)
Mar 25 12:32:03 aeson postfix/smtpd[24981]: disconnect from
mail-wi0-f176.google.com
http://mail-wi0-f176.google.com
http://mail-wi0-f176.google.com[209.85.212.176]
Mar 25 12:32:03 aeson postfix/local[24988]: 882AD2301392:
to=tweeklyfm-translation-lists.dor...@aeson.ssx.io
mailto:tweeklyfm-translation-lists.dor...@aeson.ssx.io
mailto:tweeklyfm-translation-lists.dor...@aeson.ssx.io
mailto:tweeklyfm-translation-lists.dor...@aeson.ssx.io,
orig_to=tweeklyfm-translat...@lists.dor.ky
mailto:tweeklyfm-translat...@lists.dor.ky
mailto:tweeklyfm-translat...@lists.dor.ky
mailto:tweeklyfm-translat...@lists.dor.ky, relay=local,
delay=0.27, delays=0.14/0/0/0.13, dsn=2.0.0, status=sent
Re: Reject client from domains without MX records
Am 24.03.2014 20:54, schrieb Pau Peris: I'm wondering why are you setting the following policies under recipient restrictions and not under sender restrictions? Maybe it's more efficient? reject_non_fqdn_sender reject_unlisted_sender reject_authenticated_sender_login_mismatch because with smtpd_delay_reject which is default for good reasons it does not matter and the configuration is easier to understand as well as specific overrides are better to manage reject_non_fqdn_sender reject_unlisted_sender reject_authenticated_sender_login_mismatch Last, what do you think about reject_unverified_sender? Is it a resources drainer? it may lead to blacklisting because you always make a sending attempt and in case of forged senders you do that to servers never tried to send a message to you
Re: Reject client from domains without MX records
Am 22.03.2014 10:29, schrieb Pau Peris: The issue here is mail.domain.com http://mail.domain.com is responsible of sending email for domain.com http://domain.com but not *.domain.com http://domain.com so the latter are not DKIM signed and obviously are not valid recipient addresses as those domains are not able to recieve email so i would like to reject clients using a from domain address which is not able to receive email like *.domain.com http://domain.com. please don't post in HTML, i destroys quoting in a thread and has no benefit domains without MX records is a bad idea, there is no RFC saying that a MX record is mandatory, that is why any MTA falls back to the A-record of the domain if there is no MX and to avoid Stan jumping out and shout but in this decade there are no domains without MX: they exists and they are used, i learned that after a customer complaint becausem y email-verification on the webserver rejected addresses without MX not sure how it does in case if non-existing subdomains however, that should be enabled on any public MX and catchs spam http://www.postfix.org/postconf.5.html#reject_unknown_sender_domain
Re: mod-sftp can't replace the exist file on server
Am 22.03.2014 08:58, schrieb Sense Zeng: proftpd version: 1.3.4a mod_sftp version: 0.9.8 nice but how is that a postfix topic?
Re: Reject client from domains without MX records
please avoid top-posting Am 22.03.2014 12:04, schrieb Pau Peris: Thanks for the explanation but i think i'm not understanding you. I understand MX records are not mandatory but i'm wondering what am i supposed to do when someone tries to send an email and the from address is not valid but an A or CNAME RR exists? By not valid i mean replying to the from address will never reach any mailbox. My worries are: * I'm responsible for sending email for domain.com http://domain.com but not for *.domain.com http://domain.com. * I'm only signing and following the rules - like DKIM, SPF, DMARC - for domain.com http://domain.com but haven't done anything special for *.domain.com http://domain.com. And i don't want my server to be responsible for sending not signed emails, etc. you did not make clear that you talk about sending mail * I do not want to send emails if the from address is not reachable. Probably the best solution should be to make sure the from address matches the login address? yes, you should not allow non-existent senders you need some rules before permit_sasl_authenticated in most cases that should be enough: http://www.postfix.org/postconf.5.html#reject_unlisted_sender ___ that is complexer to implement but if done properly the perfect solution however, you need to consider also aliases be listed here which may have not a own login but are allowed for the user/password combination reject_authenticated_sender_login_mismatch http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps reject_authenticated_sender_login_mismatch Enforces the reject_sender_login_mismatch restriction for authenticated clients only. This feature is available in Postfix version 2.1 and later. ___ that's how it looks in main.cf while you need a way for smtpd_sender_login_maps matching your environment, reject_non_fqdn_recipient and reject_non_fqdn_sender is highly recommended and rejects user mistakes and prevents auto-add myhostname if someone sends to johnny smtpd_sender_login_maps = proxy:mysql:/etc/postfix/mysql-senderaccess.cf smtpd_recipient_restrictions = permit_mynetworks reject_non_fqdn_recipient reject_non_fqdn_sender reject_unlisted_sender reject_authenticated_sender_login_mismatch permit_sasl_authenticated I'm already using reject_unknown_sender_domain. Thank you so much. On Sat, Mar 22, 2014 at 11:21 AM, li...@rhsoft.net mailto:li...@rhsoft.net li...@rhsoft.net mailto:li...@rhsoft.net wrote: Am 22.03.2014 10:29, schrieb Pau Peris: The issue here is mail.domain.com http://mail.domain.com http://mail.domain.com is responsible of sending email for domain.com http://domain.com http://domain.com but not *.domain.com http://domain.com http://domain.com so the latter are not DKIM signed and obviously are not valid recipient addresses as those domains are not able to recieve email so i would like to reject clients using a from domain address which is not able to receive email like *.domain.com http://domain.com http://domain.com. please don't post in HTML, i destroys quoting in a thread and has no benefit domains without MX records is a bad idea, there is no RFC saying that a MX record is mandatory, that is why any MTA falls back to the A-record of the domain if there is no MX and to avoid Stan jumping out and shout but in this decade there are no domains without MX: they exists and they are used, i learned that after a customer complaint becausem y email-verification on the webserver rejected addresses without MX not sure how it does in case if non-existing subdomains however, that should be enabled on any public MX and catchs spam http://www.postfix.org/postconf.5.html#reject_unknown_sender_domain
Re: Postfix + relayhost via riseup.net = Problems?
Am 22.03.2014 16:59, schrieb Anonymous12: How can I relay mail via riseup.net? You need to be using starttls before it allows you to login then just enable TLS, these days that should be done anyways http://www.postfix.org/TLS_README.html
Re: Postfix + relayhost via riseup.net = Problems?
Am 22.03.2014 17:04, schrieb Anonymous12: 22.3.2014 18:02, li...@rhsoft.net kirjoitti: Am 22.03.2014 16:59, schrieb Anonymous12: How can I relay mail via riseup.net? You need to be using starttls before it allows you to login then just enable TLS, these days that should be done anyways http://www.postfix.org/TLS_README.html No, I need to enable TLS for connecting to riseup.net so how can I do that? by just RTFM i linked (and don't reply off-list) http://www.postfix.org/TLS_README.html there are anchors on top http://www.postfix.org/TLS_README.html#client_tls
Re: Postfix + relayhost via riseup.net = Problems?
Am 22.03.2014 17:45, schrieb Anonymous12: 22.3.2014 18:17, li...@rhsoft.net kirjoitti: Am 22.03.2014 17:04, schrieb Anonymous12: 22.3.2014 18:02, li...@rhsoft.net kirjoitti: Am 22.03.2014 16:59, schrieb Anonymous12: How can I relay mail via riseup.net? You need to be using starttls before it allows you to login then just enable TLS, these days that should be done anyways http://www.postfix.org/TLS_README.html No, I need to enable TLS for connecting to riseup.net so how can I do that? by just RTFM i linked (and don't reply off-list) http://www.postfix.org/TLS_README.html there are anchors on top http://www.postfix.org/TLS_README.html#client_tls Mar 22 17:45:08 vps44713 postfix/smtp[2593]: 917133E0314: SASL authentication failed; cannot authenticate to server mail.riseup.net[198.252.153.56]: no mechanism available That's the error what I'm getting now so what - you do not provide any configuration details did you read http://www.postfix.org/SASL_README.html frankly that questions are answered thousand times and 5 minutes of google brings all the previous discussions and manuals however, you *always* need to provide details if you seek for help * output of postconf -n * what operating system * what packages do you have installed on Redhat systems you need at least the 3 packages below for working authentication and you should at the same time avoid cyrus-sasl-lmtp because that breaks authentication to MS exchange destinations cyrus-sasl-md5 cyrus-sasl-plain cyrus-sasl http://www.catb.org/esr/faqs/smart-questions.html
Re: Postfix + relayhost via riseup.net = Problems?
Am 22.03.2014 18:01, schrieb Anonymous12: 22.3.2014 18:57, Drizzt kirjoitti: 22.3.2014 18:17, li...@rhsoft.net kirjoitti: Am 22.03.2014 17:04, schrieb Anonymous12: 22.3.2014 18:02, li...@rhsoft.net kirjoitti: Am 22.03.2014 16:59, schrieb Anonymous12: How can I relay mail via riseup.net? You need to be using starttls before it allows you to login then just enable TLS, these days that should be done anyways http://www.postfix.org/TLS_README.html No, I need to enable TLS for connecting to riseup.net so how can I do that? by just RTFM i linked (and don't reply off-list) http://www.postfix.org/TLS_README.html there are anchors on top http://www.postfix.org/TLS_README.html#client_tls Mar 22 17:45:08 vps44713 postfix/smtp[2593]: 917133E0314: SASL authentication failed; cannot authenticate to server mail.riseup.net[198.252.153.56]: no mechanism available That's the error what I'm getting now. You need to configure your credentials as well, including mechanisms to use or not use. http://www.postfix.org/SASL_README.html#client_sasl I know that much, but I don't know which ones the destination server allows/accepts. you do not need to know, the postfix clients knows because the server tells the client the supported mechs, you need only have at least one of them supported on your side and as said avoid NTLM because it is broken to a lot of severs but preferred if it is available look at the last line [harry@srv-rhsoft:~]$ telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 srv-rhsoft.rhsoft.net ESMTP EHLO harry 250-srv-rhsoft.rhsoft.net 250-PIPELINING 250-SIZE 36700160 250-STARTTLS 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN SCRAM-SHA-1 show your /etc/postfix/sasl_passwd with passwords replaced and the rest untouched OS: Ubuntu 12.04 LTS I'll not show what packages I have installed as I see no reason to well then help yourself, nobody asked for all installed packages only the relevant sasl ones if i type yum remove cyrus-sasl-md5 cyrus-sasl-plain i get also no mechanism available for very clear reasons, thats all
Re: Postfix + relayhost via riseup.net = Problems?
Am 22.03.2014 19:41, schrieb Anonymous12: 22.3.2014 20:02, Viktor Dukhovni kirjoitti: On Sat, Mar 22, 2014 at 07:58:15PM +0200, Anonymous12 wrote: apt-cache search sasl suggests that libsasl2-2 may be what you need. There are additional mechanism-specific packages with various SASL plugins. apt-get install libsas12-2 = libsasl2-2 is already the newest version. Yes, but did you look for related packages? A bit of initiative, and you're there. I cannot locate what package I need... :( you are too lazy to seriously maintain a mailserver https://www.google.com/search?q=ubuntu+sasl+md5 http://packages.ubuntu.com/de/lucid/libsasl2-modules package: libsasl2-modules This package provides the following SASL modules: LOGIN, PLAIN, ANONYMOUS, NTLM, CRAM-MD5, and DIGEST-MD5 (with DES support).
Re: Postfix + relayhost via riseup.net = Problems?
Am 22.03.2014 19:57, schrieb Anonymous12: 22.3.2014 20:48, li...@rhsoft.net kirjoitti: Am 22.03.2014 19:41, schrieb Anonymous12: 22.3.2014 20:02, Viktor Dukhovni kirjoitti: On Sat, Mar 22, 2014 at 07:58:15PM +0200, Anonymous12 wrote: apt-cache search sasl suggests that libsasl2-2 may be what you need. There are additional mechanism-specific packages with various SASL plugins. apt-get install libsas12-2 = libsasl2-2 is already the newest version. Yes, but did you look for related packages? A bit of initiative, and you're there. I cannot locate what package I need... :( you are too lazy to seriously maintain a mailserver https://www.google.com/search?q=ubuntu+sasl+md5 http://packages.ubuntu.com/de/lucid/libsasl2-modules package: libsasl2-modules This package provides the following SASL modules: LOGIN, PLAIN, ANONYMOUS, NTLM, CRAM-MD5, and DIGEST-MD5 (with DES support) ok, you are even too lazy to read what others googled for you just install libsasl2-modules This is list of packages installed (Which might be useful to know): root@vps44713:~# cat list.txt libmail-sendmail-perl install libmail-spf-perlinstall libmailtools-perl install mail-stack-delivery install postfix install dovecot-imapd install dovecot-managesievedinstall dovecot-pop3d install dovecot-sieve install a obscure list with no relevance to SASL and even missing the already statet libsasl2-2 is already the newest version please re-consider if you really have the basic knowledge to maintain a MTA - this is a job with *high* responsibility
Re: Postfix + relayhost via riseup.net = Problems?
Am 22.03.2014 20:08, schrieb Anonymous12: 22.3.2014 21:04, li...@rhsoft.net kirjoitti: Am 22.03.2014 19:57, schrieb Anonymous12: 22.3.2014 20:48, li...@rhsoft.net kirjoitti: Am 22.03.2014 19:41, schrieb Anonymous12: 22.3.2014 20:02, Viktor Dukhovni kirjoitti: On Sat, Mar 22, 2014 at 07:58:15PM +0200, Anonymous12 wrote: apt-cache search sasl suggests that libsasl2-2 may be what you need. There are additional mechanism-specific packages with various SASL plugins. apt-get install libsas12-2 = libsasl2-2 is already the newest version. Yes, but did you look for related packages? A bit of initiative, and you're there. I cannot locate what package I need... :( you are too lazy to seriously maintain a mailserver https://www.google.com/search?q=ubuntu+sasl+md5 http://packages.ubuntu.com/de/lucid/libsasl2-modules package: libsasl2-modules This package provides the following SASL modules: LOGIN, PLAIN, ANONYMOUS, NTLM, CRAM-MD5, and DIGEST-MD5 (with DES support) ok, you are even too lazy to read what others googled for you just install libsasl2-modules This is list of packages installed (Which might be useful to know): root@vps44713:~# cat list.txt libmail-sendmail-perl install libmail-spf-perlinstall libmailtools-perl install mail-stack-delivery install postfix install dovecot-imapd install dovecot-managesievedinstall dovecot-pop3d install dovecot-sieve install a obscure list with no relevance to SASL and even missing the already statet libsasl2-2 is already the newest version please re-consider if you really have the basic knowledge to maintain a MTA - this is a job with *high* responsibility Allright then. Pastebin = http://pastebin.com/924Pyrru no need for that - grep exists command | grep -i sasl is what i expect from a sysadmin *when* have you installed libsasl2-modules? *did you* restart postfix after that, if not why? did you retry? what is the content of /etc/postfix/sasl_passwd? what is the current output of telnet localhost 25 followed be EHLO?
Re: Postfix + relayhost via riseup.net = Problems?
Am 22.03.2014 21:47, schrieb Anonymous12: package: libsasl2-modules This package provides the following SASL modules: LOGIN, PLAIN, ANONYMOUS, NTLM, CRAM-MD5, and DIGEST-MD5 (with DES support) ok, you are even too lazy to read what others googled for you just install libsasl2-modules This is list of packages installed (Which might be useful to know): root@vps44713:~# cat list.txt libmail-sendmail-perl install libmail-spf-perlinstall libmailtools-perl install mail-stack-delivery install postfix install dovecot-imapd install dovecot-managesievedinstall dovecot-pop3d install dovecot-sieve install a obscure list with no relevance to SASL and even missing the already statet libsasl2-2 is already the newest version please re-consider if you really have the basic knowledge to maintain a MTA - this is a job with *high* responsibility Allright then. Pastebin = http://pastebin.com/924Pyrru no need for that - grep exists command | grep -i sasl is what i expect from a sysadmin *when* have you installed libsasl2-modules? *did you* restart postfix after that, if not why? did you retry? what is the content of /etc/postfix/sasl_passwd? what is the current output of telnet localhost 25 followed be EHLO? root@vps44713:~# cat list.txt | grep -i sasl libsasl2-2 install libsasl2-modulesinstall php-auth-sasl install looks good root@vps44713:~# cat list.txt | grep -i dovecot dovecot-coreinstall dovecot-imapd install dovecot-managesievedinstall dovecot-pop3d install dovecot-sieve install root@vps44713:~# cat list.txt | grep -i mail-stack mail-stack-delivery install not relevant for postfix client SASL I have no clue when i have installed libsasl2-modules well, the intention of my first post was to get informations which sasl relevant packages are installed so anybody using Ubuntu can work with them, the rdhat packages where an example because my systems are redhat-based I think that it was automatically installed as requiment. Contents of: /etc/postfix/sasl_passwd: root@vps44713:~# cat /etc/postfix/sasl_passwd # destination credentials [mail.riseup.net]:587 user:pass looks good, needs to bex *exactly* written like the relayhost which is the case Real ones got replaced with user:pass. Telnet to localhost 25: 220 example.com ESMTP Postfix ehlo localhost 250-example.com 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN Does that answer the questions? i hoped to get the AUTH mechs supported but maybe you also enabled auth only via SSL in one of your previous posts you wrote OS is debian based. 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN the problem is that there is no CRAM-MD5 and most likely the other side does not like PLAIN but since you are using smtpd_sasl_type = dovecot it does not matter what your smtpd supports because different authentication libraries are used break: openssl s_client -starttls smtp -crlf -connect mail.riseup.net:587 shows after the SSL stuff and the EHLO command that the other host supports LOGIN / PLAIN, so i am somehow out of ideas did you *really* restart postfix and try again send a new message? while doing so please post the *complete log* of the trensaction 250 DSN EHLO test 250-fruiteater.riseup.net 250-PIPELINING 250-SIZE 2560 250-ETRN 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
Re: Postfix + relayhost via riseup.net = Problems?
Am 22.03.2014 22:02, schrieb li...@rhsoft.net: break: openssl s_client -starttls smtp -crlf -connect mail.riseup.net:587 shows after the SSL stuff and the EHLO command that the other host supports LOGIN / PLAIN, so i am somehow out of ideas did you *really* restart postfix and try again send a new message? while doing so please post the *complete log* of the trensaction 250 DSN EHLO test 250-fruiteater.riseup.net 250-PIPELINING 250-SIZE 2560 250-ETRN 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN uhm you posted that line in your postconf -n output smtp_tls_policy_maps = hash:/etc/postfix/tls_policy besides a complete log what is the content of that file? is there anything related to the destination which may restrict the used auth-mechs and so no matching one is left?
Re: Postfix + relayhost via riseup.net = Problems?
Am 22.03.2014 22:08, schrieb Anonymous12: 22.3.2014 23:06, li...@rhsoft.net kirjoitti: uhm you posted that line in your postconf -n output smtp_tls_policy_maps = hash:/etc/postfix/tls_policy besides a complete log what is the content of that file? is there anything related to the destination which may restrict the used auth-mechs and so no matching one is left? Output of /etc/postfix/tls_policy: [mail.riseup.net]:587 encrypt protocols=TLSv1 ciphers=high Complete log: Mar 22 22:06:02 vps44713 postfix/master[2311]: reload -- version 2.9.6, configuration /etc/postfix Mar 22 22:06:16 vps44713 postfix/smtpd[10210]: connect from localhost[127.0.0.1] Mar 22 22:06:49 vps44713 postfix/smtpd[10210]: 7BFFB3E030B: client=localhost[127.0.0.1] Mar 22 22:06:57 vps44713 postfix/cleanup[10224]: 7BFFB3E030B: message-id=20140322210649.7bffb3e0...@example.com Mar 22 22:06:57 vps44713 postfix/qmgr[10204]: 7BFFB3E030B: from=anonymou...@riseup.net, size=338, nrcpt=1 (queue active) Mar 22 22:06:58 vps44713 postfix/smtp[10225]: warning: SASL authentication failure: No worthy mechs found Mar 22 22:06:58 vps44713 postfix/smtp[10225]: 7BFFB3E030B: SASL authentication failed; cannot authenticate to server mail.riseup.net[198.252.153.55]: no mechanism available Mar 22 22:06:58 vps44713 postfix/smtpd[10210]: disconnect from localhost[127.0.0.1] Mar 22 22:07:00 vps44713 postfix/smtp[10225]: warning: SASL authentication failure: No worthy mechs found Mar 22 22:07:00 vps44713 postfix/smtp[10225]: 7BFFB3E030B: to=anonymou...@riseup.net, relay=mail.riseup.net[198.252.153.56]:587, delay=17, delays=14/0.05/2.5/0, dsn=4.7.0, status=deferred (SASL authentication failed; cannot authenticate to server mail.riseup.net[198.252.153.56]: no mechanism available) i do not see any indication that the connection is encrypted if that is the case, well, than no auth is offered main.cf: smtp_tls_loglevel = 1 (don't forget the postfix reload after that) after that you should see lines similar to the one below if teh connection is encrypted, honsetly i would *remove* smtp_tls_policy_maps from the configuraton, it is not needed for opportunistic TLS and should only be used to solve *specific* problems Mar 22 03:42:05 testserver postfix/smtp[7211]: Untrusted TLS connection established to 192.168.196.1[192.168.196.1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Re: Sending notification to sender
Am 21.03.2014 18:47, schrieb Ignacio Garcia: I wish I could send an automated notification upon receiving emails from a couple of domains. for example, let's assume those domains are hotmail.com and gmail.com. What I need is, everytime my users receive a message from either any...@hotmail.com or any...@gmail.com an automated message is sent to those accounts. Is there anyway I can implement that? not that i know and you should *hardly* avoid doing such things until you can make sure there are no forged senders - you can't do that and so the idea is broken if you seek how to get blacklistet on major sites there are easier ways http://en.wikipedia.org/wiki/Delivery_Status_Notification
Re: Separate postfix server for mail submission (MSA)
Am 20.03.2014 12:24, schrieb ML mail: That's actually the guide I have followed but I thought there must be something missing because I alwayse get the following Access denied error message: Mar 20 12:22:38 debian postfix/submission/smtpd[18467]: NOQUEUE: reject: RCPT from unknown[192.168.10.152]: 554 5.7.1 unknown[192.168.10.152]: Client host rejected: Access denied; from=t...@domain.tld to=validem...@yahoo.com proto=ESMTP helo=desktop.local What could I have done wrong here? don't top-post in HTML that is only one log line - where is the evidence that the sender used authentication at all and where is the output of postconf -n as statet in the weclome message?
Re: Separate postfix server for mail submission (MSA)
Am 20.03.2014 13:11, schrieb ML mail:
Sorry about that. Here below is the output of a postconf -n:
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
default_transport = smtp
inet_interfaces = all
inet_protocols = all
mailbox_command = procmail -a $EXTENSION
mailbox_size_limit = 0
mydestination = debian, localhost
mynetworks = 127.0.0.0/8 111..111.0/24 [::1]/128 [fe80::]/64
readme_directory = no
recipient_delimiter = +
relay_transport = smtp
relayhost =
smtp_sasl_auth_enable = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_sasl_path = inet:111.111.111.112:12345
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/certs/cert.pem
smtpd_tls_key_file = /etc/ssl/private/key.pem
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:
${data_directory}/smtpd_scache smtpd_use_tls = yes
main dot cf:
smtpd_client_restrictions = permit_sasl_authenticated
I tried that one but it did not help. Here is also the submission entry I am
using on my master.cf file:
submission inet n - - - - smtpd -v
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=inet:111.111.111.112:12345
-o smtpd_sasl_security_options=noanonymous
-o smtpd_sasl_local_domain=$myhostname
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
you still posting in HTML - stop that!
show us the complete log starting with the connection line down
to the rejection - you still did not show any evidence that
the client used authentication at all
Re: Separate postfix server for mail submission (MSA)
why do you still post in HTML? Am 20.03.2014 13:16, schrieb ML mail: Sorry my fault, it is working now! I have forgotten to add user authentication into my mail client for testing :( and that is what i said in my first reply: that is only one log line - where is the evidence that the sender used authentication at all and where is the output of postconf -n as statet in the weclome message?
Re: Issue with Windows mail client software
Am 20.03.2014 17:01, schrieb mizuki: I'm running Postfix-2.6.6 which is the version coming with latest Redhat6 and we have firewall in between the public network and campus so we have conduits 465 opened for sending emails from outside networks. All mail clients work fine except the mail clients made by Microsoft such as Windows Live Mail Mail App Outlook Express Windows Outlook. Most of them can send emails fine from Campus network but not from outside (Windows Outlook on Mac will fail on both sending from public and campus network), all have the same failing msgs in the server log with '554 5.7.1 Relay Access Denied' what about just configure the clients to use smtp-authentication? maybe some clients default to use smtp-auth with the same credentials as used for IMAP/POP3 but at the end of the day the admin/user which configures the client is repsonsible to verify that But I do not understand why it will fail on different network because they are in mynetworks as long they are in your network mynetworks = 120.199.0.0/16, 192.168.0.0/16, 127.0.0.0/8, 10.2.0.0/16 smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated
Re: Issue with Windows mail client software
Am 20.03.2014 17:32, schrieb Viktor Dukhovni: smtpd_tls_key_file = /etc/pki/mail/private/hostkey.pem smtpd_tls_mandatory_ciphers = high I would leave this at medium, otherwise you're disabling RC4, which is the best cipher available on older Windows systems (Windows XP) Windows XP is happy with DES-CBC3-SHA which is not that broken as RC4 which with end of 2013 finally falls through any security audit https://www.google.com/search?q=CVE+RC4
Re: Forwarding by Sender
Am 19.03.2014 15:19, schrieb Drew Mazurek: I have an application that sends and receives email. I don't want to have it process bounces, though, so I'd like its dedicated Postfix relay to forward all mailer-daemon messages to me rather than to the application. In other words, I'd like to create a table that maps From or sender addresses to destinations, a la: mailer-daemon@m...@domain.com mailto:m...@domain.com you application has to use a correct return-path instead hacking around, with the return-path you just decide where bounces are sent to and the sender of the bounces does not matter that said: you should not bounce in most cases at all
Re: Forwarding by Sender
just don't switch to top-posting in the middle of a thread Am 19.03.2014 19:57, schrieb Drew Mazurek: Rewriting the envelope sender address at the first hop out of the application seems to work best. Next question: is it possible to log what the address was before it gets rewritten? Our mail.log now shows the new bounce address, but for debugging purposes, it'd be nice to know what the address was before the envelope rewrite. On Wed, Mar 19, 2014 at 11:23 AM, Wietse Venema wie...@porcupine.org mailto:wie...@porcupine.org wrote: Drew Mazurek: I have an application that sends and receives email. I don't want to have it process bounces, though, so I'd like its dedicated Postfix relay to forward all mailer-daemon messages to me rather than to the application. Bounces are sent to the envelope sender address. On the Postfix relay, 1) either rewrite the envelope sender address of outbound mail to you. 2) or rewrite the envelope recipient address of inbound mail to you. I suggest doing 2) with virtual_alias_maps normally you see queue-id's in every log as well as in message headers und you get them on the smtp client in the servers response that he has accepted a message too however, you need to provide your actual log records here from all invloved hops
Re: postfix + mailman: undelivered, user unknown
Am 19.03.2014 20:08, schrieb Tout Guy: I set up postfix + dovecot and know that I want to have mailing lists I decided to install mailman. Everything is working except that I cannot send emails to my mailing list (and this is quite important, don't you think?). When I'm sending a mail to my mailing list (t...@too.gy), I get a reply 'Undelivered Mail Returned to Sender' nothing that you posted below mentioned /etc/aliases how should postfix know about the mailing lists? https://help.ubuntu.com/community/Mailman
Re: postfix after queue content filter
as lonf you are talking about pickup there is no port
involved at all and no smtp/smtpd setting is relevant
because it's just not SMTP
Am 19.03.2014 20:49, schrieb Tim Prepscius:
I'm looking through the docs of sendmail, seeing how I can get it to
send to a specific port. But not seeing it.
Am I looking in the wrong place?
On 3/19/14, Lewin Bormann der.mess...@yahoo.com wrote:
It seems that the local delivery (pickup?) uses the content filter which
it shouldn't, AFAIK.
If that is the case, the following master.cf configuration taken from my
installation may help:
-- snip ---
ip:smtpinet n - n - - smtpd
-o content_filter=myspamfilter
-o receive_override_options=no_address_mappings,no_milters
ip:587 inet n - n - - smtpd
[ip6]:smtp inet n - n - - smtpd
-o content_filter=myspamfilter
-o receive_override_options=no_address_mappings,no_milters
[ip6]:587 inet n - n- - smtpd
127.0.0.1:smtp inetn - n - - smtpd
[::1]:smtp inetn - n - - smtpd
[...]
myspamfilter unix - n n - - pipe
flags=Rq user=debian-spamd argv=/etc/postfix/spamchk -oi -f ${sender}
${recipient}
snap
The result is that only mail submitted on port 25 is piped through the
content filter (in my case a shell script involving SpamAssassin and
sendmail, similar to the mentioned README). Mail on 587 from users and
from localhost is not filtered
Re: postfix after queue content filter
Am 19.03.2014 20:59, schrieb Tim Prepscius:
so let's say I wanted to do what Lewin said,
have normal mail on 25, and then special non filtered mail (mail that
has already gone through the filter) on some other port, let's say
10025
then you just configure that listener and avoid asking questions
in context of pickup and sendmail binary because they are both
not involved
if your inital post would have had the same content as above the
first reply would have been that clear - describe your goal and
not what you have done or think has to be done to reach it
-o mynetworks=192.168.196.0/24 is in such setups typically
the address of the delivering filter and not a network, in
mayn cases just 127.0.0.1:10025 has the same result
/etc/postfix/main.cf
filter_smtpd_recipient_restrictions = permit_mynetworks, reject
/etc/postfix/master.cf:
10025 inet n - y -60 smtpd
-o mynetworks=192.168.196.0/24
-o smtpd_client_connection_count_limit=60
-o smtpd_recipient_restrictions=$filter_smtpd_recipient_restrictions
-o receive_override_options=no_header_body_checks,no_milters
-o local_header_rewrite_clients=
-o sender_dependent_relayhost_maps=
-o content_filter=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=
-o smtpd_relay_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_helo_required=no
-o smtpd_sender_restrictions=
-o smtpd_sender_login_maps=
-o smtpd_data_restrictions=
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_rate_limit=0
-o smtpd_client_recipient_rate_limit=0
-o smtpd_peername_lookup=no
-o smtpd_use_tls=no
-o smtpd_tls_security_level=none
-o smtpd_sasl_auth_enable=no
-o smtpd_reject_footer=
-o max_idle=1h
-o max_use=1000
At the end of the example filter script there is a sendmail command.
Is there anyway to have this work with this scenario?
http://www.postfix.org/FILTER_README.html
On 3/19/14, li...@rhsoft.net li...@rhsoft.net wrote:
as lonf you are talking about pickup there is no port
involved at all and no smtp/smtpd setting is relevant
because it's just not SMTP
Am 19.03.2014 20:49, schrieb Tim Prepscius:
I'm looking through the docs of sendmail, seeing how I can get it to
send to a specific port. But not seeing it.
Am I looking in the wrong place?
On 3/19/14, Lewin Bormann der.mess...@yahoo.com wrote:
It seems that the local delivery (pickup?) uses the content filter which
it shouldn't, AFAIK.
If that is the case, the following master.cf configuration taken from my
installation may help:
-- snip ---
ip:smtpinet n - n - - smtpd
-o content_filter=myspamfilter
-o receive_override_options=no_address_mappings,no_milters
ip:587 inet n - n - - smtpd
[ip6]:smtp inet n - n - - smtpd
-o content_filter=myspamfilter
-o receive_override_options=no_address_mappings,no_milters
[ip6]:587 inet n - n- - smtpd
127.0.0.1:smtp inetn - n - - smtpd
[::1]:smtp inetn - n - - smtpd
[...]
myspamfilter unix - n n - - pipe
flags=Rq user=debian-spamd argv=/etc/postfix/spamchk -oi -f ${sender}
${recipient}
snap
The result is that only mail submitted on port 25 is piped through the
content filter (in my case a shell script involving SpamAssassin and
sendmail, similar to the mentioned README). Mail on 587 from users and
from localhost is not filtered
Re: Network TCP port 47107 is being used by /usr/lib/postfix/proxymap. Possible rootkit: T0rn
Am 18.03.2014 16:09, schrieb Ben Johnson: A daily rkhunter scan produced the following warning, which mentions Postfix. Is this a false-positive? Warning: Network TCP port 47107 is being used by /usr/lib/postfix/proxymap. Possible rootkit: T0rn Use the 'lsof -i' or 'netstat -an' command to check this these are mostly false positives and that ports are the local port of a connection form the named process, any TCP connection has a non-privileged local port above 1024
Re: 20-40+ second delays. Is this normal?
Am 18.03.2014 16:38, schrieb Wietse Venema: Now, look for SELINUX warnings. Or see if the warning goes away with: /etc/selinux/config: SELINUX=disabled and $service selinux restart selinux is not a service http://www.cyberciti.biz/tips/enable-permissive-mode-for-selinux-troubleshooting-purpose.html
Re: non TLS Auth only from local
Am 18.03.2014 22:21, schrieb Sergei: Is there a way to announce and allow unencrypted smtp authentication (AUTH LOGIN) only from 127.0.0.1? I want Roundcube (webmailer) to use the users credentials when sending mail for them and for performance reasons this should not require TLS. But when remote clients connect they should not be able to use unencrypted authentication surely, configure a differnent port in master.cf and override the LS configuration - but why? it's hardly possible that the encryption for sending mails from roundcube is a performance problem and if it really is you have a larger problem
Re: Limit number of Cci recipient
Am 17.03.2014 12:36, schrieb Alexandre Ellert: Some of our customers have bad malling practices and I want to limit the max number of Cci recipient. I already use smtpd_recipient_limit but I would like to use a lower value for Cci. Do you know how can I achieve this using Postfix? on SMTP level there is only a mail to command, To/CC-headers are for the MUA, think about a BCC with no such header and you know why
Re: Mail Server Accused of Spam!
Am 15.03.2014 11:08, schrieb Tim Smith: I have a few users who just want their email forwarded onto GMail Accounts however these users seem to receive an inordinate amount of spam and so I get a message from Google in my logs stating: /Feb 7 09:39:53 xxx postfix/smtp[15191]: 118C8C0C2A6: host gmail-smtp-in.l.google.com[173.194.78.26] said: 421-4.7.0 [xx.xx.xx.xx 15] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited. Please visit http://www.google.com/mail/help/bulk_mail. 421 4.7.0 html to review our Bulk Email Senders Guidelines. fk8si1147119wib.80 - gsmtp (in reply to end of DATA command)/ That's fine and I totally understand why they do that but is there a way that Postfix can flag the message so that Google understands that we are just forwarding the message and that we are not the originator of the spam? postfix can flag the message, well it does in it's Received headers but they can't be used anywhere seriously to classify a message because the only mailheaders someone can trust are the one generated in his own network and even then needs to be taken care that faked one from the internet are removed on the border MTA - so finally no and it does not matter if you are forwarding or not if you deliver spam unfiltered you are responsible no matter who is origin the above is BTW no indication of spam per se, it's a temporary reject and that messages are delivered later, but if they are *really* spam you need to find a way REJECT them on your MX for two resons: * accept and filter after queue makes you to a backscatter * not filter at all and forward makes you to a spam-source
Re: Force AUTH before MAIL FROM command for submission port 587
Am 16.03.2014 01:53, schrieb Karl Klein: when I run the security test on http://www.emailsecuritygrader.com, I always get a - for AUTH Required (port 587). To get a +, the descriptions says: Your system requires authentication (AUTH) on port 587 before the MAIL FROM command is issued that is pure nonsense the reason is http://www.postfix.org/postconf.5.html#smtpd_delay_reject and finally don't blindly follow random tools with no clue how do you debug anything without no information in your logs?
Re: mx backup
Am 13.03.2014 14:42, schrieb Pol Hallen: Hi all, I need an advice about my mx-backup server main mail server has many antispam system (amavis, spamassassin, etc.), when an email bounced by these antispam, the email goes to mx-backup server. mx-backup server keep email inside own queue. So, do I need install amavis and other antispam system also on mx-backup? surely - the other option would be to scan the from the backup-MX delivered messages but *that* would lead in becoming a backscatter the machine which accepts mail from the internet needs to *reject* unwanted ones
Re: mx backup
Am 13.03.2014 14:46, schrieb li...@rhsoft.net: Am 13.03.2014 14:42, schrieb Pol Hallen: Hi all, I need an advice about my mx-backup server main mail server has many antispam system (amavis, spamassassin, etc.), when an email bounced by these antispam, the email goes to mx-backup server. mx-backup server keep email inside own queue. So, do I need install amavis and other antispam system also on mx-backup? surely - the other option would be to scan the from the backup-MX delivered messages but *that* would lead in becoming a backscatter the machine which accepts mail from the internet needs to *reject* unwanted ones or better forget the broken idea of a backup MX a short downtime does not matter, that's why mail get deferred by the sender and if not it was most likely only junk - a sane MTA retries
Re: mx backup
Am 13.03.2014 21:08, schrieb Pol Hallen: There's evidence that some spammers reverse-sort MX records, intentionally sending to the backup MX first. Consequently, the backup MX /must/ have anti-spam controls identical to the primary. But consider if you truly need a backup MX. Most folks have dropped them because they're spam magnets, and reliability has increased such that extended down time is unusual. Nearly all legit mail servers will retry delivery for several days if your MX is down. As a compromise, some folks keep a hot spare MX mail server configured as backup MX but with port 25 firewalled off until the primary fails. hi, thanks for your reply I need an mx-backup says who? because my first server could goes down * a server does not go down regulary * short network outages are meaningsless for a MX * if the server crashs monitoring / auto-restart / HA is the way to go * invest the time you spend or better said waste for a backup MX in HA how many domains do you have on your server? we are hosting some hundret business domains on a single server and only over my dead body i start the burden of a backup MX with all it's drawbacks there goes nothing down the last 10 years and network problems on the ISP side are self healing because any MTA out there re-tries for 3-5 days to deliver a message if the destination is not reachable
Re: Allow client hostname to relay mails.
Am 12.03.2014 12:06, schrieb tejas sarade: I want to allow a machine with dynamic IP address but static hostname through DynDNS. I know that hostname in smtpd_client_restricions works only through reverse DNS lookup. Is there any way, I can allow the client based on hostname which has dynamic IP? how should that be possible? the hostname the client pretends? how could you trust that? how could you trust any hostname? there is nothing else trustable than the connecting real IP frankly you must even not make relay decisions based on a static PTR because i can add any PTR i like in my own DNS server which is authoritative for my in-addr.arpa zone the same way you can nobody stop make a valid PTR record you like to see on your side for grant relay permissions
Re: Allow client hostname to relay mails.
Am 12.03.2014 12:58, schrieb tejas sarade: how should that be possible? the hostname the client pretends? how could you trust that? how could you trust any hostname? there is nothing else trustable than the connecting real IP No. Not the hostname that client pretends, I am talking about valid DNS A record throuch DNS lookup. how do you imagine that please read how DNS works in case of a connecting IP you have no A-Record A = translate name to IP and not the other way PTR = IP to name and controlled by the DNS responsible for the network range frankly you must even not make relay decisions based on a static PTR because i can add any PTR i like in my own DNS server which is authoritative for my in-addr.arpa zone I am not running my own DNS server does not matter, i do and if i know what hostname you like to see i greet yoi with that in EHLO and set my PTR to that name the same way you can nobody stop make a valid PTR record you like to see on your side for grant relay permissions I just want to creat and access control system where I will provide the list of valid hostname(FQDN). Postfix will lookup the IP of that FQDN through public DNS and consider that IP as trusted IP that does not work - postfix can only query the PTR and at best than verify that the PTR to a IP matchs the A-record but that also means if doing so you maust *always* make sure that your dynamic IP becomes the correct in-addr.arpa PTR please understand that you must not make relay decisions based on hostnames - the only harmless decisions are rejects based on that but never for opening a spam door
Re: Possible to block all attachments?
Am 11.03.2014 14:33, schrieb jmct: mime_header_checks = regexp:/etc/postfix/mime_header_check regexp:/etc/postfix/mime_header_check is unavailable. open /etc/postfix/mime_header_check: No such file or directory and the file /etc/postfix/mime_header_check exists?
Re: Translate error messages
Am 10.03.2014 17:58, schrieb Eduardo Ramos: I'd like to know if it's possible translate a bounce message as: Original: fabiana.ci...@a1.net: User has moved to fabiana.ci...@a2.net Translated fabiana.ci...@a1.net: Usuário movido para fabiana.ci...@a2.net please don't do that even if you find a way nothing more bad for a sysadmin need google translate to read a bounce message, most people speak english, at least enough to read such a message - i can't even say what lang your second message is (maybe spain and the maybe is the problem)
Re: postfix doesn't use NIS behind by back, right?
Am 07.03.2014 22:32, schrieb Jay G. Scott: That is, I deliberately banish all references to NIS from main.cf. (I might need the NIS client libraries to compile and link but I don't care about that.) postfix does not (in that case) use NIS for anything, right? I could firewall the ports closed and nothing bad happens, correct? i personally know nobody using NIS and especially even opens port in the firewall in case of postfix - so yes postfix is running fine without
Re: TLS help request
Am 08.03.2014 01:11, schrieb Glenn English: Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression let me guess: BSD as operating system there where a lot of posts recently that this is a problem honestly you should always disable compression in con text of TLS http://www.postfix.org/TLS_README.html LEGACY_SERVER_CONNECT See SSL_CTX_set_options(3). NO_TICKET See SSL_CTX_set_options(3). NO_COMPRESSION Disable SSL compression even if supported by the OpenSSL library. Compression is CPU-intensive, and compression before encryption does not always improve security. Example: /etc/postfix/main.cf: tls_ssl_options = no_ticket, no_compression You should only enable features via the hexadecimal mask when the need to control the feature is critical (to deal with a new vulnerability or a serious interoperability problem). Postfix DOES NOT promise backwards compatible behavior with respect to the mask bits. A feature enabled via the mask in one release may be enabled by other means in a later release, and the mask bit will then be ignored. Therefore, use of the hexadecimal mask is only a temporary measure until a new Postfix or OpenSSL release provides a better solution.
Re: Compromised Passwords
Am 06.03.2014 18:04, schrieb Adam Moffett: Two steps eliminated this problem for us: 1) Accounts with more than 6 failed login attempts in a 10 minute period are disabled for 10 minutes. This makes brute force methods to find passwords almost impossible. that is fine 2) Limit to 200 outgoing messages per day per user. We'll raise it to any reasonable value for an individual account. I.E.: We'll let you send 1000 per day so you can get your church newsletter out, but we won't remove the limit completely and let you spam (knowingly or not). This minimizes the damage if a password is still compromised. 200 is a pretty high limit. Very few people send more than 50 in a day, and almost nobody sends more than 100. We set it at 200 so we wouldn't have to hear from anybody who isn't bulk mailing i know users hitting the 200 per day regulary frankly they exceed 50 smtp connections per 30 minutes, manually written mails :-)
Re: How to redirect one specific sender to one specific non-existent recipient?
Am 04.03.2014 14:19, schrieb Matthias Egger: Can somebody point me to the propper direction on how to solve this? What we have: * secret...@ee.ethz.ch has bought a long time ago some software where she regulary receives hidden (to the public) download links for upgrades. * Secretary has quit and her account will be removed soon. * We have contacted sa...@software.tld and asked to replace the secretary address by some other address Unfortunately sa...@software.tld is ignoring us and still sends the download links to secret...@ee.ethz.ch. raise that to their managers, if you have a service contract they must not ignore you What i would like to: I would like to make sure, that these specific upgrade mails coming from sa...@software.tld sent to secret...@ee.ethz.ch will be redirected to another address. But Emails coming from some...@somewhere.tld (which also could include some.othersen...@software.tld) should receive a regular Recipient address rejected: User unknown message. Is this possible somehow? even if you find some hack to achive this - don't do that you taint your setup and over the long it will be unmaintainable what if the one understanding this mailserver setup quits? if i would be the new admin and find such hacks i would quit at day one in other words: do not try to solve social problems with technical hacks
Re: backscatter
Am 04.03.2014 17:55, schrieb Mike McGinn: I ma getting some backscatter problems lately. I used to have the line: reject_unknown_reverse_client_hostname, in my smtpd_client_restrictions but I commented it out because an important client is on a microsoft cloud and had been having problems sending mail to us. Would adding the reject_unknown_reverse_client_hostname help with the backscatter? you do not understand what a backscatter is * you accept a message * you have no inbox * you send a bounce so just don't accept messages on the MX which you finally can't deliver - period
Re: Make TLS errors hard, not soft
Am 03.03.2014 15:44, schrieb Ralf Hildebrandt: The error mesage being one of: TLS is required, but host %s refused to start TLS: %s TLS is required, but was not offered by host %s TLS is required, but our TLS engine is unavailable %s: TLS is required but unavailable, don't know why TLS is required, but unavailable Cannot start TLS: handshake failure If you are concerned about confusing error messages, making the soft error hard is obviously not sufficient. You will also need to massage the error message text. Exactly. Usually the users stop reading at the subject: of the bounce. I know this to be true, since they keep resending the same mail over and over again. that may also be the MUA in case of a iPhone you can reject with whatever status code you like in case of sending without authentication and the device will try to do the same every 5 minutes i had a customer doing this for the same message of *3 months* until the device got stolen where i was able to say day and time from the maillog - don't remember how often i called the person and said he should fix his settings our delete that message on the device
Re: any known issues with mailing lists?
Am 03.03.2014 23:45, schrieb Jay G. Scott: I have one user telling me that he has a long mailing list (on the order of 34 -- hardly long) and some of the recipients bounce. If he mails them one at a time the mail works -- so the addresses are okay. What else should I tell you? the content of the bounce message as less as possible anonymized anything else is looking in a crystal ball
Re: Mac Postfix gateway local delivering.
Am 02.03.2014 01:08, schrieb Rick Zeman: Howdy, I'm trying to set up a Mac version of postfix (2.9.4) as a mail gateway. It's been many years since I've set up a postfix instance, and being extremely rusty I've gotten myself stuck. I've got things working so that mail destined for outside the domain gets delivered to the relay host on an alternate port using SASL, so that's all working well. However, mail destined for the local domain isn't being being relayed to the mail server (at least using mail from the command line), it's apparently being handled by dovecot even though I commented out the dovecot section of the master.cf and restarted postfix: Mar 1 18:58:58 miniserv.private postfix/smtp[16760]: 3AC89A009B: to=r...@pointyears.net mailto:r...@pointyears.net, relay=127.0.0.1[127.0.0.1]:10024, delay=0.08, delays=0.02/0/0/0.06, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4D42BA00A2) transport_maps = hash:/etc/postfix/transport so what is local - if you have a transport than it happens to get used
Re: Make TLS errors hard, not soft
Am 27.02.2014 19:28, schrieb Viktor Dukhovni: On Thu, Feb 27, 2014 at 12:48:47PM -0500, Wietse Venema wrote: Peer Heinlein: You got it. That's what we ARE doing and that's why I'm asking for. :-) Well this is a very non-standard deployment. I have to spend my limited cycles wisely on things that benefit the most people. We have situations, where a mail MUST send using TLS. And I need a FAST and reliable DSN back to the sender if that's not possible. If it MUST be TLS, then why can't mail wait until the destination is repaired? Also TLS is a transport mechanism, but transport failure is not message failure. Equating transport failure with message failure is semantically flawed. Are all the destinations in question served by exactly one MX host, why? If not, the failure would have to be based on some global observation that *every* candidate MX host failed to offer TLS, or the certificates of *every* MX host failed to verify they offer a mailservice with *unconditional* encryption in germany https://mailbox.org/ http://www.heise.de/ix/meldung/Mailbox-org-Vollstaendig-verschluesselter-deutscher-E-Mail-Dienst-2120363.html
Re: TLS client logging PATCH
Am 26.02.2014 02:25, schrieb DTNX Postmaster: On 26 Feb 2014, at 00:54, li...@rhsoft.net wrote: Am 26.02.2014 00:46, schrieb DTNX Postmaster: On 26 Feb 2014, at 00:29, li...@rhsoft.net wrote: Am 25.02.2014 17:41, schrieb Dirk Stöcker: On Tue, 25 Feb 2014, Viktor Dukhovni wrote: smtp_dns_support_level = dnssec was enough to fix this. I'll see how many servers will have a Verified connection in the future. I hope you read the note about the importance of having 127.0.0.1 and/or ::1 as the only nameservers listed in /etc/resolv.conf, and No, did not read it, but this was obvious :-) why and how should this work for real networks where you have two DNS servers for failover in the LAN and typically no one on the mailserver? if 192.168.196.1 and 192.168.196.2 support DNSSEC it has to work if both of them in resolv.conf, otherwise DANE will not happen in the real world The local resolver can have the resolvers on the LAN configured as forwarders, but you need the local stub resolver. No reason not to have one, really, especially on a busy mail server yes, you normally have a local resolver on the mailserver but you hardly trust that one alone and in case it crashs you typically have another one on the LAN mailserver's /etc/resolv.conf: 127.0.0.1 192.168.196.1 192.168.192.2 If you cannot trust a local resolver by itself redundancy has nothing to do with trust as well as RAID is not a backup as the only resolver configured at the system level, you have a different problem that has nothing to with DANE, or Postfix see above For DANE to work properly and reliable, local only is a requirement if you can not trust your resolvers in the own network you have a problem and if your localhost resolver does nothing else than ask these resolvers you gain noting in case you have a postfix relay on any machine and if you start to implement DANE network wirde it is nonsense run on 20, 30, 100 machines on top of the same virtualization host a local resolver asking another VM on the same host
Re: TLS client logging PATCH
Am 26.02.2014 07:33, schrieb Viktor Dukhovni: On Wed, Feb 26, 2014 at 12:54:37AM +0100, li...@rhsoft.net wrote: The local resolver can have the resolvers on the LAN configured as forwarders, but you need the local stub resolver. No reason not to have one, really, especially on a busy mail server yes, you normally have a local resolver on the mailserver but you hardly trust that one alone and in case it crashs you typically have another one on the LAN 1. In a decade of running BIND caching resolvers of various antiquities on Morgan Stanley MTAs handling ~2 million messages a day, I've never seen a local resolver crash. that is not the point, having on every VM running postfix a local resolver is overkill - that is the point and redundancy is always a good idea 2. If yours do, arrange for automated re-start and send an alert. The postmaste master(8) daemon might be killed, which also stops mail flow. How is that different? The requirement for a local caching resolver is not a real impediment. it is overkill With a caching local resolver, all the DNSSEC validation code is where it should be, in a DNSSEC application. which are the two dedicated nameservers in the LAN http://www.avolio.com/columns/e-mailServerSecurity.html Turn off all services except for those required and limit these having two *dedicated* nameservers doing nothing else than DNS and SSH for administartion in the LAN has to be enough If the LAN housing the MTAs and multiple caching nameservers is physically secure and well firewalled, you could potentially rely on that physical security and firewall anti-spoofing rules. that is the point: if i do not trust my dedicated nameservers in my own network i can also not trust the one running on the MTA and asking the both as forwarders so the only relevant question: is 127.0.0.1 (or ::1) a hard requirement or something recommended All of the above are much more complex than a local validating stub resolver no - the two dns servers are already in the LAN and working they are trusted and if i do not trust my own LAN i also can not trust a forwarder running on 127.0.0.1 asking them
Re: TLS client logging PATCH
Am 26.02.2014 12:48, schrieb Wietse Venema: lst_ho...@kwsoft.de: Yes, of course. In practice, for most users, the local resolver is by far the simplest configuration. Is or will this be enforced by Postfix in some way for DANE? Postfix does not parse /etc/resolv.conf so can we then stop to pretend having 127.0.0.1 and/or ::1 as the only nameservers listed in /etc/resolv.conf and speak about that it is recommended in doubt but not need if someone is knowing what he is doing in his own trusted network?
Re: TLS client logging PATCH
Am 26.02.2014 12:57, schrieb Wietse Venema: li...@rhsoft.net: Am 26.02.2014 12:48, schrieb Wietse Venema: lst_ho...@kwsoft.de: Yes, of course. In practice, for most users, the local resolver is by far the simplest configuration. Is or will this be enforced by Postfix in some way for DANE? Postfix does not parse /etc/resolv.conf so can we then stop to pretend having 127.0.0.1 and/or ::1 as the only nameservers listed in /etc/resolv.conf and speak about that it is recommended in doubt but not need if someone is knowing what he is doing in his own trusted network? Postfix examples should present simple configurations. Those simple configurations can then serve as a starting point for more complex ones. A localhost resolver is a simple configuration. A configuration with dozens of hosts running Postfix is not simple nobody said anything else but as the only nameservers listed in /etc/resolv.conf implies that the environments with complex setups and working DNS across the network need to review their complete name resolution instead implement DANE in the already present nameservers the problem is the word only and this was statet more than once in the last few months on that list which spreads fear and in doubt results in no interest to look at DANE if i have to change and my review complete network - i would even go so far and say that the only 127.0.0.1 in /etc/resolv.conf comes near to FUD
Re: TLS client logging PATCH
Am 26.02.2014 17:30, schrieb Viktor Dukhovni: no - the two dns servers are already in the LAN and working they are trusted and if i do not trust my own LAN i also can not trust a forwarder running on 127.0.0.1 asking them Without an anti-spoofing firewall, remote name servers may be able to forge DNS replies that appear to come from your LAN. It is not always obvious whether such protection is in place and is robust in my case the LAN nameservers are not reachable from the WAN at all and they are doing recursion / caching without any foreign forwarder the firewall in front of the mailserver does not allow addresses with a LAN IP coming in trough the WAN interface that's why I wanted to make clear if the limitation is a strong technical one or only highly recommended
Re: is transport_maps order dependent?
Am 26.02.2014 23:59, schrieb Quanah Gibson-Mount: Fiddling with how Zimbra sets some variables that get pushed to postfix, and trying to determine if transport_maps is order dependent. I.e., are these equivalent: transport_maps = lmdb:/opt/zimbra/conf/postfix/postfix_discard_domains, proxy:ldap:/opt/zimbra/conf/ldap-transport.cf transport_maps = proxy:ldap:/opt/zimbra/conf/ldap-transport.cf, lmdb:/opt/zimbra/conf/postfix/postfix_discard_domains Right now, the postfix_discard_domains database drops emails for us, like: .eng.zimbra.com discard:mail for *.eng.zimbra.com is not deliverable My guess is that the lmdb db should be listed first, but wanted to confirm AFAIK anything in postfix is order dependent, not only the values of a option also the records itself and you should always use the most specific and fastest on the left side or on top
Re: Bounce mails manually
Am 25.02.2014 10:09, schrieb Birta Levente: On 25/02/2014 11:02, Andreas Schulze wrote: Birta Levente: Yes, but you sould give some reason why is bounced ... which IMHO is something permanent ... good point! # postbounce queue-id reason so you just set up one time some map and no more care about that problem. just this is unwanted and the reason for the request. Thats unimaginable for me: only one sender and only one time make that mistake if i write for every random mistake a user out of 500 makes a entry in a map postfix would epxlode - the idea behind bounce with reason is to * get rid of that message * explain the user what he did wrong
Re: TLS client logging PATCH
Am 25.02.2014 17:41, schrieb Dirk Stöcker: On Tue, 25 Feb 2014, Viktor Dukhovni wrote: smtp_dns_support_level = dnssec was enough to fix this. I'll see how many servers will have a Verified connection in the future. I hope you read the note about the importance of having 127.0.0.1 and/or ::1 as the only nameservers listed in /etc/resolv.conf, and No, did not read it, but this was obvious :-) why and how should this work for real networks where you have two DNS servers for failover in the LAN and typically no one on the mailserver? if 192.168.196.1 and 192.168.196.2 support DNSSEC it has to work if both of them in resolv.conf, otherwise DANE will not happen in the real world
Re: TLS client logging PATCH
Am 26.02.2014 00:46, schrieb DTNX Postmaster: On 26 Feb 2014, at 00:29, li...@rhsoft.net wrote: Am 25.02.2014 17:41, schrieb Dirk Stöcker: On Tue, 25 Feb 2014, Viktor Dukhovni wrote: smtp_dns_support_level = dnssec was enough to fix this. I'll see how many servers will have a Verified connection in the future. I hope you read the note about the importance of having 127.0.0.1 and/or ::1 as the only nameservers listed in /etc/resolv.conf, and No, did not read it, but this was obvious :-) why and how should this work for real networks where you have two DNS servers for failover in the LAN and typically no one on the mailserver? if 192.168.196.1 and 192.168.196.2 support DNSSEC it has to work if both of them in resolv.conf, otherwise DANE will not happen in the real world The local resolver can have the resolvers on the LAN configured as forwarders, but you need the local stub resolver. No reason not to have one, really, especially on a busy mail server yes, you normally have a local resolver on the mailserver but you hardly trust that one alone and in case it crashs you typically have another one on the LAN mailserver's /etc/resolv.conf: 127.0.0.1 192.168.196.1 192.168.192.2
Re: notify by email mail queue
Am 23.02.2014 19:22, schrieb Pol Hallen:
Hi all :-) I'm searching for how notify by email the mail queue... (if
there're emails inside queue). Any idea?
will not help much if it's too late and you reveive
no mails at all but in most caes enough to realize
that there is a problem growing
/etc/crontab:
*/20 * * * * root bash /usr/local/bin/watch-queue.sh
[root@mail:~]$ cat /usr/local/bin/watch-queue.sh
#!/usr/bin/bash
mailq_count=`/usr/bin/mailq | /usr/bin/tail -n1 | /usr/bin/gawk '{print $5}'`
mailq_count=`expr $mailq_count + 0`
if [ $mailq_count -gt 50 ]; then
echo Mail-Queue $HOSTNAME: $mailq_count
fi
Re: TLS client logging PATCH
Am 23.02.2014 23:57, schrieb Dirk Stöcker: Seems Postfix still need to learn a lot about secure connections seems you need to do so in case of opportunistic there is not real trust trusted in case of a secure connection means both sides know each other - opportunistic means the other side neeeds only whatever certificate by a trusted CA and is counted as trusted you can discuss about logging details but hardly about secure connections
Re: TLS client logging PATCH
Am 24.02.2014 01:16, schrieb Dirk Stöcker: On Sun, 23 Feb 2014, Viktor Dukhovni wrote: smtp_tls_verify_certs=whenpossible SMTP is not HTTP. Due to MX indirection, peer authentication is not possible without explicit per-destination configuration. Once you've gone to all that trouble, you may as well configure a secure channel. I know that there are many side-effects and things which don't work, but that does not mean that one can at least try? For a lot of domains there is a MX entry and only that server is responsible. So when a SMTP connection is made, can't at least the logfile say that cert and MX match? which of the MX servers of a domain if there are more than one? please understand as long as you don't *directl* verify a certificate on both sides there is no trust and opportunistic means excatly that who defines trusted? if you can't answer that question you can't log that with any gain
Re: next time write a subject
Am 21.02.2014 11:37, schrieb BONNET, Frank: Since I activated SMTP TLS ( client and server = may ) on our mail gateway I have this message in maillog Untrusted TLS connection established to ASPMX.L.GOOGLE.COM http://ASPMX.L.GOOGLE.COM[173.194.66.27]:25: TLSv1 with cipher RC4-SHA (128/128 bits) any info ? that this confirms exactly what you have configured? a enrcypted connection while deliver mail
Re:
Am 21.02.2014 11:58, schrieb Robert Schetterer: Am 21.02.2014 11:37, schrieb BONNET, Frank: Hello Since I activated SMTP TLS ( client and server = may ) on our mail gateway I have this message in maillog Untrusted TLS connection established to ASPMX.L.GOOGLE.COM http://ASPMX.L.GOOGLE.COM[173.194.66.27]:25: TLSv1 with cipher RC4-SHA (128/128 bits) any info ? thank you what exact is your problem with this? most likely laziness combined with lack of understanding what a trusted TLS connection is and why opportunistic TLS without certificate validating per definition is untrusted https://www.google.com/search?q=postfix+Untrusted+TLS+connection with that you get Trusted connection in case the other side has a certificate from a trusted CA but you gain nothing because it is still *opportunistic TLS* which means if somebody hijacks your TLS and a foreign server pretends to be Goggle with a self signed certificate you still deliver the message smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
Re: domain not found
Am 20.02.2014 14:46, schrieb Luigi Rosa: Feb 20 12:27:28 services postfix/smtpd[3054]: connect from unknown[205.201.129.15] Feb 20 12:27:29 services postfix/smtpd[3054]: NOQUEUE: reject: RCPT from unknown[205.201.129.15]: 450 4.1.8 bounce-mc.us6_14029727.478081-vendite=xx...@mail15.wdc01.mcdlv.net: Sender address rejected: Domain not found; from=bounce-mc.us6_14029727.478081-vendite=xx...@mail15.wdc01.mcdlv.net to=vend...@xx.it proto=ESMTP helo=mail15.wdc01.mcdlv.net ON THE SAME SERVER if I type $ host mail15.wdc01.mcdlv.net I get mail15.wdc01.mcdlv.net has address 205.201.129.15 mail15.wdc01.mcdlv.net mail is handled by 10 mail.mail15.wdc01.mcdlv.net. So why Postfix says Domain not found? * maybe your smtpd is runnign chroot (Debian?) * maybe there was a temporary error in name resloving in case 1: fix that in case 2: where is your problem? 450 is a *temporary reject* as the docs say The response is always 450 in case of a temporary DNS error reject_unknown_sender_domain Reject the request when Postfix is not final destination for the sender address, and the MAIL FROM domain has 1) no DNS MX and no DNS address record, or 2) a malformed MX record such as a record with a zero-length MX hostname (Postfix version 2.3 and later). The unknown_address_reject_code parameter specifies the numerical response code for rejected requests (default: 450). The response is always 450 in case of a temporary DNS error.
Re: sender_canonical_maps and no delivered mails
Am 19.02.2014 16:56, schrieb pgala: In dovecot i use plugin quota exceeded to inform sender about no delivered mail if somebody send internal mail. My problem is that dovecot send information about no delivered messages to envelope_sender instead header from. I try force dovecot to use header from but i cant. I also write on dovecot mailing list by i didn't get answers still. you should *not send any* mail about not delivered messages in a sane setup you REJECT the mail with a message clearly stating the account is over quota and *the sending server* is resposible to generate a bounce to *his user* for the delivering server it looks like below and that message is part of the from it generated bounce - again you must not generate the bounce and send it actively relay=*[]:25, delay=104, delays=46/54/3.5/0.32, dsn=5.0.0, status=bounced (host *[*] said: 550 Mailbox quota exceeded (in reply to RCPT TO command))
Re: Slow sending of email
correct, the empty-zone data below is because in need these
disable-empty-zone lines and have several in both which
are maintained on the forwarder on the other end(s) of
vpn-routings, maybe it's even posible to list them
explicit in disable-empty-zone, not tried yet
normally empty-zones-enable is enabled on recent namservers
empty-zones-enable yes;
disable-empty-zone 10.in-addr.arpa;
disable-empty-zone 168.192.in-addr.arpa
Am 17.02.2014 06:58, schrieb Noel Butler:
or, in bind options : empty-zones-enable yes;
any server running bind not understanding this should result is two things
1: the responsible admins resignation
2: ensuring his/her replacement upgrades to something modern
On 16/02/2014 07:43, li...@rhsoft.net wrote:
Am 15.02.2014 22:37, schrieb SW:
Yes, you are correct. That is the cause of the problem. A quick entry of my
machine in the hosts file sorted
that one out! I'm just baffled why I have never experienced this issue
before
___
zone 1.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 2.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 3.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
Re: Slow sending of email
Am 15.02.2014 22:30, schrieb SW: I can't see the -D option anywhere in my master.cf file. I think this issue was occurring before trying that anyway. I have also restarted the Postfix service. host 192.168.0.10 ;; connection timed out; no servers could be reached that is the problem I expected this to timeout as I don't have internal DNS name resolution for my desktops (never have). Could Postfix be trying to resolve the name of my desktop before sending the email? since you see resloved hostnames everywhere in the logs: clearly yes it's a damned bad idea at all to not have PTR records on a sane ssh daemon you even can't connect at all many or most network services these days do reverse lookups for connections so fix your DNS or live with the results
Re: Slow sending of email
Am 15.02.2014 22:37, schrieb SW:
Yes, you are correct. That is the cause of the problem. A quick entry of my
machine in the hosts file sorted that one out!
I'm just baffled why I have never experienced this issue before
because you did not care about network details
if your used nameserver would be sane you would not
get timeouts instead of a clear NXDOMAIN
[root@srv-rhsoft:~]$ host 192.168.0.10
Host 10.0.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
your timeout looks like your DNS is trying to reslove the
PTR for a private address with your forwarder or asking
the root servers instead response NXDOMAIN
a sane nameserver has these adresses registered
_
[root@srv-rhsoft:~]$ cat /var/named/chroot/var/named/named.empty
$TTL 86400
@ IN SOA localhost. root.localhost. (
2 ; Serial
3600 ; Refresh
3600 ; Retry
3628800; Expire
3600 ; negativer TTL-Cache
);
IN NS localhost.
_
zone 1.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 2.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 3.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 4.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 5.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 6.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 7.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 8.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 9.10.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 16.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 17.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 18.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 19.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 20.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 21.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 22.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 23.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 24.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 25.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 26.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 27.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 28.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 29.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 30.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 31.172.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 0.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 127.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 254.169.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 2.0.192.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 100.51.198.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 113.0.203.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 255.255.255.255.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 3.168.192.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 4.168.192.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 5.168.192.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 6.168.192.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 7.168.192.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 8.168.192.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 9.168.192.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
zone 10.168.192.IN-ADDR.ARPA {
typemaster;
filenamed.empty;
};
Re: Slow sending of email
Am 15.02.2014 22:40, schrieb SW: Also, why is it when I send an email from my mobile phone its instant? In the maillog it says unknown for my phones IP address so clearly there isn't a DNS name for it. Just trying to understand this. because some nameserver registered for the PTR of your IP works sane and gives a result you need to read logs complete there are different cases of unknown and it is not the same having only a PTR as most ISP's are doing for their ranges or not have a macthing A/PTR have nothing of that and forward private addresses leads to what you have seen in your setup
Re: Entries in sender_bcc_maps and the return-path header
Am 13.02.2014 10:46, schrieb template.mob...@gmx.de: How does the sender_bcc_maps mechanism exactly works? Does it react on mail body header fields like return-path? Is it in detailed documented somewhere? Can we prevent sender_bcc_maps from reacting on the return-path field? which field should it take? From: is *not* the envelope sender https://tools.ietf.org/html/rfc4021 http://www.pobox.com/helpspot/index.php?pg=kb.pageid=260 __ What is an envelope sender? An email has two addresses associated with sending it: the envelope sender, and the From: address. The envelope sender is where computers should respond (in the case of bounce messages or errors); the From: address is where people should respond. In most cases, the envelope sender and the From: address match. But they don't always, and they don't have to. In terms of how it is sent, email is like a package. On the box (that is, during the SMTP transaction), I specify where I want the package sent, and where it should be returned if it could not be delivered. If this were personal mail, these things would nearly always match -- if you got a package addressed to you, with your Aunt Martha's return address, the card inside the box is almost certainly going to addressed to you, from Aunt Martha. In personal email, the envelope sender (the return address) nearly always matches the From: header. Things are a little different from a corporation. If you got a box from Amazon, it might be something you ordered. Amazon might have one return address that they use for packages that are undelivered (the return address on the outside of the box), but inside the box, they might ask you to make returns to a different address. Or, it might be a gift that someone bought for you from Amazon. Amazon shipped it, but the package is really from Aunt Martha. With email, There are similar legitimate reasons why a envelope sender might not match the From: header, like a mailing list or a company that does automated bounce processing. Unfortunately, this is a feature of email that spammers and scammers can and do abuse. When you get a message picked up as spam that's from PayPal, or your bank, or another trusted institution, they've generally changed the From: address to be at a domain you recognize, while leaving the envelope sender as something they control.
Re: smtpd_client_restrictions
Am 13.02.2014 18:03, schrieb Roman Gelfand:
I am using this parameter to send message to be filtered by dspam.
However, I want local email to bypass dspam and go directly to mail
box server over lmtp.
I am not sure why the pcre code below doesn't work for local email.
/^192\.168\.0.\d{1,3}$/ lmtp:[192.168.0.246]:24
/./ FILTER dspam:dspam
why playing around with such hacks instead permit_mynetworks before the filter
Re: Linux servers without local delivery
Am 12.02.2014 14:46, schrieb Daniel Pocock: On 12/02/14 14:12, Wietse Venema wrote: Daniel Pocock: I'm trying to work out what is a sensible configuration for servers without local delivery. http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client I'm familiar with that, it is almost what I want They key difference is that I want to be more restrictive about usernames that are accepted I was referring to the recipient addresses, not sender addresses what is *more* restrictive in that context? you have to have a full list of valid addresses and reject *anything else* and there is nothing between example: local_recipient_maps = proxy:mysql:/etc/postfix/mysql-recipients.cf [root@rh:~]$ cat /etc/postfix/mysql-recipients.cf user = dbmail_readonly password = *** dbname = dbmail hosts= unix:/var/lib/mysql/mysql.sock query= select email from dbma_recipients where email='%s';
Re: How to block bogus localhost.localdomain/127.0.0.1 (helo_access)
Am 12.02.2014 14:53, schrieb L. D. James: On 02/12/2014 08:02 AM, Wietse Venema wrote: L. D. James: I have this in the log: - Feb 11 21:42:41 hera5 postfix/smtpd[4802]: connect from localhost.localdomain[127.0.0.1] Feb 11 21:42:41 hera5 postfix/smtpd[4802]: 05AAE155460: client=localhost.localdomain[127.0.0.1] This is a connection from your content filter. You need to look at the logging for connections from remote systems. Hi, Wietse. Actually that isn't a connection from my content filter. That is a log of how the remote system answered my helo request. The information (as per the topic header) is a lie It's bogus information. The remote system is lying to the request saying they are me if this is *your* logfile, hera5 is your machine then [127.0.0.1] can't be a lie, can't come from a remote systemd and this connection is coming *for sure* from whatever service on *your machine* smtpd is *not* talking to a remote system and not saying helo to a remote system
Re: How to block bogus localhost.localdomain/127.0.0.1 (helo_access)
Am 12.02.2014 15:26, schrieb L. D. James: On 02/12/2014 09:01 AM, li...@rhsoft.net wrote: Am 12.02.2014 14:53, schrieb L. D. James: On 02/12/2014 08:02 AM, Wietse Venema wrote: L. D. James: I have this in the log: - Feb 11 21:42:41 hera5 postfix/smtpd[4802]: connect from localhost.localdomain[127.0.0.1] Feb 11 21:42:41 hera5 postfix/smtpd[4802]: 05AAE155460: client=localhost.localdomain[127.0.0.1] This is a connection from your content filter. You need to look at the logging for connections from remote systems. Hi, Wietse. Actually that isn't a connection from my content filter. That is a log of how the remote system answered my helo request. The information (as per the topic header) is a lie It's bogus information. The remote system is lying to the request saying they are me if this is *your* logfile, hera5 is your machine then [127.0.0.1] can't be a lie, can't come from a remote systemd and this connection is coming *for sure* from whatever service on *your machine* smtpd is *not* talking to a remote system and not saying helo to a remote system Hi. hera5 in my machine. It is the host. My host machine, hera5 is reporting the information to the log. You quoted the part where hera5 (the host machine) reported what the click said when hera5 gave a helo request. The client lied. The client said they were localhost.localdomain *damned* read the other answers and stop to claim technical nonsense about a lying client in case of [127.0.0.1] which is a IP-ADDRESS, yours, your loopback device, a service running *on your machine* FOR SURE your problem is long before *that service on localhost* accepts the message from where you are showing logs, you must not accept the message at the MX The client machine is lying to hera5 because the spammers knows that, by default a machine will accept relaying messages from itself *not by default it does NOT* only the ones configured careless, dangerous and wrong and the documentation states clearly you *must not* accept a message by check_helo_access and have to have *other sane* restrictions which reject *before* check_helo_access has the chance to say permit in that case (a sane configuration) check_helo_access is the last instance who could say *reject* but never override other restrictions and accept the message ___ http://www.postfix.org/SMTPD_ACCESS_README.html The problem with this configuration is that smtpd_recipient_restrictions evaluates to PERMIT for EVERY host that announces itself as localhost.localdomain, making Postfix an open relay for all such hosts. With Postfix before version 2.10 you should place non-recipient restrictions AFTER the reject_unauth_destination restriction, not before. In the above example, the HELO based restrictions should be placed AFTER reject_unauth_destination, or better, the HELO based restrictions should be placed under smtpd_helo_restrictions where they can do no harm.
Re: How to block bogus localhost.localdomain/127.0.0.1 (helo_access)
Am 12.02.2014 16:33, schrieb L. D. James: On 02/12/2014 10:14 AM, Viktor Dukhovni wrote: On Wed, Feb 12, 2014 at 10:06:48AM -0500, L. D. James wrote: Thanks again for the input. When I post how I resolved the issue, The only issue is that you have not understood how to read your logs which log every message twice (because you're using a post-queue content filter). With content filters, each message is received, stored in the queue, and then sent via the content filter to be received and queued again (this time with a local client address) the second time it is finally delivered to its intended destination. To understand how a message entered your system you need to look at TWO queue-ids, the pre-filter queue-id and the post-filter queue-id. Thanks, Viktor. There is a lot I don't understand. I appreciate your taking the time to explain the various components. Blocking the localhost.localdomain using helo_access the best way that I could decipher has stopped the spam may i ask why you that hypersensible to localhost.localdomain while your own machine resolves that for 127.0.0.1? client=localhost.localdomain[127.0.0.1] from your log proves that HELO restrictions is not really that good solution for a sane spam-filter and if you are not damned careful to not apply them on submission you will do harm to most MUA's hence check_helo_access does not belong to main.cf apply it to port 25 in master.cf or you need to disable it explicit for submission (587) [harry@srv-rhsoft:~]$ host 127.0.0.1 1.0.0.127.in-addr.arpa domain name pointer localhost. [harry@srv-rhsoft:~]$ cat /etc/hosts | grep 127.0.0.1 127.0.0.1 localhost [harry@srv-rhsoft:~]$ nslookup 127.0.0.1 Server: 127.0.0.1 Address:127.0.0.1#53 1.0.0.127.in-addr.arpa name = localhost.
Re: SERVFAIL Errors
Am 12.02.2014 21:04, schrieb Dave Johnson: Any ideas on how I can sort sort below? how do you imagine that? you refused to post postconf -n please re-read the welcome message Feb 12 10:24:48 mail postfix/smtpd[17207]: NOQUEUE: reject: RCPT from unknown[196.14.170.132]: 450 4.7.1 SALES@ mailto:sa...@ofsg.co.za: Recipient address rejected: SPF-Result=medscheme.co.za: 'SERVFAIL' error on DNS 'MX' lookup of 'cluster1a.sa.messagelabs.com'; from=fedhea...@medscheme.co.za mailto:fedhea...@medscheme.co.za to=SALES@xx mailto:sa...@ofsg.co.za proto=ESMTP helo=mail1.bemta18.messagelabs.com It does not appear that cluster1a.sa.messagelabs.com does not have an IP when I do a dig it has, it does appear your DNS has or had a problem why panic in case of a *temporary* error? 4xx = temporary error 5xx = permanent error ;; ANSWER SECTION: cluster1a.sa.messagelabs.com. 4 IN A 196.14.170.83
Re: Exchange 2007 gives 535 5.7.3 Authentication unsuccessful
Am 11.02.2014 13:13, schrieb fleon: i disabled NTLM with sasl_mechanism_filter = !ntlm but of course now i get an error that the server offered no compatible authentication mechanism When i telnet to my exchange server i only get: STARTTLS X-ANONYMOUS TLS AUTH NTLM X-EXPS GSSAPI NTLM Like i said, if i cannot get this to work, i will rely on the virtual smtp server that is located on my webserver, which is what we already use for our website * we relay to a customer with Microsoft ESMTP MAIL Service because we don't host their email but webservices sending messages with their sender domain as envelope * the exchange machine pretends the same as yours * but SASL auth works for sure 250-SIZE 10485760 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-STARTTLS 250-AUTH NTLM 250-8BITMIME 250-BINARYMIME 250 CHUNKING on our postfix relay these packages are installed * no ntlm * no gssapi cyrus-sasl-2.1.26-10.fc19.x86_64 cyrus-sasl-md5-2.1.26-10.fc19.x86_64 cyrus-sasl-lib-2.1.26-10.fc19.x86_64 cyrus-sasl-plain-2.1.26-10.fc19.x86_64
Re: Exchange 2007 gives 535 5.7.3 Authentication unsuccessful
Am 11.02.2014 13:31, schrieb fleon: Hello, can you please put your relevant main.cf, /etc/postfix/generic, etc/postfix/sasl/sasl_passwd (or the file you set up in main.cf), /etc/aliases and maybe a syslog entry after doing a test with /usr/sbin/sendmail? all database configuration Please mangle your username, domain and password hashes. Your server seems quite similar to mine, but if you don't have NTLM installed, i think you may be using TLS to connect, and probably would need the syslog entry to confirm. for sure it uses TLS because we use *everywhere* encryption if it is possible maybe that is the reason why it just works and falls back to PLAIN which you don't see in the outgoing postfix log Trusted TLS connection established to exchange.xx.xx[xx.xx.xx.xx]:25: TLSv1 with cipher AES128-SHA (128/128 bits) you posted your server says STARTTLS well, then configure it on the postfix client smtp_use_tls = yes smtp_tls_loglevel = 1 smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt smtp_tls_security_level = may smtp_tls_note_starttls_offer = yes smtp_tls_session_cache_timeout = 3600s smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache smtp_tls_exclude_ciphers = DES-CBC3-SHA, DES-CBC3-MD5, ADH-DES-CBC3-SHA, ADH-DES-CBC3-MD5, EDH-RSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-MD5, DES, DES+MD5 My exchange server is exchangeserver.ourdomain.com and it's the 2007 version. Our windows long domain name is ourdomain.com Our windows short domain name is SEGCAT I tried using EXCHANGESERVER\myuser, myu...@ourdomain.com and SEGCAT\myuser in the sasl hash file and didn't work there is no valid reason to guess usernames just use the same credentials as you enter in a ordinary MUA
Re: Exchange 2007 gives 535 5.7.3 Authentication unsuccessful
Am 11.02.2014 20:01, schrieb Viktor Dukhovni:
On Tue, Feb 11, 2014 at 10:36:54AM -0800, fleon wrote:
I have this in my main.cf (note: i didn't set this up, my guess is that
debian itself did, or maybe when i installed libsasl2-modules, but i don't
think so)
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
Server-side TLS enabled. Use smtpd_tls_security_level = may
instead of the obsolete smtpd_use_tls = yes.
to say it clear: anything with smtpd_ as prefix has
nothing to do with send a message to another server
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
Client-side TLS is not enabled. Enable client-side TLS:
smtp_tls_security_level = may
What am i missing to enable TLS properly and then be able to use AUTH LOGIN?
See above
and that is why i hours ago posted the *client* configuration
of the machine happily sends authenticated mail over TLS to
exchange
smtp_use_tls = yes
smtp_tls_loglevel = 1
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_timeout = 3600s
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_exclude_ciphers = DES-CBC3-SHA, DES-CBC3-MD5, ADH-DES-CBC3-SHA,
ADH-DES-CBC3-MD5, EDH-RSA-DES-CBC3-SHA,
EDH-RSA-DES-CBC3-MD5, DES, DES+MD5
Re: Exchange 2007 gives 535 5.7.3 Authentication unsuccessful
Am 11.02.2014 21:15, schrieb fleon: FINALLY it worked, but not before i disabled NTLM in the config, because otherwise it would try it. as said in my first reply uninstall the NTLM module as long you have no damned good reason to install it in case of the distributions i work with it is a own sub-apckage with no frther dependencies and so you don't have to bother about configurations i never faced any positive effect in install and configure the NTLM crap except troubles over troubles, be it mail delivery or stupid Apple clients perfer it in their config while from time to time fail to handle NTLM correct So, i had to enable client side TLS and disabling NTLM. It says untrusted connection in the logs, and i tried modifying the mynetworks variable below but couldn't fix it. It may be untrusted because of the invalid exchange certificate it says untrusted because the certificate on the remote side is not from a trusted CA or postfix doe snot know the CA and that is why i have smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt connections to Google as example are trusted with and Untrusted without http://www.postfix.org/postconf.5.html#smtp_tls_CAfile Am 11.02.2014 20:17, schrieb Viktor Dukhovni: smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt Leaving it blank is better. The browser CA bundle has no relevance to SMTP it has no relevance in case of oppotunistic TLS but it makes a difference
Re: warning: hostname localhost does not resolve to address ::1: No address associated with hostname
Am 10.02.2014 16:33, schrieb Jelle de Jong: I have a dual stack IPv6/IPv4 postfix server that been running on debian stable quite happy. postfix/smtpd[15247]: warning: hostname localhost does not resolve to address ::1: No address associated with hostname 1. should I be worried? 2. why is the warning popping up now? I listed some some output of my own investigation of the below commands in my pastbin here: http://paste.debian.net/81152 # postconf | grep mynetworks # cat /etc/hosts # cat /etc/nsswitch.conf # ping6 localhost # cat /etc/host.conf # cat /proc/cmdline # getent hosts localhost # getent hosts ::1 I got the feeling it may have something to do with changes in libc? and multi on dns resolutions but I am not sure none of your commands above makes a dns request postfix does getent - get entries from Name Service Switch libraries and so it takes the value from /etc/hosts, postfix not in other words: fix your DNS servers PTR
Re: Exchange 2007 gives 535 5.7.3 Authentication unsuccessful
Am 10.02.2014 19:39, schrieb fleon: I added the debug command you requested so you can see the whole error. I don't seem to have dns issues so i haven't felt the need for the brackets. I do seem to have the NTLM module uninstall the NTLM module on my Fedora machines i had the same until yum remove cyrus-sasl-ntlm after uninstall it falls back to MD5 auth over TLS in case TLS is available on both sides
Re: how force sasl from localhost
Am 09.02.2014 12:32, schrieb Pol Hallen: External sasl authentication works, I need force users to authentication from localhost (i.e. CMS joomla and wordpress). inside main.cf: before: mynetworks = 127.0.0.0/8, 192.168.1.0/24 after #mynetworks = 127.0.0.0/8, 192.168.1.0/24 re-read the manual: mynetworks (default: see postconf -d output) removing the line means fall back to defaults postconf -d | grep mynetworks mynetworks = 127.0.0.0/8 62.178.103.0/24 192.168.2.0/24 192.168.10.0/24 192.168.196.0/24 10.0.0.0/24 however, configure your applications to use port 587 and close 25 on 127.0.0.1 may be the easier way to achieve the goal which is no problem with iptables ___ if you need more help provide the logs of a relevant message until now there is no evidence that whatever message was even sent with SMTP and not pickup (sendmail-command) where smtp-restrictions are completly irrelevant if it is pickup than disable mail and a lot of other dangerous PHP functions they will always make it possible to bypass *any* restrictions - below a sane PHP configuration from a production server disable_functions = apache_child_terminate, chown, dl, exec, fileinode, get_current_user, getmypid, getmyuid, getrusage, highlight_file, link, mail, openlog, passthru, pclose, pcntl_alarm, pcntl_errno, pcntl_exec, pcntl_fork, pcntl_get_last_error, pcntl_getpriority, pcntl_setpriority, pcntl_signal_dispatch, pcntl_signal, pcntl_sigprocmask, pcntl_sigtimedwait, pcntl_sigwaitinfo, pcntl_strerror, pcntl_wait, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, pfsockopen, popen, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, show_source, socket_accept, socket_bind, symlink, syslog, system
Re: how to configure Postfix/DNS to avoid being considered a spammer
Am 07.02.2014 16:26, schrieb LuKreme: On 07 Feb 2014, at 01:12 , Stefan Michael Guenther s.guent...@in-put.de wrote: The problem is, that our client wants to send emails with the sender domains of his clients from his own postfix server. There is no legitimate reason to do this. In fact, my servers (and I suspect many servers) block all email from outside that claims to be from our domains *there is a GOOD reason* software running on that server directly talking SMTP and not handling connection problems proper which it does not need to, in all that cases you have a local postfix and your application talks to 127.0.0.1 *but* that does not mean you have to deliver the messages directly to the final destination, better said: you should never do so if you are not the responsible server of the sender domain that's why the features below exists to queue messages local and send them out with the smtp server responsible for the sending domain and having proper SPF records that's what i expect from our customers and on the other how i handle any sender which my server is not destination for smtp_sasl_auth_enable = yes smtp_sender_dependent_authentication = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd sender_dependent_relayhost_maps = hash:/etc/postfix/sasl_relay_maps
Re: how to configure Postfix/DNS to avoid being considered a spammer
Am 07.02.2014 22:51, schrieb LuKreme: On 07 Feb 2014, at 09:16 , li...@rhsoft.net wrote: Am 07.02.2014 16:26, schrieb LuKreme: On 07 Feb 2014, at 01:12 , Stefan Michael Guenther s.guent...@in-put.de wrote: The problem is, that our client wants to send emails with the sender domains of his clients from his own postfix server. There is no legitimate reason to do this. In fact, my servers (and I suspect many servers) block all email from outside that claims to be from our domains *there is a GOOD reason* I understood the original post to be asking to send mail to users with the source domain set to the same domain as the users being sent to Is that not what was meant? it is and if you read what i wrote instead of strip it out you see the solution there: sender-dependent-realyhost and authentication because sasl-auth is the key to not block them - in other words: let the postfix server on the otehr end act like any MUA on port 587
Re: Recipient address rejected during table change
Am 06.02.2014 14:41, schrieb Konstantin: I have postfix-2.10.2 with milter and amavis as smtpd_proxy_filter installed. All information stored in database and at 1st min of each hour domains and recipients copied to local files. Then postmap command performed. don't run postmap just for fun learn your script to make a tmp file and verify if there are changes * sha1sum current config * generate new tmp config * sha1sum new tmp config * atomic mv if changes happened * postmap only if changes and mv happened At the same time between 16:01:37 - 16:09:25 a lot of mail accepted by postfix (the same domain also). My question why is this happen? What is the safe way to update recipients tables and another hash files? if you have your information as you said in a database why in the world are you generating static configurations instead use that database directy which leads to no additional magic needed and changes get active in real time http://www.postfix.org/DATABASE_README.html
Re: Restricting access to local delivery
Am 06.02.2014 22:17, schrieb Norton Allen: I think a key point here (for me anyway) is that smtpd_recipient_restrictions do not apply to mail delivered from localhost because they presumably don't use SMTP. Is that a correct understanding? yes because smtpd_ means what it says http://www.postfix.org/pickup.8.html is your friend that has nothing to to with localhost localhost can also be smtp and in that case mynetworks most likely oveerride retsrictions otherwise system-mails like from crond would not work in many environments
