Wow, you didn't waste any time on getting my ARC suggestion in there!!!
thank you

Question: I read the IETF draft carefully and >think< that I understand
that ARC signing is verified just like DKIM is, looking at the public key
via DNS.  It really is a clever idea and should be really helpful here as
more providers adopt the technology.   If we opt to do our own ARC signing
(which I doubt know we're ready to do anyway until the rest of the servers
here support it), what hostname will be used for the singnature?  Will it
be signed with the ASSP machine hostname?   If so, we'd need to but the
private key for assp.OurCharity.org (which doesn't exist yet) to the DKIM
confi file right?

Thanks again Thomas.  This is great.


On Tue, Apr 10, 2018 at 9:31 AM, Thomas Eckardt <thomas.ecka...@thockar.com>
wrote:

> Hi all,
>
> fixed in assp 2.6.2 *Fortress* build 18100:
>
>
> - the analyzer now prevents duplicate feature matching lines
>
> - because the DKIM check was skipped, if assp has changed or removed
> headerlines, DKIMWLAddresses and DKIMNPAddresses was not working in every
> case
>
> - myNameAlso was synchronized, this is no longer the case
>
> - on some OS the 'autoflush' was not working for rebuild output files
>
>
> changed:
>
> - a regular expression containing the values of myName and myNameAlso is
> added to 'trustedAuthForwarders' every time (if myName is not set to
> ASSP.nospam)
>
> - the recommended version of Mail::DKIM::Verifier (Mail::DKIM) is changed
> to 0.50
>
>
> Thomas
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> OFF - the changelog.txt
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>
>
>
> This release contains major code changes for new features. All of them are
> disabled per default. You are free to test them. But more important for me
> is to know, if the code is working well without using the new features.
>
> 1.
>
> It is possible to create an UTF8 text file 'files/disclaimer.txt'.
> If your Server/Clients adds always the same disclaimer to all emails, it
> may possible, that HMM and Bayesian are providing wrong results, because
> this disclaimer
> is found in many corpus files (spam amd notspam). Such disclaimers should
> be written in to this file. ASSP will build a regular expression for the
> disclaimers and will remove them from the email content,
> before the rebuild task analyzes the emails. The disclaimers should be
> written in to this file, the same way they are shown in the mail client.
> Lines starting with a '#' are comments and are ignored. Combine multiple
> disclaimers with a line, that contains only one dot (like
> EMAIL-END-Sequence).
>
> example 1:
>
> This is a multiline
> disclaimer.
>
> example 2:
>
> # our first disclaimer
> This is our first disclaimer.
> It contains several lines.
> .
> #This is our second disclaimer
> This disclaimer is used by the
> IT stuff
>
>
> 2.
> our $DoARC = 0; # (0/1/2/3) do ARC - Authenticated Received Chain
> 0=disabled, 1=verify, 2=sign, 3=verify and sign  !!!!  EXPERIMENTAL  !!!!
> (to be configured in 'lib/CorrectASSPcfg.pm')
>
> Authenticated Received Chain is still experimental, but used in production
> mode by gmail, AOL and some others. The draft is available at
> https://www.ietf.org/id/draft-ietf-dmarc-arc-protocol-13.txt - there is
> still no RFC stated.
> If verify is enabled (1/3) - and such a valid Authenticated Received Chain
> Signature stucture is provided by a host/domain (d=... TAG) matching
> 'trustedAuthForwarders', assp will trust the provided results for DKIM, SPF
> and DMARC.
> If ARC-signing is anabled (2/3), an Authenticated Received Chain Signature
> is added to every incoming and outgoing email by assp - providing the
> results for DKIM, SPF and DMARC (if available) to the next mail hops.
>
> The goal:
>
> Mail forwarders (like assp) may change DKIM protected mail headers and/or
> the body. If so, every received DKIM-signature will become invalid.
> It may also possible, that a mail is forwarded by a mailing list provider
> or another forwarder - which may cause SPF to fail.
> If DKIM or SPF fails, DMARC may also fail.
> ARC-signing gives the forwarder the chance, to provide its own calculated
> results for DKIM, SPF and DMARC to the next mail hops in a secure way.
> Faking such a signature is NOT possible, it is the same way protected by a
> RSA key pair, like DKIM signatures.
> If any of the next mail hops is able to process provided ARC-signatures,
> it will be able to check, if the origin of the email is valid or not (e.g.
> was valid, when the mail was received by the forwarder)..
>
>
>
>
> DISCLAIMER:
> *******************************************************
> This email and any files transmitted with it may be confidential, legally
> privileged and protected in law and are intended solely for the use of the
> individual to whom it is addressed.
> This email was multiple times scanned for viruses. There should be no
> known virus in this email!
> *******************************************************
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Assp-test mailing list
> Assp-test@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/assp-test
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test

Reply via email to