Re: [qmailtoaster] multiple email

2016-07-21 Thread Sean P. Murphy 
Yes.  Usually two per post.  The last few haven't "duped", though.

-Sean

> On Jul 21, 2016, at 7:42 PM, Tony White  wrote:
> 
> Yes.
> Actually getting three on occasions.
> 
> best wishes
>   Tony White
> 
> On 22/07/2016 09:24, Jaime Lerner wrote:
>> YES. :)
>> 
>> From: Eric 
>> Reply-To: 
>> Date: Thursday, July 21, 2016 at 7:12 PM
>> To: 
>> Subject: [qmailtoaster] multiple email
>> 
>> Are others receiving multiple emails from the qmailtoaster list?
>> 
>> -
>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>

Re: [qmailtoaster] multiple email

2016-07-21 Thread Tony White 

Yes.
Actually getting three on occasions.

best wishes
  Tony White

On 22/07/2016 09:24, Jaime Lerner wrote:


YES. :)

From: Eric >
Reply-To: >
Date: Thursday, July 21, 2016 at 7:12 PM
To: >
Subject: [qmailtoaster] multiple email

Are others receiving multiple emails from the qmailtoaster list?

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com 


For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] multiple email

2016-07-21 Thread Jaime Lerner 
YES. :)

From:  Eric 
Reply-To:  
Date:  Thursday, July 21, 2016 at 7:12 PM
To:  
Subject:  [qmailtoaster] multiple email

Are others receiving multiple emails from the qmailtoaster list?

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] multiple email

2016-07-21 Thread Eric 

Are others receiving multiple emails from the qmailtoaster list?

-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

RE: [qmailtoaster] temporarily disable a domain

2016-07-21 Thread Dan McAllister - QMT DNS Admin 
I never saw a reply to this, so I’ll pipe up here

 

When you “lose a domain” but need to keep “supporting” that domain (e.g. so 
users can still get to their old mail), the thing to do is to create a rule 
that forwards messages addressed to that domain to the correct server.

