Re: stable branch vs trunk (was: Re: colors TLDs in spam)
On Sun, 2014-08-03 at 09:22 -0400, Kevin A. McGrail wrote:
Hi Karsten, I did bring this up a few months ago discussing releases.
I'm currently catching up on list mail, and figured recent threads might
be more important than revising old-ish, finished threads, in particular
about releases already published. *sigh*
Right now trunk is effectively 3.4.1 and there is no reason to
maintain a branch. When 3.4.1 is released, I would make sure this was
the case and recopy from trunk but do not stress as I will confirm
this. We should aim for a sept 30 3.4.1 release.
But until we have a need for the branch, to me it is a waste of time
to sync both.
Fair enough.
And the plugin system let's new, experimental code go into trunk
without risking stability.
That holds true only for new plugins, like TxRep (trunk) or the Redis
BayesStore during 3.4 development. It does not prevent potential major
issues in cases like e.g. new URIDNSBL features, general DNS system
rewrite or tflags changes, which happened in trunk with the (then)
stable 3.3 branch being unaffected.
Not opposing in general. Just pointing out that this argument is only
valid, as long as substantial changes are in fact isolated in new
plugins.
So right now, I do not really envision a need for a branch and I run
trunk. My $0.02.
Hey, I didn't say trunk is unsafe either! Even while Mark happens to
rewrite large parts of DNS handling or DNSBL return value masks. ;)
As long as there is no real need for separating stable and development
branches, I'm fine with this. Given branching will happen prior to
disruptive commits.
I guess my concerns also can be outlined by anecdotal evidence: I
recently asked for RTC votes, to commit a patch not only to trunk, but
the 3.4 branch also. You told me we're not in RTC mode and to go ahead,
so I committed to the stable branch and closed the bug report. You did
not tell me committing to the branch would be needless...
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: stable branch vs trunk (was: Re: colors TLDs in spam)
Hi Karsten, I did bring this up a few months ago discussing releases. Right
now trunk is effectively 3.4.1 and there is no reason to maintain a branch.
When 3.4.1 is released, I would make sure this was the case and recopy from
trunk but do not stress as I will confirm this. We should aim for a sept 30
3.4.1 release.
But until we have a need for the branch, to me it is a waste of time to sync
both. And the plugin system let's new, experimental code go into trunk without
risking stability. So right now, I do not really envision a need for a branch
and I run trunk. My $0.02.
Regards,
KAM
Karsten Bräckelmann guent...@rudersport.de wrote:
On Fri, 2014-08-01 at 18:59 -0400, Kevin A. McGrail wrote:
On 8/1/2014 6:43 PM, Karsten Bräckelmann wrote:
That's trunk only. IMHO this should also be committed to the
current
stable (3.4) branch.
In a normal process, yes but right now, there is no difference
Worse. There are already other easy fixes [1], which have been
committed
to trunk only, despite an explicit Target Milestone of 3.4.1.
and I plan on likely blowing away the 3.4.0 branch and releasing
trunk
as 3.4.1 to be honest.
I don't like likely in this context. Either that is a definite plan,
and there won't be any heavy changes to trunk before cutting 3.4.1, or
we'd need to commit more patches to both stable and trunk.
Also, what do you mean blowing away the 3.4 branch? Recreating from
trunk once? Or cutting stable releases from trunk always, until you
branch (rather release) the next minor version 3.5.0 from trunk?
Which
would mean backporting important fixes becomes almost impossible,
because there simply is no branch other than trunk...
I'm quiet uneasy just thinking about that. Probably worth shifting over
to the dev@ list...
[1] Using plural in a general and kind of extrapolating way. In fact,
this is based on bug 7065, which I just came across wading through
dev@ backlog.
--
char
*t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8?
c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){
putchar(t[s]);h=m;s=0; }}}
stable branch vs trunk (was: Re: colors TLDs in spam)
On Fri, 2014-08-01 at 18:59 -0400, Kevin A. McGrail wrote:
On 8/1/2014 6:43 PM, Karsten Bräckelmann wrote:
That's trunk only. IMHO this should also be committed to the current
stable (3.4) branch.
In a normal process, yes but right now, there is no difference
Worse. There are already other easy fixes [1], which have been committed
to trunk only, despite an explicit Target Milestone of 3.4.1.
and I plan on likely blowing away the 3.4.0 branch and releasing trunk
as 3.4.1 to be honest.
I don't like likely in this context. Either that is a definite plan,
and there won't be any heavy changes to trunk before cutting 3.4.1, or
we'd need to commit more patches to both stable and trunk.
Also, what do you mean blowing away the 3.4 branch? Recreating from
trunk once? Or cutting stable releases from trunk always, until you
branch (rather release) the next minor version 3.5.0 from trunk? Which
would mean backporting important fixes becomes almost impossible,
because there simply is no branch other than trunk...
I'm quiet uneasy just thinking about that. Probably worth shifting over
to the dev@ list...
[1] Using plural in a general and kind of extrapolating way. In fact,
this is based on bug 7065, which I just came across wading through
dev@ backlog.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: colors TLDs in spam
The Internet is fundamentally broken. After all that talk about improving Bank security against phishing attacks, I still don't see BANK in that list, but I do see VODKA :-( The lack of one drives me to the other!!! On 02/08/14 10:43, Karsten Bräckelmann wrote: seems http://data.iana.org/TLD/tlds-alpha-by-domain.txt has changed a bit... -- Cheers Jason Haar Corporate Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: colors TLDs in spam
On 08/01/2014 01:34 AM, Kevin A. McGrail wrote: On 7/31/2014 7:17 PM, Axb wrote: if (version = 3.004000) score URI_HOST_IN_BLACKLIST 15.0 blacklist_uri_host blue blacklist_uri_host red # blacklist_uri_hostgreen # blacklist_uri_hostblue # blacklist_uri_hostblack endif Theoretically, legitimate mail could use these TLDs? is your theory that they are new enough that you are just blocking? definitely not... just a suggestion
Re: colors TLDs in spam
On 08/01/2014 10:38 AM, Paul Stead wrote: Does this domain even exist? ---8--- dig jumpclub21.blue whois jumpclub21.blue Domain Name:JUMPCLUB21.BLUE Domain ID: D53127958-LRMS Creation Date: 2014-07-14T20:15:54Z Updated Date: 2014-07-29T16:37:25Z Registry Expiry Date: 2015-07-14T20:15:54Z Sponsoring Registrar:PDR Ltd. d/b/a PublicDomainRegistry.com (R159-LRMS) Sponsoring Registrar IANA ID: 303 WHOIS Server: Referral URL: Domain Status: clientDeleteProhibited Domain Status: clientHold Domain Status: clientRenewProhibited Domain Status: clientTransferProhibited Domain Status: clientUpdateProhibited Domain Status: serverTransferProhibited Registrant ID:DI_37449094 Registrant Name:Trace Diggins Registrant Organization:Domain Proxy Registrant Street: 301 WEST PLATT ST Ste 802 Registrant City:tampa Registrant State/Province:Florida Registrant Postal Code:33606 Registrant Country:US Registrant Phone:+1.3212448907 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email:tracedigg...@outlook.com Admin ID:DI_37449094 Admin Name:Trace Diggins Admin Organization:Domain Proxy Admin Street: 301 WEST PLATT ST Ste 802 Admin City:tampa Admin State/Province:Florida Admin Postal Code:33606 Admin Country:US Admin Phone:+1.3212448907 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email:tracedigg...@outlook.com Tech ID:DI_37449094 Tech Name:Trace Diggins Tech Organization:Domain Proxy Tech Street: 301 WEST PLATT ST Ste 802 Tech City:tampa Tech State/Province:Florida Tech Postal Code:33606 Tech Country:US Tech Phone:+1.3212448907 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email:tracedigg...@outlook.com Name Server:NS1.SUSPENDED-DOMAIN.COM Name Server:NS2.SUSPENDED-DOMAIN.COM Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: DNSSEC:Unsigned
Re: colors TLDs in spam
On 08/01/2014 10:41 AM, Paul Stead wrote: Apologies, keyboard-before-brain - this is a header line - our defers come at SMTP time seen in spam uris kiloo\./blue kata-tata\./blue liquidbasket\./blue edgesphere\./blue bubblestorm\./blue pixobox\./red wrexham\./red getz-one\./red unimmortalises\./red unimmortalize\./red y-akinder\./red unimmortalised\./red wretched\./red bubblechaz\./red xerophily\./red wretchedly\./red xeroxes\./red there must be more :)
Re: colors TLDs in spam
On 08/01/2014 02:59 PM, Joe Quinn wrote: New TLDs are committed to trunk (revision 1615088). Thanks Joe! The process to update the TLDs is commented in RegistrarBoundaries.pm, so anyone is able to do it. Wanted to discuss the uper/lowercase re stuff before giving it a try ...
Re: colors TLDs in spam
--On Friday, August 01, 2014 4:14 PM +0200 Axb axb.li...@gmail.com wrote: On 08/01/2014 02:59 PM, Joe Quinn wrote: New TLDs are committed to trunk (revision 1615088). Thanks Joe! The process to update the TLDs is commented in RegistrarBoundaries.pm, so anyone is able to do it. Wanted to discuss the uper/lowercase re stuff before giving it a try ... I just got hit with pink: Return-Path: harassm...@famous.pink --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: colors TLDs in spam
On Fri, 1 Aug 2014, Quanah Gibson-Mount wrote: --On Friday, August 01, 2014 4:14 PM +0200 Axb axb.li...@gmail.com wrote: On 08/01/2014 02:59 PM, Joe Quinn wrote: New TLDs are committed to trunk (revision 1615088). Thanks Joe! I just got hit with pink: Return-Path: harassm...@famous.pink ...must...resist...xxx...domain...joke... -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Maxim I: Pillage, _then_ burn. --- 4 days until the 279th anniversary of John Peter Zenger's acquittal
Re: colors TLDs in spam
On Fri, 2014-08-01 at 08:59 -0400, Joe Quinn wrote:
New TLDs are committed to trunk (revision 1615088).
That's trunk only. IMHO this should also be committed to the current
stable (3.4) branch.
The process to update the TLDs is commented in RegistrarBoundaries.pm,
so anyone is able to do it.
seems http://data.iana.org/TLD/tlds-alpha-by-domain.txt has changed a
bit...
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: colors TLDs in spam
On 8/1/2014 6:43 PM, Karsten Bräckelmann wrote: On Fri, 2014-08-01 at 08:59 -0400, Joe Quinn wrote: New TLDs are committed to trunk (revision 1615088). That's trunk only. IMHO this should also be committed to the current stable (3.4) branch. In a normal process, yes but right now, there is no difference and I plan on likely blowing away the 3.4.0 branch and releasing trunk as 3.4.1 to be honest. Regards, KAM
colors TLDs in spam
FYI:
I recently started seeing colors TLDs in spam.
EG:From: Choice Home Warranty apollon...@jumpclub21.blue
and URIs: http://xerophthalmia.red/158b1a930024e51c42cd8_a5b5da53
worth a rule? anybody seeing this stuff in ham?
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: colors TLDs in spam
On 7/31/2014 7:17 PM, Axb wrote: if (version = 3.004000) score URI_HOST_IN_BLACKLIST 15.0 blacklist_uri_host blue blacklist_uri_host red # blacklist_uri_hostgreen # blacklist_uri_hostblue # blacklist_uri_hostblack endif Theoretically, legitimate mail could use these TLDs? is your theory that they are new enough that you are just blocking?
Re: colors TLDs in spam
On 2014-07-31 16:34, Kevin A. McGrail wrote: Theoretically, legitimate mail could use these TLDs? is your theory that they are new enough that you are just blocking? They could, but like .info and .biz, there will be a handful of legitimate users and mostly just spam and junk. To me, it's too soon to actually start blocking, but if certain TLDs have an uptick in spam use, it would be worth evaluating their usefulness in email in general, and potentially worth applying low-level scores. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
