Email message encryption

[Paul Bronson via Info-cyrus]

I am looking for an open source Cisco Ironport type email message encryption 
solution that is open source. I've looked for years but can't find anything. 
Anyone have an ideas? 



Paul

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: IPv6

[ellie timoney via Info-cyrus]

Hi Sebastian,

> after thinking about it, I think it's like this: I added a service that
> was 
> configured to listen on a privileged port. But master has dropped 
> privileges by that point, so it can't add such a listener. I just 
> double-checked that I *can* add a listener at run-time if it's set up to 
> listen to a non-privileged port. Obvious in hindsight, but perhaps worth
> a 
> note anyway.

Oh yeah, of course.  I've added the following to man/master.8 for future
releases:

> Services added or modified to listen on a privileged port may not
> be able to bind the port, depending on your system configuration.
> In this case a full restart is needed.

I'm not entirely sold on the wording, but it's better than the nothing
we had.

"depending on your system configuration", because looking at the code,
if you are running Cyrus on Linux, and if you have compiled it with
--with-libcap=yes, then master will actually drop its privileges
*before* spawning any services at all, but in such a way that it
preserves the capability to bind privileged ports.  Assuming that this
actually works, then it should also be able to start up new/modified
services on privileged ports upon receipt of a SIGHUP.  So that's pretty
cool.  But it's not default: you must be on Linux, have libcap, and
explicitly request it at compile time.

Cheers,

ellie

On Tue, Apr 5, 2016, at 04:22 PM, Sebastian Hagedorn wrote:
> Hi Ellie,
> 
> --On 5. April 2016 um 14:33:46 +1000 ellie timoney  
> wrote:
> 
> >> > Sebastian, is there anything you tried that *didn't* work, and if so,
> >> > what happened?
> >>
> >> The only thing I tried that didn't work was to add a IPv6 listener and
> >> to  HUP the master process. The manpage for master reads (in my version):
> >>
> >>Cyrus-master rereads its configuration file when it receives a
> >> hangup signal, SIGHUP.   Services  and
> >>events  may be added, deleted or modified when the configuration
> >> file is reread.  Any active services
> >>removed from the configuration file will be allowed to run until
> >> completion.
> >>
> >> From that it isn't obvious that some class of changes to cyrus.conf
> >> apparently require a restart of the service.
> >
> > I've been looking through master/master.c to see what it actually does,
> > and it looks like it matches this documentation.
> >
> > It does have some commentary in reread_conf() about recycling services
> > that have not been removed nor were newly added, which almost sounds as
> > if it might have this sort of effect... except that, digging into
> > add_service(), it will only reuse entries if their name, listen and
> > proto all match (which if you've changed one to IPv6, it won't), and
> > otherwise it will be added as a new service (and so reread_conf() will
> > treat it as a newly added service, not an existing one to recycle).
> >
> > I'm pretty tired, and so probably not reading it as closely as I could
> > otherwise -- maybe there's a bug or subtlety I've missed -- but: it at
> > least /looks like it intends to/ do what the documentation says.  So
> > it's interesting that it didn't.
> 
> after thinking about it, I think it's like this: I added a service that
> was 
> configured to listen on a privileged port. But master has dropped 
> privileges by that point, so it can't add such a listener. I just 
> double-checked that I *can* add a listener at run-time if it's set up to 
> listen to a non-privileged port. Obvious in hindsight, but perhaps worth
> a 
> note anyway.
> 
> Cheers
> Sebastian
> -- 
> .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
>  .:.Regionales Rechenzentrum (RRZK).:.
>.:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.
> Email had 1 attachment:
> + Attachment2
>   1k (application/pgp-signature)

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[Binarus via Info-cyrus]

> If you want to see flame wars even more pointless and/or entertaining than 
> this one, check out the mailing lists for DMARC. ;-)  They make these recent 
> exchanges seem quaint by comparison.

I am sorry that this thread is not useful to you. I don't consider it a flame 
war. Every party (except the one who called us "phenomenally stupid") had a 
reasoning which at least is worth thinking about.
 
