AW: google's receiving policies

[ludicree]

TOL publishes a list of their mailservers and also has them listed at DNSWL.

The list auf these ~20 IPs probably is in many configs somewhere. And/or a 
DNSWL query.
F.e. when TOL gets listed on Spamcop or others again.

Greets,
Ludi

-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im 
Auftrag von Henry R
Gesendet: Samstag, 10. Dezember 2022 04:47
An: postfix-users@postfix.org
Betreff: google's receiving policies

t-online has no SPF & DMARC & DKIM settings. but google try to maintain a 
reliable sender IP list for them.

if you forward a message which is original from t-online to gmail, if you don't 
have SRS enabled for this forwarding, gmail will just reject it.

as far as I know, many ISP level forwardings have NO SRS setup, including 
Mail.ru, Freenet.de, and even Outlook.

since there is no spf, no dkim for t-online, how google know it's coming from a 
valid IP? the only reason I can image is that google help maintain that a ip 
list for t-online itself.

how do you think of this?

Thanks & regards.

AW: how to deal with t-online's blocking

[ludicree]

Hi,

only commercial websites and those of entities (e.V. etc.) require an
imprint in germany.

The "TOL problem" also occurs for private persons who do nothing wrong
legally.
And it also affects commercial services who do not host a website under the
mail domain.

Greets,
Ludi

-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im
Auftrag von Jaroslaw Rafa
Gesendet: Mittwoch, 30. November 2022 15:10
An: postfix-users@postfix.org
Betreff: Re: how to deal with t-online's blocking

Dnia 30.11.2022 o godz. 23:41:53 Nikolai Lusan pisze:
> 
> My question is: How do they deal with non-european entities who do not 
> have such legal impediments in their jurisdiction?

While it is actually a legal requirement *in Germany* (not in whole Europe!)
and for *German* websites to have such an imprint in general, in this case
it seems to have actually nothing to do with legislation - there is no such
legal requirement for mail senders, and they seem just to pick up an
existing legal construction and put it into their own requirements for mail
senders. So you either comply to their requirement or the don't accept mail
from you.

[...]

AW: how to deal with t-online's blocking

[ludicree]

Hi,

I remember writing to TOL on behalf of a .net organisation. And request they 
whitelist the new IP of their server. That worked.

The address should be in your logfile with the reject.

Did you use that or some other channel to talk to them?

So many companies ignore basic things like abuses. Or in this case invent their 
own whitelist.
I bet nothing of all this gets them on a RFC-ignorant style list, where they 
belong IMO.

Greets,
Ludi

-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im 
Auftrag von Henry R
Gesendet: Mittwoch, 30. November 2022 03:09
An: postfix-users@postfix.org
Betreff: how to deal with t-online's blocking

Hello,

My mailserver once had some issues on sending messages to different providers. 
I have contacted the provders and most of them were kind enough to resolve the 
blocking issue. Thanks for them (ATT, GMX, 1and1 etc).

But t-online.de keep blocking me. I have contacted them twice and got the same 
answer:

We only allow evidently commercial or similar operators to connect to our 
mailservers. So, as a private user please use an SMTP relay or e-mail gateway 
of your hoster or ISP, that you can use as part of your contract with them. 
Their support will surely help you to configure your system accordingly.


That's so strange policy to permit only commercial company to send messages to 
them.
But there are many small companies/org who have their own mailservers, which 
can't send messages to t-online directly.

How do you think of this behavior?

Thanks.

AW: pflogsumm not catching some lines

[ludicree]

Hi,

thank you for clearing up the pflogsumm status.

>seems that two forks are a bit ahead
>https://github.com/sbidy/pflogsumm
>https://github.com/rebouny/pflogsumm

I tried the newer version from the debian repository and the forks above.

The one from sbidy reports the cleanup header part again.

Greets,
Ludi

AW: Spam pass the filter

[ludicree]

Hi,

pcre header checks we use. Not all the time, depends on spam volume from
these valuable enterprises.

#/sjmedia.us/   REJECT A mass mail service abused by criminals
#/bmsend.com/   REJECT A mass mail service abused by criminals
#/mailgun.net/  REJECT A mass mail service abused by criminals
#/rsgsv.net/REJECT A mass mail service abused by criminals
#/mcsv.net/ REJECT A mass mail service abused by criminals
#/sendgrid.net/ REJECT A mass mail service abused by criminals
#/crsend.com/   REJECT A mass mail service abused by criminals
#/zcsend.net/   REJECT A mass mail service abused by criminals

