Tag Info

Hot answers tagged

7

The giveaway is here: -- active services in /etc/postfix/master.cf -- # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) smtp inet n - - - - smtpd submission inet n - - - - smtpd The smtpd process on the submission ...


6

You need pcre regex compiled in Postfix. Or the distribution already includes pcre. postconf -m should show a line with pcre in it. And then you can do: /etc/postfix/login_maps.pcre: /^(.*)@example.org$/ ${1} In main.cf: smtpd_sender_login_maps = pcre:/etc/postfix/login_maps.pcre Should work fine as expected. If not let me know so that I edit it ...


6

It would appear that you are hosting an SMTP server that is attempting to perform delivery directly to Internet hosts. The IP you're hosting that server from, a Comcast client IP address, is on the Spamhaus Policy Block List (PBL). That's the root cause of your problem. Comcast has registered their client IP addresses with Spamhaus because, as a matter of ...


6

you have smtpd_recipient_restrictions twice, and the last one is the one being used and it does not have permit_sasl_authenticated


5

There is virtually no way to do this within IIS 7.5 (or any version of IIS for that matter). There may be a way to hack it if you write your own module, however that's not so much an IIS hack as it is your own hack that plugs into IIS. There are third party tools that exist to perform this. For example, EA DomainKeys/DKIM for IIS SMTP Service and Exchange ...


4

This means that the client's trying and failing to authenticate, but the server doesn't require authentication to send. Regarding security of the server, it depends how the rest of the policies on the SMTP server are configured, but it certainly warrants a closer look; the server may be filtering on source IP, or by recipient domain, but if it's not, then ...


4

Well, from what I see in your posted configuration you never set Dovecot's auth_mechanisms = plain login, thus the default of auth_mechanisms = plain is used. Try updating that setting and restarting Dovecot, afterwards re-check the output of doveconf -n. Your auth socket settings seem correct to me, Postfix should be able to do SASL authentication against ...


4

The helo name of the attacker is invalid (ylmf-pc) because it's neither a FQDN, nor resolvable via DNS, so you can easily get rid of it earlier, by blocking him after the invalid EHLO is sent. To do this with postfix, for example, do: smtpd_helo_restrictions = permit_mynetworks, check_helo_access reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, ...


3

That idiosyncratic and invalid EHLO argument "ylmf-pc" is a known fingerprint of a widespread spamming botnet known as "PushDo" (and sometimes alternatively "Cutwail"). As shown in your transcript, it is mostly trying password guessing to authenticate and send mail through your server. Keeping it from sending spam to or through your server is easy, because ...


3

