[pfx] Forward mail
Hallo, Unfortunately, I have quite a few customers who want to receive email from their own domain at a different email address, such as a Gmail or Hotmail address. I forward this in /etc/postfix/virtual. But I actually don't understand why this arrives, especially if the sender has an SPF or DMARC clearly states that it should be rejected if the email comes from the wrong IP. Perhaps Gmail and others don't care about that, but it could also be that they look beyond the forward address and see that it comes from a legitimate IP, but only forwarded is. That would be good, but maybe easily forged without DKIM? Could someone tell us more about this? And what is a good solution for forwarding? Rewrite the sender? SRS? With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Aliases with "@" in it
Op 09-04-2024 om 12:57 schreef Matus UHLAR - fantomas via Postfix-users: virtual_alias_maps and alias_maps have slightly different capabilities virtual_alias_maps - is processed when mail is being received - can be used to rewrite ANY destination mail address (including non-local recipients) - can be (usually is) used at SMTP level to validate recipients alias_maps - is used when delivering mail to local recipients - can include recipients from file - can feed mail to a program or a file - can change mail sender when "alias" is the recipient and "owner-alias" exists Preferrably use virtual_alias_maps, but if you need any of alias_maps features, use that one. Thanks for your explanation! With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Aliases with "@" in it
Op 09-04-2024 om 11:46 schreef Jaroslaw Rafa via Postfix-users: Dnia 9.04.2024 o godz. 11:11:31 Paul van der Vlis via Postfix-users pisze: When I want to make an alias, I try this in /etc/aliases: "al...@domain.nl": j...@domain.nl But when I sent mail, I get a bounce with "user unknown". When I do this in /etc/aliases: alias: j...@domain.nl This works fine, but for all domains on this server. And that's not what I want. Do you know a way how to use aliases with an @ in it? You can't do it alias_maps= table (which by default points to /etc/aliases file). You should use virtual_alias_maps= table in main.cf file and define the aliases there. Thanks, it works. I thought I would not need this file anymore. Bye, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Aliases with "@" in it
Hello, I am switching to usernames with an @ in it, like: j...@domain.nl When I want to make an alias, I try this in /etc/aliases: "al...@domain.nl": j...@domain.nl But when I sent mail, I get a bounce with "user unknown". When I do this in /etc/aliases: alias: j...@domain.nl This works fine, but for all domains on this server. And that's not what I want. Do you know a way how to use aliases with an @ in it? BTW: I use Cyrus IMAP. In Postfix: mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Different rules for submission(s)
Hello Viktor, Thanks for your quick answer! See my inline response: Op 25-01-2024 om 20:40 schreef Viktor Dukhovni via Postfix-users: On Thu, Jan 25, 2024 at 08:31:44PM +0100, Paul van der Vlis via Postfix-users wrote: Hello, Since over 20 years I use Postfix, but some things I don't understand... I want different rules for mail what comes through submission(s) and what comes from other mailservers using port 25. What is the correct way to do that? From the stock master.cf file (see also the master(5) manpage and/or <https://www.postfix.org/master.5.html>): # Choose one: enable submission for loopback clients only, or for any client. #127.0.0.1:submission inet n - n - - smtpd #submission inet n - n - - smtpd Normally I've removed the # before submission. # -o syslog_name=postfix/submission # -o smtpd_tls_security_level=encrypt # -o smtpd_sasl_auth_enable=yes # -o smtpd_tls_auth_only=yes # -o local_header_rewrite_clients=static:all # -o smtpd_reject_unlisted_recipient=no # Instead of specifying complex smtpd__restrictions here, # specify "smtpd__restrictions=$mua__restrictions" # here, and specify mua__restrictions in main.cf (where # "" is "client", "helo", "sender", "relay", or "recipient"). # -o smtpd_client_restrictions= # -o smtpd_helo_restrictions= # -o smtpd_sender_restrictions= # -o smtpd_relay_restrictions= # -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING # Choose one: enable submissions for loopback clients only, or for any client. #127.0.0.1:submissions inet n - n - - smtpd #submissions inet n - n - - smtpd And here too. # -o syslog_name=postfix/submissions # -o smtpd_tls_wrappermode=yes # -o smtpd_sasl_auth_enable=yes # -o local_header_rewrite_clients=static:all # -o smtpd_reject_unlisted_recipient=no # Instead of specifying complex smtpd__restrictions here, # specify "smtpd__restrictions=$mua__restrictions" # here, and specify mua__restrictions in main.cf (where # "" is "client", "helo", "sender", "relay", or "recipient"). # -o smtpd_client_restrictions= # -o smtpd_helo_restrictions= # -o smtpd_sender_restrictions= # -o smtpd_relay_restrictions= # -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING I understand what you mean. But what is after this? Are then the lines in main.cf used, like smtpd_relay_restrictions or smtpd_milters? And where is the point that the mail is accepted? E.g. I don't want a check on blacklists on the submission ports. And I don't want authentication on port 25. And what about milters, how can I configure them so that they are only used for e.g. SMTP on port 25? I have, for example: submission inet n - n - - smtpd -o smtpd_milters= -o smtpd_sasl_auth_enable=yes ... This is interesting for me, I would expect such lines here. But in the examples they are not there. And maybe end with "-o permit" ? with a non-empty set of milters (default, so simply ommitted smtpd_sasl_auth_enable=no) in main.cf Welcome to master.cf overrides, congratulations on managing to get by without them for 20 years. ;-) And what about lines for port 25. Better to put them in master.cf? What's left for main.cf then? Only the mail from localhost? Or is "smtpd_relay_restrictions =" not used for incoming mail from submission(s)? With regards, Paul. -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Different rules for submission(s)
Hello, Since over 20 years I use Postfix, but some things I don't understand... I want different rules for mail what comes through submission(s) and what comes from other mailservers using port 25. What is the correct way to do that? E.g. I don't want a check on blacklists on the submission ports. And I don't want authentication on port 25. And what about milters, how can I configure them so that they are only used for e.g. SMTP on port 25? E.g. I don't want SPF checking on the submission-ports. Or do I think wrong? With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: before-queue Milter support
Op 16-11-2022 om 17:19 schreef Wietse Venema: Paul van der Vlis: Hello Wietse and others: Op 16-11-2022 om 15:36 schreef Wietse Venema: Paul van der Vlis: Is there a way to get it refused before-queue? Yes. IF A MILTER REJECTS A MESSAGE then Postfix will not accept it. So far I see the message is queued as C6E2F880CEC: THEN, the Milter DID NOT REJECT the message. You are right, the problem was not in Postfix but in the configuration of the milter. See for details my reply to Matus. With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: before-queue Milter support
Hello Matus and others, Op 16-11-2022 om 17:40 schreef Matus UHLAR - fantomas: from clamav-milter.conf man page: OnInfected STRING Action to be performed on infected messages Default: Quarantine set it to reject: OnInfected Reject Ah, that was the point, now it works. Thanks for your help! With regards, Paul van der Vlis root@hosting:~# echo "Test virus body" | mutt -a eicar.com.txt -s "This is virus8" -- p...@vandervlis.nl root@hosting:~# less /var/log/mail.log root@hosting:~# grep 74D3C2304A /var/log/mail.log Nov 16 18:29:58 hosting postfix/pickup[2114568]: 74D3C2304A: uid=0 from= Nov 16 18:29:58 hosting postfix/cleanup[2117871]: 74D3C2304A: message-id= Nov 16 18:29:58 hosting postfix/qmgr[897]: 74D3C2304A: from=, size=742, nrcpt=1 (queue active) Nov 16 18:30:00 hosting postfix/smtp[2117877]: 74D3C2304A: to=, relay=server.vandervlis.nl[45.95.238.187]:25, delay=2.2, delays=0.03/0.02/0.12/2, dsn=5.7.1, status=bounced (host server.vandervlis.nl[45.95.238.187] said: 550 5.7.1 Command rejected (in reply to end of DATA command)) Nov 16 18:30:00 hosting postfix/bounce[2117879]: 74D3C2304A: sender non-delivery notification: A0F3823051 Nov 16 18:30:00 hosting postfix/qmgr[897]: 74D3C2304A: removed Nov 16 18:29:58 server postfix/smtpd[64087]: connect from hosting.vandervlis.nl[91.198.178.59] Nov 16 18:29:58 server postfix/smtpd[64087]: Anonymous TLS connection established from hosting.vandervlis.nl[91.198.178.59]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 Nov 16 18:30:00 server policyd-spf[64093]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=91.198.178.59; helo=hosting.vandervlis.nl; envelope-from=r...@hosting.vandervlis.nl; receiver= Nov 16 18:30:00 server postfix/smtpd[64087]: 857F9880C56: client=hosting.vandervlis.nl[91.198.178.59] Nov 16 18:30:00 server postfix/cleanup[64094]: 857F9880C56: message-id= Nov 16 18:30:00 server clamav-milter[63727]: Message 857F9880C56 from to with subject 'This is virus8' message-id '' date 'Wed, 16 Nov 2022 18:29:58 +0100' infected by Eicar-Signature Nov 16 18:30:00 server postfix/cleanup[64094]: 857F9880C56: milter-reject: END-OF-MESSAGE from hosting.vandervlis.nl[91.198.178.59]: 5.7.1 Command rejected; from= to= proto=ESMTP helo= Nov 16 18:30:00 server postfix/smtpd[64087]: disconnect from hosting.vandervlis.nl[91.198.178.59] ehlo=2 starttls=1 mail=1 rcpt=1 data=0/1 quit=1 commands=6/7 -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: before-queue Milter support
Hello Wietse and others: Op 16-11-2022 om 15:36 schreef Wietse Venema: Paul van der Vlis: Is there a way to get it refused before-queue? Yes. IF A MILTER REJECTS A MESSAGE then Postfix will not accept it. So far I see the message is queued as C6E2F880CEC: root@hosting:~# echo "Test virus body" | mutt -a eicar.com.txt -s "This is virus6" -- p...@vandervlis.nl root@hosting:~# less /var/log/mail.log root@hosting:~# grep C6E2F880CEC /var/log/mail.log Nov 16 14:10:41 hosting postfix/smtp[2091127]: 9A98D22A1B: to=, relay=server.vandervlis.nl[45.95.238.187]:25, delay=3.3, delays=0.02/0/0.12/3.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C6E2F880CEC) root@server:~# grep C6E2F880CEC /var/log/mail.log Nov 16 14:10:41 server postfix/smtpd[61278]: C6E2F880CEC: client=hosting.vandervlis.nl[91.198.178.59] Nov 16 14:10:41 server postfix/cleanup[61285]: C6E2F880CEC: message-id= Nov 16 14:10:41 server clamav-milter[5258]: Message C6E2F880CEC from to with subject 'This is virus6' message-id '' date 'Wed, 16 Nov 2022 14:10:38 +0100' infected by Eicar-Signature Nov 16 14:10:41 server postfix/cleanup[61285]: C6E2F880CEC: milter-hold: END-OF-MESSAGE from hosting.vandervlis.nl[91.198.178.59]: milter triggers HOLD action; from= to= proto=ESMTP helo= With regards, Paul van der VLis -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
before-queue Milter support
Hello,
I try to get mail refused when there is a virus in it, like with
"reject_invalid_hostname" in smtpd_recipient_restrictions.
Clamav-milter works on port 10026, but the mail is always added to the
queue. There it is deleted.
This is what I use at the moment in main.cf:
-
milter_protocol = 6
smtpd_milters =
{ inet:localhost:10026, connect_timeout=30s, default_action=reject }
{ inet:localhost:8891, connect_timeout=30s, default_action=accept }
non_smtpd_milters = $smtpd_milters
Is there a way to get it refused before-queue?
With regards,
Paul van der VLis
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/
Re: Solving reverse DNS problem with Postfix configuration?
Hi Richard, Op 12-04-2022 om 14:07 schreef Richard Rasker: Op 11-04-22 om 18:34 schreef Paul van der Vlis: Hi Richard, ... Eventually you could use my mailserver as a relayhost. That is a very friendly offer, but if I do, that would of course only be temporary, so that I can send e-mail again, and I'd contact you in advance. You need a username and password. That's of course why I would contact you first :-) But according to the information supplied, I should also be able to use smtp.xs4all.nl as a relay host, see https://www.xs4all.nl/eigenmailserver/ (in Dutch -- and I already took care of the Spamhaus delisting). Question: does this solve the PTR record problem? I don't think so, but I did not study it really well. Just to make sure: I guess I need to change my MX record for this to work? For sending e-mail, you don't need to change the MX record. And how does reverse DNS work in this case? Sorry if I ask beginners' questions, but as I said, I never had to get into these details of mail servers and anti-spam measures -- up until yesterday, it 'Just Worked'. You use the DNS & rDNS of the relayhost. (And unfortunately, switching to freedom.nl as a new ISP has one drawback wrt. VOIP -- I can only keep one of our current two phone lines.) Freedom.nl does not have an own VOIP service, the buy it from Voys. I did make a contract direct there: https://www.voys.nl/ I pay 19 euro a month, but calling in the Netherlands is free. And I use this for extra phone numbers: https://www.cheapconnect.nl/voip-nummer-kopen/ Costs is about 9 euro a year for an extra phone number. I use this for phone calls to other countries: https://www.intervoip.com/calling_rates/ You can configure the Fritzbox or something like that to do that automatically, while the other side sees your normal phone number as caller ID. With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Solving reverse DNS problem with Postfix configuration?
Hi Richard, Op 11-04-2022 om 18:20 schreef Richard Rasker: Hi Paul, Op 11-04-22 om 17:40 schreef Paul van der Vlis: [snip] Maybe switch to freedom.nl, they give you a good reverse DNS. Also IPv6. Thanks for the tip; I think that may be a good idea. They're a lot cheaper as well than XS4All/KPN -- I think I'll contact them first thing tomorrow morning to verify if they can indeed provide the services I was used to. Eventually you could use my mailserver as a relayhost. That is a very friendly offer, but if I do, that would of course only be temporary, so that I can send e-mail again, and I'd contact you in advance. You need a username and password. Just to make sure: I guess I need to change my MX record for this to work? For sending e-mail, you don't need to change the MX record. But maybe you need to change the SPF settings, if you have them. Bye, Paul As I mentioned before, I'm not very proficient in mail server administration, mostly because Postfix, once it's up and running, Just Works -- for years on end. Thanks once again, also to all the others who took time to reply, Best regards, Richard -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Solving reverse DNS problem with Postfix configuration?
Op 11-04-2022 om 17:19 schreef Paul van der Vlis: Hi Richard and others, Op 11-04-2022 om 16:52 schreef Richard Rasker: #Set Username and Password smtp_sasl_password_maps = static:Chosen-Username:Chosen-Password What I use is this: smtp_sasl_password_maps = hash:/etc/postfix/saslpasswd And in that file something like: smtp_sasl_password_maps = hash:/etc/postfix/saslpasswd Wrong, must be: mail.vandervlis.nlusername:secret And then: postmap /etc/postfix/saslpasswd I then tried the same with mx.kpnmail.nl -- which is a mail host of my current ISP, which indeed has a valid PTR record, but still no mail appears to get through. So in order to post here, I changed things back for the time being. Perhaps I made a mistake in main.cf? Maybe switch to freedom.nl, they give you a good reverse DNS. Also IPv6. Eventually you could use my mailserver as a relayhost. Bye, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Solving reverse DNS problem with Postfix configuration?
Hi Richard and others, Op 11-04-2022 om 16:52 schreef Richard Rasker: #Set Username and Password smtp_sasl_password_maps = static:Chosen-Username:Chosen-Password What I use is this: smtp_sasl_password_maps = hash:/etc/postfix/saslpasswd And in that file something like: smtp_sasl_password_maps = hash:/etc/postfix/saslpasswd And then: postmap /etc/postfix/saslpasswd I then tried the same with mx.kpnmail.nl -- which is a mail host of my current ISP, which indeed has a valid PTR record, but still no mail appears to get through. So in order to post here, I changed things back for the time being. Perhaps I made a mistake in main.cf? Maybe switch to freedom.nl, they give you a good reverse DNS. Also IPv6. Eventually you could use my mailserver as a relayhost. Bye, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Suggestions for less spam
I am using now much of your setting and it seems to help. Thanks a lot! Op 22-09-19 om 17:59 schreef Dominic Raferd: > On Sun, 22 Sep 2019 at 14:36, Paul van der Vlis wrote: >> >> Hello, >> >> I would like some suggestions on how to get less spam, I will paste my >> configuration at the end of the mail. >> >> Maybe somebody with a nice setup could post his/her setup? >> >> As you can see, I am experimenting with reject_unknown_client_hostname. >> What's your opinion about that setting? >> >> I've never used greylisting. Are you using it? > > I have been tweaking my settings for the last three years largely > based on advice from this list. I give below my (slightly simplified) > smtpd_recipient_restrictions settings for unauthenticated connections > (suggestions for improvement very welcome). I also apply some > header_checks and use spamassassin and clamav (via amavis) with some > bespoke rules. > > I think it is inadvisable to use reject_unknown_client_hostname (risk > of fps) but I have found reject_unknown_reverse_client_hostname very > effective. I tried greylisting but gave it up - it isn't necessary and > the delays were very irritating to users (e.g. for password reset > emails). > > smtpd_recipient_restrictions = > reject_unauth_pipelining > > # localfile whitelists > check_sender_access hash:/etc/postfix/sender_access_whitelist > check_client_access hash:/etc/postfix/client_access_whitelist > check_client_access cidr:/etc/postfix/client_access_whitelist.cidr > check_helo_access hash:/etc/postfix/helo_access_whitelist > > # localfile blacklists > check_sender_access hash:/etc/postfix/sender_access > check_client_access hash:/etc/postfix/client_access > check_helo_access hash:/etc/postfix/helo_access > check_sender_access pcre:/etc/postfix/sender_access.pcre > > # reject clients without PTR > reject_unknown_reverse_client_hostname > > # reject clients with dynamic ips > reject_rbl_client dul.dnsbl.sorbs.net=127.0.0.10 > > # rejections based on rbls for helo/sender/reverse_client > reject_rhsbl_helo dbl.spamhaus.org > reject_rhsbl_sender dbl.spamhaus.org > reject_rhsbl_reverse_client dbl.spamhaus.org > reject_rhsbl_sender fresh.fmb.la=127.2.0.[2;14] > > # ip-based remote whitelists > permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3] > permit_dnswl_client white.uribl.com > permit_dnswl_client hostkarma.junkemailfilter.com=127.0.0.[1;3;5] > > # ip-based remote blacklists > reject_rbl_client zen.spamhaus.org > reject_rbl_client dyna.spamrats.com > reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2 > reject_rbl_client truncate.gbudb.net > reject_rbl_client dnsbl.cobion.com > reject_rbl_client bl.fmb.la=127.0.0.2 > reject_rbl_client b.barracudacentral.org > -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Suggestions for less spam
Op 22-09-19 om 17:59 schreef Dominic Raferd: > I have been tweaking my settings for the last three years largely > based on advice from this list. I give below my (slightly simplified) > smtpd_recipient_restrictions settings for unauthenticated connections > (suggestions for improvement very welcome). I also apply some > header_checks and use spamassassin and clamav (via amavis) with some > bespoke rules. Much thanks for your help. It will take some time to study it. > I think it is inadvisable to use reject_unknown_client_hostname (risk > of fps) but I have found reject_unknown_reverse_client_hostname very > effective. I have heard that more. > I tried greylisting but gave it up - it isn't necessary and > the delays were very irritating to users (e.g. for password reset > emails). I don't like it too. With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Suggestions for less spam
Hello, I would like some suggestions on how to get less spam, I will paste my configuration at the end of the mail. Maybe somebody with a nice setup could post his/her setup? As you can see, I am experimenting with reject_unknown_client_hostname. What's your opinion about that setting? I've never used greylisting. Are you using it? With regards, Paul van der Vlis root@server:~# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes compatibility_level = 2 content_filter = amavis:[127.0.0.1]:10024 inet_interfaces = all inet_protocols = ipv4, ipv6 mailbox_size_limit = 0 mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp message_size_limit = 22400 mydestination = server.vandervlis.nl, server.lokaal.netwerk, localhost.lokaal.netwerk, localhost myhostname = server.vandervlis.nl mynetworks = 127.0.0.1/32 myorigin = /etc/mailname recipient_delimiter = + relayhost = smtp_tls_cert_file = /etc/letsencrypt/live/server.vandervlis.nl/fullchain.pem smtp_tls_key_file = /etc/letsencrypt/live/server.vandervlis.nl/privkey.pem smtp_tls_loglevel = 1 smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/etc/postfix/helo_access, permit smtpd_recipient_restrictions = permit_mynetworks, check_sender_access hash:/etc/postfix/sender_access, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/whitelist, warn_if_reject reject_unknown_client_hostname, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_unauth_destination, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org, check_recipient_access pcre:/etc/postfix/recipient_access, permit smtpd_relay_restrictions = smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_exceptions_networks = $mynetworks smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/live/server.vandervlis.nl/fullchain.pem smtpd_tls_exclude_ciphers = RC4 smtpd_tls_key_file = /etc/letsencrypt/live/server.vandervlis.nl/privkey.pem smtpd_tls_loglevel = 1 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_use_tls = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transportmappings virtual_maps = hash:/etc/postfix/virtual root@server:~# -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Refuse mail from hosts with closed port 25
Op 16-09-19 om 15:25 schreef Scott Kitterman: > On Monday, September 16, 2019 9:17:00 AM EDT Paul van der Vlis wrote: >> I know a provider what is actually using this. I guess only the big >> providers will have different servers for inbound and outbound email, >> and you can make a list of them. > > This is not true. My domain is about as tiny as they come and the inbound > and > outbound servers are different for reasons that make sense to me. I'm sure > I'm > not the only one. The outbound server has a closed port 25? With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/ signature.asc Description: OpenPGP digital signature
Re: Refuse mail from hosts with closed port 25
Op 16-09-19 om 14:53 schreef John Peach: > On 9/16/19 8:47 AM, Paul van der Vlis wrote: >> Hello, >> >> How can I refuse mail from hosts who don't have an open port 25? >> >> What do you think from such a check? > > > DO NOT DO THIS! > > A significant number of installations will use different servers for > inbound and outbound email. I know a provider what is actually using this. I guess only the big providers will have different servers for inbound and outbound email, and you can make a list of them. > What is worth checking, is that the sender has MX records. Hmm, interesting idea! Maybe you have some lines on how to configure this? But, I am affraid many hosting providers will not have a MX record on the hosting server, so you don't get your "forgotten password" from the CMS. With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Refuse mail from hosts with closed port 25
Hello, How can I refuse mail from hosts who don't have an open port 25? What do you think from such a check? Is there more needed? E.g. a list of exceptions for some big providers? Background: I've investigated why somebody did not receive mail from a virtual machine, and I found out her provider (reviced.nl) refuses all mail from a host what does not have port 25 open. I have much problems with spam and I would like to reduce it. -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Open relay, found it
Op 23-10-16 om 13:32 schreef Ansgar Wiechers: > On 2016-10-23 Paul van der Vlis wrote: >> Op 22-10-16 om 18:23 schreef /dev/rob0: >>> The only actual conclusion is that you have failed to put forth the >>> necessary information, as Bill [I think] pointed you to the >>> http://www.postfix.org/DEBUG_README.html#mail link. >> >> The problem is that somebody did send spam using port 587 with a not >> excisting username, and I am interested how that is possible. >> >> sigmund:/var/log# postconf -Mf > > So you finally decided to show the output of "postconf -Mf" and > "saslfinger -s". Good. Now you just need to provide the rest of the > information Bill Cole asked of you 2 days ago: > > - Full output of "postconf -nf". > - Full headers of a sample message (you may obfuscate personal > information about the recipient). > - All log lines associated with that particular message. At the very > least the output of "grep /var/log/mail.log". I am sorry when I did not give the right information. I did read the link, and did what was asked there. > In case you don't know how to find the queue ID in a log message, it's > this part of the log line: > > postfix/smtpd[]: 2758BBF4062: ... > ^^^ > And did you already investigate why the authentication backend considers > "p...@puk.nl" a valid user, as Noel Jones asked? What did you find out? Yes, and I found out that when the username is "p...@puk.nl" SASL actually checks on "piet": -- saslauthd[19855] :do_auth : auth success: [user=piet] [service=smtp] [realm=puk.nl] [mech=pam] -- I did some more tests, and it seems to be that the spammer actually did know the password. After changing the password, the logging changed: -- saslauthd[20161] :do_auth : auth failure: [user=piet] [service=smtp] [realm=puk.nl] [mech=pam] - With regards, Paul van der Vlis. -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: permit after all
Op 22-10-16 om 19:49 schreef L.P.H. van Belle: > paul, check if there are messages still in queue. I've cleaned the queue every minute using crontab, removing the mail from that specific recipient. > i had a comprimized account also and same as you it didnt stop. it did > after clearing up the queue list. > > the user in question has used its email and pass om a website which was > omprimized, at least thats what i think. No, I know the user. He is working for me. And the "authenticated username" does not excist on the server as a user what can authenticate. Only as an e-mail address. > i my case i allow my users only from specific countries for smtp, > limited by firewalling. (xtables geoip) My customers go in holliday or work in other countries. > i also use zpush (active sync) through webserver, for mobile devices for > other countrie support. > > not a fix, but help avoiding this problem is abuse. > > and check if you landed on black lists. I am. But I am not sure I can delist, because I don't know how they did it. Maybe they start again. With regards, Paul van der Vlis. -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Open relay
Op 22-10-16 om 21:12 schreef Noel Jones: > On 10/22/2016 1:30 PM, Paul Schmehl wrote: > >> He's clearly doing something very clever that is not the usual brute >> force cram-it-down-your-throat spam run. > > No evidence has been presented that this is anything other than the > usual leaked-credentials account hijacking. Any confusion is due to > a lack of information. The "Authenticated sender" does not excist as a user account. It is an correct e-mail address, but not an user account with what you can authenticate. > Postfix logs the sasl username presented by the spammer. Hopefully > the sasl backend logging will show why this name is unexpectedly > accepted, and is almost certainly not a bug or exploit. I will look for a sasl backend logging method. The spammers are still trying. Every time from another IP, so I cannot log on a specific IP. With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Open relay
Op 22-10-16 om 18:23 schreef /dev/rob0:
> On Sat, Oct 22, 2016 at 04:15:41PM +0200, Paul van der Vlis wrote:
> The only actual conclusion is that you have failed to put forth the
> necessary information, as Bill [I think] pointed you to the
> http://www.postfix.org/DEBUG_README.html#mail link.
The problem is that somebody did send spam using port 587 with a not
excisting username, and I am interested how that is possible.
sigmund:/var/log# postconf -Mf
smtp inet n - - - - smtpd -v
26 inet n - - - - smtpd
465inet n - - - - smtpd
submission inet n - - - - smtpd
pickup fifo n - - 60 1 pickup
cleanupunix n - - - 0 cleanup
qmgr fifo n - - 300 1 qmgr
rewriteunix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
showq unix n - - - - showq
error unix - - - - - error
local unix - n n - - local
virtualunix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
maildrop unix - n n - - pipe flags=DRhu
user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
uucp unix - n n - - pipe flags=Fqhu
user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix - n n - - pipe flags=F
user=ftn
argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe flags=Fq.
user=bsmtp argv=/usr/lib/bsmtp/bsmtp -d -t$nexthop -f$sender $recipient
scalemail-backend unix - n n - 2 pipe flags=R
user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop}
${user} ${extension}
amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
shadelist unix - n n - - spawn user=nobody
argv=/usr/bin/perl /usr/local/bin/shadelist.pl -w
nlwhitelist.dnsbl.bit.nl
tlsmgr unix - - - 1000? 1 tlsmgr
scache unix - - - - 1 scache
discardunix - - - - - discard
retry unix - - - - - error
-
sigmund:/var/log# saslfinger -s
saslfinger - postfix Cyrus sasl configuration zo okt 23 00:09:27 CEST 2016
version: 1.0.4
mode: server-side SMTP AUTH
-- basics --
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
Postfix: 2.11.3
System: Debian GNU/Linux 8 \n \l
-- smtpd is linked to --
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
libsasl2.so.2 => /usr/lib/i386-linux-gnu/libsasl2.so.2 (0xb73d1000)
-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
smtpd_tls_loglevel = 1
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_use_tls
Re: Open relay
Op 22-10-16 om 18:23 schreef /dev/rob0: > On Sat, Oct 22, 2016 at 04:15:41PM +0200, Paul van der Vlis wrote: >> Is the conclusion now, that Postfix is relaying here? > > The only actual conclusion is that you have failed to put forth the > necessary information, as Bill [I think] pointed you to the > http://www.postfix.org/DEBUG_README.html#mail link. Thanks, I did oversee that hint and I will study the page. At the moment no spam is coming in anymore. > What appears to be most likely, if we were given adequate > information, is that an account has been compromised, and a botnet > uses those credentials to relay spam through you. Strange is, that the "Authenticated sender" account does not excist. What does exist is an account for that mailadres and another account for the part for the "@", but I've changed the password of both and the spam did not stop. With regards, Paul van der Vlis. -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Open relay
Op 22-10-16 om 13:41 schreef Wietse Venema: > Bill Cole: >>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi >>> [87.92.55.206]) >>> (Authenticated sender: p...@puk.nl) >>> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285; >>> Fri, 21 Oct 2016 18:57:14 +0200 (CEST) >>> >>> As would my server sent it to my server... >> >> Not exactly. That Received header indicates that the machine at >> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi >> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and >> proceeded to authenticate as the user whose name you've replaced with >> p...@puk.nl. > > Thanks, I missed that. Is the conclusion now, that Postfix is relaying here? With regards, Paul van der Vlis. -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Open relay
Op 22-10-16 om 04:32 schreef Bill Cole: > On 21 Oct 2016, at 16:15, Paul van der Vlis wrote: >> >> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi >> [87.92.55.206]) >> (Authenticated sender: p...@puk.nl) >> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285; >> Fri, 21 Oct 2016 18:57:14 +0200 (CEST) >> >> As would my server sent it to my server... > > Not exactly. That Received header indicates that the machine at > 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi > introduced itself with "EHLO [127.0.0.1]" on an encrypted session and > proceeded to authenticate as the user whose name you've replaced with > p...@puk.nl. > > As a stopgap, you could add a directive like this to > smtpd_helo_restrictions: > >check_helo_access pcre:/etc/postfix/helo_checks > > And in that helo_checks file; > > /127\.0\.0\.1/REJECT you are not me Thanks, a great idea to have standard in most cases. > This will catch and reject formally correct IP literals as in this case > and the more common bare IP form of claiming to be localhost. There's no > reason for any mail client ever to say "EHLO [127.0.0.1]" except to > cause a MTA to generate a confusing Received header. Right. With regards, Paul van der Vlis. -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Open relay
Op 22-10-16 om 08:18 schreef Tomoyuki Murakami: > > On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis > wrote: >> Hello, > >> Some settings and logs: >> >> smtpd_relay_restrictions = >> permit_mynetworks, >> permit_sasl_authenticated, >> check_sender_access hash:/etc/postfix/whitelist, >> reject_invalid_hostname, >> reject_non_fqdn_sender, >> reject_non_fqdn_recipient, >> reject_unknown_sender_domain, >> reject_unknown_recipient_domain, >> reject_unauth_pipelining, >> reject_unauth_destination, >> check_policy_service unix:private/shadelist, >> reject_rbl_client bl.spamcop.net, >> reject_rbl_client zen.spamhaus.org, >> reject_rbl_client ix.dnsbl.manitu.net, >> permit > > permit after all ? Yes, I looked at it yesterday, and I am not sure about it. But I am using this kind of setup allready for a really long time (16 years?), so I think it will be right. But maybe I don't understand the logic completely, and do I have to study more on the "firewall rules logic of Postfix". With regards, Paul van der Vlis. -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/ signature.asc Description: OpenPGP digital signature
Re: Open relay
Op 22-10-16 om 01:46 schreef Wietse Venema: > Paul van der Vlis: >> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206]) >> (Authenticated sender: p...@puk.nl) >> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285; >> Fri, 21 Oct 2016 18:57:14 +0200 (CEST) > > That is NOT RELAYING. That is receiving mail from a process that > runs on the same machine. This can happen when the machine runs a > bad web application. Thank you for your help! Receiving mail from a web application is something what I have checked, but I did not found anything in the Apache logs. And I see traffic on port 587 from bad IP's when I log the firewall. I did also turn off Apache for a while, and I still saw spam coming in. I will investigate further, there are 3 web applications running on the machine. What I did yesterday night what stopped the spam, is blocking the mail from a specific sender (p...@puk.nl in my example) using check_sender_access: smtpd_recipient_restrictions = permit_mynetworks, check_sender_access hash:/etc/postfix/sender_access, permit_sasl_authenticated, (...) The strange thing is that the username they use for authentication (p...@puk.nl) is not a correct username. So maybe they will come in some time later with another fake-username... With regards, Paul van der Vlis. -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Open relay
Op 22-10-16 om 01:31 schreef li...@lazygranch.com: > Perhaps I'm being a bit anal here, and given my skill level (or lack > thereof) I should stay of of this, but is this actually an open relay in > the strict sense? Maybe that is a red herring. If they are using 587, > that would be the master.cf file, not main.cf. > > submission inet n - n - - smtpd > -o syslog_name=postfix/submission > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes > -o smtpd_reject_unlisted_recipient=no > -o smtpd_relay_restrictions=permit_sasl_authenticated,reject > -o milter_macro_daemon_name=ORIGINATING This is the only thing what I have: submission inet n - - - - smtpd Is this wrong? I would like it to set rules for every port separate, but I didn't do it till now. With regards, Paul van der Vlis. -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Open relay
Hello Angelo and others, Op 21-10-16 om 22:24 schreef Fazzina, Angelo: > So what is SASL using in Postfix ? > Is Postfix calling SASL, which calls PAM, which calls LDAP, to check the > Password? Postfix is calling saslauthd, which calls PAM, which calls unix passwords. > You must follow the trail of how they got the password if you say you changed > it and it does not help. I don't think they have a correct username/password combination, because the username is wrong. Maybe it's possible to log the username/password Postfix get? Maybe they are using some kind of trick to let Postfix think the mail comes from localhost. With regards, Paul van der Vlis. > -ALF > > -Angelo Fazzina > Operating Systems Programmer / Analyst > University of Connecticut, UITS, SSG-Linux/ M&C > 860-486-9075 > > -Original Message- > From: owner-postfix-us...@postfix.org > [mailto:owner-postfix-us...@postfix.org] On Behalf Of Paul van der Vlis > Sent: Friday, October 21, 2016 4:16 PM > To: postfix-users@postfix.org > Subject: Open relay > > Hello, > > I have a big problem, someone is using my mailserver for sending spam. I > see it in de logs. I can block the IP but then they use other IP's. > > So far I know my server is up-to-date and correct configured. And when I > do some open relay tests, everything is OK. Like this ones: > http://www.mailradar.com/openrelay/ > http://mxtoolbox.com/diagnostic.aspx > > The name of my mailserver is mail.vandervlis.nl, so far I see the > spammers are using port 587. Please feel free to do tests. > > What I see in the logs and in the headers of the spam is that they are > using authentication. But the username is not correct. On my server I > use usernames like "john", and this username lookslike an e-mail > address, so with an "@" in it. The part before the @ is a correct > username on my server, but when I change the password it does not help. > All spam is recognizeble by this authenticated username. > > In the headers I see this as the first "received" (I've changed the > authenticated sender for privacy): > > Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206]) > (Authenticated sender: p...@puk.nl) > by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285; > Fri, 21 Oct 2016 18:57:14 +0200 (CEST) > > As would my server sent it to my server... > > Does somebody have a clou here? > > With regards, > Paul van der Vlis. > > > Some settings and logs: > > smtpd_relay_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > check_sender_access hash:/etc/postfix/whitelist, > reject_invalid_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_unauth_pipelining, > reject_unauth_destination, > check_policy_service unix:private/shadelist, > reject_rbl_client bl.spamcop.net, > reject_rbl_client zen.spamhaus.org, > reject_rbl_client ix.dnsbl.manitu.net, > permit > > smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem > smtpd_use_tls = yes > smtpd_sasl_auth_enable = yes > smtpd_sasl_exceptions_networks = $mynetworks > smtpd_tls_loglevel = 1 > smtpd_tls_auth_only = yes > smtpd_sasl_security_options = noanonymous > smtpd_sasl_tls_security_options = noanonymous > broken_sasl_auth_clients = yes > smtpd_sasl_authenticated_header = yes > > Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B: > client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=p...@puk.nl > > -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Open relay
Hello, I have a big problem, someone is using my mailserver for sending spam. I see it in de logs. I can block the IP but then they use other IP's. So far I know my server is up-to-date and correct configured. And when I do some open relay tests, everything is OK. Like this ones: http://www.mailradar.com/openrelay/ http://mxtoolbox.com/diagnostic.aspx The name of my mailserver is mail.vandervlis.nl, so far I see the spammers are using port 587. Please feel free to do tests. What I see in the logs and in the headers of the spam is that they are using authentication. But the username is not correct. On my server I use usernames like "john", and this username lookslike an e-mail address, so with an "@" in it. The part before the @ is a correct username on my server, but when I change the password it does not help. All spam is recognizeble by this authenticated username. In the headers I see this as the first "received" (I've changed the authenticated sender for privacy): Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206]) (Authenticated sender: p...@puk.nl) by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285; Fri, 21 Oct 2016 18:57:14 +0200 (CEST) As would my server sent it to my server... Does somebody have a clou here? With regards, Paul van der Vlis. Some settings and logs: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/whitelist, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_unauth_destination, check_policy_service unix:private/shadelist, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, permit smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem smtpd_use_tls = yes smtpd_sasl_auth_enable = yes smtpd_sasl_exceptions_networks = $mynetworks smtpd_tls_loglevel = 1 smtpd_tls_auth_only = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_sasl_authenticated_header = yes Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B: client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=p...@puk.nl -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/ -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