> FWIW, mailing lists and DMARC make a particularly noxious couple, as almost 
> all mailing lists will break DMARC, and thus lead to all sorts of rejections. 
>  That very subject is the topic of the most vitriolic flame wars on the DMARC 
> lists. 

Maybe. We are currently not interested in DMARC.
  
> At the risk of perpetuating this severely off-topic thread, IMHO if "Binarus" 
> is able to eliminate "90% solely by checking for SPF and DKIM" then one must 
> question just what the rest of their anti-Spam measures were doing?

The answer is quite easy: Until now, there just haven't been any measures 
against SPAM on the server side. Instead, users have used Thunderbird's junk 
filter (which works great IMHO). So, before checking SPF / DKIM, the clients 
actually have received every message which hit the server, except the messages 
which were addressed to non-existent recipients. We know quite well how many 
SPAM got to the clients before and after implementing the SPF / DKIM checks.

The problem with letting the clients doing the SPAM handling (explained by the 
example of my personal account): Once per year, I had to go through the JUNK 
folder to see if there were false positives in that folder. Some weeks ago, 
this ended in manually searching through about 12000 spam message and thereby 
finding about 10 important *ham* messages.

Given some court decisions here in Germany, it could eventually be dangerous to 
not handle a message in a timely manner or even to never know about that 
message if the sender can prove that your server has accepted the message. 
Therefore, there is no way around checking your SPAM folder if you let your MUA 
sort out the SPAM.