I forgot if all those can be catched by limiting it to the Received-Line.

Greets,
Ludi


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im
Auftrag von Christian Schmitz
Gesendet: Freitag, 17. September 2021 14:41
An: postfix-users@postfix.org
Betreff: Spam pass the filter

Hi everyone:
Normally when i identify a host spammer i block entire server. Today
i receive one spam email. The origin is "mailgun.net", i already have a rule
to block him, but the email pass with no problem. I want stop the email,
what is wrong? 

The header, config and rules are the following.

Best Regards and thanks in advance
Christian

AW: Hostname DNS error

[ludicree]

Resolved - it was indeed a lookup problem.

Thx!


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im
Auftrag von Gerald Galster
Gesendet: Samstag, 21. August 2021 11:09
An: Postfix users 
Betreff: Re: Hostname DNS error

> Aug 21 10:22:59 stretch postfix/smtpd[8394]: warning: hostname 
> mail.radio-z.net does not resolve to address 136.243.54.124 Aug 21 
> 10:22:59 stretch postfix/smtpd[8394]: connect from 
> unknown[136.243.54.124] Aug 21 10:22:59 stretch postfix/smtpd[8394]: 
> 18D3F6A40A2B: client=unknown[136.243.54.124]
> 
> The reverse DNS for that host is set (IPv4 and IPv6) and seems to work.

In case you use the standard resolvers provided by your data center, you
could install a local resolver like unbound.

/etc/resolv.conf:
nameserver 127.0.0.1

Best regards
Gerald

Hostname DNS error

[ludicree]

Hi,

I am having trouble receiving mail from this specific host:

Aug 21 10:22:59 stretch postfix/smtpd[8394]: warning: hostname mail.radio-z.net 
does not resolve to address 136.243.54.124
Aug 21 10:22:59 stretch postfix/smtpd[8394]: connect from 
unknown[136.243.54.124]
Aug 21 10:22:59 stretch postfix/smtpd[8394]: 18D3F6A40A2B: 
client=unknown[136.243.54.124]

And the same error with the according IPv6 address of that host.

It requires me to change my client_restrictions:

reject_unknown_client_hostname -> reject_unknown_reverse_client_hostname

The reverse DNS for that host is set (IPv4 and IPv6) and seems to work.

When I 

dig mail.radio-z.net
;; ANSWER SECTION:
mail.radio-z.net.   53273   IN  A   136.243.54.124

I see no DNS troubles.

What could be the problem with that system?

Greets,
Ludi

AW: Google spam...

[ludicree]

Yes, many of them are regular GUI users.

But also many of them do the same scheme for years now, sometimes for long 
periods with the same accounts.
Like the notorious "Maria Elisabeth Schaeffler" mass scam every day.

I do not believe Google does not know what goes on. They just don't care.

Other freemailers care and they are not abused in such amounts.

But if one wants to get rid of the Google scam to some degree:
Many use their campaign GMail as the Reply-To address.
Especially when sending from hacked accounts, but also when using other (new) 
GMail accounts.
I have yet to see a false positive while filtering that.

Greets,
Ludi


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im 
Auftrag von Viktor Dukhovni
Gesendet: Mittwoch, 18. August 2021 07:41
An: postfix-users@postfix.org
Betreff: Re: Google spam...

On Wed, Aug 18, 2021 at 07:27:38AM +0200, ludic...@gmail.com wrote:

> Google does not honor abuse addresses, or spamcop. 
> 
> Which makes it the #1 scammer paradise.

The key problem is that email accounts are free, and the 419 scammers are not 
bots, and so it is difficult to prevent them from opening a new account.  
Ideally their messages would trigger outbound filtering when composed, but 
stopping them must be harder than one would naïvely expect, and conveniently 
for the big email hosters, not a problem they need to solve.

The scammer just needs to avoid sending spam to any Gmail users from a Gmail 
account, and everyone else has no effective way to complain.

Another barrier to effectively shutting them down is that much of the junk is 
sent via various other outbound services, with just the Reply mailbox on Gmail 
(or similar).  It is then difficult to convice Google to shut down a mailbox 
that is not even directly a sender of the junk.

