Re: [Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
On Sat, Jun 30, 2007 at 10:36:19PM +0900, Stephen J. Turnbull wrote:
> You have to be careful, though. For several years on one of my lists
> I had a subscriber whose address was something like (I don't recall
> exactly) "[EMAIL PROTECTED]", which was a
> perfectly valid address and at which he/she/it did receive mail and
> from which he/she/it would reply.
Agreed, care is needed in order to avoid false positives. ("nobody",
by the way, is often aliased thus in stock sendmail installations
on various 'nix boxes:
nobody: /dev/null
so while there's nothing wrong with it per se -- and it's not a
special address per RFC 2142 -- I find myself wondering how many
people have hardwired it into various anti-spam setups. ;-) )
I should probably mention that I'm not a fan of [EMAIL PROTECTED]
and similar addresses, which seem to be often used these days for
one-way mailing lists: I think *all* messages should be replyable.
But I figure that, as a practical matter, as long as so many sites
are using that convention, we might as well leverage it to our
advantage.
---Rsk
--
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=show&file=faq01.027.htp
Re: [Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
On Fri, Jun 29, 2007 at 01:25:15PM -0700, John W. Baxter wrote: > 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. Ah, understood. *Those* I highly approve of, since they at least help mitigate accept-then-bounce issues due to non-existent recipient addresses at the final/internal/destination MTA. Whether it's done by callforwards, or LDAP lookups, or script-generated virtual user tables, or aliases, or whatever, I'm all for it. ---Rsk -- 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=show&file=faq01.027.htp
[Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
Rich Kulawiec writes: > Any incoming mail message whose putative sender matches: > > do-not-reply@ > > 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. You have to be careful, though. For several years on one of my lists I had a subscriber whose address was something like (I don't recall exactly) "[EMAIL PROTECTED]", which was a perfectly valid address and at which he/she/it did receive mail and from which he/she/it would reply. -- 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=show&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=show&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=show&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=show&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. > [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=show&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]