Step 1: Remove the domain from the list of LOCAL DOMAINS (see 
/var/qmail/control/[locals | rcpthosts | virtualdomains]

Step 2: Create a rule to forward mail for that domain to the correct server 
(entry in /var/qmail/control/smtproutes)

 

To explain:

In Step 1 we had to remove the local-delivery mechanism for .tv – that is, 
STOP processing mail received by SMTP as-if we were a valid server for that 
domain

In Step 2 we had to tell the server just what to do with mail from that domain. 
See our wiki (http://wiki.qmailtoaster.com/index.php/Smtproutes) for a full 
explanation of smtproutes, and know that QMT already includes the 
qmail-remote-auth patch mentioned

 

NOTES: 

-  If you still wish to receive mail for that domain, but just forward 
it to the other server, you can do so by restoring the entry in rcpthosts

-  If you are worried about SPF or other types of issues that this kind 
of forwarding can cause, create a “back channel” connection. This takes 
advantage of QMT’s allowing any authorized user to send mail as any user they 
want! To do this, just add account authentication on the end of the smtproutes 
entry.

 

I hope you find this useful

 

Dan McAllister

IT4SOHO

 

 

 

From: Jim Shupert [mailto:jshup...@pps-inc.com] 
Sent: Friday, July 15, 2016 5:21 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: [qmailtoaster] temporarily disable a domain

 

Friends

I wish to temporarily disable or sever a domain on my qmailtoaster

I have 4 domains

.com
.com
.com
.tv   

and .tv is being moved ( maybe )

In truth
the folks who "are" .tv are having thier mail going to a 
rackspace mail providing service /server

so you could say i am losing them as a client ...
they have changed thier A record & the dns
But they are in the same bldging - the users are inside the same router / 
firewall.

( .tv  is a division of a master company that is .com )

my goal is to disable "my" .tv 
so that all the world sees the rackspace .tv 


I see under
Qmail Toaster Admin

http://mailhost..com/mail/vqadmin/toaster.vqadmin?nav=view_domain 

 =.tv

6 check boxes

Disable pop access   
Disable imap access   
Disable dialup access   
Disable change password   
Disable web access   
Disable email relay 

if I check  

Disable pop access   
Disable imap access 
( or all six )

and click   Modify Domain

will "my" .tv  effectively be "turned OFF"

and I could then , if i wish to , unCheck & Modify Domain there by turn it "on"


thanks

sorry this is a wacky Q

RE: [qmailtoaster] DMARC checking?

2016-07-21 Thread Dan McAllister - QMT DNS Admin 
LOL - Thanks for the "education" about DMARC :)

For the record, I depend heavily on DMARC records -- but 90% of mail servers 
that will even check for SPF, do so with the SPF record in mind, and not the 
DMARC one. As I asserted in my original message, only a few "big guns" are even 
looking at the DMARC records at all, much less providing the response 
mechanisms.

To my knowledge, the DMARC record cannot REPLACE the SPF record (they're both 
just TXT record lookups), but the DMARC record CAN tell a recipient server that 
you are interested in hearing about "bad mail" from your domain(s).
(Most SPF records end with a "~all" -- which is actually an indication that 
you're "just testing SPF" and creating a "soft fail" when it is violated. MY 
SPF records end with "-all" [that would be a DASH instead of a TILDE] -- which 
is an indication that we think we know what we're doing, and if It fails SPF, 
it should be considered a HARD FAIL... what you do with it after that is up to 
the recipient mail server. The supposition is that, someday, most will reject 
or discard HARD FAIL messages, but even in QMail, we have our own options (read 
up on SPF levels), so not everyone is playing by the same rules.)

Generally equivalent statements can be made about DKIM.

In NEITHER case have I seen any kind of documentation on what an organization 
is supposed to do if SPF says to HARD FAIL any disproven sender, but DMARC says 
not to... or the other way around!

So I repeat my assertion that the real VALUE of DMARC is in the back-reporting 
function which I will repeat has helped me numerous times to detect an 
issue BEFORE other mechanisms (like RBLs) have been triggered!

As you might expect, my servers & domains use SPF and DMARC -- and if we had 
better processing (long-standing bug) in QMAIL for DKIM, I would use it too!

Cheers!

Dan McAllister

PS: Perhaps when I retire in a few years I'll fix the DKIM processing and 
create DMARC processing for QMAIL :) 
Most on here don't know it, but I started in SW development tracking missiles 
at CCAFS!


-Original Message-
From: Eric [mailto:ebr...@whitehorsetc.com] 
Sent: Thursday, July 21, 2016 2:05 AM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] DMARC checking?

Dan,