Some weeks ago, for a reason I still don't know, the SPAM volume hitting our 
clients suddenly doubled (or tripled, I don't have the exact figures). 
Therefore, we have decided to change our SPAM handling. Nobody is keen on 
scanning 10 SPAM messages at the end of the year (my mailbox is not the 
worst one) ...

By the way, I am now finishing my working day, having got exactly 4 SPAM 
messages (two weeks ago: between 200 und 300 per day).

Regards,

Binarus

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[Nic Bernstein via Info-cyrus]

On 04/05/2016 11:33 AM, Andrew Morgan via Info-cyrus wrote:

On Tue, 5 Apr 2016, lst_hoe02--- via Info-cyrus wrote:



Zitat von Binarus via Info-cyrus :



Combine SPF / DKIM with domain blacklisting, and then you *have* an 
efficient spam fighting tool.




As stated the spam actually reaching our inboxes after around 90% 
cutoff is valid DKIM/SPF signed as it is mostly from the big free 
providers like Outlook.com, Google and Yahoo. Some other big share is 
from professional spam farms with always alternating IP and Domains 
ranges from all over the world with also valid DKIM/SPF. Next big 
share is from educational servers also mostly valid DKIM/SPF. The 
tiny rest with around 10% is in fact not DKIM/SPF signed.
From the valid e-mail around 20% looks like having a valid SPF/DKIM, 
mostly professional newsletters not personal mail from customers.


So No, SPF/DKIM is no useful spam fighting tool at least not in our 
corner of the world.


Another recent standard, DMARC (https://dmarc.org/) allows the domain 
owner to specify what the recipient should do with messages that fail 
DKIM or SPF checks.


We ran into this recently and discovered that Yahoo's DMARC records 
tell the recipient to REJECT messages that fail DKIM or SPF.  Google 
is honoring that DMARC record by putting the message into the Spam 
folder.


This seems like a pretty effective method to prevent someone from 
spoofing email from your domain.  Of course, it does not prevent an 
actual Yahoo account from sending spam, so you still need traditional 
spam detection tools as well.  However, it is nice that a third-party 
sender cannot harm your domain's reputation through spoofing.


Note: I don't care whether this email list uses SPF or DKIM.

Andy


If you want to see flame wars even more pointless and/or entertaining 
than this one, check out the mailing lists for DMARC. ;-)  They make 
these recent exchanges seem quaint by comparison.


   ___
   dmarc-discuss mailing list
   dmarc-disc...@dmarc.org
   http://www.dmarc.org/mailman/listinfo/dmarc-discuss 

FWIW, mailing lists and DMARC make a particularly noxious couple, as 
almost all mailing lists will break DMARC, and thus lead to all sorts of 
rejections.  That very subject is the topic of the most vitriolic flame 
wars on the DMARC lists.


Tho, to be honest, I had assumed that the recent changes to the From and 
Reply-To headers of this mailing list were undertaken to appease strict 
DMARC requirements.


Yes, Google, Yahoo and most of the rest of the Big Boys(c) have adopted 
DMARC with "p=reject" (or whatever that setting is.


At the risk of perpetuating this severely off-topic thread, IMHO if 
"Binarus" is able to eliminate "90% solely by checking for SPF and DKIM" 
then one must question just what the rest of their anti-Spam measures 
were doing?


Cheers,
-nic

--
Nic Bernstein n...@onlight.com
Onlight Inc.  www.onlight.com
6525 W Bluemound Rd., Ste 24  v. 414.272.4477
Milwaukee, Wisconsin  53213-4073  f. 414.290.0335


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[Andrew Morgan via Info-cyrus]

On Tue, 5 Apr 2016, lst_hoe02--- via Info-cyrus wrote:



Zitat von Binarus via Info-cyrus :



Combine SPF / DKIM with domain blacklisting, and then you *have* an 
efficient spam fighting tool.




As stated the spam actually reaching our inboxes after around 90% cutoff is 
valid DKIM/SPF signed as it is mostly from the big free providers like 
Outlook.com, Google and Yahoo. Some other big share is from professional spam 
farms with always alternating IP and Domains ranges from all over the world 
with also valid DKIM/SPF. Next big share is from educational servers also 
mostly valid DKIM/SPF. The tiny rest with around 10% is in fact not DKIM/SPF 
signed.
From the valid e-mail around 20% looks like having a valid SPF/DKIM, mostly 
professional newsletters not personal mail from customers.


So No, SPF/DKIM is no useful spam fighting tool at least not in our corner of 
the world.


Another recent standard, DMARC (https://dmarc.org/) allows the domain 
owner to specify what the recipient should do with messages that fail DKIM 
or SPF checks.


We ran into this recently and discovered that Yahoo's DMARC records tell 
the recipient to REJECT messages that fail DKIM or SPF.  Google is 
honoring that DMARC record by putting the message into the Spam folder.


This seems like a pretty effective method to prevent someone from spoofing 
email from your domain.  Of course, it does not prevent an actual Yahoo 
account from sending spam, so you still need traditional spam detection 
tools as well.  However, it is nice that a third-party sender cannot harm 
your domain's reputation through spoofing.


Note: I don't care whether this email list uses SPF or DKIM.

Andy

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[Binarus via Info-cyrus]

On 05.04.2016 09:34, lst_hoe02--- via Info-cyrus wrote:
 
> The "we generally have to reject all messages which are not secured by SPF or 
> DKIM" mean you want to force others to use non standard headers so in fact 
> you are breaking SMTP RFC.

I think we don't. At least SPF works without additional headers in the messages.

Furthermore, I still can't see how we would break RFCs even if we would "force" 
people to use the DKIM header (in fact, we are not forcing anybody to do so, 
because we let messages pass which have at least *one* of SPF or DKIM passed): 
The RFCs nowhere say that every MTA MUST accept ANY message regardless of the 
sender, connecting server etc. On the contrary, the RFCs explicitly name 
mechanisms (e.g. DSNs) which should be used if a message cannot be delivered to 
its recipient, and people are rejecting messages (and returning appropriate 
DSNs) according to their own policies for decades now.

If you are saying that not accepting *all* messages means breaking the RFCs, I 
disagree.

What I exceptionally like about the way we have implemented the SPF and DKIM 
checks is that the sender gets informed about the problem because he will 
receive an appropriate DSN containing a polite message which explains the 
problem. In summary, I am convinced that our MTA's behavior conforms with the 
RFCs.

> It is your server so your rules, but don't complain if other do not agree 
> with you.

I promise I won't :-)

Regards,

Binarus

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[Binarus via Info-cyrus]

On 05.04.2016 14:15, Alvin Starr via Info-cyrus wrote:
> 
> I kind of have to agree with Andreas to some extent on this.
> SPF/DKIM does not help on incoming spam filtering all that much just because 
> so few people use it and the default action is to accept mail that has no 
> SPF/DKIM tagging.

Our default action is to reject all messages which do not pass either the SPF 
or the DKIM test.

> 
> It is great however for controlling how other people abuse your email address.
> SPF can stop people from sending mail as you from systems that are not your 
> own.

Not really, AFAIK. Even if you add the SPF record to your domain's DNS, a 
spammer of course can still use @ as envelope 
sender or From: header. It is the receiving part who checks if the connecting 
MTA (i.e. the "sending server") is allowed to send messages for  (the check is done by querying the name server for  for 
the SPF record and then checking if the sending (connecting) server one of the 
servers the SPF record allows).

In other words, if no SPF checks are done by the *receiving* MTAs, fake 
messages will make their way through the net without problems.
 
> I would argue that anybody operating a mail server should use SPF/DKIM just 
> to make sure they are not helping the spammers.

I strongly agree.
 
> Sadly putting these tools in place is not trivial and it will only be when 
> postfix, sendmail, qmail and others include SPF/DKIM setups as part of the 
> default install can things really start to change.

Actually, I have been surprised how ridiculously easy I could setup the 
*sending* part of SPF. Using SPF as a sender means adding one TXT record (whose 
syntax can't be simpler) to your DNS records; this could be done within minutes 
(no more true if you want your MTA to forward messages from other domains; 
that's a special case). DKIM is slightly more complicated since it needs 
additional software which must be interfaced to the MTA. I used opendkim and 
liked it very much, though.

Checking SPF and DKIM (the *receiving* part) was much more complicated in our 
case, though. So I would recommend everybody who wants to improve email 
security to start with the sending part. If you don't forward messages for 
other domains, just start with adding the SPF record to your name server (and 
end that record with "-all" in every case, despite other examples which could 
be found on the net).

Regards,

Binarus

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[Binarus via Info-cyrus]

On 05.04.2016 09:42, lst_hoe02--- via Info-cyrus wrote:
> 
> As stated the spam actually reaching our inboxes after around 90% cutoff is 
> valid DKIM/SPF signed as it is mostly from the big free providers like 
> Outlook.com, Google and Yahoo. Some other big share is from professional spam 
> farms with always alternating IP and Domains ranges from all over the world 
> with also valid DKIM/SPF. Next big share is from educational servers also 
> mostly valid DKIM/SPF. The tiny rest with around 10% is in fact not DKIM/SPF 
> signed.
> From the valid e-mail around 20% looks like having a valid SPF/DKIM, mostly 
> professional newsletters not personal mail from customers.
> 
> So No, SPF/DKIM is no useful spam fighting tool at least not in our corner of 
> the world.
> 

We seem to be located in the same country (Germany), nevertheless the situation 
is completely different for us. As I have already reported, we have cut off 
SPAM by 90% solely by checking for SPF and DKIM, and it looks like we could cut 
down it by another order of magnitude if we are blacklisting domains which have 
sent SPF- or DKIM-"signed" SPAM (doing so for a few days, but no exact figures 
yet).

I admit that our situation is somewhat special because we are purely B2B, and I 
absolutely don't care about a freemail provider being blacklisted. I can't even 
remember the last time when we got a valid message which has been sent from a 
freemailer account.

Actually, if everybody did SPF or DKIM tests, this finally would force the 
providers to implement DKIM or SPF the right way. For example, using an 
individual DKIM signature for every sender of a domain is ridiculously easy (at 
least when using the opendkim daemon). That would be a great progress because 
then you could blacklist individual senders instead of the provider.

Regards,

Binarus


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[Binarus via Info-cyrus]

On 04.04.2016 23:02, Vincent Fox via Info-cyrus wrote:
> I'll admit I am testing SPF as a greylisting measure.
> Your IP gets hardfail, you get 5min deferral.
> 
> I don't delude myself it does anything other than catch maybe
> 5-10% of spammers that don't bother with retries.  More often it
> seems to catch people like a major network backbone operation
> that OUGHT to know better, that has no SPF and acted like it
> was going to require committees and 2 months for the
> brain surgery.
> 
> YMMV indeed.
> 

Well, that seems to be the case. I have no reason to boast here; it is indeed 
true that we cut down the number of spam messages by 90% solely by rejecting 
all messages without one of SPF or DKIM. Since a few days, we are blacklisting 
the domains which have sent SPAM, and now it looks like we could cut down the 
SPAM an additional order of magnitude by doing so (no exact figures yet).

Regards,

Binarus


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[Binarus via Info-cyrus]

On 04.04.2016 21:50, Joseph Brennan via Info-cyrus wrote:
> 
>> But with SPF or DKIM, you can immediately blacklist any sender
>> domain after having received SPAM from that domain.
> 
> It would never be a phished stolen account, so that would be safe.
> 

You are right. It is the only logical thing to accept emails from stolen or 
phished accounts for the sole reason that they have been stolen or phished.

Joking apart: After having repaired the problem, the victim (i.e. the 
legitimate, white-hat real owner of the account) hopefully sees the DSNs, and, 
if his message is important, might call us and ask what has happened.

Even more, the DSN from our MTA eventually might let the "real owners" know 
that somebody is doing damage to them. Did you think about that? By the way, 
there are countries where you are liable if you send viruses, and in those 
countries, people might be even more grateful if they receive a DSN after a 
spammer has abused their account.

Regards,

Binarus



Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[Alvin Starr via Info-cyrus]

On 04/05/2016 03:42 AM, lst_hoe02--- via Info-cyrus wrote:


Zitat von Binarus via Info-cyrus :



Combine SPF / DKIM with domain blacklisting, and then you *have* an 
efficient spam fighting tool.




As stated the spam actually reaching our inboxes after around 90% 
cutoff is valid DKIM/SPF signed as it is mostly from the big free 
providers like Outlook.com, Google and Yahoo. Some other big share is 
from professional spam farms with always alternating IP and Domains 
ranges from all over the world with also valid DKIM/SPF. Next big 
share is from educational servers also mostly valid DKIM/SPF. The tiny 
rest with around 10% is in fact not DKIM/SPF signed.
From the valid e-mail around 20% looks like having a valid SPF/DKIM, 
mostly professional newsletters not personal mail from customers.


So No, SPF/DKIM is no useful spam fighting tool at least not in our 
corner of the world.


I kind of have to agree with Andreas to some extent on this.
SPF/DKIM does not help on incoming spam filtering all that much just 
because so few people use it and the default action is to accept mail 
that has no SPF/DKIM tagging.


It is great however for controlling how other people abuse your email 
address.
SPF can stop people from sending mail as you from systems that are not 
your own.
DKIM signs your messages so that you have assurance that they are coming 
from your mail servers.


I would argue that anybody operating a mail server should use SPF/DKIM 
just to make sure they are not helping the spammers.


Sadly putting these tools in place is not trivial and it will only be 
when postfix, sendmail, qmail and others include SPF/DKIM setups as part 
of the default install can things really start to change.



--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[lst_hoe02--- via Info-cyrus]

Zitat von Binarus via Info-cyrus :



Combine SPF / DKIM with domain blacklisting, and then you *have* an  
efficient spam fighting tool.




As stated the spam actually reaching our inboxes after around 90%  
cutoff is valid DKIM/SPF signed as it is mostly from the big free  
providers like Outlook.com, Google and Yahoo. Some other big share is  
from professional spam farms with always alternating IP and Domains  
ranges from all over the world with also valid DKIM/SPF. Next big  
share is from educational servers also mostly valid DKIM/SPF. The tiny  
rest with around 10% is in fact not DKIM/SPF signed.
From the valid e-mail around 20% looks like having a valid SPF/DKIM,  
mostly professional newsletters not personal mail from customers.


So No, SPF/DKIM is no useful spam fighting tool at least not in our  
corner of the world.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[lst_hoe02--- via Info-cyrus]

Zitat von Binarus via Info-cyrus :


On 04.04.2016 18:12, Sebastian Hagedorn via Info-cyrus wrote:
Personally, I think that's a phenomenally stupid approach. As long  
as you can't show me an RFC that says you MUST or even SHOULD use  
SPF or DKIM, you're breaking SMTP.


I think it's a phenomenally intelligent approach. I can't see in  
which way SMTP is broken by using DKIM or SPF. The DKIM signature is  
in an additional header (additional headers *are* allowed by the  
RFCs), and signing and checking usually is done by milters (I am  
sure that you know them). If a message is rejected by the receiving  
MTA due to failing SPF or DKIM, the sender will get a DSN (which is  
perfectly in conformance with the RFCs).


By the way, many people use all sorts of mail filtering and DSNs  
(and do so since 20 years and more) without an RFC saying they  
SHOULD or MUST do so. Are all people which use any sort of mail  
filter breaking SMTP as well?


Could you please give an example of an SMTP RFC which is violated by  
SPF or DKIM?


Regards,

Binarus




Due to the exponential increase of spam, we generally have to reject all
messages which are not secured by SPF or DKIM, and we know a lot of other
people who do the same (by the way, this has proven to be extremely
effective in our case). When our MTA encounters such a message, it
rejects it and returns a bounce message to the pretended sender,
notifying him about the problem.


The "we generally have to reject all messages which are not secured by  
SPF or DKIM" mean you want to force others to use non standard headers  
so in fact you are breaking SMTP RFC.


It is your server so your rules, but don't complain if other do not  
agree with you.


Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: IPv6

[Sebastian Hagedorn via Info-cyrus]

Hi Ellie,

--On 5. April 2016 um 14:33:46 +1000 ellie timoney  
wrote:



> Sebastian, is there anything you tried that *didn't* work, and if so,
> what happened?

The only thing I tried that didn't work was to add a IPv6 listener and
to  HUP the master process. The manpage for master reads (in my version):

   Cyrus-master rereads its configuration file when it receives a
hangup signal, SIGHUP.   Services  and
   events  may be added, deleted or modified when the configuration
file is reread.  Any active services
   removed from the configuration file will be allowed to run until
completion.

From that it isn't obvious that some class of changes to cyrus.conf
apparently require a restart of the service.


I've been looking through master/master.c to see what it actually does,
and it looks like it matches this documentation.

It does have some commentary in reread_conf() about recycling services
that have not been removed nor were newly added, which almost sounds as
if it might have this sort of effect... except that, digging into
add_service(), it will only reuse entries if their name, listen and
proto all match (which if you've changed one to IPv6, it won't), and
otherwise it will be added as a new service (and so reread_conf() will
treat it as a newly added service, not an existing one to recycle).

I'm pretty tired, and so probably not reading it as closely as I could
otherwise -- maybe there's a bug or subtlety I've missed -- but: it at
least /looks like it intends to/ do what the documentation says.  So
it's interesting that it didn't.


after thinking about it, I think it's like this: I added a service that was 
configured to listen on a privileged port. But master has dropped 
privileges by that point, so it can't add such a listener. I just 
double-checked that I *can* add a listener at run-time if it's set up to 
listen to a non-privileged port. Obvious in hindsight, but perhaps worth a 
note anyway.


Cheers
Sebastian
--
   .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
.:.Regionales Rechenzentrum (RRZK).:.
  .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.

pgpRxGxAmv9hJ.pgp
Description: PGP signature

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus