Disable unauthenticated sending of OUTGOING email for all local users

[Ignacio García]

Hello there, and thanks so much for your help


I've got a web+mail server in the same machine. PHP's mail function is 
disabled, but other 3rd party functions such as PHPMailer can use 
sendmail to potentially send emails, as if I was invoking it from a shell



echo hello | sendmail m...@email.com


where email.com is an outside domain


I've been all morning browsing through postfix docs and googling around 
finding an answer to prevent sending unauthenticated email to OUTSIDE 
DESTINATIONS ONLY and pretty much all I found is removing 
'permit_mynetworks' all over main.cf . However, and since I'm not an 
expert at all,  I'm still not sure that's the correct way to act. Could 
anybody please confirm that, or offer a better suggestion?



Thanks so much in advance


Ignacio


This is my postconf -n output:


address_verify_negative_refresh_time = 60s
address_verify_sender_ttl = 15686s
alias_database = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
append_dot_mydomain = no
biff = no
body_checks = regexp:/etc/postfix/body_checks
broken_sasl_auth_clients = yes
compatibility_level = 2
default_extra_recipient_limit = 50
dovecot_destination_recipient_limit = 1
duplicate_filter_limit = 50
enable_original_recipient = no
greylisting = check_policy_service inet:127.0.0.1:10023
header_checks = regexp:/etc/postfix/header_checks
html_directory = /usr/share/doc/postfix/html
in_flow_delay = ${stress?{3}:{1}}s
inet_interfaces = all
inet_protocols = all
mailbox_size_limit = 0
maildrop_destination_concurrency_limit = 1
maildrop_destination_recipient_limit = 1
message_size_limit = 53687091200
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_protocol = 6
mime_header_checks = regexp:/etc/postfix/mime_header_checks
mydestination = s0.cibernetik.net, localhost, localhost.localdomain
myhostname = s0.cibernetik.net
mynetworks = 127.0.0.0/8 [::1]/128
myorigin = /etc/mailname
nested_header_checks = regexp:/etc/postfix/nested_header_checks
non_smtpd_milters = inet:localhost:11332
owner_request_special = no
proxy_read_maps = $local_recipient_maps $mydestination 
$virtual_alias_maps $virtual_alias_domains $sender_bcc_maps 
$virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps 
$relay_domains $canonical_maps $sender_canonical_maps 
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks 
$smtpd_sender_login_maps $virtual_uid_maps $virtual_gid_maps 
$smtpd_client_restrictions $smtpd_sender_restrictions 
$smtpd_recipient_restrictions

readme_directory = /usr/share/doc/postfix
recipient_canonical_classes = envelope_recipient,header_recipient
recipient_canonical_maps = tcp:localhost:10002
recipient_delimiter = +
relay_domains = proxy:mysql:/etc/postfix/mysql-virtual_relaydomains.cf
relay_recipient_maps = 
proxy:mysql:/etc/postfix/mysql-virtual_relayrecipientmaps.cf

relayhost =
sender_bcc_maps = proxy:mysql:/etc/postfix/mysql-virtual_outgoing_bcc.cf
sender_canonical_classes = envelope_sender
sender_canonical_maps = tcp:localhost:10001
smtp_bind_address = 1.2.3.4
smtp_connect_timeout = ${stress?{10}:{30}}s
smtp_destination_concurrency_limit = 2
smtp_destination_rate_delay = 3s
smtp_dns_support_level = dnssec
smtp_extra_recipient_limit = 2
smtp_helo_timeout = ${stress?{10}:{60}}s
smtp_mail_timeout = ${stress?{10}:{60}}s
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_exclude_ciphers = RC4, aNULL
smtp_tls_protocols = !SSLv2,!SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_connection_rate_limit = 10
smtpd_client_message_rate_limit = 100
smtpd_client_recipient_rate_limit = 50
smtpd_client_restrictions = check_client_access 
proxy:mysql:/etc/postfix/mysql-virtual_client.cf, 
permit_inet_interfaces, permit_mynetworks, permit_sasl_authenticated, 
reject_rbl_client zen.spamhaus.org, reject_unauth_pipelining, permit
smtpd_data_restrictions = permit_mynetworks, reject_unauth_pipelining, 
reject_multi_recipient_bounce, permit

