Great points - my view from earlier was that it really isn’t the
registrar’s job to make sure someone’s doing is cfg’d properly. I
would much rather have the registrar take a more hand-off approach to
configuring domains rather than the alternative. Just imagine
registrars who try and poke th
>> That aside, IMHO, this is a huge screw-up for SC - not even in the
>> realm of acceptable…
>
> On the other hand, why did the domain registrar put a blanket entry for
> *.spamcop.net pointing to their server's IP when the domain expired instead of
> just returning NXDOMAIN?
Because you can't m
On the other hand, why did the domain registrar put a blanket entry
for
*.spamcop.net pointing to their server's IP when the domain expired
instead of
just returning NXDOMAIN?
Well, this could also have been a screw-up by SC and if so, I would view
that as merely part of the same set of mista
Dnia 1.02.2021 o godz. 20:31:51 Antonio Leding pisze:
>
> That aside, IMHO, this is a huge screw-up for SC - not even in the
> realm of acceptable…
On the other hand, why did the domain registrar put a blanket entry for
*.spamcop.net pointing to their server's IP when the domain expired instead
>> Given the ip 1.2.3.4 - if postfix is configured to query the spamcop
>> blacklist then a dns query like this is issued:
>>
>> [gerry@noc ~]$ dig 4.3.2.1.bl.spamcop.net
>> [...]
>> ;; ANSWER SECTION:
>> 4.3.2.1.bl.spamcop.net. 300 IN A 91.195.240.87
>
> But isn't this a comm
On Sun, Jan 31, 2021 at 06:26:06PM -0500, vi...@vheuser.com wrote:
> Something's amiss...
> First time in 10 years I've gotten this:
>
> "An error occurred while processing your request.
> Reference #30.24721cb8.1612134453.1a374d81"
>
> from here:?? https://www.spamcop.net/
>
> Something has
Jaroslaw Rafa:
> Dnia 31.01.2021 o godz. 17:00:50 Gerald Galster pisze:
> >
> > Given the ip 1.2.3.4 - if postfix is configured to query the spamcop
> > blacklist then a dns query like this is issued:
> >
> > [gerry@noc ~]$ dig 4.3.2.1.bl.spamcop.net
> > [...]
> > ;; ANSWER SECTION:
> > 4.3.2.1.b
Dnia 31.01.2021 o godz. 17:00:50 Gerald Galster pisze:
>
> Given the ip 1.2.3.4 - if postfix is configured to query the spamcop
> blacklist then a dns query like this is issued:
>
> [gerry@noc ~]$ dig 4.3.2.1.bl.spamcop.net
> [...]
> ;; ANSWER SECTION:
> 4.3.2.1.bl.spamcop.net. 300 IN
Something's amiss...
First time in 10 years I've gotten this:
"An error occurred while processing your request.
Reference #30.24721cb8.1612134453.1a374d81"
from here: https://www.spamcop.net/
Something has changed.
On 2021/01/31 11:13 AM, Gerald Galster wrote:
Good news, the namese
Good news, the nameservers have changed again:
[gerry@noc ~]$ whois spamcop.net
Domain Name: SPAMCOP.NET
Registry Domain ID: 3340109_DOMAIN_NET-VRSN
Registrar WHOIS Server: whois.enom.com
Registrar URL: http://www.enom.com
Updated Date: 2021-01-31T16:04:06Z
Creation Date: 1999-01
Hello Ludi,
> But if spamcop.net is still intact, how can someone grab bl.spamcop.net?
it does not matter if spamcop servers are up and running, the problem is
that the responsible dns-servers do not answer with the spamcop servers'
ips anymore. Now the ip of a website belonging to a domain broke
> On Nov 18, 2016, at 1:01 PM, Phil Stracchino wrote:
>
> On 11/18/16 14:43, @lbutlr wrote:
>> On Nov 17, 2016, at 12:22 AM, Voytek wrote:
>>> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
>>> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
>>> Cl
On 11/18/16 14:43, @lbutlr wrote:
> On Nov 17, 2016, at 12:22 AM, Voytek wrote:
>> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
>> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
>> Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Current
On Nov 17, 2016, at 12:22 AM, Voytek wrote:
> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
> Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Currently
> Sending Spam See: http://www.sorbs
On 11/17/2016 1:22 AM, Voytek wrote:
> just noticed some email sent from gmail/google bouncing from my server as
> sorbs RBL had that server/host listed;
>
> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailab
d be - is outright blocking based on SORBS something I
should be doing?
Answer of course is a resounding NO. Use it for socring, maybe, but I
don't even use them because of their propensity for false positives.
just noticed some email sent from gmail/google bouncing from my server as
sorbs RBL had that server/host listed;
Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
Client host [209.85.217.170] blocked using
Simplest fix: prevent *that* class of false positives by narrowing the
> check to a single attribute, rather than including all attributes in the
> header following one which includes 'name' in its name:
>
> - /^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2
On 9 Apr 2016, at 9:00, Wietse Venema wrote:
Unfortunately, I don't have time to decode this discussion. Can
someone post a tested diff, someone maybe post a revised version,
and when there is agreement, then I can adopt it.
Simplest fix: prevent *that* class of false positives by narr
On 4/9/2016 8:00 AM, Wietse Venema wrote:
> Unfortunately, I don't have time to decode this discussion. Can
> someone post a tested diff, someone maybe post a revised version,
> and when there is agreement, then I can adopt it.
>
> Wietse
>
Does someone have a full, unmodified offending he
Unfortunately, I don't have time to decode this discussion. Can
someone post a tested diff, someone maybe post a revised version,
and when there is agreement, then I can adopt it.
Wietse
;s client software.
The fault here is no Apple's. It is a sin to parse MIME with regexps.
A proper MIME parser is required to do the job right.
The Postfix header checks are a not a complete solution, just a cheap
filter that can stop the most common junk. It is a bug in the (sample)
filter t
Curtis Villamizar wrote:
> Since pcre evaluates in order you could add>
> /^Content-(Disposition|Type).*;??x-apple-part-url="[^"]+"$/x DUNNO
>
> before the pcre that does the rejection.
That's one possibility, but:
(a) you probably won't want the '??' qualifying the ';'. '??' in the
Postfix lo
Since pcre evaluates in order you could add
/^Content-(Disposition|Type).*;??x-apple-part-url="[^"]+"$/x DUNNO
before the pcre that does the rejection.
Since "." is commonly "%2E" you could also change the "\." in the RE to
"(\.|%2E)".
That doesn't solve base64 encoding.
Disclaimer: I have
This is great information.
It's very odd ... Apple has been responsible for the foundation of quite a few
RFC's but in our experience has actually made it difficult for our software to
both comply with the RFC as well as Apple's client software.
Thank you Cedric.
~ Laz Peterson
Paravis, LLC
>
The documentation for header_checks includes an example to "block
attachments with bad file name extensions", and I expect many
installations have a similar rule to cut down on malware. This reads:
/^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(
ade|adp|asp|bas|bat|chm|cmd|com|cpl|cr
== Stan Hoeppner wrote on Fri 10.Aug'12 at 10:57:24 -0500 ==
> On 8/10/2012 8:31 AM, li...@sbt.net.au wrote:
>
> > what are current 'recommended' rbl lists that people use ?
>
> This thread could potentially explode with responses. Probably best to
> nip it in the bud now. This subject is deci
On 8/10/2012 8:31 AM, li...@sbt.net.au wrote:
> what are current 'recommended' rbl lists that people use ?
This thread could potentially explode with responses. Probably best to
nip it in the bud now. This subject is decidedly off topic for the
Postfix list. Please discuss this in an appropria
On Fri, August 10, 2012 11:20 pm, wolfgang wrote:
> FYI: DNS queries for *.dsbl.org currently return the IP 74.92.59.67 of
> shelob.surriel.com.
> Time to remove the discontinued RBL dsbl.org from your postfix configs
> if you haven't done so yet, see www.dsbl.org
wolfgang, thanks.
what are curr
FYI: DNS queries for *.dsbl.org currently return the IP 74.92.59.67 of
shelob.surriel.com.
Time to remove the discontinued RBL dsbl.org from your postfix configs
if you haven't done so yet, see www.dsbl.org
Hope this helps,
wolfgang
> -Original Message-
> From: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones
> Sent: Wednesday, April 28, 2010 4:04 PM
> To: postfix-users@postfix.org
> Subject: Re: false positives
> On 4/28/2010 4:29 AM, Mut
On 4/28/2010 4:29 AM, Mutashobya A. Mushumbusi wrote:
Hi guys, I don’t know if I should ask this here or in spamassassin
forum. I am running postfix-2.1.5 and I have employed spamassassin-3.0.1
(via amavisd-new) to check for spams. Based on scores, some legitimate
emails get marked as spam and ge
Hi guys, I don't know if I should ask this here or in spamassassin forum. I am
running postfix-2.1.5 and I have employed spamassassin-3.0.1 (via amavisd-new)
to check for spams. Based on scores, some legitimate emails get marked as spam
and get quarantined. I want to know how to resend those ema
33 matches
Mail list logo
