I have had other experiences with spammers. I suspect there is different
spammers out there that spam in different ways.
I once got a very irritating spammer that send a lot of spam, that was
completely identical, had a identical color in the header and it was really
obvious this spammer was the
> On 21 Sep 2016, at 01:40, Sebastian Nielsen wrote:
>
> I would really suggest using DISCARD instead of "500 This TLD sends spam - g
> e t lost.".
> Thus the spammer dosen't get to know he got stuck in a spam filter and can
> update their tools to bypass it.
Spammers generally don’t pay that l
I would really suggest using DISCARD instead of "500 This TLD sends spam - g
e t lost.".
Thus the spammer dosen't get to know he got stuck in a spam filter and can
update their tools to bypass it.
DISCARD accepts the mail but throws it into /dev/null
-Ursprungligt meddelande-
Från: owner-
Tell ya what. Let's hold the suggestions here. This one looks like something I
can handle. (I really need things spelled out.)
BTW, the SpamAssassin enlist trick caught about 20% of this flavor of spam. But
I'm really OK will killing the TLD.
I did some googling on this and some claim Baracuda
On 20 Sep 2016, at 16:10, li...@lazygranch.com wrote:
After studying these spam messages, I think postfix blocking via
tld is the only solution. The problem is the message is embedded in
graphics with brief text regarding "if you can't view this click
here". There isn't enough to trip the spa
felderm:
> Hi All
>
> We operate multiple Postfix instances behind HA-Proxies. The haproxy
> upstream protocol is enabled:
>
> smtpd_upstream_proxy_protocol=haproxy
> (the IPs of the HA-proxies are in mynetworks)
You should never have to list the HA-proxies in mynetworks.
If the remote connecti
On Tue, Sep 20, 2016 at 12:03:37PM +0200, felderm wrote:
> Hi All
>
> We operate multiple Postfix instances behind HA-Proxies. The haproxy
> upstream protocol is enabled:
>
> smtpd_upstream_proxy_protocol=haproxy
> (the IPs of the HA-proxies are in mynetworks)
>
> There are brute-force attacks a
Hi Alex,
You should be able to see more details in /var/log/mail.log. postfix is pretty
verbose in the logs. Try sending a test mail and observe the log file. Revert
with the relevant entry to see what happened.
On September 21, 2016 12:30:27 AM EEST, Alex Hall wrote:
>Hello list,
>A very qui
On Tue, Sep 20, 2016 at 05:30:27PM -0400, Alex Hall wrote:
>
> Bottom line: on one server, everything was great. On my company's virtual
> server, with the same configuration, packages, and settings, mail sent out
> is silently discarded by Gmail when delivered to anyone on the company's
> domain.
On Tue, Sep 20, 2016 at 05:30:27PM -0400, Alex Hall wrote:
> From all I can tell, Postfix is doing it right: it sends the emails, and so
> long as the recipient is *not* @domain.com, the message is delivered. If it
> *is* @domain.com, the message silently disappears.
See
http://www.postfix.o
Hello list,
A very quick intro first. I work for a company that uses all virtual
servers, a change we recently adopted. I'm setting up Request Tracker for
internal use, which requires a Linux system to run. Thus, I'm learning
about Linux and all of RT's required packages at the same time. I'm
comfo
I'm simply making sure my subscription worked. I had some trouble getting
it to go through, so want to check that I've made it on the list.
--
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
> On 20 Sep 2016, at 21:10, li...@lazygranch.com wrote:
>
> What is the simplest way to block a TLD?
Put the offending TLD in a map and have that map referenced through
check_sender_access and/or check_client_access.
ie
in main.cf:
smtpd_client_restrictions = permit_mynetworks
Im using the following to block TLDs, but not in helo checks, im using sender
checks instead:
/\.bid$/ DISCARD
/\.top$/ DISCARD
/\.xyz$/ DISCARD
/\.pro$/ DISCARD
/\.date$/ DISCARD
/\.faith$/ DISCARD
/\.download$/ DISCARD
DISCARD blocks the mail without telling the sender the mail was blocked so
On Tue Sep 20 2016 14:10:17 li...@lazygranch.com
said:
>
> After studying these spam messages, I think postfix blocking via tld is the
> only solution. The problem is the message is embedded in graphics with brief
> text regarding "if you can't view this click here". There isn't enough
On 2016-09-20 22:10, li...@lazygranch.com wrote:
After studying these spam messages, I think postfix blocking via tld
is the only solution. The problem is the message is embedded in
graphics with brief text regarding "if you can't view this click
here". There isn't enough to trip the spam bot.
After studying these spam messages, I think postfix blocking via tld is the
only solution. The problem is the message is embedded in graphics with brief
text regarding "if you can't view this click here". There isn't enough to trip
the spam bot.
What is the simplest way to block a TLD?
postscreen will not invoke tests for every connection, nor will it
store configuration overrides in its cache. You can build your own
MTA front-end, or convince some other project to build DNSBL lookups
into their loadbalancer or proxy.
Wietse
On Mon, Sep 19, 2016 at 7:19 PM, Wietse Venema wrote:
> What you are asking for requires either that a test happens for
> every connection, or the ability to store configuration overrides
> in the postscreen cache. The first is not a good idea, and the
> latter just adds complexity.
>
> The first
Hi All
We operate multiple Postfix instances behind HA-Proxies. The haproxy
upstream protocol is enabled:
smtpd_upstream_proxy_protocol=haproxy
(the IPs of the HA-proxies are in mynetworks)
There are brute-force attacks agains the SMTP servers (auth Backend is
OpenLDAP). We would like to block t
Believe it or not, Tellus doesn't support encryption.
https://www.reddit.com/r/canada/comments/464glo/psaif_you_use_a_telus_email_account_telus_does/?st=itb9thrx&sh=2a6ed83e
I think when Google starts to refuse unencrypted email, it would make sense for
postfix to bounce them.
Original Mess
On 09/19/2016 05:29 PM, li...@lazygranch.com wrote:
The last time TLD blocking came up, the consensus of the hive was not
to block based on TLD. (You may recall .xyz being used by
Alphabet.) However lately I'm getting a ridiculous number of .stream
SPAM coming through. The RBLs are getting abou
https://topicdesk.com/downloads/tutorials/spamassassin-filter-for-new-tlds-xyz-info-ninja-etc/
I used this, more or less. It wasn't exactly set up for freebsd. The
directory needed is at
/usr/local/etc/mail/spamassassin
PS:
Benny, is that your real email address? I'd like to take this off the
list
23 matches
Mail list logo