Externalities are great when you're not the one on the hook for the costs.

-- 
Viktor.

AW: Google spam...

[ludicree]

Google does not honor abuse addresses, or spamcop. 

Which makes it the #1 scammer paradise.

Greets,
Ludi


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im 
Auftrag von Vince Heuser
Gesendet: Mittwoch, 18. August 2021 02:06
An: postfix-users@postfix.org
Betreff: Re: Google spam...

What's the matter with ab...@google.com  and at spamcop.net?




On 2021/08/17 17:35 PM, Viktor Dukhovni wrote:
>> On 17 Aug 2021, at 5:13 pm, SH Development  
>> wrote:
>>
>> We have been getting inundated by spam from Google (gmail).
>>
>> I know that if our server gets reported for even a few spammy messages, 
>> Google won’t hesitate to block our server.
>>
>> Short of blocking Google on our server, is there some place to report spam 
>> we have received from the Google platform?
> Yes, but I doubt it would have any meaningful effect. :-(
>
> You can (with much manual effort) fill in Google's abuse report form:
>
>   https://support.google.com/mail/contact/abuse
>
> or (easier, but no idea whether this is effective), use an IMAP client 
> to move the message into the INBOX of a Gmail account, and then report 
> it as spam.
>
> Unless you have friends in high places at Gmail, or manage to get law 
> enforcement interested, you're unlikely to get much feedback.
>

AW: Timeout, bounce, duplicate mails

[ludicree]

Hi,

Von: owner-postfix-us...@postfix.org  Im
Auftrag von Wietse Venema

>> plesk_virtual (total: 2)
>>  2   Command time limit exceeded:
"/usr/lib/plesk-9.0/postfix-local"

>Some message delivery needed more than one thousand seconds.

>> Is this timeout somehow configurable for me? My guess is that it 
>> happens due to high load at times.

>The default command time limit is 1000s, which in my opinion is already
ridiculously large. Increasing Postfix time limits further would just fight
a symptom instead of addressing the root cause.

I agree that is a lot.

> a) Get yourself a better computer (https://dilbert.com/strip/1995-06-24)

Well, it's a rootserver with 8-core Xeon, 64 GB - but no flash, just a RAID
of enterprise HDDs.

Mailboxes have grown in numbers and size over time.

The next machine for this case will have the mail service on NVME.

> b) Reduce the workload. 

>IF the overload is caused by Postfix, then I know how to reduce the
overload if you can share Postfix configuration.  See
http://www.postfix.org/DEBUG_README.html#mail for some instructions.
>Reducing overload from Postfix can be as simple as reducing a process limit
in main.cf or in master.cf.

As a first try I will reduce the default process limit and see how that
goes.

Thanks!

Greets,
Ludi

Timeout, bounce, duplicate mails

[ludicree]

Hi all,

 

I see a few occasions of this every day:

 

plesk_virtual (total: 2)

 2   Command time limit exceeded: "/usr/lib/plesk-9.0/postfix-local"

 

It leads to particular mails to bounce, then be sent again, then having
multiple copies of it in the mailbox.

 

This happens with external senders and with server-local php mail scripts.

 

Is this timeout somehow configurable for me? My guess is that it happens due
to high load at times.

 

The local mailboxes are handled by courier, which uses the qmail directory
structure under plesk.

 

Greets,

Ludi

 

AW: Postfix Helo reverse Exception

[ludicree]

I tried to work with reject_unknown_helo_hostname time and time again.
But way too many regular servers don't comply.
It does not seem as there is much progress.

OTOH, reject_invalid_helo_hostname does a good job in my realm of mail traffic.
I have yet to see a complaint about turning these away.

Greets,
Ludi





-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im 
Auftrag von Phil Stracchino
Gesendet: Sonntag, 21. März 2021 02:21
An: postfix-users@postfix.org
Betreff: Re: Postfix Helo reverse Exception

On 3/20/21 8:23 PM, Wietse Venema wrote:
> But it is better to stop using reject_unknown_helo_hostname because 
> the are many misconfigured servers that send legitimat mail.

That is an interesting piece of advice.


--
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958

AW: can't send to GSuite mailserver via IPv6 protocol

[ludicree]

Sending to Gmail via IPv6 gives me no troubles.

 

MX, host and helo all have their  records.

 

