Re: [Mailman-Users] rare problem
I've applied changes in my regexp like u said, thanks! and this is the From line you requested: From: =?ISO-8859-1?Q?123456789-123456789-12345678=E99-123456789-123456789?= =?ISO-8859-1?Q?-123456789-123456789-?= [EMAIL PROTECTED] This one comes from a mail that has not beed accepted by mailman, although address in from is allowed by regexp in Allowed senders. Thanks for your help. Mark Sapiro escribió: Jesús Oliván wrote: i'm using mailman 2.1.5 on a Solaris box, and i've got a very rare issue... if i try to post a list using a non-suscribed email address, and this email address is included in non-suscribers allowed senders, it accepts my post... but if i use a regular expression like this [EMAIL PROTECTED] and try to post using a from line using more than 30 characters (from line splits in two in mail header then) and an accent. Then, mailman doesn't accept this mail and return it to me, although this email address is under my.net.com domain. First, while it is not the issue you are asking about, your regexp is probably more liberal than you want. I suggest something like ^[A-Za-z0-9.\-_%]+@([A-Za-z0-9.-]*\.)?mynet\.com$ to preclude matching things like [EMAIL PROTECTED] and [EMAIL PROTECTED] As far as your question is concerned, the sender address is retrieved from the From: header using Python email library methods and functions. If there is a bug there, we'd have to see an exact copy of the split From: header to check that out. Also, when your MUA folds the from header into multiple lines, it should not be folding inside the email address. If by chance, it is, then it is your MUA that is at fault. In any case, I don't understand why this would affect only a regexp match and not a string match. The address that is being checked is the same in both cases. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Blank Characters Removed from Subject: Line
Barry Finkel writes: I am running Mailman 2.1.9. I have a list where one posting has a Subject: line: Change in Procedure for Computers on list with possible Antivirus Problems The next posting in the thread has: Change in Procedure for Computers on list with possible AntivirusProblems and Stephen J. Turnbull [EMAIL PROTECTED] replied: What is happening, I guess, is that Mailman is folding that header to keep it within some number of characters, maybe 76 or so. RFC 2822 specifies that this may be done by inserting a linebreak (CRLF) before whitespace. The RFC implies that the right thing to do in that case is to remove the CRLF only, but some MUAs also remove a space. I suspect that is what is happening to this case. Can you post a copy of the raw header as received by Mailman and as sent by Mailman? Below are pieces of two messages. I have the original message from the archives of the sender followed by the relevant lines of the list .mbox file (including line numbers). === -Original Message- From: ... Sent: Tuesday, June 26, 2007 2:30 PM To: ... Subject: RE: Change in Procedure for Computers on list with possible AntivirusProblems Not a question ... === 184331 Subject: RE: Change in Procedure for Computers on list with possible 184332 AntivirusProblems 184333 Date: Tue, 26 Jun 2007 14:29:52 -0500 184342 From: ... 184343 To: ... 184358 184359 Not a question ... === === -Original Message- From: ... Sent: Tuesday, June 26, 2007 3:50 PM To: ... Cc: ... Subject: RE: Change in Procedure for Computers on list withpossibleAntivirusProblems Hi ... === 184735 Subject: RE: Change in Procedure for Computers on list 184736 withpossibleAntivirusProblems 184737 Date: Tue, 26 Jun 2007 15:50:20 -0500 184747 From: ... 184748 To: ... 184751 Cc: ... 184765 184766 Hi ... === === In both cases, I do not see that Mailman has removed any blanks from the Subject: line. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 222, Room D209 Internet: [EMAIL PROTECTED] Argonne, IL 60439-4828 IBMMAIL: I1004994 -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
Two related suggestions. (1) LHS (left-hand-side) rules Any incoming mail message whose putative sender matches: do-not-reply@ do.not.reply@ donotreply@ no-reply@ no.reply@ noreply@ and which is directed to any of the Mailman standard aliases can be rejected (not bounced [1]) with SMTP status 550 (extended status 5.7.1) since either: (a) it's a forgery, therefore there's no point in letting Mailman attempt to emit a reply -- or even in accepting the message to begin with. (a) it's not a forgery, therefore there's no point in trying to reply to it. (Nor is there any point in permitting it to subscribe to a list or send any traffic to one.) Arguably, this could be done in some MTAs by configuring rejection of those LHS patterns on a per-local-user basis; but I'll argue that doing this in Mailman itself would be more useful, since many (perhaps most) sites don't use per-local-user configuration (and perhaps don't know how). Moreover, any site running multiple mailing lists would need to set this up for every Mailman alias for every mailing list -- so it seems simpler to handle it inside Mailman itself. My guess is that this should be a switchable feature, named something like reject-noreplies. (Not that I can envision a need to switch it off, but I think it'd be more conversative to have that option.) (2) sender rules Any incoming mail message whose putative sender matches the list below can also be rejected (SMTP status 550, extended status 5.7.1) because these addresses will never send traffic to any mailing list nor subscribe to any mailing list. There's thus no point in expending the bandwidth/CPU necessary to process them, nor in forwarding them on to list admins for possible approval -- any message from these addresses to any Mailman-related address is invariably a phish attempt. I'm sure this list is incomplete; I built it by looking at incoming attempts received locally in 2007. It's not meant to be complete, only illustrative. Again, this could be done at the MTA level by blocking on a per-local-user basis, but (as above) I think wiring it into Mailman would make it useful to people who do not have their MTAs so configured. And this should probably also be switchable feature, perhaps named reject-obvious-phishes. More comments below this list. [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[Mailman-Users] Problem/Question Regarding Bounce Processing
I have a question/problem with Mailman bounce processing. We have Mailman lists here that are re-built every morning from our Human Resources database. When mail is sent to one of these lists, and one or more of the e-mail addresses therein have problems, I see in my morning report (and/or in the Mailman bounce log) that specific addresses have had bounces. I do not see the rejection messages that are sent to listname-bounce so I do not know what the problem might have been. I assume that the rejection message is discarded after it has been processed, the bounce log appended, and the e-mail address bounce score increased. I would like to be able to correct those bad addresses that come from our HR Database when they are first seen as bad, but I cannot correct them if I do not know what the nature of the bounce was. And I really do not want to have to send test mail to each of the failed addresses in order to get a rejection message. I know that I can add an additional address in the /var/lib/mailman/data/aliases file to the listname-bounce: alias line, but I do not want to do this manually every time I create a new list. Are there any suggestions on what I can do? Thanks. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 222, Room D209 Internet: [EMAIL PROTECTED] Argonne, IL 60439-4828 IBMMAIL: I1004994 -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] rare problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesús Oliván wrote: I've applied changes in my regexp like u said, thanks! and this is the From line you requested: From: =?ISO-8859-1?Q?123456789-123456789-12345678=E99-123456789-123456789?= =?ISO-8859-1?Q?-123456789-123456789-?= [EMAIL PROTECTED] This one comes from a mail that has not beed accepted by mailman, although address in from is allowed by regexp in Allowed senders. The problem is a bug in some versions of the Python email library. This problem will occur whether the 'address' in *_these_nonmembers is a regexp or a string. It also does not depend on the 'real name' being RFC 2047 encoded. All that is required is that the 'real name' be long enough that the From: header folds into two lines. In this case, the email.Utils function getaddresses() returns a spurious extra 'address' based on the first line of the folded header and this is the 'address' we check against *_these_nonmembers instead of checking the real address. This bug exists in Mailman through 2.1.9. I will work around it for Mailman 2.1.10. - -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFGhSXFVVuXXpU7hpMRAkRpAKDYF1Lk1dsNRfVAgX8QomeswrkadwCfbmVN Yk6i/KOIfDCFHUrUGUhurq4= =dH8a -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Problem/Question Regarding Bounce Processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Finkel wrote: I have a question/problem with Mailman bounce processing. We have Mailman lists here that are re-built every morning from our Human Resources database. When mail is sent to one of these lists, and one or more of the e-mail addresses therein have problems, I see in my morning report (and/or in the Mailman bounce log) that specific addresses have had bounces. I do not see the rejection messages that are sent to listname-bounce so I do not know what the problem might have been. I assume that the rejection message is discarded after it has been processed, the bounce log appended, and the e-mail address bounce score increased. I would like to be able to correct those bad addresses that come from our HR Database when they are first seen as bad, but I cannot correct them if I do not know what the nature of the bounce was. And I really do not want to have to send test mail to each of the failed addresses in order to get a rejection message. I'm not sure what the issue is. Do these bad addresses never get removed because you are continuously removing and re-adding them, thus resetting their bounce score every day? Or do you just want to see the 'first' bounce from a new member so you can delete that address faster than normal bounce processing does? You are correct about what Mailman does. The only actual bounce DSN that is not simply discarded after processing is the one that caused the score to reach threshold and disables delivery. That one is sent to the list owner with the disable notice if bounce_notify_owner_on_disable is Yes. If the problem is that bad addresses are never getting disabled and removed because you are continuously rebuilding the list and resetting scores, you could try using bin/sync_members to update the list from the HR data. This will not reset scores or options for existing members. If that is not the issue, and you just want to see the first bounce for a new member, and you don't want to do this in the MTA and you don't want to modify Mailman code, the only way is to set bounce_score_threshold to 1.0 or less so that everyone is disabled on the first bounce and then re-enable those that shouldn't be disabled so soon. - -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFGhSp/VVuXXpU7hpMRAuL9AKDp3+Y9vHOgnIP0ZqAopwCStxUpaACgwo4L h+nLERWMfWEEW4RdRm3RkPI= =847S -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Blank Characters Removed from Subject: Line
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Finkel wrote: Below are pieces of two messages. I have the original message from the archives of the sender followed by the relevant lines of the list .mbox file (including line numbers). === -Original Message- From: ... Sent: Tuesday, June 26, 2007 2:30 PM To: ... Subject: RE: Change in Procedure for Computers on list with possible AntivirusProblems This is some rendering of the Subject:, but it is not the actual Subject: header. If it were, the Subject: of the outgoing message would be simply Subject: RE: Change in Procedure for Computers on list with possible since a header continuation must begin with at least one whitespace character. You need to get the 'message source' from the sender. Not a question ... === 184331 Subject: RE: Change in Procedure for Computers on list with possible 184332 AntivirusProblems And here we see Mailman has sent the post with the subject folded with a tab as the whitespace character. 184333 Date: Tue, 26 Jun 2007 14:29:52 -0500 184342 From: ... 184343 To: ... 184358 184359 Not a question ... === === -Original Message- From: ... Sent: Tuesday, June 26, 2007 3:50 PM To: ... Cc: ... Subject: RE: Change in Procedure for Computers on list withpossibleAntivirusProblems And someones MUA has dropped the tab in unfolding (and this has happened more than once) I think it would be better if Mailman folded using sp rather than tab since with tab a standards compliant unfolding would leave a tab in the middle of the subject which may be worse than dropping it. But, the fact remains that there are many commonly used MUAs that drop a whitespace character in unfolding and there's not much we can do about that. - -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFGhS/jVVuXXpU7hpMRAm5XAKCdZAzuN7TYt4lD9KTmsvffUqnS7wCeKUew V6Pn0pu0CJwDfJNv9aA7pno= =HqSS -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rich Kulawiec wrote: Two related suggestions. snip [1] The difference between a reject and a bounce: a reject is performed by emitting the appropriate SMTP status code and closing the connection; that is, the message is refused while the SMTP connection is open from the sending side. Exactly, which is why Mailman can't do this. It has to be done in the incoming MTA. Mailman doesn't see the message until the MTA has already accepted it. - -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFGhSyHVVuXXpU7hpMRAlcXAKDGo+YS4KQLzIWOe9ftDLVv2zW+MACdFnQJ dIabTI1fLUvo0sgxf8R98hk= =lcgV -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Problem/Question Regarding Bounce Processing
Barry Finkel wrote: I have a question/problem with Mailman bounce processing. We have Mailman lists here that are re-built every morning from our Human Resources database. When mail is sent to one of these lists, and one or more of the e-mail addresses therein have problems, I see in my morning report (and/or in the Mailman bounce log) that specific addresses have had bounces. I do not see the rejection messages that are sent to listname-bounce so I do not know what the problem might have been. I assume that the rejection message is discarded after it has been processed, the bounce log appended, and the e-mail address bounce score increased. I would like to be able to correct those bad addresses that come from our HR Database when they are first seen as bad, but I cannot correct them if I do not know what the nature of the bounce was. And I really do not want to have to send test mail to each of the failed addresses in order to get a rejection message. And Mark Sapiro [EMAIL PROTECTED] replied: I'm not sure what the issue is. Do these bad addresses never get removed because you are continuously removing and re-adding them, thus resetting their bounce score every day? Or do you just want to see the 'first' bounce from a new member so you can delete that address faster than normal bounce processing does? You are correct about what Mailman does. The only actual bounce DSN that is not simply discarded after processing is the one that caused the score to reach threshold and disables delivery. That one is sent to the list owner with the disable notice if bounce_notify_owner_on_disable is Yes. If the problem is that bad addresses are never getting disabled and removed because you are continuously rebuilding the list and resetting scores, you could try using bin/sync_members to update the list from the HR data. This will not reset scores or options for existing members. If that is not the issue, and you just want to see the first bounce for a new member, and you don't want to do this in the MTA and you don't want to modify Mailman code, the only way is to set bounce_score_threshold to 1.0 or less so that everyone is disabled on the first bounce and then re-enable those that shouldn't be disabled so soon. I am sorry that I was not clear in my posting. In a normal list, where persons subscribe and unsubscribe, I am content with the Mailman bounce processing, where Mailman will set nomail for addresses that continually bounce. When there is a bad e-mail address in our HR Database, that address needs to be corrected so that future mailings to that address, either via a Mailman list or via an ad-hoc mailing list derived from the HR Database, will reach the intended recipient. With the Mailman lists, I (as Mailman admin) do not see the rejection message; neither do the individual list owner(s). So, without my daily report I do not know that a bounce has occurred, and I do not know the nature of the bounce. As I did this morning, I had to send test mail to the address to get a rejection message to see what the failure was. If there is a bounce, can I be assurred that the bounce was due to the mailbox not existing? -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 222, Room D209 Internet: [EMAIL PROTECTED] Argonne, IL 60439-4828 IBMMAIL: I1004994 -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Problem/Question Regarding Bounce Processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Finkel wrote: I am sorry that I was not clear in my posting. In a normal list, where persons subscribe and unsubscribe, I am content with the Mailman bounce processing, where Mailman will set nomail for addresses that continually bounce. When there is a bad e-mail address in our HR Database, that address needs to be corrected so that future mailings to that address, either via a Mailman list or via an ad-hoc mailing list derived from the HR Database, will reach the intended recipient. With the Mailman lists, I (as Mailman admin) do not see the rejection message; neither do the individual list owner(s). So, without my daily report I do not know that a bounce has occurred, and I do not know the nature of the bounce. As I did this morning, I had to send test mail to the address to get a rejection message to see what the failure was. If there is a bounce, can I be assurred that the bounce was due to the mailbox not existing? No. The bounce can be for many reasons, including such things as 'full mailbox'. You are correct in thinking that you have to see the actual DSN to know what the reason is. I am still not clear on what happens with the HR based list and whether the issue is that you need to see a bounce DSN as soon as possible in order to identify problems in the HR database, or if the issue is that bouncing members never get disabled. As I tried to say in my previous reply, if you need to see the first bounce, the only way to do that with Mailman settings is to set bounce_score_threshold to 1.0 or less so that everyone is disabled on the first bounce and set bounce_notify_owner_on_disable to Yes so that the list owner receives a notice which will contain the bounce DSN. Then the list owner has to notify HR if the DSN shows the address is no good or re-enable delivery if the DSN is for some other reason. If the issue is that bouncing members never get disabled, you need to revise the way you update the list from the HR database to use a method like bin/sync_members so that bounce scores are not reset in this process. In the first case, it is a balance between the extra effort to re-enable 'transient' bounce disables vs. the effort to extract the fact of the bounce from the bounce log and send a test email that determines which approach is better. - -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFGhT9jVVuXXpU7hpMRAgoUAKDymAF/J6dmJNO3onu9fMd1FeKZWgCg0F5o WbNWQ8NlQg3buysOvanjwrw= =Uo2D -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
On 6/29/07 7:44 AM, Rich Kulawiec [EMAIL PROTECTED] wrote: Two related suggestions. (1) LHS (left-hand-side) rules Any incoming mail message whose putative sender matches: do-not-reply@ do.not.reply@ donotreply@ no-reply@ no.reply@ noreply@ and which is directed to any of the Mailman standard aliases can be rejected (not bounced [1]) with SMTP status 550 (extended status 5.7.1) since either: (a) it's a forgery, therefore there's no point in letting Mailman attempt to emit a reply -- or even in accepting the message to begin with. (a) it's not a forgery, therefore there's no point in trying to reply to it. (Nor is there any point in permitting it to subscribe to a list or send any traffic to one.) Arguably, this could be done in some MTAs by configuring rejection of those LHS patterns on a per-local-user basis; but I'll argue that doing this in Mailman itself would be more useful, since many (perhaps most) sites don't use per-local-user configuration (and perhaps don't know how). Moreover, any site running multiple mailing lists would need to set this up for every Mailman alias for every mailing list -- so it seems simpler to handle it inside Mailman itself. My guess is that this should be a switchable feature, named something like reject-noreplies. (Not that I can envision a need to switch it off, but I think it'd be more conversative to have that option.) At least here, this good idea would have to be implemented in the MTA which receives the message, as the message is not presented to Mailman until after the receiving MTA has accepted the message (in fact, here, it's not even presented to Mailman by the same MTA or on the same machine). Thus rejection is not possible based on what Mailman does. (Further, in the present Mailman, the presentation is by pipe, so doing something like Exim's recipient verification callout doesn't work.) There have indeed been discussions about making the MTA able to get information from Mailman in time to do SMTP-time rejection. It's not simple to do in the general case. --John -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
Mark, John -- reading both your messages (and applying significantly more coffee) has induced enlightenment. Yep, this is just not going to work the way I'd suggested. Bad me. No biscuit. So let me modify these as follows and see if this is any better: (1) LHS (left-hand-side) rules Present to list-owner for disposition as done today, but mark it prominently as noreply address, almost certainly a forgery. (2) sender rules Present to list-owner for disposition as done today, but mark it prominently as probable phish. Granted, in both cases, the message still has be to processed, but perhaps marking it (both on the Subject line and inside the message body) will make it easier/faster for list-owners to deal with. ---Rsk p.s. As as aside, I strongly recommend against callbacks/SAV. It's inherently abusive, it's a deliberate attempt to bypass site security policies [and thus illegal in some jurisdictions, but ask your attorney for clarification 'cause IANAL], it provides a spam support service, and -- as we've already seen -- it can be used to conduct quite effective DoS/DDoS attacks. And on top of that, far more effective, efficient, and difficult-to-abuse anti-spam methods exist. I'm working [yeah, alright, for some values of work] on a stupid anti-spam techniques FAQ that will cover this in considerably more depth, so I don't intend this to be by any means a full explanation. However, this topic has been repeatedly discussed on Spam-L in depth, so I'll refer anyone interested to that list's archives until I can manage to get that FAQ cranked out. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] Making list owner (listname-owner) appear in Return Path
We are doing well in our migration from MJ2 to mailman. The default of sending emails with the -bounce address doesn't fit with our needs. We'd like it to work the way it did with MJ2, where the listname-owner type of address was in the Return-Path. Typically we set our list owner to be some administrative email address which several of us can check for interesting items or bulk delete after some time. In other cases, the owner of some fund raising campaign wants to receive bounce notifications to see immediately what addresses are not current. I think my answer is to edit SMTPDirect.py to set the Sender and Return Path, but I'm not sure what variable I need to use there. Is 'mlist.owner[:]' what I'll need? I'd want the specific list owner, not the site mailman owner. None of these are publicly subscribe-able lists, so the features of bounce processing are not valuable to us. Any suggestions? --Donald -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Making list owner (listname-owner) appear in ReturnPath
D G Teed wrote:
I think my answer is to edit SMTPDirect.py to set the
Sender and Return Path, but I'm not sure what variable
I need to use there. Is 'mlist.owner[:]' what I'll need?
I'd want the specific list owner, not the site mailman owner.
What you need is mlist.GetOwnerEmail() which will get the
[EMAIL PROTECTED] address.
You don't want mlist.owner[:] because that is a list and you can't have
a list of addresses as the SMTP MAIL FROM address (envelope sender).
Any mail returned to the [EMAIL PROTECTED] address gets delivered
to the owner(s) and moderator(s).
None of these are publicly subscribe-able lists, so the features
of bounce processing are not valuable to us.
There are lots of reasons why addresses on even non-public lists become
undeliverable, but presumably, you are willing to deal with these
manually.
If I understand what you want, you can accomplish it by finding the code
# Calculate the non-VERP envelope sender.
envsender = msgdata.get('envsender')
if envsender is None:
if mlist:
envsender = mlist.GetBouncesEmail()
else:
envsender = Utils.get_site_email(extra='bounces')
at the beginning of process() in SMTPDirect.py and changing it to
# Calculate the non-VERP envelope sender.
if mlist:
envsender = mlist.GetOwnerEmail()
else:
envsender = Utils.get_site_email(extra='owner')
The else: clause comes into play for messages that don't come from a
list, e.g. monthly password reminders.
--
Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Making list owner (listname-owner) appear inReturnPath
Mark Sapiro wrote:
If I understand what you want, you can accomplish it by finding the code
# Calculate the non-VERP envelope sender.
envsender = msgdata.get('envsender')
if envsender is None:
if mlist:
envsender = mlist.GetBouncesEmail()
else:
envsender = Utils.get_site_email(extra='bounces')
at the beginning of process() in SMTPDirect.py and changing it to
# Calculate the non-VERP envelope sender.
if mlist:
envsender = mlist.GetOwnerEmail()
else:
envsender = Utils.get_site_email(extra='owner')
Actually, the above change is a bad idea. It should really be
# Calculate the non-VERP envelope sender.
envsender = msgdata.get('envsender')
if envsender is None:
if mlist:
envsender = mlist.GetOwnerEmail()
else:
envsender = Utils.get_site_email(extra='owner')
You shouldn't ignore the envsender in the message metadata. It exists
to prevent bounce loops. I was thinking they wouldn't occur if the
bounces were sent to the list owner directly, but of course, a list
owner's address can be undeliverable for many reasons and loops can
still occur.
--
Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
On 6/29/07 11:23 AM, Rich Kulawiec [EMAIL PROTECTED] wrote: p.s. As as aside, I strongly recommend against callbacks/SAV. It's inherently abusive, it's a deliberate attempt to bypass site security policies [and thus illegal in some jurisdictions, but ask your attorney for clarification 'cause IANAL], I wasn't referring to sender verification callbacks (which we do not use). I was referring to recipient verification callforwards, where the edge MTA doesn't know valid recipients but some internal (or even customer) MTA does. Exim can configure these easily (but that doesn't help because Mailman doesn't act like an MTA). I don't know about any other MTAs in this regard. --John -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] specific (1) LHS and (2) sender rules tofrustrate spam/phishing
Rich Kulawiec wrote:
So let me modify these as follows and see if this is any better:
(1) LHS (left-hand-side) rules
Present to list-owner for disposition as done today, but mark it
prominently as noreply address, almost certainly a forgery.
(2) sender rules
Present to list-owner for disposition as done today, but mark it
prominently as probable phish.
Granted, in both cases, the message still has be to processed, but
perhaps marking it (both on the Subject line and inside the
message body) will make it easier/faster for list-owners to deal with.
Referring back to your original idea where you wanted the messages
refused at SMTP time, it seems that what you really want is for
messages that match your rules to be discarded. You can use
header_filter_rules for this, but maintaining them would be a pain.
If I were trying to do it, I would use the KNOWN_SPAMMERS list in
mm_cfg.py. For example just listing a few of yours
KNOWN_SPAMMERS = [
('from', '^(.*[\s])?do-not-reply@'),
('from', '^(.*[\s])[EMAIL PROTECTED]([\s].*)?'),
]
This list applies installation wide and will discard any message to a
list or list-owner address that contains a matching header.
The entries are 2-tuples ('a', 'b') where a is the case-insensitive
name of a header and b is a Python regexp to match case-insensitively
against the values of all headers of that type in the message.
This doesn't address mail to the other (e.g., -request or -bounces)
list addresses, but it's a start, and using KNOWN_SPAMMERS frees you
from maintaining rules per list.
--
Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Blank Characters Removed from Subject: Line
Mark Sapiro writes: But, the fact remains that there are many commonly used MUAs that drop a whitespace character in unfolding and there's not much we can do about that. I wonder if they're better with RFC 2047. That is, suppose we rendered Subject: Pretend this is a long field as Subject: Pretend this is =?US-ASCII?Q?a=20?= =?US-ASCII?Q?long=20field?= Of course, that would be just unbearably ugly if your MUA doesn't do MIME headers. Maybe the best course would be to use two spaces at the beginning of a folded physical line. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
