On 28/08/2016 02:48, Lyle wrote:
> Use any in the allow stanza.
You'll be using a shared key for this to work anyway, but I'd suggest
being slightly more paranoid than 'any' in the allow stanza - perhaps
the address range in which your local machine is to be allocated its
address?
___
Sorry...wrong post. After a little bit more testing, the errors are
still appearing. The masterfile-format didn't solved the errors
Thank you,
Tom
On 08/30/2016 08:20 AM, Tom wrote:
Hi list
After some more troubleshooting, I was able to locate the problem:
- One Spamhaus-Zone-File (dbl
Hi list
After some more troubleshooting, I was able to locate the problem:
- One Spamhaus-Zone-File (dbl.rpz.spamhaus.org, ca. 180MB in
"masterfile-format text;") is loaded correctly, but if this zone is
loaded, then I got the mentioned errors.
- Configuring the "masterfile-format map;" for thi
Hi list
Using self-compiled latest bind (9.10.4-P2):
I have a bind-setup with activated response-policy-zones. For *each*
client-forward-query, which has a valid dns-response, I got an error in
the client-log (for NXDOMAIN-Reponses, I didn't have such errors... ex.
"dig @nameserver aasledkfja
In article you write:
>Awesome, Actually one more question. If we allow folks from another domain
>to send as us is there a chance anywhere in any of the email "from" headers
>it would reveal the "true" domian?
The names of their servers will show up in Received headers. It is a
poor idea to ass
If alphazulu.com is sending email as foxtrot.com it would be best to
sign the message as foxtrot.com as well so that the signature is
"aligned" from a DMARC standpoint (matches the From domain).
The keys are always in the domain specified by the d= value in the
signature. The best approach is for
Yes of course as that would be the original sender of the email and their
information would also be in your SPF policy. You can change the Sender and
Reply-to headers to be from your domain and mask it a bit better but the
received by headers would show the alphazulu.com mail server.
On Mon, Aug
Glad to help! If you need a low cost DMARC reporting service, I would
recommend www.dmarcian.com
On Mon, Aug 29, 2016 at 10:33 AM project722 wrote:
> Thanks guys - very helpful information indeed.
>
> On Mon, Aug 29, 2016 at 9:08 AM, Mike Ragusa wrote:
>
>> Ideally it is best to use both techno
Awesome, Actually one more question. If we allow folks from another domain
to send as us is there a chance anywhere in any of the email "from" headers
it would reveal the "true" domian?
eg..
folks at alphazulu send as @foxtrot.com.
Would @alphazulu.com appear anywhere in the headers?
On Mon, Au
Thanks guys - very helpful information indeed.
On Mon, Aug 29, 2016 at 9:08 AM, Mike Ragusa wrote:
> Ideally it is best to use both technologies and then put DMARC on top to
> ensure reporting and enforcement of the policies. DKIM cryptographically
> signs your messages and SPF informs receiving
Ideally it is best to use both technologies and then put DMARC on top to
ensure reporting and enforcement of the policies. DKIM cryptographically
signs your messages and SPF informs receiving mail servers of who is
allowed to send on your behalf. You should not think of using only one or
the other
What about DKIM only? Can it be used instead of, or, as a "replacement" for
SPF? For example mails are signed with DKIM from the SMTP servers, and the
receiving servers are checking both SPF and DKIM. If the receiving server
detected a missing SPF would it allow mail through if DKIM is present and
2016-08-25 17:16 GMT+07:00 Tony Finch :
> Aleks Ostapenko wrote:
> >
> > Then I made `rndc freeze `. But after this command - the
> > signed zone file (`.signed`) still remain
> > in raw format (not text readable) - so I can read it via
> > `named-compilezone` utility, but unfortunately I can't c
13 matches
Mail list logo
