[pfx] Re: Spam mails seen in logfiles question
Bill Cole via Postfix-users: > On 2023-08-23 at 14:38:18 UTC-0400 (Wed, 23 Aug 2023 12:38:18 -0600) > IUL Support via Postfix-users > 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. ...modern versions that integrate with Dovecot, so that the Postfix check_pilocy_service feature can query Dovecot. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Spam mails seen in logfiles question
On 2023-08-23 at 14:38:18 UTC-0400 (Wed, 23 Aug 2023 12:38:18 -0600) IUL Support via Postfix-users 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 Sent: Wednesday, August 23, 2023 9:17 AM To: IUL Support via Postfix-users 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 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 _
[pfx] Re: Spam mails seen in logfiles question
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. 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. -Original Message- From: Bill Cole via Postfix-users Sent: Wednesday, August 23, 2023 9:17 AM To: IUL Support via Postfix-users 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 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
[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 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
[pfx] Re: Spam mails seen in logfiles question
Dnia 23.08.2023 o godz. 03:22:21 IUL Support via Postfix-users pisze: > 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? I think they do it for bounce handling. If the recipient some_spammy_text-myuser=mydomain@notmydomain.com gets a bounce, they know myu...@mydomain.com does not accept their mail. I guess they can use this knowledge to remove the address from their mailing list, but who knows what they are doing with it actually... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