smtpd_error_sleep_time = ${stress?{1}:{2}}s
smtpd_etrn_restrictions = permit_mynetworks, reject
smtpd_forbidden_commands = CONNECT,GET,POST,USER,PASS
smtpd_hard_error_limit = ${stress?{1}:{10}}
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname, 
permit_mynetworks, check_helo_access regexp:/etc/postfix/helo_access, 
permit_sasl_authenticated, reject_non_fqdn_helo_hostname, 
check_helo_access regexp:/etc/postfix/blacklist_helo, 
reject_unknown_helo_hostname, permit

smtpd_milters = inet:localhost:11332
smtpd_recipient_limit = 50
smtpd_recipient_overshoot_limit = ${stress?{60}:{600}}
smtpd_recipient_restrictions = check_policy_service 
inet:127.0.0.1:10040, permit_mynetworks, 
reject_unknown_recipient_domain, reject_unlisted_recipient, 
check_recipient_access 
proxy:mysql:/etc/postfix/mysql-verify_recipients.cf, 

SPAM attack from bounce techniques

[Rafael Azevedo]

Hi there,

I've noticed that one of our servers is receiving a huge amount of
unauthorized requests.

User connects to our server and tries to send an email to any destination.
Our servers denies the message because user is not authenticated. Then, a
bounce is generated to the source address, which was fake and turns to be
the final destination, so at the end, the email is actually sent as a
bounce, proliferating lots of spam.

Is there a way to avoid this?

Thanks in advance.

BR,

Rafael

Connection refused / telnet: connect to address 10.5.2.1: Connection refused

[Wolfgang Paul Rauchholz]

I am setting up an email server on my home box with postfix and dovecot
My server is modem router and has as such an internal and external network
interface


*From my laptop (LAN)*From Thunderbird I get the message: Could not connect
to server localhost. The connection was refused.
Testing with telnet from CLI I get
(1) telnet home smtp
Trying 10.5.2.1...
telnet: connect to address 10.5.2.1: Connection refused
(2) telnet home imap
Trying 10.5.2.1...
Connected to home.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.


*Testing from server works fine.*telnet localhost imap
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 home.wo-lar.com ESMTP

The server is listening on port 25, 587 and 465
netstat -plutn | grep 25 and 587
tcp0  0 127.0.0.1:250.0.0.0:*   LISTEN
 28704/master
tcp0  0 127.0.0.1:587   0.0.0.0:*   LISTEN
 21435/smtpd

