message may be sent more than once
Sep 11 09:21:22 mail2 postfix/cleanup[23372]: 3cZZKZ2WvdzBt9C: message-id=f0cdc3dbf712aa448525e5dddc62b6f4039fe69d4...@exchange31.charite.de Sep 11 09:21:22 mail2 postfix/qmgr[10759]: 3cZZKZ2WvdzBt9C: from=sen...@charite.de, size=36991, nrcpt=1 (queue active) Sep 11 09:31:23 mail2 postfix/smtp[22134]: 3cZZKZ2WvdzBt9C: conversation with mail.vivantes.de[62.220.2.98] timed out while sending end of data -- message may be sent more than once Sep 11 09:31:23 mail2 postfix/smtp[22134]: 3cZZKZ2WvdzBt9C: to=recipi...@vivantes.de, relay=mail1.vivantes.de[62.220.2.99]:25, delay=601, delays=0.01/0/601/0.55, dsn=2.0.0, status=sent (250 2.0.0 r8B7VMsm013069 Message accepted for delivery) Sep 11 09:31:23 mail2 postfix/qmgr[10759]: 3cZZKZ2WvdzBt9C: removed It seems the first delivery fails (after 10 minutes), and the subsequent retry succeeds immediately. It strikes me as odd that the mail is being retried in the very second the error message ist being logged. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: message may be sent more than once
On Wed, Sep 11, 2013 at 10:19:19AM +0200, Ralf Hildebrandt wrote: Sep 11 09:21:22 mail2 postfix/cleanup[23372]: 3cZZKZ2WvdzBt9C: message-id=f0cdc3dbf712aa448525e5dddc62b6f4039fe69d4...@exchange31.charite.de Sep 11 09:21:22 mail2 postfix/qmgr[10759]: 3cZZKZ2WvdzBt9C: from=sen...@charite.de, size=36991, nrcpt=1 (queue active) Sep 11 09:31:23 mail2 postfix/smtp[22134]: 3cZZKZ2WvdzBt9C: conversation with mail.vivantes.de[62.220.2.98] timed out while sending end of data -- message may be sent more than once Sep 11 09:31:23 mail2 postfix/smtp[22134]: 3cZZKZ2WvdzBt9C: to=recipi...@vivantes.de, relay=mail1.vivantes.de[62.220.2.99]:25, delay=601, delays=0.01/0/601/0.55, dsn=2.0.0, status=sent (250 2.0.0 r8B7VMsm013069 Message accepted for delivery) Sep 11 09:31:23 mail2 postfix/qmgr[10759]: 3cZZKZ2WvdzBt9C: removed It seems the first delivery fails (after 10 minutes), and the subsequent retry succeeds immediately. It strikes me as odd that the mail is being retried in the very second the error message ist being logged. The message was immediately accepted by the second MX host for vivantes.de after the first MX host timed out. Paul. -- Paul Hoffman p...@flo.org Systems Librarian Fenway Libraries Online c/o Wentworth Institute of Technology 550 Huntington Ave. Boston, MA 02115 (617) 442-2384 (FLO main number)
mail delivery to Inbox , not to spam
How can I be sure that the email send through my server to anybody should delivered to recipients inbox; not to the spam folder. Where all the default settings are used in recipient inbox. Regards,
Re: mail delivery to Inbox , not to spam
On Wed, Sep 11, 2013 at 02:21:54PM +0530, Vishal Agarwal wrote: How can I be sure that the email send through my server to anybody should delivered to recipients inbox; not to the spam folder. Where all the default settings are used in recipient inbox. You can't be sure. Ever. The receiving SMTP server says I accept that message but can then do absolutely anything it wants -- throw the message away, bounce it, forward it to the CIA, etc. Paul. -- Paul Hoffman p...@flo.org Systems Librarian Fenway Libraries Online c/o Wentworth Institute of Technology 550 Huntington Ave. Boston, MA 02115 (617) 442-2384 (FLO main number)
Re: mail delivery to Inbox , not to spam
Am 11.09.2013 10:51, schrieb Vishal Agarwal: How can I be sure that the email send through my server to anybody should delivered to recipients inbox; not to the spam folder. Where all the default settings are used in recipient inbox. you as sender are not the one who decides what at the destination happens with a message and by whatever rules messages are flagged as spam
Re: message may be sent more than once
* Paul Hoffman p...@flo.org: On Wed, Sep 11, 2013 at 10:19:19AM +0200, Ralf Hildebrandt wrote: Sep 11 09:21:22 mail2 postfix/cleanup[23372]: 3cZZKZ2WvdzBt9C: message-id=f0cdc3dbf712aa448525e5dddc62b6f4039fe69d4...@exchange31.charite.de Sep 11 09:21:22 mail2 postfix/qmgr[10759]: 3cZZKZ2WvdzBt9C: from=sen...@charite.de, size=36991, nrcpt=1 (queue active) Sep 11 09:31:23 mail2 postfix/smtp[22134]: 3cZZKZ2WvdzBt9C: conversation with mail.vivantes.de[62.220.2.98] timed out while sending end of data -- message may be sent more than once Sep 11 09:31:23 mail2 postfix/smtp[22134]: 3cZZKZ2WvdzBt9C: to=recipi...@vivantes.de, relay=mail1.vivantes.de[62.220.2.99]:25, delay=601, delays=0.01/0/601/0.55, dsn=2.0.0, status=sent (250 2.0.0 r8B7VMsm013069 Message accepted for delivery) Sep 11 09:31:23 mail2 postfix/qmgr[10759]: 3cZZKZ2WvdzBt9C: removed It seems the first delivery fails (after 10 minutes), and the subsequent retry succeeds immediately. It strikes me as odd that the mail is being retried in the very second the error message ist being logged. The message was immediately accepted by the second MX host for vivantes.de after the first MX host timed out. ARGH. Thanks for the second set of eyes. I just didn't see mail|mail1 (was expecting mail|mail2 or something along those lines). -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: mail delivery to Inbox , not to spam
That's true. I wanted to know; that besides the special rules from any recipient server; is there some way to get the message delivered to the users inbox ? Regards, On Wed, Sep 11, 2013 at 2:26 PM, Paul Hoffman p...@flo.org wrote: On Wed, Sep 11, 2013 at 02:21:54PM +0530, Vishal Agarwal wrote: How can I be sure that the email send through my server to anybody should delivered to recipients inbox; not to the spam folder. Where all the default settings are used in recipient inbox. You can't be sure. Ever. The receiving SMTP server says I accept that message but can then do absolutely anything it wants -- throw the message away, bounce it, forward it to the CIA, etc. Paul. -- Paul Hoffman p...@flo.org Systems Librarian Fenway Libraries Online c/o Wentworth Institute of Technology 550 Huntington Ave. Boston, MA 02115 (617) 442-2384 (FLO main number)
Re: message may be sent more than once
Ralf Hildebrandt: [ Charset UTF-8 unsupported, converting... ] Sep 11 09:21:22 mail2 postfix/cleanup[23372]: 3cZZKZ2WvdzBt9C: message-id=f0cdc3dbf712aa448525e5dddc62b6f4039fe69d4...@exchange31.charite.de Sep 11 09:21:22 mail2 postfix/qmgr[10759]: 3cZZKZ2WvdzBt9C: from=sen...@charite.de, size=36991, nrcpt=1 (queue active) Sep 11 09:31:23 mail2 postfix/smtp[22134]: 3cZZKZ2WvdzBt9C: conversation with mail.vivantes.de[62.220.2.98] timed out while sending end of data -- message may be sent more than once Sep 11 09:31:23 mail2 postfix/smtp[22134]: 3cZZKZ2WvdzBt9C: to=recipi...@vivantes.de, relay=mail1.vivantes.de[62.220.2.99]:25, delay=601, delays=0.01/0/601/0.55, dsn=2.0.0, status=sent (250 2.0.0 r8B7VMsm013069 Message accepted for delivery) Sep 11 09:31:23 mail2 postfix/qmgr[10759]: 3cZZKZ2WvdzBt9C: removed It seems the first delivery fails (after 10 minutes), and the subsequent retry succeeds immediately. It strikes me as odd that the mail is being retried in the very second the error message ist being logged. Delivery fails to the primary MX host (mail.vivantes.de) and then it succeeds to the secondary MX host. Why should Postfix wait when it switches from primary to secondary MX? Wietse
Re: DSN to include original email's subject
Kev: Hi! I have an issue, we have DSN enabled by default on postfix, and it works great, but we have an issue when sending multiple emails, its difficult to see what email got deliver, so is there anyway to include the subject of the original email in the DSN notifications ? Each Postfix DSN contains the entire message header INCLUDING subject, either as message/rfc822 or as text/rfc822-headers. Wietse
Re: mail delivery to Inbox , not to spam
Top-posting fixed. Please don't top-post here. Thank you. On Wed, Sep 11, 2013 at 03:08:16PM +0530, Vishal Agarwal wrote: On Wed, Sep 11, 2013 at 2:26 PM, Paul Hoffman p...@flo.org wrote: On Wed, Sep 11, 2013 at 02:21:54PM +0530, Vishal Agarwal wrote: How can I be sure that the email send through my server to to anybody should delivered to recipients inbox; not to the spam folder. Where all the default settings are used in recipient inbox. There are no such settings. And as such, this really is off-topic here. You could bring it to SDLU http://spammers.dontlike.us, a mailing list for discussion of spam and related issues, and be on topic. (Disclaimer: I am a SDLU moderator.) You can't be sure. Ever. The receiving SMTP server says I accept that message but can then do absolutely anything it wants -- throw the message away, bounce it, forward it to the CIA, etc. That's true. I wanted to know; that besides the special rules from any recipient server; is there some way to get the message delivered to the users inbox ? You can follow best practices and possibly improve your chances. First and foremost: do NOT send ANY spam. Send only to confirmed addresses, diligently prune your list of rejects. No repurposing lists; only send what the recipient signed up to get. http://www.rhyolite.com/anti-spam/that-which-we-dont.html is an amusing look at a long list of spammers' excuses. Are yours on it? Bad sign, if so. It means you're doing something wrong. Second: buy your connectivity from a reputable provider which is not listed on any major spam DNSBLs. Look them up at Spamhaus. Do they have longterm unresolved issues? Third: ensure that your sending host has valid FCrDNS (forward- confirmed reverse DNS): your IP address should resolve to $myhostname, which in turn should resolve to your IP address. Fourth: remove yourself from Spamhaus PBL if applicable. Sign up at DNSWL.org's whitelist service. If any of this does not make sense to you, I strongly suggest that you should not send bulk mail directly. Hire an ESP like Sendgrid, Mailchimp, or Constant Contact. They can quickly clean up your list and get mail into the recipient's inbox. Assuming that there is revenue at stake in your sending, spend a bit of it. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: disable all filtering deliver email direclty
On 9/10/2013 10:54 PM, Jumping Mouse wrote:
I am really needing some help with this I hope someone can look at
my postconf -n and let me know how can get this email delivered
quickly. with no filtering.
Your postfix configuration shown does not appear to have any
filtering enabled. If filtering is still happening, there is no
evidence shown that postfix is calling the filter.
Sorry, I can't help any more here.
-- Noel Jones
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
delay_warning_time = 4h
home_mailbox = Maildir/
ignore_mx_lookup_error = yes
inet_interfaces = all
inet_protocols = ipv4
mailbox_command = /usr/bin/maildrop
mailbox_size_limit = 0
message_size_limit = 26214400
mydestination = $myhostname, $mydomain, localhost.$mydomain,
lists.domain.com
mydomain = domain.com
myhostname = mail.domain.com
mynetworks = 10.0.0.0/24, 10.5.0.0/24, 127.0.0.0/8, 159.250.29.243/32
myorigin = domain.com
recipient_delimiter = +
relay_domains = mailman.domain.com, domain.com, www.domain.com,
localhost.domain.com, 159.250.29.243, svahs.net, kong2.domain.com,
10.5.0.25, 10.0.0.19, 10.0.0.4, 10.5.0.10, 10.0.0.10, hec-pdc,
mindtouch, mindtouch.domain.com, 10.0.0.128, kablink,
dev1.domain.com, dev2.domain.com, 10.0.0.15
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_recipient_restrictions =
permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,check_policy_service
inet:127.0.0.1:6
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain =
smtpd_sasl_path = private/auth-client
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/ssl/sub.class2.server.ca.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/ssl.crt
smtpd_tls_key_file = /etc/ssl/ssl.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_transport = maildrop
From: kafr...@hotmail.com
To: postfix-users@postfix.org
Subject: RE: disable all filtering deliver email direclty
Date: Tue, 10 Sep 2013 23:43:56 -0400
From: kafr...@hotmail.com
To: postfix-users@postfix.org
Subject: RE: disable all filtering deliver email direclty
Date: Tue, 10 Sep 2013 11:05:00 -0400
Date: Mon, 9 Sep 2013 16:05:23 -0500
From: njo...@megan.vbhcs.org
To: postfix-users@postfix.org
Subject: Re: disable all filtering deliver email direclty
On 9/9/2013 3:46 PM, Jumping Mouse wrote:
Hello I have an old email server with a mail stuck in the queue.
I want to flush all email out and let be delivered with out any
filtering.
It looks like I have turned off all filtering but still messages are
delivered very slowly.
Can someone help me with my config files? I can't seem to figure
out were the issue is that is causing for mail to still be
filtered.
Thank you!
Here is my main.cf
postconf -n is strongly preferred, but I see no evidence of a
content filter here.
Perhaps you are calling spamassassin by maildrop during delivery.
-- Noel Jones
Here is my maildroprc it does not seem to be calling Spamassassin
so not sure where the delay is. Do you see anything in the config
file that could be causing this delay?
logfile /var/log/maildrop
VERBOSE=5
log
if (/^X-Spam-Flag: YES/)
{
#Create SPAM IMAP folder if they don't have one
`test -d $DEFAULT/.Junkmail`
if( $RETURNCODE == 1 )
{
`/usr/bin/maildirmake -f Junkmail $DEFAULT`
`echo INBOX.Junkmail $DEFAULT/courierimapsubscribed`
}
exception {
to Maildir/.Junkmail
}
}
Here is my postconf -n
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
delay_warning_time = 4h
home_mailbox = Maildir/
ignore_mx_lookup_error = yes
inet_interfaces = all
inet_protocols = ipv4
mailbox_command = /usr/bin/maildrop
mailbox_size_limit = 0
message_size_limit = 26214400
mydestination = $myhostname, $mydomain, localhost.$mydomain,
lists.domain.com
mydomain = domain.com
myhostname = mail.domain.com
mynetworks = 10.0.0.0/24, 10.5.0.0/24, 127.0.0.0/8, 159.250.29.243/32
myorigin = domain.com
recipient_delimiter = +
relay_domains = mailman.domain.com, domain.com, www.domain.com,
localhost.domain.com, 159.250.29.243, svahs.net, kong2.domain.com,
10.5.0.25,
Re: message may be sent more than once
* Wietse Venema postfix-users@postfix.org: Delivery fails to the primary MX host (mail.vivantes.de) and then it succeeds to the secondary MX host. Why should Postfix wait when it switches from primary to secondary MX? PEBCAK (on my side here). -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Rejecting mail to unknown users
Hello everyone! I need your help setting up postfix. This is my problem/question: I have multiple domains on my mail server running postfix (adn dovecot), with LDAP based user accounts. When someone from outside (that is: not from my domains) sends mail to a user that does not exist, he gets a bounce message that the given mail account/user does not exist on server. But, when someone from inside (from one of my domains) tries to send mail to non existing user, he is not able to send e-mail, and mail clients give him reject code (some with explanation that account/user does not exist, some with no explanation). What I want to do is to set postfix to let those inside mails pass too, and then recive bounce mail with note that user does not exist (that is, the same behavior as when someone from outside sends mail to non existing user). I've tried numerous changes in main.cf, but could not achieve this behaviour. Is it even possible? Thanks, Zel
Re: Anyone use this email server configuration ?
* Frank Bonnet frank.bon...@esiee.fr: Hello Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ I finally got around reading this. I wonder if it should be more strict regaring the used ciphers (both in Postfix and Dovecot), given that it's for self-hosting only. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Rejecting mail to unknown users
On 11/09/2013 12:23, Zel Uneec wrote: Hello everyone! I need your help setting up postfix. This is my problem/question: I have multiple domains on my mail server running postfix (adn dovecot), with LDAP based user accounts. When someone from outside (that is: not from my domains) sends mail to a user that does not exist, he gets a bounce message that the given mail account/user does not exist on server. But, when someone from inside (from one of my domains) tries to send mail to non existing user, he is not able to send e-mail, and mail clients give him reject code (some with explanation that account/user does not exist, some with no explanation). What I want to do is to set postfix to let those inside mails pass too, and then recive bounce mail with note that user does not exist (that is, the same behavior as when someone from outside sends mail to non existing user). It might help if you explained why you want to do this. What particular problem is being caused by your internal users getting an error message instead of a bounce? As a general rule, sending a bounce is a last resort, something that you do when you can't reject a message. That's how the system is designed to work, and sending a bounce when you don't need to is generally considered bad practice. Mark -- My blog: http://mark.goodge.co.uk
Re: Rejecting mail to unknown users
On 11.09.2013 13:31, Mark Goodge wrote: It might help if you explained why you want to do this. What particular problem is being caused by your internal users getting an error message instead of a bounce? As a general rule, sending a bounce is a last resort, something that you do when you can't reject a message. That's how the system is designed to work, and sending a bounce when you don't need to is generally considered bad practice. Mark This is why: previously we used qmail, but I decided to migrate to postfix+dovecot. On previous mail server installation (qmail) we had the behaviour I now want to achieve - bounce mails for everyone, not only outsiders, and thus no error message while trying to send to unknown user. Particular problem: my boss (and his Mac Mail). :) My boss wants this functionality. With old mail server, he could send mail to numerous addresses, and if one of them does not exist, he would recieve a bounce mail note for non existing user, but mails to valid users will be sent. Now, if he misspells only one address, the mail is not sent at all, nor even to valid addresses. That's how he sees it. No matter what I say and try to explain which is better and why. He wants the old functionality, as it is better for him. So, here's one more additional question from me: why is it so problematic if inside (my domains) users send mails to non existing mail addresses? I assume this would not happen so often to have some impact on server. Much much more impact have outsider mails to non existing addresses.
smtp IPv4/IPv6 map
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there a way to override smtp_address_preference for a single host (or domain) to force an IPv4 or IPv6 connection? I am asking because we are (hopefully even if slowly) approaching to a period when IPv6 could be adopted not only by SMTP servers with (presumed) skilled SysAdmin, but also by large organization whith sloppy IPv6 support. A sort of tranport map for IPv4/IPv6/any could be useful for: * force IPv4 connection with bogous IPv4/IPv6 MTAs * force IPv6 connection for testing purposes Ciao, luigi - -- / +--[Luigi Rosa]-- \ Got Mole problems? Call Avogadro 6.02 x 10^23 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIwW+0ACgkQ3kWu7Tfl6ZSpSACbBjW5Z6ErJOTDkhsOFilDiYjR AUAAoLKXiCamZAcxpwQQ9Y4I7g6Redvh =Ru0f -END PGP SIGNATURE-
Re: Rejecting mail to unknown users
On Wed, Sep 11, 2013 at 01:23:01PM +0200, Zel Uneec wrote: This is my problem/question: I have multiple domains on my mail server running postfix (adn dovecot), with LDAP based user accounts. When someone from outside (that is: not from my domains) sends mail to a user that does not exist, he gets a bounce message that the given mail account/user does not exist on server. No, not from your server, anyway. Your server rejects the mail from the remote client, and that MTA generates the bounce for their own user. But, when someone from inside (from one of my domains) tries to From one of my domains? Do you mean from your networks? send mail to non existing user, he is not able to send e-mail, and mail clients give him reject code (some with explanation that account/user does not exist, some with no explanation). What I want to do is to set postfix to let those inside mails pass too, and then recive bounce mail with note that user does not exist This is what happens if permit_mynetworks precedes any other reatrictions you may have set. (that is, the same behavior as when someone from outside sends mail to non existing user). No, it is not. But in effect it is similar, if their MTA sent a bounce. I guess that's what you mean? I've tried numerous changes in main.cf, but could not achieve this behaviour. Is it even possible? Of course it is. But it is not possible to guess what you did. http://www.postfix.org/DEBUG_README.html#mail -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Rejecting mail to unknown users
/dev/rob0: On Wed, Sep 11, 2013 at 01:23:01PM +0200, Zel Uneec wrote: This is my problem/question: I have multiple domains on my mail server running postfix (adn dovecot), with LDAP based user accounts. When someone from outside (that is: not from my domains) sends mail to a user that does not exist, he gets a bounce message that the given mail account/user does not exist on server. No, not from your server, anyway. Your server rejects the mail from the remote client, and that MTA generates the bounce for their own user. But, when someone from inside (from one of my domains) tries to From one of my domains? Do you mean from your networks? send mail to non existing user, he is not able to send e-mail, and mail clients give him reject code (some with explanation that account/user does not exist, some with no explanation). What I want to do is to set postfix to let those inside mails pass too, and then recive bounce mail with note that user does not exist This is what happens if permit_mynetworks precedes any other reatrictions you may have set. It is slightly different. The user unknown test is enabled by default: Built-in default: smtpd_reject_unlisted_recipient = yes With this, there is an implicit reject_unlisted_recipient that is enforcedi for all clients. To accept mail from local clients to unknown recipients, while blocking mail from remote clients to unknown recipients, you have to specify the reject_unlisted_recipient explicitly. /etc/postfix/main.cf: smtpd_reject_unlisted_recipient = no smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unlisted_recipient ... reject_unauth_destination ... It's is very easy to screw this up and become a backscatter source. That is why smtpd_reject_unlisted_recipient = no is not the default setting. http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_recipient http://www.postfix.org/postconf.5.html#reject_unlisted_recipient Wietse
Re: smtp IPv4/IPv6 map
Luigi Rosa: Is there a way to override smtp_address_preference for a single host (or domain) to force an IPv4 or IPv6 connection? /etc/postfix/transport: example.com smtp-ipv4-only: example.net smtp-upv6-only: /etc/postfix/master.cf: smtp-ipv4-only unix - - n - - smtp inet_protocols=ipv4 smtp-ipv6-only unix - - n - - smtp inet_protocols=ipv6 /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport Execute postmap hash:/etc/postfix/transport and postfix reload when the transport map is changed. http://www.postfix.org/postconf.5.html#inet_protocols Wietse I am asking because we are (hopefully even if slowly) approaching to a period when IPv6 could be adopted not only by SMTP servers with (presumed) skilled SysAdmin, but also by large organization whith sloppy IPv6 support. A sort of tranport map for IPv4/IPv6/any could be useful for: * force IPv4 connection with bogous IPv4/IPv6 MTAs * force IPv6 connection for testing purposes Ciao, luigi -- / +--[Luigi Rosa]-- \ Got Mole problems? Call Avogadro 6.02 x 10^23 -- End of PGP signed section, PGP failed!
Re: smtp IPv4/IPv6 map
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wietse Venema said the following on 11/09/2013 14:47: /etc/postfix/transport: example.com smtp-ipv4-only: example.net smtp-upv6-only: /etc/postfix/master.cf: smtp-ipv4-only unix - - n - - smtp inet_protocols=ipv4 smtp-ipv6-only unix - - n - - smtp inet_protocols=ipv6 Great, thank you Wietse! Ciao, luigi - -- / +--[Luigi Rosa]-- \ The primary function of the design engineer is to make things difficult for the fabricator and impossible for the serviceman. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIwaEkACgkQ3kWu7Tfl6ZR0GwCgnMx9yzlDi9rE2lteHmlnWRO+ JfgAn15/fG/XnTqYjrSvUf0IqAwJQlBx =gXvx -END PGP SIGNATURE-
Re: spamassassin (spamd/spamc) duplicating messages in alias/forward+mailbox situation
Hello Wietse,
Hi List,
Thanks for the quick response and sorry for not posting the complete
configuration, I thought the linked tutorial would be sufficient.
On Tue, Sep 10, 2013 at 12:38 PM, Wietse Venema wie...@porcupine.org wrote:
You created a mail filter loop. How to fix: please see the mailing
list welcome message below. I.e., describe what you have, we already
know what you want.
I solved the duplication problem by adding :dummy to the
content_filter definition.
There are two aspects of this configuration bothering me:
1) Every incoming email will be scanned n times, n being the number
of recipients or alias targets
2) Logfiles are getting harder to read because of the after-queue filtering
Are there any before-queue integration methos for spamassassin and
postfix that can be used in a spamd/spamc setup like ours?
Neither amavis-new, nor the spampd method described here
(http://wiki.apache.org/spamassassin/IntegratePostfixViaSpampd) seem
to support being client for remote spamd server(s).
I would love to be able to grep for the queued-as-id in the logs to
get the full processing log of those emails ;)
Having to deal with qmail logs for the last 5 years was driving me nuts...
Thanks again for your patiance!
John
Now my configuration looks like this:
main.cf:
--
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
autoresponder_destination_recipient_limit = 1
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
delay_warning_time = 4h
inet_interfaces = all
mailbox_size_limit = 0
message_size_limit = 5120
mydestination = mx10.domain.net
myhostname = mx10.domain.net
mynetworks = /etc/postfix/mynetworks
policy-spf_time_limit = 3600s
readme_directory = no
recipient_delimiter = +
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_client_restrictions = reject_rbl_client dnsbl.sorbs.net
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks,
reject_invalid_hostname, reject_unknown_recipient_domain,
reject_unverified_recipient, permit_sasl_authenticated,
reject_unauth_destination, reject_rbl_client zen.spamhaus.org,
reject_rbl_client sbl.spamhaus.org, reject_rhsbl_helo
dbl.spamhaus.org, reject_rhsbl_sender dbl.spamhaus.org,
check_policy_service unix:private/policy-spf, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = cyrus
smtpd_tls_cert_file = /etc/ssl/private/smtpd.pem
smtpd_tls_key_file = /etc/ssl/private/smtpd.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport_maps
unknown_local_recipient_reject_code = 550
virtual_alias_domains = hash:/etc/postfix/virtual_alias_domains
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps
virtual_gid_maps = static:101
virtual_mailbox_base = /var/qmail/mailnames/
virtual_mailbox_domains = hash:/etc/postfix/virtual_mailbox_domains
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps
virtual_minimum_uid = 100
virtual_uid_maps = static:110
--
master.cf:
--
smtp inet n - - - - smtpd
-o content_filter=spamassassin:dummy
submission inet n - - - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
smtps inet n - - - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
pickupfifo n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgrunix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounceunix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verifyunix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
relay unix - - - -
Postfix newbie looking for help
I have a remote server running CentOS-6.4 in another country.
I was running sendmail/procmail on this machine
but recently changed to postfix/amavis/clamd .
Email is no longer being sent from the remote server
(eg by ddclient), I assume because it is sent
from ddclient@localhost.localdomain .
(I give the entries in /var/log/maillog below.)
The full name of the server is alfred.gayleard.eu .
I believe that my ISP in Italy (where the server is situated)
requires me to give my From address as gayle...@alice.it
when sending email, though I may be wrong about that.
I'd be very grateful if someone could tell me the changes I need to make
to the files in /etc/postfix .
The changes I've made to main.cf are given in this diff file:
-
[tim@alfred postfix]$ diff main.cf main.cf.orig
77,78d76
#myhostname = localhost.localdomain
myhostname = alfred.gayleard.eu
86,87d83
#mydomain = localdomain
mydomain = gayleard.eu
104d99
myorigin = alice.it
121,122c116
#inet_interfaces = localhost
inet_interfaces = all
---
inet_interfaces = localhost
170c164
#mydestination = $myhostname, localhost.$mydomain, localhost
---
mydestination = $myhostname, localhost.$mydomain, localhost
174d167
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
274d266
mynetworks = 192.168.2.0/24, 127.0.0.0/8
305d296
relay_domains =
429d419
home_mailbox = Maildir/
687,691d676
# added by TGM
content_filter=amavisfeed:[127.0.0.1]:10024
-
Apologies for this rather long request for help.
I would be most grateful for any help or advice you might be able to give me.
Maillog entry for ddclient:
-
Sep 11 07:37:22 alfred postfix/qmgr[15529]: 65BAE2309D5:
from=ddclient@localhost.localdomain, size=784, nrcpt=1 (queue active)
Sep 11 07:37:22 alfred amavis[17266]: (17266-01) LMTP::10024
/var/spool/amavisd/tmp/amavis-20130911T073722-17266-4IBNRfPh:
ddclient@localhost.localdomain - tim@localhost.localdomain SIZE=784
Received: from alfred.gayleard.eu ([127.0.0.1]) by localhost
(localhost.localdomain [127.0.0.1]) (amavisd-new, port 10024) with LMTP for
tim@localhost.localdomain; Wed, 11 Sep 2013 07:37:22 +0200 (CEST)
Sep 11 07:37:22 alfred amavis[17266]: (17266-01) Checking: RFbVYVx6KI50 MYNETS
[127.0.0.1] ddclient@localhost.localdomain - tim@localhost.localdomain
Sep 11 07:37:33 alfred amavis[17266]: (17266-01) dkim: candidate originators:
From:ddclient@localhost.localdomain
Sep 11 07:37:33 alfred amavis[17266]: (17266-01) dkim: not signing, empty
signing domain, From: ddclient@localhost.localdomain
Sep 11 07:37:33 alfred postfix/qmgr[15529]: 72018230C6D:
from=ddclient@localhost.localdomain, size=1263, nrcpt=1 (queue active)
Sep 11 07:37:33 alfred amavis[17266]: (17266-01) FWD from
ddclient@localhost.localdomain - tim@localhost.localdomain,BODY=7BIT 250
2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 72018230C6D
Sep 11 07:37:33 alfred amavis[17266]: (17266-01) Passed CLEAN
{RelayedInternal}, MYNETS LOCAL [127.0.0.1]:54623 [127.0.0.1]
ddclient@localhost.localdomain - tim@localhost.localdomain, Message-ID:
201309110537.r8B5bM8w017743@localhost.localdomain, mail_id: RFbVYVx6KI50,
Hits: -2.652, size: 784, queued_as: 72018230C6D, 11034 ms
Sep 11 07:37:34 alfred postfix/smtp[17753]: BBA4E230C7C:
to=ddclient@localhost.localdomain, relay=none, delay=0.21,
delays=0.05/0/0.16/0, dsn=5.4.4, status=bounced (Host or domain name not
found. Name service error for name=localhost.localdomain type=: Host not
found)
-
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin 2, Ireland
Re: spamassassin (spamd/spamc) duplicating messages in alias/forward+mailbox situation
Johannes Jakob: Hello Wietse, Hi List, Thanks for the quick response and sorry for not posting the complete configuration, I thought the linked tutorial would be sufficient. You appear to believe that you implemented the cookbook recipe correctly. I think that is too optimistic. In my experience, people often don't see the difference between what they want to have and what they actually have. Wietse
Re: Rejecting mail to unknown users
On 11.09.2013 14:43, Wietse Venema wrote: /etc/postfix/main.cf: smtpd_reject_unlisted_recipient = no smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unlisted_recipient ... reject_unauth_destination ... It's is very easy to screw this up and become a backscatter source. That is why smtpd_reject_unlisted_recipient = no is not the default setting. Thank you Wietse, that is what I was looking for! So, for now, my problem is solved. Just one more thing: Will this setting have some kind of (big) negative impact? I guess not, but just to be sure... Thank you, once again. Cheers, Zel
Re: Rejecting mail to unknown users
Zel Uneec: On 11.09.2013 14:43, Wietse Venema wrote: /etc/postfix/main.cf: smtpd_reject_unlisted_recipient = no smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unlisted_recipient ... reject_unauth_destination ... It's is very easy to screw this up and become a backscatter source. That is why smtpd_reject_unlisted_recipient = no is not the default setting. Thank you Wietse, that is what I was looking for! So, for now, my problem is solved. Just one more thing: Will this setting have some kind of (big) negative impact? I guess not, but just to be sure... Yes. When a client becomes malware infected, it will send spam with a false sender address, and Postfix will return some of that spam to innocent people. Wietse
Re: Rejecting mail to unknown users
Is there any way to control the malware infected computer, not to send more then counted or limited messages. On Wed, Sep 11, 2013 at 6:57 PM, Wietse Venema wie...@porcupine.org wrote: Zel Uneec: On 11.09.2013 14:43, Wietse Venema wrote: /etc/postfix/main.cf: smtpd_reject_unlisted_recipient = no smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unlisted_recipient ... reject_unauth_destination ... It's is very easy to screw this up and become a backscatter source. That is why smtpd_reject_unlisted_recipient = no is not the default setting. Thank you Wietse, that is what I was looking for! So, for now, my problem is solved. Just one more thing: Will this setting have some kind of (big) negative impact? I guess not, but just to be sure... Yes. When a client becomes malware infected, it will send spam with a false sender address, and Postfix will return some of that spam to innocent people. Wietse
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote: Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ I finally got around reading this. I wonder if it should be more strict regaring the used ciphers (both in Postfix and Dovecot), given that it's for self-hosting only. With opportunistic TLS, reducing the set of ciphers available always reduces security, since when the handshake fails mail is subsequently sent in the clear. The Postfix SMTP client and server cipherlists are *ordered* sensibly, and with SSLv2 disabled (default), there should be no downgrade attacks. It only makes sense to restrict the cipherlist to a more secure subset when TLS is mandatory. The default cipher grade for mandatory TLS is medium. The medium grade is essentially just 128-bit RC4: AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 IDEA-CBC-SHASSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 IDEA-CBC-MD5SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDH-RSA-RC4-SHASSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 so if not using RC4 is a requirement, raising the mandatory grade to high can be tried with care, but the effect is not always necessarily for the better: $ posttls-finger -c -L summary gmail.com posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits) $ posttls-finger -c -L summary -g high gmail.com posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher AES128-SHA (128/128 bits) So with medium you get RC4 with PFS, and with high you get AES128 without PFS. Which is better, we don't know for sure. On a related note, in the Postfix SMTP client, I'd like at some point to disable not only SSLv2, but also SSLv3, leaving only TLSv1 and up enabled. This ensures that TLSv1 extensions are sent in the SSL client HELO message. Extensions can signal the list of supported EECDH curves, support for session tickets, ... The right time for this would probably be after OpenSSL 1.0.2 is released, because then with an appropriate small change to Postfix, the best EECDH curve can be negotiated, rather than fixed by the server. SSLv3 is already disabled in Postfix 2.11 when the remote server is authenticated via DNSSEC DANE TLSA records, because in this case the Postfix SMTP client needs to send the SNI extension to the server (just in case the right certificate is contingent on SNI). -- Viktor.
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 04:57:01PM +0200, DTNX Postmaster wrote: SSLv3 is already disabled in Postfix 2.11 when the remote server is authenticated via DNSSEC DANE TLSA records, because in this case the Postfix SMTP client needs to send the SNI extension to the server (just in case the right certificate is contingent on SNI). I was looking at this yesterday, and this already answers some of the questions I had, thanks Victor :-) The cry to drop RC4 as quick as possible seems to be getting stronger again this week, but of course in SMTP interop it's never that simple. And then there's the BEAST attack, which RC4 seems to be immune to? The BEAST, CRIME, ... attacks are HTTPS specific, and do not generally apply to other TLS applications, in particular they are not relevant to SMTP. One could in theory disable only the MD5 based RC4 ciphers for now, as they are not used by the ECDHE based options? SMTP servers don't know whether the client is doing opportunistic TLS or authenticating the server. They should generally allow all ciphersuites on port 25 (they can if desired switch from client cipher order to server cipher order). Shrinking the server cipherlist increases the odds of plaintext re-transmission with little gain. Port 25 TLS security is in the hands of the client. On 587, servers can be more selective. We did disable SSLv3 for incoming connections yesterday, as TLS connection statistics over August suggest that they make up only 0,005% of the total. This is counter-productive. You get TLSv1 whenever the client supports it, so rejecting SSLv3 at the server does not improve security. May do the same for outgoing connections. This is more reasonable, provided systems you send mail to all support TLSv1 and up. What fraction of outbound handshakes end up with SSLv3? In a couple of years time, when OpenSSL 1.0.2 is out, and Postfix 2.12 or 2.13 ships, I think we can safely turn off SSLv3 by default in the Postfix SMTP *client*. The rationale is improved EECDH support (servers can offer more trust-worthy curves when clients support them) and a negligible and diminishing set of servers that only support SSLv3. At this time, the only plausibly useful TLS extension for the client to send is session ticket support, and this mostly breaks session caching in Postfix SMTP servers other than the just released 2.10.2, 2.9.8, 2.8.16 and 2.7.15. So it is premature to disable SSLv3. The Postfix default TLS settings are chosen with care, most efforts to improve them are counter-productive. The only change justified by recent events is perhaps forcing the non-export EDH prime to 2048-bits as described in recent threads. -- Viktor.
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote: Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ I finally got around reading this. I wonder if it should be more strict regaring the used ciphers (both in Postfix and Dovecot), given that it's for self-hosting only. The blog recommends at least one of smtp[d]_tls_loglevel = 2, this is unwise except when debugging. -- Viktor.
Re: Rejecting mail to unknown users
On 9/11/2013 9:18 AM, Vishal Agarwal wrote: Is there any way to control the malware infected computer, not to send more then counted or limited messages. There are several policy services that implement rate limits. postfwd is one that is commonly used. http://www.postfix.org/SMTPD_POLICY_README.html http://www.postfix.org/addon.html#policy -- Noel Jones
Re: Anyone use this email server configuration ?
On Sep 11, 2013, at 16:34, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote: Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ I finally got around reading this. I wonder if it should be more strict regaring the used ciphers (both in Postfix and Dovecot), given that it's for self-hosting only. With opportunistic TLS, reducing the set of ciphers available always reduces security, since when the handshake fails mail is subsequently sent in the clear. The Postfix SMTP client and server cipherlists are *ordered* sensibly, and with SSLv2 disabled (default), there should be no downgrade attacks. It only makes sense to restrict the cipherlist to a more secure subset when TLS is mandatory. The default cipher grade for mandatory TLS is medium. The medium grade is essentially just 128-bit RC4: AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 IDEA-CBC-SHASSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 IDEA-CBC-MD5SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDH-RSA-RC4-SHASSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 so if not using RC4 is a requirement, raising the mandatory grade to high can be tried with care, but the effect is not always necessarily for the better: $ posttls-finger -c -L summary gmail.com posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits) $ posttls-finger -c -L summary -g high gmail.com posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher AES128-SHA (128/128 bits) So with medium you get RC4 with PFS, and with high you get AES128 without PFS. Which is better, we don't know for sure. On a related note, in the Postfix SMTP client, I'd like at some point to disable not only SSLv2, but also SSLv3, leaving only TLSv1 and up enabled. This ensures that TLSv1 extensions are sent in the SSL client HELO message. Extensions can signal the list of supported EECDH curves, support for session tickets, ... The right time for this would probably be after OpenSSL 1.0.2 is released, because then with an appropriate small change to Postfix, the best EECDH curve can be negotiated, rather than fixed by the server. SSLv3 is already disabled in Postfix 2.11 when the remote server is authenticated via DNSSEC DANE TLSA records, because in this case the Postfix SMTP client needs to send the SNI extension to the server (just in case the right certificate is contingent on SNI). I was looking at this yesterday, and this already answers some of the questions I had, thanks Victor :-) The cry to drop RC4 as quick as possible seems to be getting stronger again this week, but of course in SMTP interop it's never that simple. And then there's the BEAST attack, which RC4 seems to be immune to? One could in theory disable only the MD5 based RC4 ciphers for now, as they are not used by the ECDHE based options? We did disable SSLv3 for incoming connections yesterday, as TLS connection statistics over August suggest that they make up only 0,005% of the total. Will see if that causes any trouble with the few big senders that seem to be stuck on SSLv3/RC4-MD5. May do the same for outgoing connections. Google seems to be only major user of 'ECDHE-RSA-RC4-SHA' at the moment, by the way, not seen that anywhere else. And the AES based ciphers make up the vast majority of connections seen. Mvg, Joni
Re: Rejecting mail to unknown users
Am 11.09.2013 16:52, schrieb Kris Deugau: Mark Goodge wrote: It might help if you explained why you want to do this. What particular problem is being caused by your internal users getting an error message instead of a bounce? Some idiot mail clients (*cough*ManyversionsofOutlook*cough*) don't actually display the SMTP error response to the user, they just pop up a generic Wahh! Can't do that! error message iPhones do not show the errors at all as well as ignoring the 5xx repsonse a try over months and weeks to send the same message every 5 minutes by stupidity but that is no reason to generate bounces
Re: Rejecting mail to unknown users
Mark Goodge wrote: It might help if you explained why you want to do this. What particular problem is being caused by your internal users getting an error message instead of a bounce? Some idiot mail clients (*cough*ManyversionsofOutlook*cough*) don't actually display the SMTP error response to the user, they just pop up a generic Wahh! Can't do that! error message. Some users are also quite resistant to actually *reading* the text of the error (although these users will also have trouble with reading the bounce message). -kgd
Re: spamassassin (spamd/spamc) duplicating messages in alias/forward+mailbox situation
On Wed, Sep 11, 2013 at 5:03 PM, Noel Jones njo...@megan.vbhcs.org wrote: There are some milters that use spamc/spamd, and should work well with recent postfix versions. Google is your friend. Thanks Noel... milter was the keyword I needed... google'd a lot, but thought, postfix and spamassassin sites would be the best source of howtos. spamass-milter is working perfectly and all my problems are solved. Thanks again, John
Re: Unifying virtual_alias_maps and domains
Am Mittwoch, 11. September 2013, 15:30:15 schrieb Viktor Dukhovni: On Wed, Sep 11, 2013 at 05:18:55PM +0200, Florian Lindner wrote: Since there are not many users and rather low mail traffic on the machine I want to simplify the query. There will be no more mail enabled or disabled domains, postfix should take all emails for which virtual_alias_maps returns an alias. You are confused. That may certainly be right. ;-) Virtual alias rewriting applies to all domains unconditionally. Your original settings are fine. Don't change them. With virtual alias domains, the recipient *must* be found in virtual alias maps (close enough to the truth), while with other domains the recipient *may* be found in virtual alias maps. Ok, I hope I'm right now: A recipient is found in virtual_alias_domains but not in maps - bounced. A recipient is not found in domains but in maps - email is delivered to alias if the the MTA considers itself destination A recipient is neither found in domains nor maps - email is delivered using other means of getting the final user to deliver the mail to. From: http://www.postfix.org/postconf.5.html#virtual_alias_domains The default value is $virtual_alias_maps so that you can keep all information about virtual alias domains in one place. If you have many users, it is better to separate information that changes more frequently (virtual address - local or remote address mapping) from information that changes less frequently (the list of virtual domain names). That gave me the impression that it is possible and desirable to use the same query for viritual_alias_maps and domains. For my configuration it would be fine to tie maps and domains together. All recipients that are in maps are also listed in domains. Hope I got at least my question right this time ;-) Florian
Unifying virtual_alias_maps and domains
Hello! Currently I've virtual_alias_maps and virtual_alias_domains set: virtual_alias_domains = mysql:/etc/postfix/mysql-virtual-alias-domains.cf virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf domains use this query: query = SELECT domain FROM domains WHERE mail AND domain = '%s' UNION SELECT alias FROM http_aliases WHERE domain IN (SELECT domain FROM domains WHERE mail) AND alias = '%s' It checks if the domain is in the domains table with mail enabled or if there is a http_alias of a mail enabled domain. maps this: query = SELECT alias FROM virtual_aliases WHERE virtual='%s' alias is the system user account, e.g. flindner virtual is the mail address, e.g. mailingli...@xgm.de Since there are not many users and rather low mail traffic on the machine I want to simplify the query. There will be no more mail enabled or disabled domains, postfix should take all emails for which virtual_alias_maps returns an alias. If I simply remove virtual_alias_domains from the configuration it defaults to $virtual_alias_maps, but the query with %s = xgm.de returns nothing and relay access is denied. A virtual_alias_maps query = SELECT alias FROM virtual_aliases WHERE virtual LIKE '%%s' (first % should be the SQL wildcard, probably needs escaping) could be doing the trick and return a result for the domain query (afaik postfix only checks existince of a result) and return an alias for the maps query. I have some concern that this query might be overly brought and returns false positives. What is the best way here? Thanks, Florian
Re: spam - headers: from ME to ME, but different anvelope sender
On 09/07/2013 05:19 AM, FliedRice wrote: Just a thought, In order to block more incoming spam you could add more rbl's to your main.cf file. I have spamassassin, but it's turned off in favor of the following smtpd restrictions and domain blocking in the plesk user interface, or filtering in the Cpanel interface. I have 2 servers which both use these restrictions: smtpd_client_restrictions = permit_mynetworks, reject_rbl_client sbl.spamhaus.org, reject_rbl_client xbl.spamhaus.org, That's all zen now. reject_rbl_client bl.spamcop.net, reject_rbl_client cbl.abuseat.org, reject_rbl_client dnsbl.mags.net, reject_rbl_client bl.mailspike.net, reject_rbl_client l2.apews.org, reject_rbl_client bl.tiopan.com, reject_rbl_client niku.2ch.net, reject_rbl_client bl.spameatingmonkey.net You would want to use postscreen(8) for that. For starters, it does parallel lookups (which is faster) and maintains its own cache (which is faster still.) It also allows you to do weighted scoring for multiple DNSBLs (which smtpd_client_restrictions does not.) Available in postfix 2.8+ (which is over 2 years old) -- J.
Re: Dealing with outages
On 09/09/2013 09:27 PM, Wietse Venema wrote: Postfix does a hard bounce when the DNS server replies that the name has no MX record AND the DNS server replies that the name has no A record, AND (if Postfix IPv6 support is on) the DNS server replies that the name has no record. Does that mean that postfix will do a hard bounce if there is no reply to an MX query after a timeout ? I thought it would at least try the other queries (A and/or ) before giving up, since this costs no more than when there /is/ a (negative) reply. Since postfix may be talking to a cache or a resolver with numerous hops in between postfix and the authoritative source, any of the queries may fail individually, and yet not be conclusive. Postfix does a soft bounce when any of those lookups does not produce a reply. This seems to suggest the former, but I am double-checking. -- J.
Re: Unifying virtual_alias_maps and domains
On Wed, Sep 11, 2013 at 07:26:28PM +0200, Florian Lindner wrote:
With virtual alias domains, the recipient *must* be found in virtual
alias maps (close enough to the truth), while with other domains the
recipient *may* be found in virtual alias maps.
Ok, I hope I'm right now:
A recipient is found in virtual_alias_domains but not in maps - bounced.
- Essentially correct (the whole truth is merely distracting with
technicalities).
A recipient is not found in domains but in maps - email is delivered to alias
[unconditionally].
- All recipients (even remote) are subject to virtual alias rewriting.
A recipient is neither found in domains nor maps - email is delivered using
other means of getting the final user to deliver the mail to.
- The recipient address is not rewritten via virtual(5).
That gave me the impression that it is possible and desirable to use the same
query for viritual_alias_maps and domains.
No. This is a backwards compatibility crutch for Postfix versions
prior to 2.0. It is best practice to separate virtual alias domains
and virtual alias maps.
For my configuration it would be fine to tie maps and domains together. All
recipients that are in maps are also listed in domains.
I would not store both in the same table, but you can store both
in the same database. If you want to suppress virtual alias lookups
for recipients outside a static list of domains, the LDAP, MySQL
and PgSQL drivers for Postfix support a domain attribute in the
table configuration file that restricts table lookups to addresses
in particular domains.
If you do use the domain attribute, the list of virtual domains
can no longer be stored in the table
main.cf:
...
virtual_alias_domains = example.com
virtual_alias_maps = mysql:${config_directory}/virtual.cf
virtual.cf:
...
domain = example.com
because only keys of the form localp...@example.com are passed to the
database.
--
Viktor.
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 09:12:40PM +0200, DTNX Postmaster wrote: This is counter-productive. You get TLSv1 whenever the client supports it, so rejecting SSLv3 at the server does not improve security. It rejects the systems that only support SSLv3, does it not? Or am I understanding it incorrectly? The reasoning was that accepting SSLv3/RC4-MD5 connections from systems for which that is apparently the maximum they can support, even today, constitutes a false sense of security. It being the low-hanging fruit, and the most likely to be brute-forcable by the Powers That Be, if they indeed have that capability. And even if they don't, systems which have that as the maximum would be more likely to have backdoors or vulnerabilities that would allow for the recovery of private keys. Forcing the traffic to be sent clear-text is not an improvement. People also have a false sense of security about mail they send in the clear. Pedantry is counter-productive in security. Think about the practical results of proposed policy changes. Also, I think it was like five servers that had this as their maximum, in the entire month. Given those numbers, we figured we could run some tests and see what happens with those rare connections. There is little to gain by breaking TLS from those 5 servers unless they are spammers, and you would reject their traffic anyway. In a couple of years time, when OpenSSL 1.0.2 is out, and Postfix 2.12 or 2.13 ships, I think we can safely turn off SSLv3 by default in the Postfix SMTP *client*. The rationale is improved EECDH support (servers can offer more trust-worthy curves when clients support them) and a negligible and diminishing set of servers that only support SSLv3. At this time, the only plausibly useful TLS extension for the client to send is session ticket support, and this mostly breaks session caching in Postfix SMTP servers other than the just released 2.10.2, 2.9.8, 2.8.16 and 2.7.15. So it is premature to disable SSLv3. The Postfix default TLS settings are chosen with care, most efforts to improve them are counter-productive. I am aware of this, and we generally do not override the defaults unless it is to solve problems. Had to disable 'DES-CBC3-SHA' as a cipher in the client because it was bugging out vs. an Exchange 2003 server that should be phased out before year's end, for example. That's a very old problem! Historically the Microsoft systems with this problem selected RC4 in preference to 3DES. I am surprised to hear that the problem is still not fixed, and that the server selected 3DES. The only change justified by recent events is perhaps forcing the non-export EDH prime to 2048-bits as described in recent threads. That was the problem with certain versions of Exim, was it not? Yes, current Exim on Debian squeeze (6.0) or stale Exim (before 4.80-3) on Debian wheezy (7.x). The road to hell is paved with good intentions. In this case one of the Debian maintainers wanted to improve Exim security, as a result of which a lot more mail was sent in the clear as Exim TLS stopped interoperating with most other MTAs. Avoid counter-productive knee-jerk designs. If you want better email security, consider deploying to DNSSEC and publishing DANE TLSA RRs. When you deploy Postfix 2.11, consider making dane the default client TLS security level: smtp_dns_support_level = dnssec smtp_tls_security_level = dane With DANE you take advantage of ECDSA self-signed certificates in parallel with RSA self-signed certificates. Clients that support EECDH and ECDSA will be able to authenticate your server via stronger high-performance public keys and DH groups. At some point in the not too distant future there will be specifications for new EC curves with TLS that are not tainted by the mystery seeds of the NIST curves, making use of these will require OpenSSL 1.0.2 or later, so it will be some time before the state of the art moves beyond what is best-practice today. Stay tuned, but don't expect things to get much better very fast. -- Viktor.
Re: Anyone use this email server configuration ?
On Sep 11, 2013, at 17:24, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Sep 11, 2013 at 04:57:01PM +0200, DTNX Postmaster wrote: SSLv3 is already disabled in Postfix 2.11 when the remote server is authenticated via DNSSEC DANE TLSA records, because in this case the Postfix SMTP client needs to send the SNI extension to the server (just in case the right certificate is contingent on SNI). I was looking at this yesterday, and this already answers some of the questions I had, thanks Victor :-) The cry to drop RC4 as quick as possible seems to be getting stronger again this week, but of course in SMTP interop it's never that simple. And then there's the BEAST attack, which RC4 seems to be immune to? The BEAST, CRIME, ... attacks are HTTPS specific, and do not generally apply to other TLS applications, in particular they are not relevant to SMTP. Ah, I thought I had read that it affected other applications as well, must have misunderstood, thanks. One could in theory disable only the MD5 based RC4 ciphers for now, as they are not used by the ECDHE based options? SMTP servers don't know whether the client is doing opportunistic TLS or authenticating the server. They should generally allow all ciphersuites on port 25 (they can if desired switch from client cipher order to server cipher order). Shrinking the server cipherlist increases the odds of plaintext re-transmission with little gain. Port 25 TLS security is in the hands of the client. On 587, servers can be more selective. We did disable SSLv3 for incoming connections yesterday, as TLS connection statistics over August suggest that they make up only 0,005% of the total. This is counter-productive. You get TLSv1 whenever the client supports it, so rejecting SSLv3 at the server does not improve security. It rejects the systems that only support SSLv3, does it not? Or am I understanding it incorrectly? The reasoning was that accepting SSLv3/RC4-MD5 connections from systems for which that is apparently the maximum they can support, even today, constitutes a false sense of security. It being the low-hanging fruit, and the most likely to be brute-forcable by the Powers That Be, if they indeed have that capability. And even if they don't, systems which have that as the maximum would be more likely to have backdoors or vulnerabilities that would allow for the recovery of private keys. Also, I think it was like five servers that had this as their maximum, in the entire month. Given those numbers, we figured we could run some tests and see what happens with those rare connections. It may simply turn out to be misguided paranoia, however ;-) May do the same for outgoing connections. This is more reasonable, provided systems you send mail to all support TLSv1 and up. What fraction of outbound handshakes end up with SSLv3? I'll have a look, I only checked for incoming connections yesterday. In a couple of years time, when OpenSSL 1.0.2 is out, and Postfix 2.12 or 2.13 ships, I think we can safely turn off SSLv3 by default in the Postfix SMTP *client*. The rationale is improved EECDH support (servers can offer more trust-worthy curves when clients support them) and a negligible and diminishing set of servers that only support SSLv3. At this time, the only plausibly useful TLS extension for the client to send is session ticket support, and this mostly breaks session caching in Postfix SMTP servers other than the just released 2.10.2, 2.9.8, 2.8.16 and 2.7.15. So it is premature to disable SSLv3. The Postfix default TLS settings are chosen with care, most efforts to improve them are counter-productive. I am aware of this, and we generally do not override the defaults unless it is to solve problems. Had to disable 'DES-CBC3-SHA' as a cipher in the client because it was bugging out vs. an Exchange 2003 server that should be phased out before year's end, for example. The only change justified by recent events is perhaps forcing the non-export EDH prime to 2048-bits as described in recent threads. That was the problem with certain versions of Exim, was it not? Mvg, Joni
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 10:03:52PM +0200, DTNX Postmaster wrote: The odd thing is that both banks drop to RC4-MD5 when sending to us. I've seen this on another product that we support ourselves as well; the Postfix client negotiates a higher protocol level and better cipher for outgoing mail than the server does for incoming mail. There is probably a good reason for this, but it feels to me like they should support the same protocol and cipher level regardless of direction? I am not surprised. In our own case though this is with current software, a direct connection without firewall tomfoolery and whatnot. I shall see if their support department can explain it to me and satisfy my curiosity as to what causes the difference. One thing too keep in mind is that in many cases servers honour client cipher preferences. When your SMTP client connects to their server the cipher-suite chosen is the highest on your preference list that they support. When their client connects to your server the cipher-suite chosen is the highest on their preference list that you support. The two cipher-suites need not be the same even with the same software on their side sending and receiving. http://www.postfix.org/postconf.5.html#tls_preempt_cipherlist -- Viktor.
Re: Anyone use this email server configuration ?
On Wed, Sep 11, 2013 at 09:39:57PM +0200, DTNX Postmaster wrote: This is more reasonable, provided systems you send mail to all support TLSv1 and up. What fraction of outbound handshakes end up with SSLv3? Outbound is an even smaller percentage of total TLS connections established in August; 0,0002%. Interestingly, they are both banks; one Dutch, and one Swiss. Both using SSLv3 with AES256-SHA, wouldn't be surprised if that means they are using the same brand of security product. For many large organizations inbound and outbound email are handled by completely separate infrastructure. Inbound mail is often first received by various anti-spam appliances. Outbound mail often bypasses these, and for bulk transactional mail, may be handled by other appliances that handle deliverability tracking, ... The odd thing is that both banks drop to RC4-MD5 when sending to us. I've seen this on another product that we support ourselves as well; the Postfix client negotiates a higher protocol level and better cipher for outgoing mail than the server does for incoming mail. There is probably a good reason for this, but it feels to me like they should support the same protocol and cipher level regardless of direction? I am not surprised. Re-enabled SSLv3 for incoming connections again, by the way; turns out that about half of those incoming connections are from an outsourcing firm that handles payment notifications for, yes, another Dutch bank. Sigh ;-) As I mentioned, at this time, deprecating SSLv3 is most likely counter-productive. I am hoping that in a couple of years it will be a practical default for the SMTP client only, where you can define exceptions for problem destinations via smtp_tls_policy_maps. A polite note to their postmaster linking to this thread may encourage them to start making plans to upgrade to inbound systems that can support TLSv1 and up (strictly speaking the STARTTLS EHLO response in SMTP promises support of TLS an IETF standard, not SSLv3). -- Viktor.
Re: Anyone use this email server configuration ?
On Sep 11, 2013, at 21:37, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Sep 11, 2013 at 09:12:40PM +0200, DTNX Postmaster wrote: The reasoning was that accepting SSLv3/RC4-MD5 connections from systems for which that is apparently the maximum they can support, even today, constitutes a false sense of security. It being the low-hanging fruit, and the most likely to be brute-forcable by the Powers That Be, if they indeed have that capability. And even if they don't, systems which have that as the maximum would be more likely to have backdoors or vulnerabilities that would allow for the recovery of private keys. Forcing the traffic to be sent clear-text is not an improvement. People also have a false sense of security about mail they send in the clear. Pedantry is counter-productive in security. Think about the practical results of proposed policy changes. Also, I think it was like five servers that had this as their maximum, in the entire month. Given those numbers, we figured we could run some tests and see what happens with those rare connections. There is little to gain by breaking TLS from those 5 servers unless they are spammers, and you would reject their traffic anyway. Aye, true. Change has been reversed. Misguided paranoia ;-) I am aware of this, and we generally do not override the defaults unless it is to solve problems. Had to disable 'DES-CBC3-SHA' as a cipher in the client because it was bugging out vs. an Exchange 2003 server that should be phased out before year's end, for example. That's a very old problem! Historically the Microsoft systems with this problem selected RC4 in preference to 3DES. I am surprised to hear that the problem is still not fixed, and that the server selected 3DES. It is possible to install AES extensions on Windows 2003 servers and upgrade the encryption support that way, but given that this server is the last Exchange 2003 server we have to support, on its way out, and Microsoft gives you a gazillion warnings, we decided that it was just not worth the hassle. Supposedly you can disable that particular cipher via registry settings, too, but that didn't work either. In other words, after spending two hours trying to figure out where it was going wrong, we decided that all parties involved would be better off speeding up migration to the new Exchange server instead. The only change justified by recent events is perhaps forcing the non-export EDH prime to 2048-bits as described in recent threads. That was the problem with certain versions of Exim, was it not? Yes, current Exim on Debian squeeze (6.0) or stale Exim (before 4.80-3) on Debian wheezy (7.x). The road to hell is paved with good intentions. In this case one of the Debian maintainers wanted to improve Exim security, as a result of which a lot more mail was sent in the clear as Exim TLS stopped interoperating with most other MTAs. We generally love Debian, but sadly, these things are one of the drawbacks of using the distribution. They too are misguided at times, heh :-( We haven't seen the issue yet, though, so perhaps we'll stay lucky and be able to avoid the workaround for it. Avoid counter-productive knee-jerk designs. If you want better email security, consider deploying to DNSSEC and publishing DANE TLSA RRs. When you deploy Postfix 2.11, consider making dane the default client TLS security level: smtp_dns_support_level = dnssec smtp_tls_security_level = dane With DANE you take advantage of ECDSA self-signed certificates in parallel with RSA self-signed certificates. Clients that support EECDH and ECDSA will be able to authenticate your server via stronger high-performance public keys and DH groups. At some point in the not too distant future there will be specifications for new EC curves with TLS that are not tainted by the mystery seeds of the NIST curves, making use of these will require OpenSSL 1.0.2 or later, so it will be some time before the state of the art moves beyond what is best-practice today. Stay tuned, but don't expect things to get much better very fast. I will keep it in mind. Thanks for the valuable feedback, Victor :-) Mvg, Joni
Re: Anyone use this email server configuration ?
On Sep 11, 2013, at 21:52, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Sep 11, 2013 at 09:39:57PM +0200, DTNX Postmaster wrote: This is more reasonable, provided systems you send mail to all support TLSv1 and up. What fraction of outbound handshakes end up with SSLv3? Outbound is an even smaller percentage of total TLS connections established in August; 0,0002%. Interestingly, they are both banks; one Dutch, and one Swiss. Both using SSLv3 with AES256-SHA, wouldn't be surprised if that means they are using the same brand of security product. For many large organizations inbound and outbound email are handled by completely separate infrastructure. Inbound mail is often first received by various anti-spam appliances. Outbound mail often bypasses these, and for bulk transactional mail, may be handled by other appliances that handle deliverability tracking, ... Ahh, yes. It's the same IP address, but that could just as well be the firewall itself that fronts multiple devices. The odd thing is that both banks drop to RC4-MD5 when sending to us. I've seen this on another product that we support ourselves as well; the Postfix client negotiates a higher protocol level and better cipher for outgoing mail than the server does for incoming mail. There is probably a good reason for this, but it feels to me like they should support the same protocol and cipher level regardless of direction? I am not surprised. In our own case though this is with current software, a direct connection without firewall tomfoolery and whatnot. I shall see if their support department can explain it to me and satisfy my curiosity as to what causes the difference. Re-enabled SSLv3 for incoming connections again, by the way; turns out that about half of those incoming connections are from an outsourcing firm that handles payment notifications for, yes, another Dutch bank. Sigh ;-) As I mentioned, at this time, deprecating SSLv3 is most likely counter-productive. I am hoping that in a couple of years it will be a practical default for the SMTP client only, where you can define exceptions for problem destinations via smtp_tls_policy_maps. A polite note to their postmaster linking to this thread may encourage them to start making plans to upgrade to inbound systems that can support TLSv1 and up (strictly speaking the STARTTLS EHLO response in SMTP promises support of TLS an IETF standard, not SSLv3). Noted. In our experience however the postmaster account rarely works, and if it does you run into a mess of red tape where even the most simple change requires multiple signatures, several hours of consulting billed and whatnot. Mvg, Joni
1 mail being stuck in incoming mail queue.
I have this 1 email from 1 company from 1 person who for some reason gets stuck in the incoming folder. Mail After it goes through. Mail Before it goes through. The maillog show the message showing up. Then that is it. The file stays in chmod 600. I found a suggestion of putting -v behind pickup. All that seemed to do was reqeue the message each time restarted postfix and get stuck again. I have never had any problem before with postfix. That I know of. If I restart the postfix. The message goes away and is never delivered. Need the first step of that to do. Perhaps I can manually push the file through? Thanks, Josh -- This message has been scanned for viruses and dangerous content by Galaxy Mail Server, and is believed to be clean.
Re: 1 mail being stuck in incoming mail queue.
On Wed, Sep 11, 2013 at 02:15:34PM -0600, Josh Cason wrote: I have this 1 email from 1 company from 1 person who for some reason gets stuck in the incoming folder. Mail After it goes through. Mail Before it goes through. The maillog show the message showing up. Then that is it. The file stays in chmod 600. I found a suggestion of putting -v behind pickup. All that seemed to do was reqeue the message each time restarted postfix and get stuck again. I have never had any problem before with postfix. That I know of. Messages in the incoming directory that are mode 0600 are in the process of being received by the cleanup(8) service. The entire message has not yet been received, and so naturally does not get delivered. If there is a cleanup(8) process with the queue file open for write, the problem is upstream in smtpd(8) or remote sender or in pickup(8). Look for problem reports from cleanup(8) in your logs. Does the message arrive from outside via SMTP or is it submitted locally? Does pickup(8) or smtpd(8) log any problems? -- Viktor.
Re: 1 mail being stuck in incoming mail queue.
Josh Cason: I have this 1 email from 1 company from 1 person who for some reason gets stuck in the incoming folder. Mail After it goes through. Mail Before it goes through. The maillog show the message showing up. Then that is it. The file stays in chmod 600. I found A file with mode 600 in the incoming queue means that the file is incomplete, and that the cleanup daemon process was killed before it got a chance to remove the incomplete file. Wietse
Re: 1 mail being stuck in incoming mail queue.
Wietse Venema: Josh Cason: I have this 1 email from 1 company from 1 person who for some reason gets stuck in the incoming folder. Mail After it goes through. Mail Before it goes through. The maillog show the message showing up. Then that is it. The file stays in chmod 600. I found A file with mode 600 in the incoming queue means that the file is incomplete, and that the cleanup daemon process was killed before it got a chance to remove the incomplete file. .. or that the cleanup process is still running, perhaps looping on a bad header_checks or body_checks pattern. In that case the process will be killed by a watchdog timer and leave a suitable warning in the maillog file. Wietse
Re: Dealing with outages
Jeroen Geilman: On 09/09/2013 09:27 PM, Wietse Venema wrote: Postfix does a hard bounce when the DNS server replies that the name has no MX record AND the DNS server replies that the name has no A record, AND (if Postfix IPv6 support is on) the DNS server replies that the name has no record. Does that mean that postfix will do a hard bounce if there is no reply to an MX query after a timeout ? Postfix does a hard bounce when the DNS server replies that the name has no MX record AND ... Can you see the difference with the DNS server replies that and there is no reply? Wietse
Re: Dealing with outages
Am 11.09.2013 20:19, schrieb Jeroen Geilman: On 09/09/2013 09:27 PM, Wietse Venema wrote: Postfix does a hard bounce when the DNS server replies that the name has no MX record AND the DNS server replies that the name has no A record, AND (if Postfix IPv6 support is on) the DNS server replies that the name has no record. Does that mean that postfix will do a hard bounce if there is no reply to an MX query after a timeout ? I thought it would at least try the other queries (A and/or ) before giving up, since this costs no more than when there /is/ a (negative) reply. Since postfix may be talking to a cache or a resolver with numerous hops in between postfix and the authoritative source, any of the queries may fail individually, and yet not be conclusive. Postfix does a soft bounce when any of those lookups does not produce a reply. This seems to suggest the former, but I am double-checking * no reply - defer - soft bounce * NEGATIVE reply - no defer - hard bounce this answsers all possible cases because timeout is also no reply if a domain does not exist because the worldwide DNS recursion says there is no such domain, there is no nameserver to ask it would be pointless to soft bounce / defer and hope someone registers the domain a outage is by definition no reply
Re: 1 mail being stuck in incoming mail queue.
The two entries in log file. I change a few things to protect my mail server, client and sender. But you should get the idea. This is how my mailserver system is setup. cisco router - assp spam filter - postfix mailserver with mailscanner. It is suspose to go to the hold folder. So MailScanner can pick it up. But never makes it to that folder. I thought perhaps the assp was cutting out to soon on the message. I have some disconnects around that time. But if that was the case I thought I would have found more. But I observered most of the day and have been running this assp setup for 2 months. Everything goes fine. Before that was postini - router - postfix with mailscanner. I did check the assp log and say the message went just fine. No errors. Thinking maybe it was disconnecting to soon. But the servers are on the same shelve with the same switch on the same network. I asked my client if the if there customer was sending the mail was getting a error message. He did not know. They just know the email was not showing up. So I checked my normal spots. No dice. Then that is when I found it stuck in the incoming folder. I see the email three times in the log. All next to each other. I see the connection from my spam filter. The hold header on the messag and the third time with a message id. Sep 11 17:29:38 primary postfix/cleanup[25098]: 054AC10D800E: hold: header Received: from BOZO2.onsite.local (spamfilter.mydomain.com [172.16.0.188])??by primary.mydomain.cc ) with ESMTP id 054AC10D800E??for custo...@theredomain.com; Wed, 11 Sep 2013 17:29:36 -0600 (M from spamfilter.mydomain.com[172.16.0.188]; from=sen...@theredomain.com to= custo...@theredomain.com proto=ESMTP helo=BOZO2.onsite.local Sep 11 17:29:38 primary postfix/cleanup[25098]: 054AC10D800E: message-id=4e653ecbe3cd403bb 5254d7554e43fd9@BOZO2.onsite.local I hope this helps some more. Unelss I need to turn on debugging or missing it. I didn't see any error messages in the maillog. That the first thing I looked for was error messages. Then I have something to follow. Thanks, Josh - Original Message - From: Viktor Dukhovni postfix-us...@dukhovni.org To: postfix-users@postfix.org Sent: Wednesday, September 11, 2013 2:44 PM Subject: Re: 1 mail being stuck in incoming mail queue. On Wed, Sep 11, 2013 at 02:15:34PM -0600, Josh Cason wrote: I have this 1 email from 1 company from 1 person who for some reason gets stuck in the incoming folder. Mail After it goes through. Mail Before it goes through. The maillog show the message showing up. Then that is it. The file stays in chmod 600. I found a suggestion of putting -v behind pickup. All that seemed to do was reqeue the message each time restarted postfix and get stuck again. I have never had any problem before with postfix. That I know of. Messages in the incoming directory that are mode 0600 are in the process of being received by the cleanup(8) service. The entire message has not yet been received, and so naturally does not get delivered. If there is a cleanup(8) process with the queue file open for write, the problem is upstream in smtpd(8) or remote sender or in pickup(8). Look for problem reports from cleanup(8) in your logs. Does the message arrive from outside via SMTP or is it submitted locally? Does pickup(8) or smtpd(8) log any problems? -- Viktor. -- This message has been scanned for viruses and dangerous content by Galaxy Mail Server, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by Galaxy Mail Server, and is believed to be clean.
About smtpd_recipient_restrictions
Hello, Myfriend This is Tom, I'm sending my greeting from China In the main.cf smtpd_recipient_restrictions = reject_unknown_recipient_domain reject_unlisted_recipient permit_auth_destination permit_sasl_authenticated permit_mynetworks reject_unauth_destination one week before, It's working wel, for now, there is so many mail in my queue just like 2A63AAC1844 400211 Thu Sep 12 10:26:37 some...@example.com (host other.example.com[IP] said: 450 4.1.2 anyone@qq.c: Recipient address rejected: Domain not found (in reply to RCPT TO command)) anyone@qq.c I do not know, why smtpd_recipient_restrictions not working Thanks for your time TOM
Re: About smtpd_recipient_restrictions
On 9/11/2013 10:08 PM, Feel Zhou wrote: Hello, Myfriend This is Tom, I'm sending my greeting from China In the main.cf http://main.cf smtpd_recipient_restrictions = reject_unknown_recipient_domain reject_unlisted_recipient permit_auth_destination permit_sasl_authenticated permit_mynetworks reject_unauth_destination one week before, It's working wel, for now, there is so many mail in my queue just like 2A63AAC1844 400211 Thu Sep 12 10:26:37 some...@example.com mailto:some...@example.com (host other.example.com http://other.example.com[IP] said: 450 4.1.2 anyone@qq.c: Recipient address rejected: Domain not found (in reply to RCPT TO command)) anyone@qq.c I do not know, why smtpd_recipient_restrictions not working Thanks for your time TOM smtpd_recipient_restrictions only work with mail received with SMTP. Perhaps these messages arrived from the the postfix/pickup service. -- Noel Jones
Re: About smtpd_recipient_restrictions
Hello, Noel At the same time, smtpd_sender_restrictions not working too smtpd_sender_restrictions = reject_non_fqdn_sender reject_unknown_sender_domain reject_unlisted_sender check_sender_mx_access cidr:/etc/postfix/bad_mx_access_check check_sender_access hash:/etc/postfix/sender_reject_addr_check, hash:/etc/postfix/feel/sender_access_check check_client_access cidr:/etc/postfix/enforce_ip_match_domain permit_sasl_authenticated permit_mynetworks The simple log file show me Sep 12 03:57:59 shcx amavis[19706]: (19706-20) Passed CLEAN, [27.24.141.102] [27.24.141.102] vpg...@194798.com - some...@example.com, There is no mx recorder with sender domain, but this mail was sent Thanks a lot Tom 2013/9/12 Noel Jones njo...@megan.vbhcs.org On 9/11/2013 10:08 PM, Feel Zhou wrote: Hello, Myfriend This is Tom, I'm sending my greeting from China In the main.cf http://main.cf smtpd_recipient_restrictions = reject_unknown_recipient_domain reject_unlisted_recipient permit_auth_destination permit_sasl_authenticated permit_mynetworks reject_unauth_destination one week before, It's working wel, for now, there is so many mail in my queue just like 2A63AAC1844 400211 Thu Sep 12 10:26:37 some...@example.com mailto:some...@example.com (host other.example.com http://other.example.com[IP] said: 450 4.1.2 anyone@qq.c: Recipient address rejected: Domain not found (in reply to RCPT TO command)) anyone@qq.c I do not know, why smtpd_recipient_restrictions not working Thanks for your time TOM smtpd_recipient_restrictions only work with mail received with SMTP. Perhaps these messages arrived from the the postfix/pickup service. -- Noel Jones
LDAP groups
I am currently running postfix 2.6.6 on a Centos 6.3 machine. I have setup a samba 3.5.10 domain with openldap 2.4.23 as the central authentication. I am now trying to get postfix to be able to expand groups. We currently have about 50 groups, but not all of them will need to be addressable. All of them can be, just only about half will be used. I would like to be able to keep my existing group ou in ldap and let postfix check against it. That way when I add users to ldap groups they will automatically be in the email groups also. I have looked at the page here: http://www.postfix.org/LDAP_README.html#example_group but that looks like I will have to manually add all the members to the group using the postmap command. Is this right? -- Donny B.
Re: LDAP groups
On Wed, Sep 11, 2013 at 11:14:23PM -0500, Donny Brooks wrote: I have looked at the page here: http://www.postfix.org/LDAP_README.html#example_group but that looks like I will have to manually add all the members to the group using the postmap command. Is this right? No, the postmap(1) commands in that document show you how to run *queries* against LDAP groups that illustrate how the various group-related features works. You should run postmap commands to *test* your table definitions before you configure them into a live Postfix system. However, you certainly don't have to do that for every group. Once you understand the Postfix LDAP group features thoroughly you will often be able to just type in correct LDAP table definitions that work first time, but the prudent approach is to always test. -- Viktor.