You currently have two contradictory lines in your m4: define(`confAUTH_OPTIONS', `A')dnl define(`confAUTH_OPTIONS', `A p')dnl Assuming the second of these takes precedence, the p flag tells sendmail not to offer authentication unless encryption is in place, which means you will need to have TLS up and running to be offered authentication. Here's a ...


3

(Based on log entries provided in comment) ... No such file or directory:bss_file.c:169:fopen('/etc/postfix/cacert.pem','r'): ... cannot load Certificate Authority data: disabling TLS support ... host smtp.gmail.com[173.194.68.109] said: 530 5.7.0 Must issue a STARTTLS command first 0 Fix your smtp_tls_CAfile Check Postfix: Configuring Gmail as ...


3

You can have saslauthd installed but not have any mechanisms installed. It's quite frustrating and poor error-proofing, IMO. "no applicable SASL mechanisms" literally means it can't find any of its mechanisms. On a Fedora-based system you'd need to install the cyrus-sasl-plain package if you want to use the 'PLAIN' auth mechanisms (i.e. SMTP/STARTTLS). ...


3

You allow relaying from 0/0 in main.cf main.cf mynetworks = 0.0.0.0/0 [::/0] smtpd_relay_restrictions = permit_mynetworks smtpd_client_restrictions = permit_mynetworks


3

How about putting your SMTP AUTH on another port like 587, and using iptables to restrict access to that port? 587 isn't a hidden port, it's an RFC defined mail submission port. Mail to you arrives on 25, mail through you needs to go over 587. http://tools.ietf.org/html/rfc6409


3

Your email client didn't actually authenticate. Are you sure you have correctly configured Outlook to connect to port 587 and given it a username and password?


3

This is actually more of a sasl question than a Postfix question. You've got postfix set up to talk to sasl - so far, so good. Now you need to tell saslauthd where to find your usernames and password. If you don't give it any arguments, it will default to treating them as local users, which is what you're seeing in your auth.log. As far as I know (which may ...


3

I have the same problem. And it causes problems if the email is sent to a group rather than to an individual. The Exchange server won't send to groups if the message is not AUTH'd. But if postfix has been set to authenticate by logging on, why is the email not AUTH'd? Clue: If you use telnet to send the mail the email will be AUTH'd. the header that the ...


3

Just because you auth with your mailserver has no bearing on whether or not the mailserver you're sending to will subsequently get rejected. The entry in the PBL for the IP address (given in the link in the bounce message) gives a clear description of the problem and it's solution (relay through Comcast's mail server).


3

We use the following rules in acl_check_rcpt, but I suspect they would work better in acl_check_helo deny condition = ${if and{{eq{$interface_port}{587}} {eq{$tls_cipher}{}} } } message = All port 587 connections must use TLS deny condition = ${if eq{$interface_port}{587}} !authenticated = * message = All port 587 ...


3

From the Exim manual (section 38.1). Hope this helps: You can insist that any client that uses the AUTH command for authentication must start a TLS session first, by setting auth_over_tls_hosts. For example, auth_over_tls_hosts = * means that all authentication must take place over secure sessions. This setting does not force the ...


3

Ok thanks all I found nullmailer is the software I was looking for. It is a ubuntu package which can deliver mail on behalf of a software to the corporate mail server with authentication as a user.As I can not run a MTA so nullmailer suits my needs.


3

saslauthd can handle only PLAIN and LOGIN authentication methods but you have disabled plaintext with smtpd_sasl_security_options. Also you have typo in your config - smtpd_sasl_path statement is duplicated, it seems first one should be typed as smtpd_sasl_type instead. Check http://www.postfix.org/SASL_README.html for additional details.


2

If you want the SMTP connection from your MTA to mailhost.zen.co.uk to be SASL auth'd, you want the smtp_sasl_* parameters, not the smtpd_sasl_* parameters. The latter is for when you're the receiving MTA, while the former are for when you're connecting to another MTA, as you appear to want to do here.


2

Point it at one of your MX servers. If those don't accept unauthenticated mail something is very wrong (or you intentionally don't receive mail from the internet). Then you just have to worry about getting the message past your spam filters. You could also alter your MTA to accept without auth from that devices IP address.


2

I would try something like this: /etc/postfix/main.cf: smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access_table, ..., permit /etc/postfix/access_table: mydomain.com REJECT You're not me! The theory is this: If they've authenticated already, they trigger ...


2

Two things: It's not a DNS problem. A. You're trying to send email THROUGH your server to another domain, and your server doesn't allow unathenticated relaying (which it shouldn't, in which case this is the expected and desired behavior). OR B. You're trying to send email TO an internal recipient using an email address which your server isn't configured ...


2

It looks like your Roundcube installation doesn't support CRAM-MD5, which is the only mechanism offered by Postfix. I would probably just enable the PLAIN and LOGIN mechanisms and use those. You probably have a line like this in /etc/postfix/main.cf: smtpd_sasl_security_options = noanonymous, noplaintext Change this to read: smtpd_sasl_security_options = ...


2

chroot is defnitely the reason, however for my case, copying to /var/spool/postfix/etc did not work. So I just got rid of chroot and that works for me. n order to do that you will need to edit /etc/postfix/master.cf locate the following line: smtp inet n - - - - smtpd and modify it as follows: smtp inet n ...


2

the solution was very simple, the SASL daemon was down. /etc/init.d/saslauthd start Some hacker managed to shut it down again and again so eventually I had closed it completely.


2

They are trying to exploit a bad configuration and not getting the message to stop trying when they find it (those are the 450 status messages). This is normal background hacking, and it is being handled correctly.



Only top voted, non community-wiki answers of a minimum length are eligible