Sounds excellent, we are on the same page. On the cache issue you could have a settable option as to whether they should be cleared or not (would build over time if not). Another way would be to assign an age in the cache yourself and clear them after they have been in the cache for 7 days rather than after they are 7 days of age.
Just some thoughts. Thanks for understanding, and all your work on ASSP. John C. -----Original Message----- From: Thomas Eckardt [mailto:thomas.ecka...@thockar.com] Sent: Friday, 23 May 2014 4:14 PM To: For Users of ASSP Subject: Re: [Assp-user] FW: FW: V14141 >Hopefully this is clearer? Yes John - thank you. V2 will have a fix for this in the next release. ASSP will process its own BATV tags strictly to the draft - there is no need to be more weak. For foreign BATV tags the behavior will be changed. The foreign BATV tags will be parsed using : prvs=[\da-zA_Z]+=......, the tags will be removed (and stored ,if configured so) and will be reused for bounced mails from our internal MTA. Target is that our local users never see a BATV tag and that they never have to care about it. Autowhitelisting will work like expected, because all mail addresses are processed by assp without the BATV tags. At least one issue will be, if a foreign BATV tag does not follow the draft. ASSP has a check for the age of a BATV tag. This is possible, if it follows the draft. Tags older than 7 days will be ignored and the BATV-Cache cleaning code uses this check to remove old cache entries. So it may possible that the next cache cleaning will remove not draft compatible BATV tags - and if a bounce is sent, the tag will be no longer available. Thomas Von: "John Calvi" <webform...@lewis.com.au> An: "'For Users of ASSP'" <assp-user@lists.sourceforge.net> Datum: 23.05.2014 03:55 Betreff: Re: [Assp-user] FW: FW: V14141 I agree BATV is wrong concept and that Message-ID signing is the way to go for ASSP. I was assuming your concern for following the draft was if you were implementing it as a feature in V2 or something that I did not know about, if not then ignore all previous comment about adding the tag on outgoing. I have no interest in BATV feature either except it is adversely affecting my email server. I think I have not explained the issue I am seeing very well. In simple terms I have a LARGE number of (legitimate) clients/suppliers whose email servers envelope sender has a malformed BATV tag. This causes ASSP to not recognise them as otherwise whitelisted. These are not bounce messages but actual regular email messages. I don't see any reason for ASSP to be strict in stripping out BATV tags for the purposes of checking if the envelope sender is on the whitelist or not. There would be no advantage to a spammer in adding a malformed BATV tag as it is the <user @ domain> component that is whitelisted and if a spammer knows that they will get the email through anyway. As such being strict about whether a BATV tag is correct or not for the purposes of checking against the whitelist only harms the user and adds no spam prevention value. Hopefully this is clearer? PS: All of the malformed tags I have seen still at least follow prvs=<some tag value>= but often have 3 digits at the start instead of 4, or a 5 character hash instead of 6 so "prvs=.*=" or "prvs=\d+\w+=" or similar work fine but "prvs=\d\d\d\d\w{6}=" will of course fail to strip out the tags and then ASSP treats the sender as not whitelisted even if they are. John. Some examples below just in the past month... prvs=154507940=user at csiro.au prvs=497c69323=user at sick.com.au prvs=183223242=user at oakleighcentre.org prvs=1883d2545=user at mackayrubber.com.au prvs=1936878be=user at ap.jll.com prvs=20372b8ee=user at nord.com prvs=2077c0d5c=user at portofmelbourne.com prvs=0219cf1c9c=user at neighbourhood.com.au -----Original Message----- From: Thomas Eckardt [mailto:thomas.ecka...@thockar.com] Sent: Friday, 23 May 2014 5:18 AM To: For Users of ASSP Subject: Re: [Assp-user] FW: FW: V14141 BATV is a wrong concept. Use the Message-ID signing. This works hidden and perfect. Thomas Von: "John Calvi" <webform...@lewis.com.au> An: <assp-user@lists.sourceforge.net> Datum: 22.05.2014 09:20 Betreff: [Assp-user] FW: FW: V14141 I certainly don't want to whitelist malformed BATV tags, refer below. The draft is not very strict, BUT I agree ASSP should follow the draft convention for PRVS for its own BATV validation purposes, but it need NOT be strict about stripping other mail servers PRVS implementations out for whitelisting purposes. Eg. If I email thomas.ecka...@thockar.com (with auto whitelisting and BATV PRVS enables) then ASSP should whitelist thomas.ecka...@yourdomain.com and send the email from prvs=1234abcdef=jcalvi@ <mailto:prvs=1234abcdef=jca...@mydomain.com%20> mydomain.com as per the draft. If you then try to reply to me with your server that implements PRVS not exactly as per the draft, eg prvs=1234abcde=thomas.ecka...@yourdomain.com <mailto:prvs=1234abcde=thomas.ecka...@yourdomain.com%20> instead of eg prvs=1234abcdef=thomas.ecka...@yourdomain.com <mailto:prvs=1234abcdef=thomas.ecka...@yourdomain.com%20> then my ASSP server should still recognise that it is you replying and that you were whitelisted. Hope this makes sense. I am seeing these tags from very legitimate users at large multinational companies, Eg NORD.COM, CSIRO.AU, SICK.COM.AU etc. John. ---------------------------------------------------------------------------- -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Assp-user mailing list Assp-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-user 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! ******************************************************* ---------------------------------------------------------------------------- -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Assp-user mailing list Assp-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-user 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! ******************************************************* ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Assp-user mailing list Assp-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-user