This is from the DMARC website
(https://dmarc.org/wiki/FAQ#How_does_DMARC_work.2C_briefly.2C_and_in_non-technical_terms.3F):

"How does DMARC work, briefly, and in non-technical terms?"

"A DMARC policy allows a sender to indicate that their messages are protected 
by SPF and/or DKIM, and tells a receiver what to do if neither of those 
authentication methods passes – such as junk or reject the message. DMARC 
removes guesswork from the receiver’s handling of these failed messages, 
limiting or eliminating the user’s exposure to potentially fraudulent & harmful 
messages. DMARC also provides a way for the email receiver to report back to 
the sender about messages that pass and/or fail DMARC evaluation."

And:

"Why is DMARC needed?"

"End users and companies all suffer from the high volume of spam and phishing 
on the Internet. Over the years several methods have been introduced to try and 
identify when mail from (for example) IRS.GOV really is, or really isn’t coming 
from the IRS. However:

 These mechanisms all work in isolation from each other
 Each receiver makes unique decisions about how to evaluate the results
 The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:

 Domain owners to:
 Signal that they are using email authentication (SPF, DKIM)
 Provide an email address to gather feedback about messages using their 
domain – legitimate or not
 A policy to apply to messages that fail authentication (report, 
quarantine, reject)

 Email receivers to:
 Be certain a given sending domain is using email authentication
 Consistently evaluate SPF and DKIM along with what the end user sees 
in their inbox
 Determine the domain owner’s preference (report, quarantine or
reject) for messages that do not pass authentication checks
 Provide the domain owner with feedback about messages using their 
domain

A domain owner who has deployed email authentication can begin using DMARC in 
“monitor mode” to collect data from participating receivers. As the data shows 
that their legitimate traffic is passing authentication checks, they can change 
their policy to request that failing messages be quarantined. As they grow 
confident that no legitimate messages are being incorrectly quarantined, they 
can move to a 'reject' policy."

It seems to me that the DMARC website indicates that not only is feedback 
provided for but a message policy (report, quarantine, reject) for failed 
authentication.

Correct me if I'm wrong.

Eric





On 7/20/2016 4:57 PM, Dan McAllister - QMT DNS Admin wrote:
> I'm not sure what you mean by

Re: [qmailtoaster] DMARC checking?

2016-07-21 Thread Eric 

Dan,

This is from the DMARC website 
(https://dmarc.org/wiki/FAQ#How_does_DMARC_work.2C_briefly.2C_and_in_non-technical_terms.3F):


"How does DMARC work, briefly, and in non-technical terms?"

"A DMARC policy allows a sender to indicate that their messages are 
protected by SPF and/or DKIM, and tells a receiver what to do if neither 
of those authentication methods passes – such as junk or reject the 
message. DMARC removes guesswork from the receiver’s handling of these 
failed messages, limiting or eliminating the user’s exposure to 
potentially fraudulent & harmful messages. DMARC also provides a way for 
the email receiver to report back to the sender about messages that pass 
and/or fail DMARC evaluation."


And:

"Why is DMARC needed?"

"End users and companies all suffer from the high volume of spam and 
phishing on the Internet. Over the years several methods have been 
introduced to try and identify when mail from (for example) IRS.GOV 
really is, or really isn’t coming from the IRS. However:


These mechanisms all work in isolation from each other
Each receiver makes unique decisions about how to evaluate the results
The legitimate domain owner (e.g. IRS) never gets any feedback

DMARC attempts to address this by providing coordinated, tested methods for:

Domain owners to:
Signal that they are using email authentication (SPF, DKIM)
Provide an email address to gather feedback about messages 
using their domain – legitimate or not
A policy to apply to messages that fail authentication (report, 
quarantine, reject)


Email receivers to:
Be certain a given sending domain is using email authentication
Consistently evaluate SPF and DKIM along with what the end user 
sees in their inbox
Determine the domain owner’s preference (report, quarantine or 
reject) for messages that do not pass authentication checks
Provide the domain owner with feedback about messages using 
their domain


A domain owner who has deployed email authentication can begin using 
DMARC in “monitor mode” to collect data from participating receivers. As 
the data shows that their legitimate traffic is passing authentication 
checks, they can change their policy to request that failing messages be 
quarantined. As they grow confident that no legitimate messages are 
being incorrectly quarantined, they can move to a 'reject' policy."


It seems to me that the DMARC website indicates that not only is 
feedback provided for but a message policy (report, quarantine, reject) 
for failed authentication.


Correct me if I'm wrong.

Eric





On 7/20/2016 4:57 PM, Dan McAllister - QMT DNS Admin wrote:

I'm not sure what you mean by DMARC checking?
Generally, SPF is triggered by the existence of an appropriate DNS entry, while 
a DKIM check would be triggered by a DKIM signature in the header of the 
message.
The point of DMARC isn't to trigger any checking, it is to provide a FEEDBACK 
mechanism to senders whose domains may be being attacked or otherwise abused.
AFIK, only a few MAJOR mail providers are actively providing that feedback -- 
but even so, it's been EXTREMELY valuable to me as an ESP admin! They have 
helped me capture abuse far faster than otherwise possible!

So again, I'm not sure what you're asking for with regards to DMARC

Dan McAllister
IT4SOHO

-Original Message-
From: Eric [mailto:ebr...@whitehorsetc.com]
Sent: Wednesday, July 20, 2016 12:44 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] DMARC checking?

Jaime,

I'm not sure. It can be run from the command line so I'm wondering if it could 
not be put in a .qmail/.mailfilter file or even implemented with 
Dovecot...somehow?

Eric


On 7/20/2016 9:07 AM, Jaime Lerner wrote:

Is it possible to set up inbound DMARC checking on a QMT setup?


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com