I can send mails to my gmail account. But when responding to this mail I
get nothing back, not even an error message in gmail (might come later?
I opened the firewall ports too:

Extract from my firewall.

### Allow all Internal traffic to Server
iptables -A INPUT -i $INT_DEV -s $INT_NET -d $INT_NET -j ACCEPT
iptables -A OUTPUT -o $INT_DEV -s $INT_NET -d $INT_NET -j ACCEPT

# New Connection: SMTP and SMTPS (over TLS/SSL)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn
--dport 25 -j ACCEPT
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn
--dport 465 -j ACCEPT

# New Connection: IMAP Email Clients (over SSL and non-encrypted)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --dport
993 -j ACCEPT
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn
--dport 143 -j ACCEPT

# Submission
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --dport
587 -j ACCEPT

Any help to solve this issue is welcome.

Thank you

Wolfgang

AW: SPAM attack from bounce techniques

[ludicree]

Hi Rafael,

 

quick thoughts. Do you have

 

smtpd_recipient_restrictions = reject_unauth_destination

 

in your main.cf?

 

The request should be rejected and not be queued.

 

Greets,

Ludi

 

Von: owner-postfix-us...@postfix.org  Im 
Auftrag von Rafael Azevedo
Gesendet: Dienstag, 29. Dezember 2020 13:38
An: Postfix users 
Betreff: SPAM attack from bounce techniques

 

Hi there,

 

I've noticed that one of our servers is receiving a huge amount of unauthorized 
requests.

 

User connects to our server and tries to send an email to any destination. Our 
servers denies the message because user is not authenticated. Then, a bounce is 
generated to the source address, which was fake and turns to be the final 
destination, so at the end, the email is actually sent as a bounce, 
proliferating lots of spam.

 

Is there a way to avoid this?

 

Thanks in advance.

 

BR,

 

Rafael 

AW: Controlling MS Azure Cloud Spam

[ludicree]

Hi,

 

thanks for your replies.

 

I took a second look at that spam wave and noticed that the scheme

 

1.  Return-Path: 
2.  Empty From Field

 

might not actually be true. The From field often contains something, but no
FQDN.

 

Postfix rejected the spam correctly when pointed at Azure account IDs in the
Received line.

So header checks do apply before "Bounce message. Skip".

 

@Nick

A check for a valid FQDN in From is in smtpd_sender_restrictions.

At the point where it got to bounce message, SPF was skipped. Would
OpenDMARC then still work?

 

@John

It is a Plesk machine. Spamassassin has many implications there. 

I might install it again, but will have to check that all the user mailboxes
do not get altered.

Also I am trying to secure it via postfix only and reject what is unwanted
and discard what should be unknown.

Works out pretty good so far. A permanent field of work, of course.

 

Greets,

Ludi

 

Von: owner-postfix-us...@postfix.org  Im
Auftrag von John Schmerold
Gesendet: Montag, 28. Dezember 2020 03:29
An: Nick Tait ; postfix-users@postfix.org
Betreff: Re: Controlling MS Azure Cloud Spam

 

On 12/27/2020 3:15 PM, Nick Tait wrote:



Hi Ludi.

One option might be to add OpenDMARC to your implementation? The reason for
mentioning this is because in addition to checking DMARC policies, OpenDMARC
also has an option to reject any message that doesn't have the mandatory
headers according to RFC 5322:

RequiredHeaders (Boolean)

If set, the filter will ensure the header of the message conforms to the
basic header field count restrictions laid out in RFC5322, Section 3.6.
Messages failing this test are rejected without further processing. A From:
field from which no domain name could be extracted will also be rejected.

If I understand the RFC correctly this includes the Date and From headers.

Nick.

 

On 26/12/20 6:58 am, ludic...@gmail.com   wrote:

Hi,

 

I am seeing a wave of MS Azure Cloud Spam these days.

 

Many of these mails come with a header:

 

1.  Return-Path: 
2.  Empty From Field

 

They than pass the greylisting filter (and all others it seems) with "Bounce
message. Skip."

 

Is there a way to influence this behaviour?

 

Postfix on debian stretch / no Spamassassin.

 

Greets,

Ludi

 

You don't say why no Spam-assassin, assuming you're not philosophically
opposed to SA, I recommend you add it to the mix.

Proxmox Mail Gateway & MailScanner.info are good implementations

 

Re: Disable unauthenticated sending of OUTGOING email for all local users

[Nick]

On 2020-12-29 12:36 GMT, Ignacio García wrote:
> finding an answer to prevent sending unauthenticated email to OUTSIDE
> DESTINATIONS ONLY and pretty much all I found is removing

Try including permit_mynetworks in smtpd_helo_restrictions and in
smtpd_sender_restrictions, but omit permit_mynetworks from the other
smtpd_*_restrictions.

HTH,
-- 
Nick

Re: Connection refused / telnet: connect to address 10.5.2.1: Connection refused

[Jan Ceuleers]

On 29/12/2020 13:58, Wolfgang Paul Rauchholz wrote:
> I am setting up an email server on my home box with postfix and dovecot
> My server is modem router and has as such an internal and external
> network interface
>
> *>From my laptop (LAN)
> *From Thunderbird I get the message: Could not connect to server
> localhost. The connection was refused.
> Testing with telnet from CLI I get
> (1) telnet home smtp
> Trying 10.5.2.1...
> telnet: connect to address 10.5.2.1 : Connection refused
> (2) telnet home imap
> Trying 10.5.2.1...
> Connected to home.
> Escape character is '^]'.
> * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
> IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

The Thunderbird error message is about a server named localhost
(meaning: the host on which Thunderbird itself is running). Localhost
always resolves to the loopback interface, usually with IP address
127.0.0.1. So your Thunderbird test was irrelevant in that it was
configured to connect to the wrong host.

Your telnet tests suggest that you expect the server to be running and
reachable at IP address 10.5.2.1.

> *Testing from server works fine.
> *telnet localhost imap
> * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
> IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

This test demonstrates that the IMAP server is running on your server
machine and is bound to the localhost IP address (again: typically
127.0.0.1 which resolves to the loopback interface).

>
> telnet localhost smtp
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 220 home.wo-lar.com  ESMTP

Same here.

> The server is listening on port 25, 587 and 465
> netstat -plutn | grep 25 and 587
> tcp        0      0 127.0.0.1:25           
>  0.0.0.0:*               LISTEN      28704/master
> tcp        0      0 127.0.0.1:587           
> 0.0.0.0:*               LISTEN      21435/smtpd

You need to configure your IMAP and SMTP servers to listen on
10.5.2.1:587 and 10.5.2.1:25 respectively. So not localhost.

Re: Connection refused / telnet: connect to address 10.5.2.1: Connection refused

[Jim Reid]

> On 29 Dec 2020, at 12:58, Wolfgang Paul Rauchholz  
> wrote:
> 
> The server is listening on port 25, 587 and 465
> netstat -plutn | grep 25 and 587
> tcp0  0 127.0.0.1:250.0.0.0:*   LISTEN
>   28704/master
> tcp0  0 127.0.0.1:587   0.0.0.0:*   LISTEN
>   21435/smtpd
> 
> I can send mails to my gmail account. But when responding to this mail I get 
> nothing back

That’s to be expected. You seem to have configured postfix to only listen on 
port 25 for the loopback interface (127.0.0.1). If postfix isn’t listening on 
an IP address that’s reachable from the Internet, it’s never going to receive 
any email from the Internet. Check inet_interfaces in main.cf and post the 
output of postconf if you need further help.

postfix should probably be listening on that 10.5.2.1 interface (as well as 
127.0.0.1). But there will be even more to do. 10.5.2.1 is a private IP address 
that isn’t routed on the Internet. See RC1918. So that isn’t reachable either. 
Presumably your DSL or cable box is doing network or port address translation 
to map its real IP address on to 10.5.2.1, the internal one you’ve used on your 
home network. You’ll need to confirm that address translation is working 
correctly for both inbound and outbound packets.

You’ll also need to configure the DNS for your domain name(s) to have MX 
records that ultimately map to that public IP address. If not, the world won’t 
know how to deliver email to you. ie in the zone file for your-domain.com have 
entries like:

your-domain.com. IN MX 20 foo.your-domain.com.
foo.your-domain.com. IN A public-ip-address-goes-here

On your internal network, you’ll need to configure mail clients to connect to 
port 25 on 10.5.2.1 when they send email. Or use the loopback interface if the 
clients run on the same box that’s running postfix. You could do this with a 
split DNS configuration - two versions of your-domain.com, one for the Internet 
and one for your internal net. However based on your questions here, that 
requires a lot more DNS expertise than you appear to have. Questions about that 
belong on a DNS forum and not the postfix mailing list.

BTW Your test connections to 10.5.2.1:imap work because IIRC dovecot listens on 
all available network interfaces by default. postfix has to be told which 
interfaces to listen on port 25 for incoming email.

Re: Javamail connection

[James B. Byrne]

On Fri, December 25, 2020 12:43, John Stoffel wrote:

>
> Why don't you setup a local only postfix instance on the same host as
> the application, which only listed on 127.0.0.1:25, which the dumb
> Java app can then send email through *without encryption*, then let
> the local postfix instance do all the hard work of sending the email
> to other servers using encryption?
>
> It seems like the simpler setup to get working right, and gets most of
> the pain in the Java app out of the way.
>
> John
>

That is reasonable suggestion and is a possibility which I have considered
several times.  However, in this case the application is being evaluated for
its suitability to replace and existing one.  Bypassing this particular problem
with Postfix only exposes the next arising from the application's unwillingness
to accept our certificates.

It is established to my satisfaction that this is not a Postfix issue. 
Therefore,this has to be a configuration issue within the application itself. 
If I do not solve it now then at some point it is going to cause another
problem, likely when we do not have the luxury of time to figure it out.

Regards,

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
   Unencrypted messages have no legal claim to privacy
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: [External] SPAM attack from bounce techniques

[Kevin A. McGrail]

On 12/29/2020 7:37 AM, Rafael Azevedo wrote:

Hi there,

I've noticed that one of our servers is receiving a huge amount of 
unauthorized requests.


User connects to our server and tries to send an email to any 
destination. Our servers denies the message because user is not 
authenticated. Then, a bounce is generated to the source address, 
which was fake and turns to be the final destination, so at the end, 
the email is actually sent as a bounce, proliferating lots of spam.


Is there a way to avoid this?


Hi Rafael, This sounds like backscatter.  To avoid it, you need to 
reject the email during the real-time SMTP dialog with the sender, i.e. 
during the connection from the sender, if it's an invalid recipient, 
reject with 5xx.  This will cause you to tell the sending server and you 
don't generate a bounce.


The question is: Why are you accepting the email, then determining it's 
invalid, and creating a bounce?  I would typically look at some sort of 
architecture issue where you haven't done what we call promoted the 
valid users to the edge of your internet connection.


Hope this helps and share more information for more guidance.


Regards,
KAM

Re: Disable unauthenticated sending of OUTGOING email for all local users

[Wietse Venema]

Ignacio Garc?a:
> Hello there, and thanks so much for your help
> 
> 
> I've got a web+mail server in the same machine. PHP's mail function is 
> disabled, but other 3rd party functions such as PHPMailer can use 
> sendmail to potentially send emails, as if I was invoking it from a shell
> 
> echo hello | sendmail m...@email.com

Unlike submission with SMTP, Postfix has no destination access
controls for email that is submitted with the Postfix sendmail
command.

However, you can disable Postfix sendmail submission from web
applications. There is a documented example:

http://www.postfix.org/postconf.5.html#authorized_submit_users

Wietse

Re: SPAM attack from bounce techniques

[Rafael Azevedo]

Hi there,
Thanks for the reply.

Yes I do:

smtpd_recipient_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unknown_reverse_client_hostname,
  reject_unknown_client_hostname,
  reject_unknown_sender_domain,
  reject_non_fqdn_recipient,
  reject_unauth_destination,
  #reject_unauth_pipelining,
  reject_unverified_recipient,
  reject_unknown_recipient_domain,
  #reject_invalid_hostname,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client sbl-xbl.spamhaus.org,
  check_recipient_access mysql:/etc/postfix/mysql_hold.cf

Huge thanks

Em ter., 29 de dez. de 2020 às 10:28,  escreveu:

> Hi Rafael,
>
>
>
> quick thoughts. Do you have
>
>
>
> smtpd_recipient_restrictions = reject_unauth_destination
>
>
>
> in your main.cf?
>
>
>
> The request should be rejected and not be queued.
>
>
>
> Greets,
>
> Ludi
>
>
>
> *Von:* owner-postfix-us...@postfix.org  *Im
> Auftrag von *Rafael Azevedo
> *Gesendet:* Dienstag, 29. Dezember 2020 13:38
> *An:* Postfix users 
> *Betreff:* SPAM attack from bounce techniques
>
>
>
> Hi there,
>
>
>
> I've noticed that one of our servers is receiving a huge amount of
> unauthorized requests.
>
>
>
> User connects to our server and tries to send an email to any destination.
> Our servers denies the message because user is not authenticated. Then, a
> bounce is generated to the source address, which was fake and turns to be
> the final destination, so at the end, the email is actually sent as a
> bounce, proliferating lots of spam.
>
>
>
> Is there a way to avoid this?
>
>
>
> Thanks in advance.
>
>
>
> BR,
>
>
>
> Rafael
>

Re: [External] SPAM attack from bounce techniques

[Rafael Azevedo]

Hi Kevin,
I think this might be related to a customized content filter after queue
that we have.
How should the content filter answer in case we don't want to accept the
message neither for bounces or to the delivery queue?
Huge thanks!

Em ter., 29 de dez. de 2020 às 11:31, Kevin A. McGrail 
escreveu:

> On 12/29/2020 7:37 AM, Rafael Azevedo wrote:
> > Hi there,
> >
> > I've noticed that one of our servers is receiving a huge amount of
> > unauthorized requests.
> >
> > User connects to our server and tries to send an email to any
> > destination. Our servers denies the message because user is not
> > authenticated. Then, a bounce is generated to the source address,
> > which was fake and turns to be the final destination, so at the end,
> > the email is actually sent as a bounce, proliferating lots of spam.
> >
> > Is there a way to avoid this?
>
> Hi Rafael, This sounds like backscatter.  To avoid it, you need to
> reject the email during the real-time SMTP dialog with the sender, i.e.
> during the connection from the sender, if it's an invalid recipient,
> reject with 5xx.  This will cause you to tell the sending server and you
> don't generate a bounce.
>
> The question is: Why are you accepting the email, then determining it's
> invalid, and creating a bounce?  I would typically look at some sort of
> architecture issue where you haven't done what we call promoted the
> valid users to the edge of your internet connection.
>
> Hope this helps and share more information for more guidance.
>
>
> Regards,
> KAM
>
>
>

Re: [External] SPAM attack from bounce techniques

[Wietse Venema]

Rafael Azevedo:
> Hi Kevin,
> I think this might be related to a customized content filter after queue
> that we have.
> How should the content filter answer in case we don't want to accept the
> message neither for bounces or to the delivery queue?
> Huge thanks!

Options:

- Run it as a before-queue filter (using smtpd_proxy_filter, see
http://www.postfix.org/SMTPD_PROXY_README.html).

- Run it as a before-queue filter (using the Milter API, see
http://www.postfix.org/MILTER_README.html). There are several systems
that can be used this way (spamassassin, amavis, to name a few).

- Otherwise, quarantine, or file to spam folder (perhaps add a
"SPAM" message header and use a Sieve rule). This is not as bad as
silently discarding email.

Wietse

> Em ter., 29 de dez. de 2020 ?s 11:31, Kevin A. McGrail 
> escreveu:
> 
> > On 12/29/2020 7:37 AM, Rafael Azevedo wrote:
> > > Hi there,
> > >
> > > I've noticed that one of our servers is receiving a huge amount of
> > > unauthorized requests.
> > >
> > > User connects to our server and tries to send an email to any
> > > destination. Our servers denies the message because user is not
> > > authenticated. Then, a bounce is generated to the source address,
> > > which was fake and turns to be the final destination, so at the end,
> > > the email is actually sent as a bounce, proliferating lots of spam.
> > >
> > > Is there a way to avoid this?
> >
> > Hi Rafael, This sounds like backscatter.  To avoid it, you need to
> > reject the email during the real-time SMTP dialog with the sender, i.e.
> > during the connection from the sender, if it's an invalid recipient,
> > reject with 5xx.  This will cause you to tell the sending server and you
> > don't generate a bounce.
> >
> > The question is: Why are you accepting the email, then determining it's
> > invalid, and creating a bounce?  I would typically look at some sort of
> > architecture issue where you haven't done what we call promoted the
> > valid users to the edge of your internet connection.
> >
> > Hope this helps and share more information for more guidance.
> >
> >
> > Regards,
> > KAM
> >
> >
> >

Re: SPAM attack from bounce techniques

[Rafael Azevedo]

Guys,
According to this referente [1], one of the principal operations is to
discard or quarantine the message.
How should the MAIL FILTER respond to postfix so it could do such actions?

Huge thanks,

BR,
Rafael

[1] - http://www.postfix.org/FILTER_README.html

Em ter., 29 de dez. de 2020 às 09:37, Rafael Azevedo 
escreveu:

> Hi there,
>
> I've noticed that one of our servers is receiving a huge amount of
> unauthorized requests.
>
> User connects to our server and tries to send an email to any destination.
> Our servers denies the message because user is not authenticated. Then, a
> bounce is generated to the source address, which was fake and turns to be
> the final destination, so at the end, the email is actually sent as a
> bounce, proliferating lots of spam.
>
> Is there a way to avoid this?
>
> Thanks in advance.
>
> BR,
>
> Rafael
>

Re: [External] SPAM attack from bounce techniques

[Rafael Azevedo]

Hi Wietse,
Thanks for the help !
I've just asked in another message about how to proceed in the "otherwise"
option.
I'm trying to quarantine the message and don't really know how to do it.
Any help would be appreciated.

Thanks once again.
BR,
Rafael

Em ter., 29 de dez. de 2020 às 15:16, Wietse Venema 
escreveu:

> Rafael Azevedo:
> > Hi Kevin,
> > I think this might be related to a customized content filter after queue
> > that we have.
> > How should the content filter answer in case we don't want to accept the
> > message neither for bounces or to the delivery queue?
> > Huge thanks!
>
> Options:
>
> - Run it as a before-queue filter (using smtpd_proxy_filter, see
> http://www.postfix.org/SMTPD_PROXY_README.html).
>
> - Run it as a before-queue filter (using the Milter API, see
> http://www.postfix.org/MILTER_README.html). There are several systems
> that can be used this way (spamassassin, amavis, to name a few).
>
> - Otherwise, quarantine, or file to spam folder (perhaps add a
> "SPAM" message header and use a Sieve rule). This is not as bad as
> silently discarding email.
>
> Wietse
>

>

Re: SPAM attack from bounce techniques

[Wietse Venema]

Rafael Azevedo:
> Guys,
> According to this referente [1], one of the principal operations is to
> discard or quarantine the message.
> How should the MAIL FILTER respond to postfix so it could do such actions?

EHLO blah
250 ok
MAIL FROM:
250 ok
RCPT TO:
250 ok
DATA
351 blah
header
body
.
250 ok
QUIT
220 blah

But, consider the three options that I mentioned in my response.

Wietse

Re: [External] SPAM attack from bounce techniques

[Wietse Venema]

Rafael Azevedo:
> Hi Wietse,
> Thanks for the help !
> I've just asked in another message about how to proceed in the "otherwise"
> option.
> I'm trying to quarantine the message and don't really know how to do it.
> Any help would be appreciated.

Add a header that says this is spam, then use a mail filter rule
(sieve, procmail, whatever) to file the message to a spam folder.

Wietse

Re: Javamail connection

[John Stoffel]

> "James" == James B Byrne  writes:

James> On Fri, December 25, 2020 12:43, John Stoffel wrote:

>> 
>> Why don't you setup a local only postfix instance on the same host as
>> the application, which only listed on 127.0.0.1:25, which the dumb
>> Java app can then send email through *without encryption*, then let
>> the local postfix instance do all the hard work of sending the email
>> to other servers using encryption?
>> 
>> It seems like the simpler setup to get working right, and gets most of
>> the pain in the Java app out of the way.
>> 
>> John
>> 

James> That is reasonable suggestion and is a possibility which I have
James> considered several times.  However, in this case the
James> application is being evaluated for its suitability to replace
James> and existing one.  Bypassing this particular problem with
James> Postfix only exposes the next arising from the application's
James> unwillingness to accept our certificates.

Sure, then the application is pretty much failing your acceptance
tests.  *grin*.

James> It is established to my satisfaction that this is not a Postfix
James> issue.  Therefore,this has to be a configuration issue within
James> the application itself.  If I do not solve it now then at some
James> point it is going to cause another problem, likely when we do
James> not have the luxury of time to figure it out.

Good luck then!

Re: AW: Controlling MS Azure Cloud Spam

[Nick Tait]

On 30/12/2020 2:38 am, ludic...@gmail.com wrote:

@Nick

A check for a valid FQDN in From is in smtpd_sender_restrictions.

At the point where it got to bounce message, SPF was skipped. Would 
OpenDMARC then still work?


The smtpd_sender_restrictions that you specify are applied to the 
/envelope/ sender address (a.k.a. RFC5321.MailFrom). IIUC the mail you 
are talking about has the null sender address, <>, which is probably 
handled as a special case and /not/ rejected by reject_non_fqdn_sender 
(and other smtpd_sender_restrictions)?


FYI I'd also suspect that SPF treats the null address as a special case too?

In order to accept or reject the mail based on the From header in the 
mail (a.k.a. RFC5322.From) you'd need to use some sort of content filter...


The simplest option is to use the Postfix built-in content inspection 
available with the header_checks option, to reject mail containing a 
From header matching a particular regular expression. Check out 
http://www.postfix.org/BUILTIN_FILTER_README.html for more information. 
However this won't work if the header is absent (i.e. no From header in 
the message).


Other options are a before-queue content filter 
(http://www.postfix.org/SMTPD_PROXY_README.html) or before-queue milter 
(http://www.postfix.org/MILTER_README.html). OpenDMARC is an example of 
the latter.


The one caveat with using OpenDMARC is that I'm pretty sure you'd need 
to use OpenDKIM and OpenDMARC together to implement DMARC policy 
checking and then you get that option I mentioned previously as bonus 
functionality. But if you had no desire to implement DMARC policy 
checking then this is a bit like using a sledgehammer to crack a nut.


Nick.