I figure it would not only be Gmail with problems if IPv6 MX had no reverse
DNS.

 

Greets,

Ludi

 

Von: owner-postfix-us...@postfix.org  Im
Auftrag von Thomas
Gesendet: Montag, 1. März 2021 10:15
An: Postfix users 
Betreff: Re: can't send to GSuite mailserver via IPv6 protocol

 

Please see this description which is similar to mine:

https://serverfault.com/questions/655250/gmail-bouncing-mail-sent-over-ipv6-
ipv4-working

 

And the answers look interesting.

 

Regards.

AW: replying with OK

[ludicree]

Or set it up to catch-all für a certain domain?

Greets,
Ludi

-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im
Auftrag von dev...@dvb.homelinux.org
Gesendet: Mittwoch, 24. Februar 2021 12:57
An: postfix-users@postfix.org
Betreff: Re: replying with OK

On Wed, Feb 24, 2021 at 12:40:43PM +0100, Zsombor B wrote:
> Hi,
> 
> 
> Is there a way to reply with 'OK' to the sender instead of 'relay 
> access denied'?
> 
> Reason: thousands of junk emails per day are sent from DEV environment 
> to forged recipients but there is only a couple of recipient domains 
> are allowed. The others get 'relay access denied' but the developers 
> are complaining that their automated tests are falsely failing because 
> of the relay access denied response. (I got a promise that the tests 
> will be fixed but that will take months and automated test reports 
> will be red until
> then.)

Why not setup a Postfix instance for dev which simply discards all received
email?

Devdas Bhagat

AW: How to deal with sending mail from host isbd.uk?

[ludicree]

Give the machine a hostname, put hostname.domain.tld in hostname file and
DNS.

Greets,
Ludi


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im
Auftrag von Chris Green
Gesendet: Freitag, 12. Februar 2021 17:18
An: postfix-users@postfix.org
Betreff: How to deal with sending mail from host isbd.uk?

Just a quickie, how do I configure /etc/hostname etc. for a system at
isbd.uk?

It really *is* just isbd.uk:-

chris$ host isbd.uk
isbd.uk has address 92.243.2.29
isbd.uk mail is handled by 0 mail.vhdns.net.

So, if I set /etc/hostname to isbd.uk then postfix thinks the domain name is
just uk which doesn't work very well.

--
Chris Green

AW: Can I get postfix to use what's returned by dnsdomainname for mydomain?

[ludicree]

Can't this be simply done by bash/cron?

Execute dnsdomainname
Alter main.cf
postfix reload

Not sure about startup / system boot.

Just my first thoughts.

Greets,
Ludi

-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im
Auftrag von Chris Green
Gesendet: Mittwoch, 10. Februar 2021 14:57
An: postfix-users@postfix.org
Betreff: Can I get postfix to use what's returned by dnsdomainname for
mydomain?

It would be really handy if I could get postfix to use the value returned by
the dnsdomainname command for its mydomain value as I could then use the
same main.cf file in several headless 'send only'
systems where postfix is used solely for sending error messages from cron
and similar.

There isn't an 'include' type directive in postfix configuration so I can't
see any way of doing this by capturing the output of dnsdomainname at
startup and then including this in main.cf.

Has anyone else wanted to do anything like this and come up with a solution?

--
Chris Green

AW: Catch a forged Return Path

[ludicree]

Hi,

>Does Plesk not give you access to the main.cf file? How do you configure 
>postfix at all?

Plesk does rewrite the main.cf file (and possible others) upon changes in the 
GUI or updates.
Not everything gets thrown out, but quite some lines revert to a Plesk default.

It is not bad when it is known, some extra care needed.

Greets,
Ludi

AW: Catch a forged Return Path

[ludicree]

Hi,

>On 6/02/21 2:23 am, Matus UHLAR - fantomas wrote:
>> while I support using postscreen, I'm not sure it would be able to 
>> catch backscatter, becsuse backscatter often comes from servers who 
>> properly follow SMTP RFCs.

>The question here is whether this is really backscatter, or just spam taking 
>advantage of the null sender address? Sounds like it might be the latter, in 
>which case Postscreen may prove useful?
>Nick

The cases I have seen are spam campaigns with AWS and Azure Accounts. 

I took a look at postscreen, but not sure how to implement that on a Plesk 
machine.

