Re: [Mailman-Developers] Change to acceptable_aliases
[Barry A. Warsaw]
Except that I think `@'-less regexps still have useful semantics, so I don't want to prohibit them. I just want the matching to (eventually) always be done against the entire recip address, not just the localpart.
Then wouldn't it make more sense to already now try matching the regexp against the entire address, even if the regexp does not contain any '@'?
Your change will cause the (not too far-fetched, IMO) regexp
.*\.uio\.no$
to _only_ be matched against the localpart (and thus very likely _not_ produce a match) for now, although you're saying that you eventually want it to match against the entire address (and that likely _will_ produce a match).
So, I still say:
If the regexp does not contain an '@', first try matching it against the localpart (i.e. the way things work now).
If 1) was skipped *or* if it didn't produce a match, try matching against entire recip address (i.e. try this even if the regexp does not contain any '@' signs).
Or am I misunderstanding something?
Harald
"HM" == Harald Meland <Harald.Meland@usit.uio.no> writes:
HM> So, I still say:
HM> 1) If the regexp does not contain an '@', first try matching
HM> it against the localpart (i.e. the way things work now).
HM> 2) If 1) was skipped *or* if it didn't produce a match, try
HM> matching against entire recip address (i.e. try this even if
HM> the regexp does not contain any '@' signs).
HM> Or am I misunderstanding something?No, I think I misunderstood your original proposal. Sorry about that.
+1 on Harald's approach, with a provision to remove #1 in some future version.
-Barry
P.S. The "+1" is taken from Apache's voting mechanism, as described by Greg Stein on the Python-Dev list:
http://www.python.org/pipermail/python-dev/2000-March/004312.html
Briefly explained:
+1 "I'm all for it. Do it!" +0 "Seems cool and acceptable, but I can also live without it" -0 "Not sure this is the best thing to do, but I'm not against it." -1 "Veto. And <HERE> is my reasoning."
It's actually worked quite nicely on Python-Dev, so I propose we adopt it here too.
"BAW" == Barry A Warsaw <bwarsaw@cnri.reston.va.us> writes:
BAW> +1 on Harald's approach, with a provision to remove #1 in
BAW> some future version.And here's the patch.
-Barry
Index: MailList.py
RCS file: /projects/cvsroot/mailman/Mailman/MailList.py,v retrieving revision 1.161 diff -c -r1.161 MailList.py *** MailList.py 2000/04/13 23:25:16 1.161 --- MailList.py 2000/04/14 17:34:09
*** 1215,1250 ****
# this is the list's full address
listfullname = '%s@%s' % (self.internal_name(), self.host_name)
recips = []
! # check all recipient addresses against the list's full address...
for fullname, addr in msg.getaddrlist('to') + msg.getaddrlist('cc'):
! localpart = string.lower(string.split(addr, '@')[0])
! laddr = string.lower(addr)
if (# TBD: backwards compatibility: deprecated
localpart == self.internal_name() or
! # new behavior
! laddr == listfullname):
return 1
! recips.append((laddr, localpart))
! # ... and only then try the regexp acceptable aliases.
! for laddr, localpart in recips:
for alias in string.split(self.acceptable_aliases, '\n'):
stripped = string.strip(alias)
! if '@' in stripped:
! # new behavior: match the entire recipient string
! recip = laddr
! else:
! # TBD: backwards compatibility: deprecated
! recip = localpart
! try:
! # The list alias in stripped is a user supplied regexp,
! # which could be malformed.
! if stripped and re.match(stripped, recip):
! return 1
! except re.error:
! # `stripped' is a malformed regexp -- try matching
! # safely, with all non-alphanumerics backslashed:
! if stripped and re.match(re.escape(stripped), recip):
! return 1
return 0
def parse_matching_header_opt(self):--- 1215,1261 ----
# this is the list's full address
listfullname = '%s@%s' % (self.internal_name(), self.host_name)
recips = []
! # check all recipient addresses against the list's explicit address.
for fullname, addr in msg.getaddrlist('to') + msg.getaddrlist('cc'):
! addr = string.lower(addr)
! localpart = string.split(addr, '@')[0]
if (# TBD: backwards compatibility: deprecated
localpart == self.internal_name() or
! # exact match against the complete list address
! addr == listfullname):
return 1
! recips.append((addr, localpart))
! #
! # helper function used to match a pattern against an address. Do it
! def domatch(pattern, addr):
! try:
! if re.match(pattern, addr):
! return 1
! except re.error:
! # The pattern is a malformed regexp -- try matching safely,
! # with all non-alphanumerics backslashed:
! if re.match(re.escape(pattern), addr):
! return 1
! #
! # Here's the current algorithm for matching acceptable_aliases:
! #
! # 1. If the pattern does not have an @' in it, we first try matching ! # it against just the localpart. This was the behavior prior to ! # 2.0beta3, and is kept for backwards compatibility. ! # (deprecated). ! # ! # 2. If that match fails, or the pattern does have an @' in it, we
! # try matching against the entire recip address.
! for addr, localpart in recips:
for alias in string.split(self.acceptable_aliases, '\n'):
stripped = string.strip(alias)
! if not stripped:
! # ignore blank or empty lines
! continue
! if '@' not in stripped and domatch(stripped, localpart):
! return 1
! if domatch(stripped, addr):
! return 1
return 0
def parse_matching_header_opt(self):
No, I think I misunderstood your original proposal. Sorry about that.
+1 on Harald's approach, with a provision to remove #1 in some future version.
About a year ago I sent out a proposal to the list about this that I think might still have some merit. Rather than doing regular expression matching, why not do regex plus substitution? That would allow admins to create rules like
'\+[^@]' ' '
which essentially converts all plus-addressed subscriptions to a non-plus-addressed format, thereby fixing the existing problem with plus-addressing.
Unfortunately, if it's left in acceptable_aliases it will go ahead and approve anybody with plus-addressing. :) So what do people think about creating another option in the privacy settings entitled sub_regex? Basically, all email addresses would be transformed with this regex before going to acceptable_aliases.
What does this buy me?
I could have a sub_regex setting like
'@.*\.ncsa\.uiuc\.edu$' '@ncsa.uiuc.edu'
followed by an acceptable_alias setting of
@ncsa\.uiuc\.edu$
Now anyone at ncsa.uiuc.edu can post to the list, whether or not their hostname shows up in their address, etc. Likewise,
'^lindsey@[^@]+$' 'lindsey@ncsa.uiuc.edu'
would accept email from anyone who's email address starts with 'lindsey@'.
Sure, you can shoot yourself in the foot. Sure, you can open up your list. But the extra power far outweighs the potentially stupid things that people can do with it. :)
Chris
Chris
participants (4)
-
Barry A. Warsaw -
Christopher Lindsey -
Harald Meland -
Ricardo Kustner