On 2023-08-23 at 14:38:18 UTC-0400 (Wed, 23 Aug 2023 12:38:18 -0600)
IUL Support via Postfix-users <iul-supp...@iul.net>
is rumored to have said:
I must be missing something in what you're saying.
If the server receives a message for myu...@mydomain.com and myuser's
mailbox is full... by default the server generates a bounce, I don't
see any
way around that.
In most modern configurations of Postfix, a full mailbox will result in
a rejection code in SMTP. The incoming message is never queued. If the
sender uses the ESMTP SIZE extension, the receiving server may reject an
oversize message without seeing the message data at all.
It tries to send the bounce back to the sender from whence
it came, lets say that is
"enlarge_your_part-myuser=mydomain....@theirdomain.com" and then their
server throws a 4xx and defers accepting the bounce, repeatedly, for a
week,
until retries finally times out. If their server is deferring
inbound
mail that doesn't sound like any sort of successful bounce management
strategy to me.
Yes, you will only notice when bounces fail. Most happen almost
immediately and just work. Depending on why you are bouncing messages,
you may only be bouncing messages sent by reckless spammers who use VERP
only because that's what their tools do, and their spamming gets their
accounts killed or filled before their giant piles of spam have fully
delivered.
-----Original Message-----
From: Bill Cole via Postfix-users <postfix-users@postfix.org>
Sent: Wednesday, August 23, 2023 9:17 AM
To: IUL Support via Postfix-users <postfix-users@postfix.org>
Subject: [pfx] Re: Spam mails seen in logfiles question
On 2023-08-23 at 05:22:21 UTC-0400 (Wed, 23 Aug 2023 03:22:21 -0600)
IUL
Support via Postfix-users <iul-supp...@iul.net> is rumored to have
said:
Hi All,
Have a legacy server that I've just taken over maintaining. It's set
up with postfix that handles a small handful of email users. In
looking through the logfile I'll frequently see emails bouncing (and
the bounce messages being deferred so they just sit in the queue
wasting retries).
You should fix that. It is a dangerous practice to accept mail and
then
attempt to bounce it on a machine accepting mail from the Internet.
This
generates a "backscatter" of bounces to forged addresses, often with
embedded spam and malware in the bounce messages.
The email will be from
some_spammy_text-myuser=mydomain....@notmydomain.com and addressed
to
myu...@mydomain.com.
The LHS always seems to have the same basic format ie. the
underscores
and the equal sign so it seems obvious that they're trying to
accomplish
something specific. Is it supposed to help them get past spam
filtering,
or get around some sort of bug?
It is called "variable envelope return path" or more often just VERP.
It is
a common practice used in modern mailing list management that sends
each
message with one recipient and a unique envelope sender to assure that
any
delayed bounces (which are sent to the envelope sender, a.k.a.
'return path') can be positively matched to a user, so that the user
can be
removed or suspended from a list if there are problems delivering to
them
that can be understood from the bounce as likely to be repaired.
There are related variants on VERP that are used to encode an earlier
return
path into a new one on forwarded messages (SRS) and as a trick to give
every
message a unique return path and hence eliminate fake bounces
(BATV.)
Can anyone enlighten me as to what they're trying to accomplish and
if
I should be doing anything configuration wise to block them from
accomplishing it??
Don't block based solely on VERP use. VERP is almost universally used
in
business-to-consumer bulk and transactional email, including messages
which
are very much wanted and valuable. SRS and BATV, which look very
similar,
are used to make other spam mitigation tactics possible.
Is it supposed to help them get past spam filtering, or get around
some sort of bug?
It's all about spam, like everything these days in email...
But it is NOT about getting around filters. It is about enabling
rigorous
bounce handling (GOOD!) so that bulk mail senders can avoid sending de
facto
spam and keep their lists clean. The similar-looking BATV and SRS are
tactics developed to allow other anti-spam techniques to work with
fewer
errors.
--
Bill Cole
b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many
*@billmail.scconsult.com addresses) Not Currently Available For Hire
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe
send
an email to postfix-users-le...@postfix.org
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