The more interesting point with this was for me, what happens when spammers use 
the null sender address und how far they were able to trick all my checks.

Greets,
Ludi

AW: Catch a forged Return Path

[ludicree]

Hi,

>>Return-Path: 
>>
>>to disguise as a bounce and bypass any further checks.
>>
>>So the PCRE header check
>>
>>/^Return-Path: /   REJECT Forged Return-Path
>>
>>does not catch.

>are you sure it's a Return-Path header?
>usually, envelope sender is put to Return-Path, so you may need to block
envelope sender MAILER-DAEMON.
>You can see Return-Path after delivery to mbox, but it's often not
generated before that, so at SMTP level it may not exist.

Not sure what puts it there. The logs reveal very little about those
deliveries.

I mainly see a connect and then:

Feb  3 13:34:47 stretch greylisting filter[32274]: Bounce message. SKIP
Feb  3 13:34:48 stretch postfix/qmgr[16941]: B0F0D6A402A6: from=<>,
size=925, nrcpt=1 (queue active)
Feb  3 13:34:48 stretch postfix-local[32278]: postfix-local:
from=MAILER-DAEMON, to=...

In between just plesk stuff about what it can not do with that mail, like
greylisting, virus scan..

>I catch those by putting reject_non_fqdn_sender into
smtpd_sender_restrictions:

Mine looks like this:

smtpd_sender_restrictions = check_sender_access
hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated,
reject_non_fqdn_sender, check_sender_access pcre:/etc/postfix/pcre_sender,
reject_unknown_sender_domain

Greets,
Ludi

Catch a forged Return Path

[ludicree]

Hi all,

new MS Azure Cloudapp Spam Wave these days.

Just a few hosts, but a lot of Spam. There is a pattern there, they all use

Return-Path: 

to disguise as a bounce and bypass any further checks.

So the PCRE header check

/^Return-Path: / REJECT Forged Return-Path

does not catch.

Any other chance of making this work in postfix checks?

Actually a re-visit to my topic about MS Azure Cloud Spam from December, but
much more clarified matters now after some time of observation.

Greets,
Ludi

AW: Sender address rejected: Domain not found

[ludicree]

Hi,

looks like a simple DNS error to me.

In order for mails from @server.cointalk.com to be valid, that domain must
exist as A records in DNS.

You could whitelist *.cointalk.com in postfix config, but I suggest fixing
the DNS.

Greets,
Ludi


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im
Auftrag von Ruben Safir
Gesendet: Dienstag, 5. Januar 2021 09:19
An: postfix-users@postfix.org
Betreff: Sender address rejected: Domain not found

I'm sorry to bother everyone

Any clue why this is happening from the cointalk.com domain I am locked out
of the forum :)

2021-01-05T03:11:38.999012-05:00 www2 postfix/smtpd[26176]: NOQUEUE:
reject: RCPT from 23-111-188-110.static.hvvc.us[23.111.188.110]: 450
4.1.8 : Sender address rejected: Domain not
found; from= to=
proto=ESMTP helo= www2:~ # grep cointalk
/var/log/mail|less


www2:~ # dig mx ng...@server.cointalk.com

; <<>> DiG 9.9.2 <<>> mx ng...@server.cointalk.com ;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58851 ;; flags: qr rd
ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nginx\@server.cointalk.com.IN  MX

;; AUTHORITY SECTION:
cointalk.com.   180 IN  SOA ns0.dnsmadeeasy.com.
dns.dnsmadeeasy.com. 2008010139 43200 3600 1209600 180

;; Query time: 321 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan  5 03:18:18 2021
;; MSG SIZE  rcvd: 110


--
So many immigrant groups have swept through our town that Brooklyn, like
Atlantis, reaches mythological proportions in the mind of the world - RI
Safir 1998 http://www.mrbrklyn.com 

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com
- Leadership Development in Free Software http://www2.mrbrklyn.com/resources
- Unpublished Archive http://www.coinhangout.com - coins!
http://www.brooklyn-living.com 

Being so tracked is for FARM ANIMALS and extermination camps, but
incompatible with living as a free human being. -RI Safir 2013

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

 

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 

Controlling MS Azure Cloud Spam

[ludicree]

Hi,

 

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

 

Many of these mails come with a header:

 

*   Return-Path: 
*   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