specific (1) LHS and (2) sender rules to frustrate spam/phishing
![](https://secure.gravatar.com/avatar/3978a8b63a4176f76121fae9de6595f7.jpg?s=120&d=mm&r=g)
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.
acc-overview@paypal.com
account-update@amazon.com
account.issue@paypal.com
account.protection@ebay.com
account.support@chaseonline.com
account@amazon.com
account@bankofamerica.com
account@capitalone.com
account@chase.com
account@ebay.com
account@paypal.com
accounts@amazon.com
accounts@bscu.org
accounts@chaseonline.com
accounts@downeysavings.com
accounts@mybankfirstunited.com
accounts@paypal.com
accounts@regions.com
accounts@searscard.com
accounts@wellsfargo.com
accounts_support@paypal.com
accountservice@bankofamerica.us
accountupdate@chase.com
admin@bankofhanover.com
admin@paypal.com
administrator@paypal.com
ads@servicecu.org
alertingservice@searscard.com
alertsrobots@bankofamerica.com
assistance@paypal.com
auto-confirm@amazon.com
aw-confirm@ebay.com
aw-confirm@paypal.com
aw.confirm@paypal.com
aw.confirm@regions.com
banking@chase.com
bankofamericaalerts@alerts.bankofamerica.com
bankofamericaalerts@bankofamerica.com
billing@ebay.com
billing@paypal.com
boa@bankofamerica.com
cardpayments@citibank.com
cards@paypal.com
cgi-bin@paypal.com
chase@chase.com
chase@chaseonline.com
chase@notify.chase.com
chase@service.com
chasecardservices@notify.chase.com
chaseco@chase.com
chaseonline@chase.com
chaseonlinealerts@alerts.chase.com
chaseonlinealerts@chase.com
checkout@ebay.com
closed@paypal.com
confirm145@paypal.com
confirmer@paypals.com
contact@paypal.com
customcare@paypal.com
customecare@paypal.com
customer-service@westernunion.com
customer-services@bankofamerica.com
customer.service@capitalone.com
customer.service@chase.com
customer.support@capitalone.com
customer.support@chase.com
customer.support@paypal.com
customer@bankofamerica.com
customer@paypal.com
customer@redwood-bank.com
customercare@amazon.com
customercare@paypal.com
customers@amazon.com
customerservice@bankofamerica.com
customerservice@paypal.com
customerservice@wachovia.com
customersupport@citibank.co.uk
dncu@dncu.org
do-not-replay@azfcu.org
do-not-replay@chase.com
do-not-replay@xfcu.org
do-not-reply@azfcu.org
do-not-reply@bankofamerica.com
do-not-reply@chase.com
do-not-reply@customers.cacu.net
do-not-reply@germanamericanbancorp.com
do-not-reply@lacapfcu.org
do-not-reply@paypal.com
do-not-reply@regions.com
financial@regions.com
flafstar-bank@security.org
fraud@paypal.com
fraud_help@chase.com
info@azfcu.org
info@bankofamerica.com
info@ebay.com
info@paypal.com
info@westernunion.com
member@ebay.com
member@paypal.com
memsvc@vacu.org
mesage.center@chase.com
message.center@chase.com
message@ebay.com
message@northforkbank.com
messages@ebay.com
militarybankalerts@alerts.bankofamerica.com
militarybankalerts@bankofamerica.com
mychase@chase.com
no-reply@chase.com
no-reply@ebay.com
no-reply@maybank.org
no.reply@ebay.com
no.reply@paypal.com
noreply@bankofamerica.com
noreply@germanamericanbancorp.com
noreply@westernunion.com
notice.alert@bankofamerica.com
notice@azfcu.org
notice@bankofamerica.com
notice@chase.com
notice@chaseonline.com
notice@ebay.com
notice@paypal.com
notice@wellsfargo.com
notices.alert@bankofamerica.com
office@paypal.com
office@westernunion.com
online-banking@chase.com
online-support@online-bankofamerica.com
online-survey@chase.com
online.bank@regions.com
online.banking@regions.com
online.services@wachovia.com
online@bankofamerica.com
online@paypals.com
onlineaccount@capitalone.com
onlinebanking.alert@bankofamerica.com
onlinebanking@alert.bankofamerica.com
onlinebanking@bankofamerica.com
onlinebanking@wellsfargo.com
onlinesecurity@bankofamerica.com
onlinesecurity@wachovia.com
onlineservice@bankofamerica.com
onlineservice@capitalone.com
onlineservice@paypal.com
onlineservice@wachovia.com
onlineservice@wellsfargo.com
onlineservices@bankofamerica.com
onlineservices@wachovia.com
onlinesrvices@wachovia.com
onlinesupport@pafcu.org
onlineupdate@paypal.com
payment@paypal.com
paymentprotector@cuna.org
paypal-acc@paypal.com
paypal-account@paypal.com
paypal-service@paypal.com
paypal@onlinesecure.com
powersellersinfo@ebay.com
privacy@regions.com
pw-confirm@chase.com
renew@azfcu.org
renew@tscu.org
resolution-center@paypal.com
reward@chaseonline.com
reward@downeysavings.com
rewards@chase.com
rewards@westernunion.com
secure-acc@amazon.com
secure-acc@paypal.com
secure-bank@regions.com
secure-cc@capitalone.com
secure-cc@paypal.com
secure-login@chase.com
secure-login@regions.com
secure@boa.com
secure@paypal.com
secure@wachovia.com
secure@watermarkcu.org
secure@wellsfargo.com
security.alert@bankofamerica.com
security@amazon.com
security@baefcu.org
security@bankofamerica.com
security@bankofhanover.com
security@boa.com
security@capitalone.com
security@cefcu.net
security@chase.com
security@comchoicecu.org
security@dncu.org
security@ebay.com
security@ncua.gov
security@paypal.com
security@regions.com
security@security.com
security@transwestcu.com
security@visa.com
security@wellsfargo.com
security_alert@citizensbank.com
service-account@paypal.com
service-bank@regions.com
service.account@capitalone.com
service.customer@paypal.com
service@amazon.com
service@azfcu.org
service@bankofamerica.com
service@bankofamerlca.com
service@bankofhanover.com
service@capitalone.com
service@chase.com
service@chaseonline.chase.com
service@chaseonline.com
service@chesterfieldfcu.net
service@cscu.org
service@downeysavings.com
service@ebay.com
service@mandtbank.com
service@midamericabank.com
service@mybankfirstunited.com
service@ncua.gov
service@paypal.com
service@paypal.it
service@paypals.com
service@regions.com
service@secure.regions.com
service@visa.com
service@wachovia.com
service@wamu.com
service@warrenfcu.com
service@wellsfargo.com
service@westernunion.com
service_banking@chase.com
servicecenter@bankofamerica.us
servicecenter@firstinterstatebank.com
services@bankofamerica.com
services@chesterfieldfcu.net
services@downeysavings.com
services@ebay.com
services@paypal.com
services@watermarkcu.org
sitesecurity@citibank.com
store-news@amazon.com
support@amazon.com
support@capitalone.com
support@chase.com
support@ebay.com
support@flagstar.com
support@online-bankofamerica.com
support@paypal.com
support@wamu.com
support@wellsfargo.com
support@yahoo.com
survery@twcu.org
survey@arizonafederal.org
survey@azfcu.org
survey@bankofhanover.com
survey@cuna.org
survey@downeysavings.com
survey@tyndallcreditunion.com
suspension@ebay.com
unsuspend@paypal.com
update-accounts@paypal.com
update.profile@amazon.com
update@boa.com
update@paypal.com
update@wellsfargo.com
updating@capitalone.com
web-info@cuna.org
web-service@mybankfirstunited.com
webmaster@paypal.com
westernunionalerts@westernunion.com
westernunionresponse@westernunion.com
In both these cases, the check can be carried out by doing some simple string-matching. The second list will need ongoing (and careful) maintenance -- and one way to achieve that might be to enlist the cooperation of the domains in question. However, note that (a) under-inclusion is no worse than the current situation and (b) over-inclusion is unlikely given even a modicum of scrutiny applied to prospective list entries.
---Rsk
[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. A bounce is performed by accepting the message (again, emitting the appropriate SMTP status code), then performing further processing, deciding not to accept the message, and attemping to "return" the message to the putative sender. The simplest way of putting this is "reject good, bounce bad", since bounces invariably result in outscatter (aka "backscatter"), which is a form of spam, which in turn will cause sufficiently egregious emitters to be (correctly) blacklisted. Note as well that various mitigating strategies designed to blunt the effects of bounce-instead-of-reject policies lose entirely due to rampant forgery, DNS redirection, an estimated 100M+ fully-compromised systems, and widespread failure of end-user ISPs to control outbound SMTP abuse. So saying that it's immensely preferable to reject rather than bounce is an understatement.
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rich Kulawiec wrote:
Two related suggestions.
<snip>
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 <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFGhSyHVVuXXpU7hpMRAlcXAKDGo+YS4KQLzIWOe9ftDLVv2zW+MACdFnQJ dIabTI1fLUvo0sgxf8R98hk= =lcgV -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 6/29/07 7:44 AM, "Rich Kulawiec" <rsk@gsp.org> wrote:
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
![](https://secure.gravatar.com/avatar/3978a8b63a4176f76121fae9de6595f7.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 6/29/07 11:23 AM, "Rich Kulawiec" <rsk@gsp.org> 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.
--John
![](https://secure.gravatar.com/avatar/3978a8b63a4176f76121fae9de6595f7.jpg?s=120&d=mm&r=g)
On Fri, Jun 29, 2007 at 01:25:15PM -0700, John W. Baxter wrote:
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
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Rich Kulawiec wrote:
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<])?acc-overview@paypal.com([\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 <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/3978a8b63a4176f76121fae9de6595f7.jpg?s=120&d=mm&r=g)
On Fri, Jun 29, 2007 at 01:35:51PM -0700, Mark Sapiro wrote:
That's *very* handy to know. I'm going to do some limited experiments with it over the next week or two, and will be back with results.
Thanks!
---Rsk
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Rich Kulawiec writes:
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) "nobody@not-a-real-address.somewhere.net", which was a perfectly valid address and at which he/she/it did receive mail and from which he/she/it would reply.
![](https://secure.gravatar.com/avatar/3978a8b63a4176f76121fae9de6595f7.jpg?s=120&d=mm&r=g)
On Sat, Jun 30, 2007 at 10:36:19PM +0900, Stephen J. Turnbull wrote:
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 noreply@example.com 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
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rich Kulawiec wrote:
Two related suggestions.
<snip>
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 <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFGhSyHVVuXXpU7hpMRAlcXAKDGo+YS4KQLzIWOe9ftDLVv2zW+MACdFnQJ dIabTI1fLUvo0sgxf8R98hk= =lcgV -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 6/29/07 7:44 AM, "Rich Kulawiec" <rsk@gsp.org> wrote:
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
![](https://secure.gravatar.com/avatar/3978a8b63a4176f76121fae9de6595f7.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/2247d70341dcc3fe9a429c684a774a11.jpg?s=120&d=mm&r=g)
On 6/29/07 11:23 AM, "Rich Kulawiec" <rsk@gsp.org> 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.
--John
![](https://secure.gravatar.com/avatar/3978a8b63a4176f76121fae9de6595f7.jpg?s=120&d=mm&r=g)
On Fri, Jun 29, 2007 at 01:25:15PM -0700, John W. Baxter wrote:
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
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Rich Kulawiec wrote:
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<])?acc-overview@paypal.com([\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 <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/3978a8b63a4176f76121fae9de6595f7.jpg?s=120&d=mm&r=g)
On Fri, Jun 29, 2007 at 01:35:51PM -0700, Mark Sapiro wrote:
That's *very* handy to know. I'm going to do some limited experiments with it over the next week or two, and will be back with results.
Thanks!
---Rsk
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Rich Kulawiec writes:
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) "nobody@not-a-real-address.somewhere.net", which was a perfectly valid address and at which he/she/it did receive mail and from which he/she/it would reply.
![](https://secure.gravatar.com/avatar/3978a8b63a4176f76121fae9de6595f7.jpg?s=120&d=mm&r=g)
On Sat, Jun 30, 2007 at 10:36:19PM +0900, Stephen J. Turnbull wrote:
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 noreply@example.com 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
participants (4)
-
John W. Baxter
-
Mark Sapiro
-
Rich Kulawiec
-
Stephen J. Turnbull