spf failures on forwarded emails
Hi, We started received SPF failures on forwarded emails, from our domainA to remote domainB. I have googled, and Sender Rewriting Scheme (SRS) comes up as a possible solution, but all the links and docs are old. (2015, 2014, not recent) I would just like to ask the experts here: Is SRS still the way to deal with such situations in 2020? There is not much we can do to get rid the forwards, and we have many of them, so a good solution would be welcome. :-) We are running debian 10, btw. Thanks! MJ
Re: ADVICE: Best Practice - Usernames with Domain components
Hi, So, do I understand correctly that you are running postfix/mailutils etc directly on your ADDC, and you are using 'local' (=winbind) users? Then probably I ould change that: not use local users, but make everything mail-related talk to ldap only, and don't use local users. Also...perhaps consider running it on a seperate machine. (perhaps even a VM on your samba ADDC) MJ On 5/27/20 12:40 PM, Nick Piggott wrote: Hi, I'm not able to suppress the DOMAIN element of the username part on *this* machine. All the machines in the AD have a directive in their /etc/samba/smb.conf file winbind use default domain = yes however this doesn't work on this machine acting as the AD-DC, and looking at the Samba mailing lists, this is by design, and unlikely to change. It does work on the workstations (where users are just shown as their username). So one "workaround" would be to work out how to suppress the DOMAIN through Samba / Winbind on this machine. But I have not been able to achieve that at all, so that's why I'm looking to fix it around postfix. Nick On Tue, 26 May 2020 at 13:49, mj <mailto:li...@merit.unu.edu>> wrote: Hi, I have read your mail, and we're using a setup similar to yours (samba, postfix, debian) and we're using 'regular' usernames, without the domain prefix. Sometimes, but only in windows, we specify a domain name to make clear to windows that we mean the DOMAIN account username, and not a local account, or DOMAINB\username. But in common practise, we never login anywhere with DOMAIN\username And we also never have the issues you are describing, and no need fotr mappings of any kind. Are you *sure* you need your usernames in that format? MJ On 26/05/2020 13:50, Nick Piggott wrote: > Hello, > > Here's my setup: > * Ubuntu 18.04 LTS > * Postfix 3.3.0 > * Mailutils 3.4 > * Samba 4.7.6 > * Active Directory (provided by Samba) > > My usernames are of the format: > * DOMAIN\username > > I can separately maintain a list of mappings between DOMAIN\username > and username. > > Here are the problems I'm looking to solve appropriately: > * mail - sends the origination user as "DOMAIN\username", which > postfix provides onto the destination mail exchanger, which rejects it > as being an incorrect format > * postfix - is configured with: > local_recipient_maps = proxy:unix:passwd.byname $alias_maps > which flattens the return address to "domain\username", and creates a > mailbox in /var/mail as "domain\username". When the user types "mail" > to read their email, it opens "DOMAIN\username", so they never see > their newly received messages. > > Things I have tried: > * Using > sender_canonical_maps = hash:\etc\postfix\sender_canonical > to change a specific DOMAIN\username to username. It didn't work, > although I could see it parsing sender_canonical.db when sending. The > exact line was > DOMAIN\\username : username > Postfix still provided "DOMAIN\username" as the originator to the > destination mail exchanger. > * Using > recipient_canonical_maps = hash:\etc\postfix\recipient_canonical > to convert a specific username back to DOMAIN\username. That failed > because the output is still casefolded to domain\username before > writing to the mailbox file. > > Questions: > * Am I trying the right approach to rewriting the originating email > address from DOMAIN\username to username? What am I potentially > missing to get it working? > * As postfix will always fold the return address to lowercase (because > of the local_recipient_maps filter), should I just softlink together > the mailbox files DOMAIN\username and domain\username in /var/mail, or > is there a solution I can put into postfix to revert back to > DOMAIN\username before outputting to the mail file? > > Thanks in advance, > -- Nick
Re: ADVICE: Best Practice - Usernames with Domain components
Hi, I have read your mail, and we're using a setup similar to yours (samba, postfix, debian) and we're using 'regular' usernames, without the domain prefix. Sometimes, but only in windows, we specify a domain name to make clear to windows that we mean the DOMAIN account username, and not a local account, or DOMAINB\username. But in common practise, we never login anywhere with DOMAIN\username And we also never have the issues you are describing, and no need fotr mappings of any kind. Are you *sure* you need your usernames in that format? MJ On 26/05/2020 13:50, Nick Piggott wrote: Hello, Here's my setup: * Ubuntu 18.04 LTS * Postfix 3.3.0 * Mailutils 3.4 * Samba 4.7.6 * Active Directory (provided by Samba) My usernames are of the format: * DOMAIN\username I can separately maintain a list of mappings between DOMAIN\username and username. Here are the problems I'm looking to solve appropriately: * mail - sends the origination user as "DOMAIN\username", which postfix provides onto the destination mail exchanger, which rejects it as being an incorrect format * postfix - is configured with: local_recipient_maps = proxy:unix:passwd.byname $alias_maps which flattens the return address to "domain\username", and creates a mailbox in /var/mail as "domain\username". When the user types "mail" to read their email, it opens "DOMAIN\username", so they never see their newly received messages. Things I have tried: * Using sender_canonical_maps = hash:\etc\postfix\sender_canonical to change a specific DOMAIN\username to username. It didn't work, although I could see it parsing sender_canonical.db when sending. The exact line was DOMAIN\\username : username Postfix still provided "DOMAIN\username" as the originator to the destination mail exchanger. * Using recipient_canonical_maps = hash:\etc\postfix\recipient_canonical to convert a specific username back to DOMAIN\username. That failed because the output is still casefolded to domain\username before writing to the mailbox file. Questions: * Am I trying the right approach to rewriting the originating email address from DOMAIN\username to username? What am I potentially missing to get it working? * As postfix will always fold the return address to lowercase (because of the local_recipient_maps filter), should I just softlink together the mailbox files DOMAIN\username and domain\username in /var/mail, or is there a solution I can put into postfix to revert back to DOMAIN\username before outputting to the mail file? Thanks in advance,
Re: prevent NDRs for sieve-forwarded emails
Thanks for your reply. On 04/19/2018 02:51 PM, Matus UHLAR - fantomas wrote: rewriting sender of the forwarded mail in the SRS (https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme) way and delivering all the mail to rewritten sender to someone who is able to fix or remove such forwarding. I would consider delivering mail back to the mailbox of u...@ourdomain.com or maybe postmas...@ourdomain.com So, if I understand correctly, I would set something like: sieve_redirect_envelope_from = "<dedicated_u...@merit.unu.edu>" (dovecot.conf) Thanks again! MJ
prevent NDRs for sieve-forwarded emails
Hi, Here is our situation: We have an email server at ourdomain.com where some folks setup a sieve redirect to other mailboxes. Now, consider the case where a us...@randomdomain.com sends an email to our u...@ourdomain.com, and it is sieve-forwarded to u...@forwarddomain.com. But suppose the u...@forwarddomain.com mailbox no longer exists: an NDR is generated at forwarddomain.com. Currently this NDR is sent back all the way to the original sender us...@randomdomain.com. However, the message *was* in fact successfully delivered to our mailbox u...@ourdomain.com, and we would like to prevent NDRs for these sieve-forwarded messages. Is there a way to achieve this? If it helps: the sieve-forwards are mostly to very few foreign domains, so perhaps we could filter NDRs at some stage, based on coming-from domain..? Best regards, MJ
Re: why is smtpd_recipient_restrictions ignored..?
On 03/23/2018 01:06 AM, Viktor Dukhovni wrote: Yes, but the right answer is turn off the webform until you can replace it with something that is not open to abuse. We will install a captcha tomorrow. (it's after midnight now) It's also not *that* harmful: they s u b s c r i b e to a wordpress blog, using russian email addresses. Actually: We don't understand what's in it for them... The system then sends a c o n f i r m a t i o n email, that 99% of the time is not clicked. And this all happens to four different .ru domains. Requiring a captcha to s u b s c r i b e will probably get rid of this. MJ
Re: why is smtpd_recipient_restrictions ignored..?
On 03/23/2018 12:58 AM, mj wrote: Is there perhaps also another error code we can use, that blackholes the email, instead of politely bouncing it with a "Diagnostic-Code: X-Postfix; Destination domain blacklisted"? I just found the "discard" option. Thanks you again, Viktor! MJ
Re: why is smtpd_recipient_restrictions ignored..?
Hi Viktor, On 03/23/2018 12:42 AM, Viktor Dukhovni wrote: Almost certainly bounces, which did not come in via SMTP, they are originated locally, when inbound mail from mail.ru is undeliverable, and sent outbound via the smarthost. Yes, they are originated locally, yes, using a webform that is currently being abused. How can I make sure that this particular postfix instance will DISALLOW sending ANY email to @mail.ru? Seems a rather harsh policy, but if you must: transport: mail.ru error:5.1.2 Destination domain blacklisted It's very harsh, but we'll do it just for the time being, until we have fixed the webform. Your solution works super, thanks a lot! Is there perhaps also another error code we can use, that blackholes the email, instead of politely bouncing it with a "Diagnostic-Code: X-Postfix; Destination domain blacklisted"? MJ
why is smtpd_recipient_restrictions ignored..?
Hi all,
This postfix 2.9.6 from wheezy. I have added to main.cf:
smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/blacklisted_domains, permit_mynetworks,
reject_unauth_destination, permit
and /etc/postfix/blacklisted_domains contains just one line:
mail.ru REJECT
I postmapped the file and restarted postfix.
Alas... postfix is still happily forwarding emails to 1...@mail.ru to my
smarthost.
How can I make sure that this particular postfix instance will DISALLOW
sending ANY email to @mail.ru?
What am I missing?
Thanks in advance!
MJ
Here is my complete main.cf:
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
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
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# to prevent russian spam
smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/blacklisted_domains, permit_mynetworks,
reject_unauth_destination, permit
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname = www.site1.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = www.site1.com, site2.com, localhost.site2.com, localhost,
site3.com
relayhost = outgoing.smarthost.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
sender_canonical_maps = hash:/etc/postfix/sender_canonical
Re: send specific NDR message for users in certain OU
Hi Wietse, Super! I'll checkout the information provided. Thanks a lot, it's appreciated! :-) MJ On 02/01/2018 04:04 PM, Wietse Venema wrote: mj: Anyone..? On 01/30/2018 02:55 PM, lists wrote: Hi, The question can perhaps be made more generic like this: Can postfix generate a *specific* NDR (or an autoreply) for accounts that meet a specific criterium, such as: - user account was found under OU=to-delete,CN=company... contrary to the regular location CN=Users,CN=company... You can configure user-dependent responses with the error mailer. /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport /etc/pos1fix/transport: us...@example.com error:5.1.1 Mailbox is closed. Yadda yadda yadda. us...@example.com error:5.1.1 Some other text The 5.x.x codes are defined in RFC 3463. If you don't specify one, Postfix will use 5.0.0. The SMTP server will reject the recipients, so that Postfix does not have to send an NDR. For mail not received via SMTP, Postfix generates a bounce message when it attempts to deliver mail. If you have many users, you may want to use database instead of a text editor. With a database you can make the queries as complex as you need, and distinguish between OU=to-delete and other cases. /etc/postfix/main.cf: transport_maps = proxy:database:/config/file Wietse We would like to move to-be-deleted users to this container, before actually deleting them. That gives us an easy way to revert, if the deletion turns out to be erroneous. If postfix could send a "delivery failure" specific for those accounts (with instructions who to contact to revert the situation) it would be very easy: only move the user to the specific OU, and have the system do the rest. Can this be done? (postfix 2.11.1 from debian wheezy, yes we know we should upgrade, and we also will, but it runs rock solid...) MJ
Re: send specific NDR message for users in certain OU
Anyone..? On 01/30/2018 02:55 PM, lists wrote: Hi, The question can perhaps be made more generic like this: Can postfix generate a *specific* NDR (or an autoreply) for accounts that meet a specific criterium, such as: - user account was found under OU=to-delete,CN=company... contrary to the regular location CN=Users,CN=company... We would like to move to-be-deleted users to this container, before actually deleting them. That gives us an easy way to revert, if the deletion turns out to be erroneous. If postfix could send a "delivery failure" specific for those accounts (with instructions who to contact to revert the situation) it would be very easy: only move the user to the specific OU, and have the system do the rest. Can this be done? (postfix 2.11.1 from debian wheezy, yes we know we should upgrade, and we also will, but it runs rock solid...) MJ
Re: Calendar & Contacts
We're very happy with sogo. (https://sogo.nu/) MJ On 12/27/2017 08:40 AM, Philip Paeps wrote: On 2017-12-27 13:08:44 (+1030), Mal wrote: Interested to hear from those running a Postfix(MTA)/Dovecot(IMAP) combo on what contacts & calendar server projects they are having success with. I run Nextcloud. It's implemented in PHP (of all things) so you definitely want to lock it up in a jail. It stores its data in a PostgreSQL database (or possibly other kinds of databases -- I haven't looked). If you're on FreeBSD, you can install it in a fresh jail with `pkg install nextcloud`. The documentation is fairly comprehensive. Philip
Re: sasl auth LOGIN / PLAIN
On 09/02/2017 01:16 PM, Patrick Ben Koetter wrote: Mandatory STARTTLS*and* disallowing any shared-secret mechanism (CRAM-MD5, DIGEST-MD5, NTLM) is a clever move. This way you protect the identity while it is transported from the client to the server and you are able to store the passwords crypted. Thank you, Patrick!
Re: sasl auth LOGIN / PLAIN
Hi, Ok, so disallowing LOGIN is not a clever move :-) Thanks for your answers! MJ On 09/02/2017 08:32 AM, Patrick Ben Koetter wrote: * postfix <post...@ayni.com>: On 09/01/2017 04:25 PM, mj wrote: Just a small question: we currently use posfix with sasl authentication, and folowing many docs, we have enabled PLAIN and LOGIN authentication. However, googling leads me to believe that LOGIN is mostly used by Outlook Express, and that most (or all?) modern clients support the PLAIN mechanism. I also noticed that most failed authentication attempts are done using LOGIN. Now, assuming that most of these failed authentications are simply username/password guessing... how many problems would I expect, if I simply only offer PLAIN mechanism? It's hard to find info on what clients use what auth type. So, are all/most modern clients capable of doing PLAIN? (thunderbird, outlook 2010/2013) so could I simply disallow LOGIN? Thunderbird: PLAIN, DIGEST-MD5 Outlook 20**: LOGIN, NTLM As far as I know, outlook does only LOGIN, even: because of outlook the LOGIN mechanism was introduced. That is correct. p@rick
sasl auth LOGIN / PLAIN
Hi, Just a small question: we currently use posfix with sasl authentication, and folowing many docs, we have enabled PLAIN and LOGIN authentication. However, googling leads me to believe that LOGIN is mostly used by Outlook Express, and that most (or all?) modern clients support the PLAIN mechanism. I also noticed that most failed authentication attempts are done using LOGIN. Now, assuming that most of these failed authentications are simply username/password guessing... how many problems would I expect, if I simply only offer PLAIN mechanism? It's hard to find info on what clients use what auth type. So, are all/most modern clients capable of doing PLAIN? (thunderbird, outlook 2010/2013) so could I simply disallow LOGIN? MJ
Re: check_sasl_access question
Hi! Right! Remove permit_sasl_authenticated and keep check_sasl_access hash:/etc/postfix/sasl_list Thanks! It works! MJ
Re: check_sasl_access question
Hi Viktor!
Thanks for the quick reply!
On 08/11/2017 11:37 PM, Viktor Dukhovni wrote:
Far simpler:
indexed = ${default_database_type}:${config_directory}/
smtpd_relay_restrictions =
permit_mynetworks,
check_sasl_access ${indexed}sasl_list,
reject_unauth_destination
/etc/postfix/sasl_list:
username1 OK
username3 OK
With this, you only need to list the permitted users, there's no
need to list the rejects, these are handled by the required "default
deny" restriction at the end.
But where is the "default deny" at the end?
Because this does not look very different from my config:
smtpd_relay_restrictions = permit_mynetworks, check_sasl_access
hash:/etc/postfix/sasl_list, permit_sasl_authenticated,
reject_unauth_destination, check_recipient_access
pcre:$config_directory/x-add-envelope-to
I don't see much difference..? (except the indexed = $)
What am I missing/not seeing?
MJ
check_sasl_access question
Hi, I would like to only allow sasl authenticated relay for specific users, so I have in main.cf: smtpd_relay_restrictions = permit_mynetworks, check_sasl_access hash:/etc/postfix/sasl_list, and in /etc/postfix/sasl_list: username1 OK username2 REJECT username3 OK * REJECT The config works. I tested: username1 can relay, username2 cannot. However, I want to blacklist ALL my users, except username1 / username3, so the line with "*" is ignored. Googled and googled, but I can't find: How can I enter wildcards in that file, or otherwise get the same result? This is postfix 2.11.2 MJ
Re: limit sasl usernames
Hi all, On 08/08/2017 04:05 PM, Wietse Venema wrote: mj: In smtpd_client_restrictions, use check_sasl_access: Thanks very much, for the replies, both on- and off-list! MJ
limit sasl usernames
Hi all, Is there a way to limit/restrict the usernames that are allowed to use our postfix dovecot-sasl authenticated smtp relay? We would like only *specific* usernames to be able to use the authenticated relay. And currently everybody with dovecot imap access can also use the relay. Is there a way to restrict that? A simple list of usernames would work, or more advanced: dynamically using an ldap lookup to check group membership. Thanks in advance for pointers/tips, MJ
Re: Yahoo disconnecting at end of data on large messages.
Le 09/06/2010 23:19, Wietse Venema a écrit : Philippe Chaintreuil: One of our users sent a large (about 10MB) e-mail to Yahoo. Yahoo has not been accepting it, they don't give a reason, they just disconnect after getting the whole message: Jun 9 13:20:50 hobbes postfix/smtp[7398]: 02EB432E022: lost connection with e.mx.mail.yahoo.com[67.195.168.230] while sending end of data -- message may be sent more than once Small messages make it through without a problem, and sending the same message from a Gmail account works. Instead of tweaking, spend the effort to become whitelisted. Wietse I emailed Yahoo using the instructions which they had provided the previous time this subject was touched, and they replied to me: --- snip --- From : Yahoo! Mail mail-abuse-b...@cc.yahoo-inc.com Thank you for submitting your White List application. We have changed our application form so that you can provide us with more detailed information about your emailing practices. Please use our new form to submit your application. The new form can be found at: http://help.yahoo.com/l/us/yahoo/mail/postmaster/bulkv2.html Thank you. --- snip --- Not only can you get whitelisted using this form, but you can describe the time-out with large messages. Along with Postfix rate-limiting features, this should improve delivery with Yahoo MX. Kind regards, Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
Re: Yahoo disconnecting at end of data on large messages.
Le 09/06/2010 19:35, Philippe Chaintreuil a écrit : One of our users sent a large (about 10MB) e-mail to Yahoo. Yahoo has not been accepting it, they don't give a reason, they just disconnect after getting the whole message: Jun 9 13:20:50 hobbes postfix/smtp[7398]: 02EB432E022: lost connection with e.mx.mail.yahoo.com[67.195.168.230] while sending end of data -- message may be sent more than once Small messages make it through without a problem, and sending the same message from a Gmail account works. I've tried messing with MTU size (down to 950 from 1500), various sysctl settings, DKIM signing and probably a few things I'm forgetting about: to no avail. The best I can find is this post: http://article.gmane.org/gmane.mail.postfix.user/208435 But there's no resolution. Alas, I never received any follow-up. I sense it could be a time-out due to DSL - but I still don't understand why it only does it with Yahoo and with no-one else. Warm regards, Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
Re: lost connection with yahoo servers
Le 13/04/2010 14:28, Voytek Eymont a écrit : I seem to be having problems delivering emails to yahoo, how can I troubleshoot this ? mailq: ... 777DAB446E8 7709303 Fri Apr 9 12:15:32 a...@googlemail.com (lost connection with e.mx.mail.yahoo.com[67.195.168.230] while sending end of data -- message may be sent more than once) l...@yahoo.com.au m...@yahoo.com y...@yahoo.com ... We've got the same problem for large messages sent to Yahoo. (including yahoo.fr, yahoo.co.uk etc.) I don't think that it's a Postfix problem at all because only Yahoo causes this, so it much more likely to be a Yahoo problem. Kind regards, Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
Re: IPv6 Reverse DNS
Le 21/03/2010 16:32, Martin Barry a écrit : Hi I noted that postfix is writing headers with unknown instead of the IPv6 reverse DNS that I know exists. e.g. Received: from merboo.mamista.net (unknown [IPv6:2001:470:1f0b:1055::1]) by tigger.mamista.net (Postfix) with ESMTP id 581F21100B4 for sage...@sage-au.org.au; Mon, 22 Mar 2010 02:18:00 +1100 (EST) $ dig -x 2001:470:1f0b:1055::1 +short merboo.mamista.net. I'm still convinced the problem is not with postfix but is there a way to imitate it's IPv6 reverse DNS lookups so I can get closer to the cause of the problem? I have no trouble with reverse IPv6 DNS in my postfix headers. Looks like a local DNS config error or mis-delegation. Either way, I don't think it's a postfix issue at all. -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
Re: I'm not able to smtp relay email to yahoo...
Le 05/02/2010 17:11, Clayton Keller a écrit : On 2/5/2010 10:07 AM, DUBOURG Kevin wrote: Hello, Probably the yahoo domain Key policy. http://en.wikipedia.org/wiki/DomainKeys You have to install Dkimproxy. [...] It could be a part of some of the connectivity issues that they have been reporting off and on over the past week: http://tech.groups.yahoo.com/group/ymailadmin/ We have been seeing similar type deferrals amongst other connection issues during that time frame. Here too, for a while already, and we run DKIMProxy so DomainKeys/DKIM is not an issue. Not a Postfix issue either. Our sendmail-based MX have the same problem. Kind regards, -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
Re: ipv6 address syntax in master.cf
Use the notation with the square brackets: [::1]:10028 They are used to differentiate the colon used for separaring the port, as opposed to a colon which is part of the IPv6 address. Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html - Original Message - From: Byung-Hee HWANG b...@izb.knu.ac.kr To: postfix-users@postfix.org Sent: Saturday, January 24, 2009 10:53 AM Subject: ipv6 address syntax in master.cf hello, simple question. is that possible writing ipv6 address style in master.cf? if it is possible, which is correct syntax? [::1]:10028 inet (...) smtpd or ::1:10028 inet (...) smtpd byunghee
Re: emails not arriving timeout after CONNECT, E ND-OF-MESSAGE, DATA, EHLO
What I meant Martin was that there was a space in the destination word, which was written as destina tion rather than destination. If you make smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination Does it work? Olivier -- Olivier MJ Crepin-Leblond, Ph.D Global Information Highway Ltd http://www.gih.com/ocl.html - Original Message - From: Martin Vila To: postfix Sent: Friday, November 21, 2008 2:41 AM Subject: RE: emails not arriving timeout after CONNECT, END-OF-MESSAGE, DATA, EHLO smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destina tion Could it be this line, which as reject_unauth_destina tion or is this my email viewer of your cut/paste process? Thanks Olivier, I just tried only: smtpd_recipient_restrictions = permit_mynetworks and got this error: Nov 20 20:29:13 smtprelay postfix/postfix-script: refreshing the Postfix mail system Nov 20 20:29:13 smtprelay postfix/master[3355]: reload configuration /etc/postfix Nov 20 20:29:13 smtprelay postfix/anvil[2100]: statistics: max connection rate 1/60s for (smtp:200.38.12.191) at Nov 20 20:25:26 Nov 20 20:29:13 smtprelay postfix/anvil[2100]: statistics: max connection count 1 for (smtp:200.38.12.191) at Nov 20 20:25:26 Nov 20 20:29:13 smtprelay postfix/anvil[2100]: statistics: max cache size 5 at Nov 20 20:27:39 Nov 20 20:30:01 smtprelay postfix/smtpd[23963]: fatal: parameter smtpd_recipient_restrictions: specify at least one working instance of: check_relay_domains, reject_unauth_destination, reject, defer or defer_if_permit Nov 20 20:30:02 smtprelay postfix/master[3355]: warning: process /usr/libexec/postfix/smtpd pid 23963 exit status 1 Nov 20 20:30:02 smtprelay postfix/master[3355]: warning: /usr/libexec/postfix/smtpd: bad com mand startup -- throttling Nov 20 20:30:10 smtprelay postfix/smtpd[23964]: connect from unknown[10.13.0.9] what else can I try? Martin -- Discover the new Windows Vista Learn more!
Re: Postfix listening on 25, unable to telnet to 25 - my first config
Also check SElinux if you are running this. It may prevent changes to the port config from taking place. You can see entries in the logfile called /var/log/messages Regards, Olivier -- Olivier MJ Crepin-Leblond, Ph.D Global Information Highway Ltd http://www.gih.com/ocl.html - Original Message - From: D G Teed To: Paul Cocker Cc: postfix users list Sent: Friday, November 21, 2008 2:47 AM Subject: Re: Postfix listening on 25, unable to telnet to 25 - my first config Paul Cocker schrieb: Definitely nothing in between, of that I'm certain. Are there any tools which will give me more information about attempts to connect to a port on a remote host? use tcpdump for that purpose please try $ telnet $IP_OF_SMTP_HOST 25 and show exactly, what you get I ran windump in the background and did a telnet to the IP, however a findstr on the output file contains no matches. If I do the same thing using the server name the only matching output in the dump is when the server performs a name lookup, after that there are no matching entries by IP or name. Am I doing something wrong? There are a few things that can make postfix listen only locally. One is firewall. You say it isn't an issue. On the postfix machine, if it is a Unix machine, use lsof -Pni to verify what ports and addresses master is listening on. If it is only listening to 127.0.0.1 then you have a problem with inet_interfaces, or else the look up of the host name listed in inet_interfaces. On many Linux machines, the host resolution order is hosts, dns, and so a bad entry on /etc/hosts can sting you. Make sure you don't have 127.0.0.1 set up with the internet host name of the server in /etc/hosts. It should be only localhost next to 127.0.0.1 I've seen Redhat installs with this messed up. --Donald
Re: Queue ID gets reused? Not unique?
Dear Wietse, thank you for your detailed explanation. In the future, would you consider having unique identifiers generated by an algorithm which would take into account the CPU ID (or other unique identifier), process ID time, so as to make it a unique ID worldwide, or is this not something which you would find to be of interest? I am asking this, in view of future possible instances of the law re: legal status of an email its authoritative tracking. Just curious. Thanks, Olivier - Original Message - From: Wietse Venema [EMAIL PROTECTED] To: Postfix users postfix-users@postfix.org Sent: Friday, November 14, 2008 12:40 PM Subject: Re: Queue ID gets reused? Not unique? Durk Strooisma: I was examining my Postfix logs and saw two sequential sessions using the same queue ID. I was a bit surprised as I had the assumption that queue IDs were generated randomly, which means they should be practically unique. Postfix behaves as documented. Please point out where the documentation made the promise to you that queue IDs are unique. Thanks. Well, the documentation is fine. Actually, I think it's one of best among software projects. The only information I couldn't find was about the creation of queue IDs. Therefore I found myself in the situation I couldn't refute my assumption. Sometimes I am in the mood to pull people's leg. More seriously, I take pride in documenting the behavior that is guaranteed. The algorithm that assigns queue IDs may change, therefore the documentation makes no promises about how it's done. Currently the ID is the name of a short-lived file. A future queue implementation may use persistent files. In that case the queue ID may need to be assigned in some other way. The only hard requirement is that no two messages have the same ID while they are in the Postfix queue. Wietse
Re: Finally blocking some spam
Joey said: I would like to know everyone's techniques... but yes there goes that completive advantage you mentioned. I get no spam whatsoever (zero, nil, zip) because my mailer rejects email from *all* countries. :-) Seriously, rejecting emails from a complete country is overkill. Might kill all spam, but will also kill legitimate emails, and I'm not sure how your clients will know about an email they did not receive. As others have said, be careful because this might bite you back at some point. On the other hand, it's your network so do as you see fit. Cheers, -- Olivier MJ Crepin-Leblond, Ph.D. E-mail:[EMAIL PROTECTED] | http://www.gih.com/ocl.html
Re: Re[2]: Issues enabling SASL in Postfix
This problem also happens with CISCO routers (ie. not only PIX firewalls). We had a similar problem with a CISCO 837 ADSL Router here. The firewall checks normal behaviour for SMTP traffic seems to interfere with ESMTP hence TLS etc. Procedure to resolve it on the router is the same command. Regards, Olivier -- Olivier MJ Crepin-Leblond, Ph.D. E-mail:[EMAIL PROTECTED] | http://www.gih.com/ocl.html - Original Message - From: Diego Ledesma [EMAIL PROTECTED] To: Алексей Доморадов [EMAIL PROTECTED] Cc: postfix-users@postfix.org Sent: Friday, September 12, 2008 8:51 PM Subject: Re: Re[2]: Issues enabling SASL in Postfix 2008/9/12 Алексей Доморадов [EMAIL PROTECTED]: Finally it's working!. You where right. There was something interfering. Turns out that our cisco firewall had some smtp fix-up feature enabled. After disabling it i could telnet smtp from the outside as i did from the inside. cisco pix? FYI Question Background: I have a Cisco PIX firewall in place. I am trying to force SMTP authentication so that remote users can relay through my server without having to open my server up to true relay. The problem is, no one outside my firewall can use SMTPAuth. Why is this? Answer: This likely because your firewall is using the SMTP Fixup protocol. This is stopping the EHLO command sent by the clients being passed on to the server. As the EHLO command is rejected the clients then correctly go on to use HELO and thus can not authenticate. Disable fixup on your router and the clients will then be able to send the EHLO Command correctly. If your firewall is a Cisco PIX then you should be able to use the command: no fixup protocol smtp 25 Thanks for that. Yes, it´s a Cisco PIX 501 firewall and yes, the ehlo command was not working from the outside only helo thus i couldn´t authenticate. I still don´t know what is the purpose of this fixup thing, segurity messure i guess but not sure. Anyways, that´s off-topic. Thanks.
Re: Postfix not sending using TLS
as you can see, psg.com says ESMTP which indicates that it speaks ESMTP. EHLO salsa.gih.co.uk 500 unrecognized command but firewall or proxy doesn't. old code, old behaviour. The error in your previous dump was an indication (unrecognized command). psg.com exim server would have said STARTTLS command used when not advertised. check your docs on how to disable smtp filtering in your firewall (look for somthing like no ip inspect name yourrulename smtp...). That solved it! Thank you very much to you Noel. O. -- Olivier MJ Crepin-Leblond, Ph.D. E-mail:[EMAIL PROTECTED] | http://www.gih.com/ocl.html
