I want all mails sent to the list to come from the list's email address...
But, in this case, if the user forgets to sign their name at the
bottom of their mail body, effectively the mail to the list is
anonymous...!
Is there a way to add the user name (or email address) to the top of
each mail so that the mails have the name of the sender, while the
mail itself comes from the list address?
I have looked high and low for an answer, but noone seems to have the solution.
Thank you!
Mal
Hi - I have searched FAQ and archives to find an answer. Hoping you can
help.
I have a new list (with previously imported addresses) for announcements
only, and wish these announcements to be received immediately.
I set the defaults to allow non-digest and to not allow digest.
I wish to send out announcements in html, and so wish to make the
default for new subscribers be MIME. While I see a setting under Digest
Options (MIME_is_Default_Digest), I don't see any equivalent option
under Non-Digest Options... and new subscribers continue to come in as
plain text.
QUESTIONS:
In order to avoid having to manually change this option for each
existing subscriber, is there a way to force all existing subscribers to
receive MIME in Non-Digest mode?
If not, is there a way to force all NEW subscribers to be enrolled with
MIME as their default?
Also, is there a way to "lock" the MIME switch on, so that users who try
to change their option to plain text will be prevented from doing so?
Thanks -
Steve
OK,
I've got another problem with Qmail/Plesk/Mailman (same customer,
rebuilt server). Plesk is 7.5.4 reloaded.
Mail delivered fails with "need GID 110 got 101" error. I set up the
brute-force wrapper to deliver with GID 110, and set the permissions
correctly for it to work. Now, I'm getting the following (broken up
into multiple lines for courtesy):
qmail: 1157518628.995172 delivery 726: success:
group_mismatch_error._Mailman_expected_the_mail_wrapper_script_to_be/
executed_as_one_of_the_following_groups:/[mail,_nobody,_mailman],/
but_the_system's_mail_server_executed_the_mail_script_as_group:_"popuser"./
Try_tweaking_the_mail_server_to_run_the_script_as_one_of_these_groups:/
[mail,_nobody,_mailman],/or_re-run_configure_providing_the_
command_line_option:/'--with-mail-gid=popuser'./Failed_to_start_
/usr/lib/mailman/mail/mailman./did_0+0+1/
I'm about ready to pull my hair out. I even added the popuser user to
the mailman group in /etc/passwd.
So, that being said, are there any ideas out there? I have been
messing with this for a week, and have not come up with anything else
to do.
--
Douglas G. Phillips
Simple Business Solutions
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
I have the task of setting up a replacement for an existing
Mailman/Postfix server. I am new to Mailman and I am looking for some
guidance in this transition. Mailman is currently being used solely as
a diffusion of information. That is, it does not accept contributions
from list members (read-only).
Firstly, should I attempt to migrate data/files over to the new system
or should I start fresh?
The new system will be running OpenBSD 4.0.
Other comments welcome.
Peter
Hello
I need generate a file aliases in mailman.. for postfix..
but when I put /bin/genaliases..
I can't generarte..
Could anyone help me...
thanks
gustavo navarro
Hi!
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
^[A-Za-z0-9.\-_%]+(a)[A-Za-z0-9.-]*mynet.com$ 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.
Anyone can help, plz? =)
Hello,
Our server recently had hard drive problems, and the system was copied
to another drive where it seems to be more or less happy.
But we're having a strange Mailman problem (Mailman 2.1.5 on OSX Server
10.4.10): the lists are running, mail is being delivered, but no
archiving is taking place and nothing is being written to the log files.
The last change date for all log files is the day the original drive
died, as is the date of the last archived messages to our lists.
Otherwise all seems to be well...
Can someone help me with some ideas of where to start looking? I've run
out of ideas at this point. Permissions seem to be fine. Nothing is in
our system logs indicating a problem. I run:
roar:/var/mailman/logs root# /usr/share/mailman/bin/mailmanctl stop
Shutting down Mailman's master qrunner
roar:/var/mailman root# /usr/share/mailman/bin/mailmanctl start
Starting Mailman's master qrunner.
With no problems, but as mentioned, the stop/start does not appear in
the logs.
Any ideas?
thanks,
douglas
--
............................................... http://artbots.org
.....douglas.....irving........................ http://dorkbot.org
.......................... http://music.columbia.edu/cmc/music-dsp
.......... repetto....... http://works.music.columbia.edu/organism
............................... http://music.columbia.edu/~douglas
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
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(a)paypal.com
account-update(a)amazon.com
account.issue(a)paypal.com
account.protection(a)ebay.com
account.support(a)chaseonline.com
account(a)amazon.com
account(a)bankofamerica.com
account(a)capitalone.com
account(a)chase.com
account(a)ebay.com
account(a)paypal.com
accounts(a)amazon.com
accounts(a)bscu.org
accounts(a)chaseonline.com
accounts(a)downeysavings.com
accounts(a)mybankfirstunited.com
accounts(a)paypal.com
accounts(a)regions.com
accounts(a)searscard.com
accounts(a)wellsfargo.com
accounts_support(a)paypal.com
accountservice(a)bankofamerica.us
accountupdate(a)chase.com
admin(a)bankofhanover.com
admin(a)paypal.com
administrator(a)paypal.com
ads(a)servicecu.org
alertingservice(a)searscard.com
alertsrobots(a)bankofamerica.com
assistance(a)paypal.com
auto-confirm(a)amazon.com
aw-confirm(a)ebay.com
aw-confirm(a)paypal.com
aw.confirm(a)paypal.com
aw.confirm(a)regions.com
banking(a)chase.com
bankofamericaalerts(a)alerts.bankofamerica.com
bankofamericaalerts(a)bankofamerica.com
billing(a)ebay.com
billing(a)paypal.com
boa(a)bankofamerica.com
cardpayments(a)citibank.com
cards(a)paypal.com
cgi-bin(a)paypal.com
chase(a)chase.com
chase(a)chaseonline.com
chase(a)notify.chase.com
chase(a)service.com
chasecardservices(a)notify.chase.com
chaseco(a)chase.com
chaseonline(a)chase.com
chaseonlinealerts(a)alerts.chase.com
chaseonlinealerts(a)chase.com
checkout(a)ebay.com
closed(a)paypal.com
confirm145(a)paypal.com
confirmer(a)paypals.com
contact(a)paypal.com
customcare(a)paypal.com
customecare(a)paypal.com
customer-service(a)westernunion.com
customer-services(a)bankofamerica.com
customer.service(a)capitalone.com
customer.service(a)chase.com
customer.support(a)capitalone.com
customer.support(a)chase.com
customer.support(a)paypal.com
customer(a)bankofamerica.com
customer(a)paypal.com
customer(a)redwood-bank.com
customercare(a)amazon.com
customercare(a)paypal.com
customers(a)amazon.com
customerservice(a)bankofamerica.com
customerservice(a)paypal.com
customerservice(a)wachovia.com
customersupport(a)citibank.co.uk
dncu(a)dncu.org
do-not-replay(a)azfcu.org
do-not-replay(a)chase.com
do-not-replay(a)xfcu.org
do-not-reply(a)azfcu.org
do-not-reply(a)bankofamerica.com
do-not-reply(a)chase.com
do-not-reply(a)customers.cacu.net
do-not-reply(a)germanamericanbancorp.com
do-not-reply(a)lacapfcu.org
do-not-reply(a)paypal.com
do-not-reply(a)regions.com
financial(a)regions.com
flafstar-bank(a)security.org
fraud(a)paypal.com
fraud_help(a)chase.com
info(a)azfcu.org
info(a)bankofamerica.com
info(a)ebay.com
info(a)paypal.com
info(a)westernunion.com
member(a)ebay.com
member(a)paypal.com
memsvc(a)vacu.org
mesage.center(a)chase.com
message.center(a)chase.com
message(a)ebay.com
message(a)northforkbank.com
messages(a)ebay.com
militarybankalerts(a)alerts.bankofamerica.com
militarybankalerts(a)bankofamerica.com
mychase(a)chase.com
no-reply(a)chase.com
no-reply(a)ebay.com
no-reply(a)maybank.org
no.reply(a)ebay.com
no.reply(a)paypal.com
noreply(a)bankofamerica.com
noreply(a)germanamericanbancorp.com
noreply(a)westernunion.com
notice.alert(a)bankofamerica.com
notice(a)azfcu.org
notice(a)bankofamerica.com
notice(a)chase.com
notice(a)chaseonline.com
notice(a)ebay.com
notice(a)paypal.com
notice(a)wellsfargo.com
notices.alert(a)bankofamerica.com
office(a)paypal.com
office(a)westernunion.com
online-banking(a)chase.com
online-support(a)online-bankofamerica.com
online-survey(a)chase.com
online.bank(a)regions.com
online.banking(a)regions.com
online.services(a)wachovia.com
online(a)bankofamerica.com
online(a)paypals.com
onlineaccount(a)capitalone.com
onlinebanking.alert(a)bankofamerica.com
onlinebanking(a)alert.bankofamerica.com
onlinebanking(a)bankofamerica.com
onlinebanking(a)wellsfargo.com
onlinesecurity(a)bankofamerica.com
onlinesecurity(a)wachovia.com
onlineservice(a)bankofamerica.com
onlineservice(a)capitalone.com
onlineservice(a)paypal.com
onlineservice(a)wachovia.com
onlineservice(a)wellsfargo.com
onlineservices(a)bankofamerica.com
onlineservices(a)wachovia.com
onlinesrvices(a)wachovia.com
onlinesupport(a)pafcu.org
onlineupdate(a)paypal.com
payment(a)paypal.com
paymentprotector(a)cuna.org
paypal-acc(a)paypal.com
paypal-account(a)paypal.com
paypal-service(a)paypal.com
paypal(a)onlinesecure.com
powersellersinfo(a)ebay.com
privacy(a)regions.com
pw-confirm(a)chase.com
renew(a)azfcu.org
renew(a)tscu.org
resolution-center(a)paypal.com
reward(a)chaseonline.com
reward(a)downeysavings.com
rewards(a)chase.com
rewards(a)westernunion.com
secure-acc(a)amazon.com
secure-acc(a)paypal.com
secure-bank(a)regions.com
secure-cc(a)capitalone.com
secure-cc(a)paypal.com
secure-login(a)chase.com
secure-login(a)regions.com
secure(a)boa.com
secure(a)paypal.com
secure(a)wachovia.com
secure(a)watermarkcu.org
secure(a)wellsfargo.com
security.alert(a)bankofamerica.com
security(a)amazon.com
security(a)baefcu.org
security(a)bankofamerica.com
security(a)bankofhanover.com
security(a)boa.com
security(a)capitalone.com
security(a)cefcu.net
security(a)chase.com
security(a)comchoicecu.org
security(a)dncu.org
security(a)ebay.com
security(a)ncua.gov
security(a)paypal.com
security(a)regions.com
security(a)security.com
security(a)transwestcu.com
security(a)visa.com
security(a)wellsfargo.com
security_alert(a)citizensbank.com
service-account(a)paypal.com
service-bank(a)regions.com
service.account(a)capitalone.com
service.customer(a)paypal.com
service(a)amazon.com
service(a)azfcu.org
service(a)bankofamerica.com
service(a)bankofamerlca.com
service(a)bankofhanover.com
service(a)capitalone.com
service(a)chase.com
service(a)chaseonline.chase.com
service(a)chaseonline.com
service(a)chesterfieldfcu.net
service(a)cscu.org
service(a)downeysavings.com
service(a)ebay.com
service(a)mandtbank.com
service(a)midamericabank.com
service(a)mybankfirstunited.com
service(a)ncua.gov
service(a)paypal.com
service(a)paypal.it
service(a)paypals.com
service(a)regions.com
service(a)secure.regions.com
service(a)visa.com
service(a)wachovia.com
service(a)wamu.com
service(a)warrenfcu.com
service(a)wellsfargo.com
service(a)westernunion.com
service_banking(a)chase.com
servicecenter(a)bankofamerica.us
servicecenter(a)firstinterstatebank.com
services(a)bankofamerica.com
services(a)chesterfieldfcu.net
services(a)downeysavings.com
services(a)ebay.com
services(a)paypal.com
services(a)watermarkcu.org
sitesecurity(a)citibank.com
store-news(a)amazon.com
support(a)amazon.com
support(a)capitalone.com
support(a)chase.com
support(a)ebay.com
support(a)flagstar.com
support(a)online-bankofamerica.com
support(a)paypal.com
support(a)wamu.com
support(a)wellsfargo.com
support(a)yahoo.com
survery(a)twcu.org
survey(a)arizonafederal.org
survey(a)azfcu.org
survey(a)bankofhanover.com
survey(a)cuna.org
survey(a)downeysavings.com
survey(a)tyndallcreditunion.com
suspension(a)ebay.com
unsuspend(a)paypal.com
update-accounts(a)paypal.com
update.profile(a)amazon.com
update(a)boa.com
update(a)paypal.com
update(a)wellsfargo.com
updating(a)capitalone.com
web-info(a)cuna.org
web-service(a)mybankfirstunited.com
webmaster(a)paypal.com
westernunionalerts(a)westernunion.com
westernunionresponse(a)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.
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" <stephen(a)xemacs.org> 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: BSFinkel(a)anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994