On 13 Oct 2015, at 15:46, Dianne Skoll wrote:
CPanel is just a "hosting control panel" used by a bazillion hosting
providers. It's a more sophisticated version of Webmin and the like;
Or *less* depending on your concept of 'sophisticated'... It is slicker,
but it is much more tightly bound
On 13 Oct 2015, at 15:08, Larry Goldman wrote:
My experience to date is that GoDaddy doesn’t really support the
internals of CPanel, and CPanel doesn’t provide end-user customer
support either.
Cheap is indeed cheap. Skilled individualized MTA & anti-spam support is
NOT cheap.
I figured I
On 13 Oct 2015, at 16:04, Larry Goldman wrote:
Point me to the documentation of the SpamAssassin framework.
You mentioned being a Mac user so in addition to the website Dianne
pointed you to or manually installing from the SA source tarball, you
can get a working installation with all of
On 10/14/2015 12:00 PM, Bill Cole wrote:
Describe, in detail, the new SA technology which fights abuse of new
TLDs.
Prior to v3.4.1, the mechanism for detecting and parsing hostnames to
identify body URIs used an embedded array of hardcoded domains in
Thanks for the reply George. We tried that link yesterday and made the
change as described with no results. We restarted mailscanner but
nothing else. Maybe I need to restart our MTA or other daemon.
Allen
a...@bandwise.com
On 2015-10-14 12:04, George Ficzeri wrote:
This?
Hi,
We activated the relay country plugin yesterday. As part of the process
we did a yum install perl-Geo-IP. Now we get the following warning when
we lint or salearn.
Use of uninitialized value $hasStructureInfo in numeric eq (==) at (eval
31) line 5520
I have no idea which file line
This?
https://github.com/maxmind/geoip-api-perl/pull/22
If you click 'Files changed' you'll see the path, and see the fix.
On 10/14/15 11:49 AM, a...@satester.com wrote:
> Hi,
>
> We activated the relay country plugin yesterday. As part of the process
> we did a yum install perl-Geo-IP. Now
On Wed, 2015-10-14 at 10:36 -0400, Bill Cole wrote:
> Self-hosting email is feasible if you have a proper business-fit
> Internet connection: static IP, rDNS in your own domain, no filtering
> or DNS hijacking. MacOS X Server isn't a horrible (any more... ) mail
> server and if you're willing to
Hi, I cannot get the fix below to work. Does the Geo::IP package need
to be recompiled for the change to go into effect? If so, any tips on
how to recompile would be greatly appreciated.
Allen
a...@satester.com
On 2015-10-14 12:04, George Ficzeri wrote:
This?
On Wed, 14 Oct 2015, Rejaine Monteiro wrote:
how can i write a rule to get xml attach files from an e-mail?
Headers:
Content-Type: multipart/mixed;
boundary=--boundary_6_9e03550b-93b5-4e32-88c8-2a1cd6037099
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
Hi,
On 10/14/2015 06:08 PM, Dianne Skoll wrote:
On Wed, 14 Oct 2015 17:51:23 -0400
Alex wrote:
I'd like to make sure incoming mail that appears to be "From:" one of
our internal users has indeed gone through one of the systems
specified in the SPF record, resulting in
On Wed, 14 Oct 2015, Rejaine Monteiro wrote:
how can i write a rule to get xml attach files from an e-mail?
Headers:
Content-Type: multipart/mixed;
boundary=--boundary_6_9e03550b-93b5-4e32-88c8-2a1cd6037099
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
On Wed, 14 Oct 2015, Dave Wreski wrote:
Hi,
On 10/14/2015 06:08 PM, Dianne Skoll wrote:
On Wed, 14 Oct 2015 17:51:23 -0400
Alex wrote:
I'd like to make sure incoming mail that appears to be "From:" one of
our internal users has indeed gone through one of the systems
Hi,
I have a few questions about SPF as it relates to spamassassin, and
more specifically, as it relates to stopping incoming phishing
attempts, and assumes we're using "-all".
I'd like to make sure incoming mail that appears to be "From:" one of
our internal users has indeed gone through one of
how can i write a rule to get xml attach files from an e-mail?
Headers:
Content-Type: multipart/mixed;
boundary=--boundary_6_9e03550b-93b5-4e32-88c8-2a1cd6037099
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
Content-Type: application/octet-stream; name=filename.xml
On Wed, 14 Oct 2015 17:51:23 -0400
Alex wrote:
> I'd like to make sure incoming mail that appears to be "From:" one of
> our internal users has indeed gone through one of the systems
> specified in the SPF record, resulting in an SPF_PASS.
Can't be done. SPF looks at
On Tue, 13 Oct 2015, Kevin A. McGrail wrote:
At the end of the day, if you are having problems with new TLDs, ONE solution
is to use something that uses SA 3.4.1 and has sa-update configured so you
get updates with said new TLDs.
I think maybe people are confused about how exactly this
Am 14.10.2015 um 23:51 schrieb Alex:
I have a few questions about SPF as it relates to spamassassin, and
more specifically, as it relates to stopping incoming phishing
attempts, and assumes we're using "-all".
I'd like to make sure incoming mail that appears to be "From:" one of
our internal
2015-10-15 00:09, a...@satester.com wrote:
Does the Geo::IP package need
to be recompiled for the change to go into effect?
No.
Use of uninitialized value $hasStructureInfo in numeric eq (==)
at (eval 31) line 5520
According to comments in Geo/IP.pm your GeoIP database files
must be very
Dave Wreski skrev den 2015-10-15 00:11:
Yes, I realize SPF is only concerned with the envelope-sender. I was
thinking it would be possible to somehow correlate the SPF_PASS with a
rule that analyzes the From: header and use that to compare?
From: header is dkim, just know that some milters
20 matches
Mail list logo