Re: Sending Bulk Mails
Le 04/06/2011 23:37, mouss a écrit : Le 04/06/2011 07:09, Frank Bonnet a écrit : Hello 1 - configure your DNS SPF record personal opinion: I recommend against: my experience with hotmail is as follows: - I've added an spf record. cool it works - i had to move the server to another IP. I updated the spf record. doesn't work (yep, even after a long long time) - so I had to keep a relay with the old IP. sigh. in another life, I didn't add an spf record. works better... 2 - Use DKIM to sign your emails agreed. 3 - Use a mailing lists software ( LISTSERV Mailman ... etc ) agreed. We have been in trouble with gmail yahoo hotmail before doing this after configuring Postfix and Bind like this we do not have blacklist troubles with those email providers been there... saw funny things (such as people replying to an auto mail when the body is an invitation by their friend...). but all that won't be as fun as what I've seen in the "mobile" life... The hotmail case is "special" they can be contacted in case of trouble I am far to be a MS fan but I must say this service works as we did it and they answered after few days and put our domain in their "good reputation" white list, after that no more trouble to send emails to hotmail. We felt in troubles because of our students ;-) they started an email war between them ( hundreds of emails a day X 1000 students ), as MANY of them forward copies of their ESIEE's emails to GMAIL or HOTMAIL personnal accounts I let you imagine the result ... The war has ended after some "recommendations" of our commander in chief :-) This war have had a positive side : our mailhub/MX is now better configured :-)
Re: postscreen MX Policy test and multiple listening IP addresses
On Fri, Jun 03, 2011 at 01:09:28PM -0400, Wietse Venema wrote: > postscreen_whitelist_interfaces matters only for clients that are > not yet whitelisted (or that have expired). Issue: previously whitelisted client gets WHITELIST VETO on secondary MX IP address (excluded from postscreen_whitelist_interfaces.) Funny thing, however: I have seen this work on another client today. Today I entered these in DNS (munged domain): q.example.us. MX 10 mx1.q.example.us. q.example.us. MX 20 mx2.q.example.us. mx1.q.example.us. A 216.23.247.74 mx2.q.example.us. A 216.23.247.78 Previously only the mx1 record existed, resolving to the same address. Jun 5 01:50:46 cardinal postfix/postscreen[15628]: CONNECT from [174.37.3.121]:33695 to [216.23.247.74]:25 Jun 5 01:50:52 cardinal postfix/postscreen[15628]: PASS OLD [174.37.3.121]:33695 Jun 5 01:50:52 cardinal postfix/smtpd[15816]: connect from 174.37.3.121-static.reverse.softlayer.com[174.37.3.121] Jun 5 01:50:53 cardinal postfix/smtpd[15816]: NOQUEUE: reject: RCPT from 174.37.3.121-static.reverse.softlayer.com[174.37.3.121]: 450 4.1.8 : Sender address rejected: Domain not found; from= to= proto=ESMTP helo= This thing has been badgering us for a few days, but I am not going to let up on my reject_unknown_sender_domain restriction. And now for the first time (that I know of) it is retrying at the mx2 IP address: Jun 5 01:50:53 cardinal postfix/postscreen[15628]: CONNECT from [174.37.3.121]:52927 to [216.23.247.78]:25 Jun 5 01:50:53 cardinal postfix/postscreen[15628]: WHITELIST VETO [174.37.3.121]:52927 It was whitelisted 7 seconds ago. Could that have expired? Jun 5 01:50:53 cardinal postfix/tlsproxy[15853]: CONNECT from [174.37.3.121]:52927 Jun 5 01:50:53 cardinal postfix/postscreen[15628]: NOQUEUE: reject: RCPT from [174.37.3.121]:52927: 450 4.3.2 Service currently unavailable; from=, to=, proto=ESMTP, helo= Jun 5 01:50:53 cardinal postfix/postscreen[15628]: DISCONNECT [174.37.3.121]:52927 Jun 5 01:50:53 cardinal postfix/tlsproxy[15853]: DISCONNECT [174.37.3.121]:52927 Jun 5 01:50:54 cardinal postfix/smtpd[15816]: disconnect from 174.37.3.121-static.reverse.softlayer.com[174.37.3.121] Checking for first whitelisting: rob0@cardinal:/var/log$ grep "PASS NEW \[174\.37\.3\.121\]:" maillog rob0@cardinal:/var/log$ zgrep "PASS NEW \[174\.37\.3\.121\]:" maillog.1.gz May 28 12:51:46 cardinal postfix/postscreen[25301]: PASS NEW [174.37.3.121]:34539 Round up the usual suspects: rob0@cardinal:~$ /usr/sbin/postconf mail_version mail_version = 2.9-20110501 rob0@cardinal:~$ /usr/sbin/postconf -n alias_database = $alias_maps alias_maps = hash:$config_directory/aliases append_dot_mydomain = no command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 default_privs = mailman enable_long_queue_ids = yes home_mailbox = Mail/ html_directory = /usr/doc/postfix/html mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/local/man mydestination = hash:$config_directory/mydestination mydomain = $myhostname myhostname = cardinal.lizella.net mynetworks = 127.0.0.0/8, 192.168.0.0/20, 216.23.247.72/29 newaliases_path = /usr/bin/newaliases owner_request_special = no postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr postscreen_bare_newline_action = enforce postscreen_bare_newline_enable = yes postscreen_blacklist_action = drop postscreen_dnsbl_action = enforce postscreen_dnsbl_reply_map = pcre:$config_directory/postscreen_dnsbl_reply_map.pcre postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*2 dnsbl.njabl.org*2 bl.spameatingmonkey.net*2 dnsbl.ahbl.org*2 bl.spamcop.net dnsbl.sorbs.net spamtrap.trblspam.com swl.spamhaus.org*-4 list.dnswl.org=127.[0..255].[0..255].0*-2 list.dnswl.org=127.[0..255].[0..255].1*-4 list.dnswl.org=127.[0..255].[0..255].[2..255]*-6 postscreen_dnsbl_threshold = 3 postscreen_greet_action = enforce postscreen_non_smtp_command_enable = yes postscreen_pipelining_enable = yes postscreen_whitelist_interfaces = 216.23.247.74/31 !216.23.247.72/29 static:all queue_directory = /var/spool/postfix readme_directory = /usr/doc/postfix/readme recipient_delimiter = + relay_clientcerts = hash:$config_directory/relay_clientcerts relay_domains = sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtp_tls_CAfile = /etc/ssl/certs/cardinal.lizella.net.crt smtp_tls_cert_file = /etc/ssl/certs/cardinal.lizella.net.crt smtp_tls_key_file = /etc/ssl/private/cardinal.lizella.net.key.nopass smtp_tls_policy_maps = hash:$config_directory/tls_policy smtp_tls_session_cache_database = btree:$data_directory/smtp_tls_session_cache smtp_use_tls = yes smtpd_data_restrictions = reject_unauth_pipelining, accepted smtpd_recipient_restrictions = common,relay_block,
Re: Postfix restricting local mail locally.
On 06/04/2011 05:50 PM, mouss wrote: yes if you have an "internal side". do you? I have 3+ sides. External, wired and wireless. I may eventually add a dmz or include the dmz with wireless. Wired and wireless both go through the server to external but don't know the other exists. putting the internal on different ports is not a problem if you cant specify different settings for the different sides of the server specifically. the way the documentation is worded it confuses me which one would apply here. does smtpd_sender... = out going mail or the from: box? the way you word it confuses me:) Havent studied much on mail servers before. until a year or 2 agao my systems hadent seen much spam. Some one used my domain in the from box for a bunch of spam and now i get alot of junk. On 06/04/2011 02:04 PM, Victor Duchovni wrote: On Sat, Jun 04, 2011 at 10:25:37AM -0400, Kendrick wrote: smtpd_recipient_restrictions = permit_sasl_authenticated No, this won't work, rather: smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_sender_access hash:/etc/postfix/access_sender # Optional final permit, just to make it clear permit Does that apply to multi homed machines or is it possible to specify things per network? or would i be better off having a mail server instance specifically for external mail and a 2nd server that is for the internal clients?
Re: Postfix restricting local mail locally.
Le 04/06/2011 16:25, Kendrick a écrit :
> On 06/04/2011 05:06 AM, mouss wrote:
>> Using check_*_access before reject_unauth_destination is discouraged. it
>> may (accidentally) lead to open relay should "someone" add an entry that
>> returns OK.
>>
>> better use:
>>
>> smtpd_recipient_restrictions =
>> permit_sasl_authenticated
>> permit_myneyworks
>> reject_unauth_destination
>> check_sender_access hash:/etc/postfix/access_sender
>>
>> == access_sender:
>> techsoft3d.com REJECT
>> .techsoft3d.com REJECT
>>
> That makes sense now that I see an example. Lists of options like the
> documentation tend to just confuse me.
>> Note to OP: this rejects mail with a sender in your domain unless it
>> comes from mynetworks or is authenticated (SASL).
>>
>> a better setup is to separate inbound mail service (MX) and submission
>> service (MSA), for example by using port 587 for submission. then you
>> wouldn't need to create exception ("reject unless").
>>
>> he could start with
>> http://www.postfix.org/SMTPD_ACCESS_README.html
>> http://www.postfix.org/RESTRICTION_CLASS_README.html
>>
> If i understand this right. for the mx side I could put
>
> smtpd_recipient_restrictions =
> permit_sasl_authenticated
>
No.
- the default in all smtpd_*_restrictions is OK
- open relay is checked in smtpd_recipient_restrictions
so the latter should have a reject_something. in general:
reject_unauth_destination (which rejects open relay).
> or should it be
>
> smtpd_sender_restrictions =
> check_sender_access hash:/etc/postfix/access_sender
>
> == access_sender:
> techsoft3d.com REJECT
> .techsoft3d.com REJECT
>
>
> and on the internal side it would accept all with no restrictions?
yes if you have an "internal side". do you?
>
> the way the documentation is worded it confuses me which one would apply
> here. does smtpd_sender... = out going mail or the from: box?
the way you word it confuses me:)
all smtpd checks apply to the SMTP commands such as HELO/EHLO, MAIL
FROM, RCPT TO. smtpd checks do not apply to headers (Subject:, Date:
From:, To:, Cc:, ... etc).
you need to udnderstand how smtp works. smtp is a transport protocol
that is used to convey messages. smtp has commands: HELO/EHLO, MAIL
FROM, RCPT TO, DATA, QUIT, ... etc. the messages it convey have headers
(such as Received, Date, Subject, From, To, Cc, ... etc) and a body
(which may itself contain multiple MIME parts, sometimes called
attachments).
Re: Sending Bulk Mails
Le 04/06/2011 07:09, Frank Bonnet a écrit : > Hello > > 1 - configure your DNS SPF record personal opinion: I recommend against: my experience with hotmail is as follows: - I've added an spf record. cool it works - i had to move the server to another IP. I updated the spf record. doesn't work (yep, even after a long long time) - so I had to keep a relay with the old IP. sigh. in another life, I didn't add an spf record. works better... > 2 - Use DKIM to sign your emails agreed. > 3 - Use a mailing lists software ( LISTSERV Mailman ... etc ) agreed. > > We have been in trouble with gmail yahoo hotmail before doing this > after configuring Postfix and Bind like this we do not have blacklist > troubles with those email providers > been there... saw funny things (such as people replying to an auto mail when the body is an invitation by their friend...). but all that won't be as fun as what I've seen in the "mobile" life...
Re: Sending Bulk Mails
Le 04/06/2011 13:25, /dev/rob0 a écrit : > On Sat, Jun 04, 2011 at 11:14:42AM +0200, mouss wrote: >> Le 04/06/2011 08:43, Goutam Baul a ecrit : >>> 2) Can you indicate some reliable website to get the dkim-milter >>> package for my RHEL 3.8? >> >> no idea. >> PS. isn't 3.8 way too outdated? > > RHEL, IIUC, has EOL'ed 4.5 or thereabouts. RHEL 5.x dates back to 2007. OP is almost 4 years too old. the real questions are - is OP's version still supported by RH? I not, he is in trouble - does OP really need RH support? if not, why use RHEL? debian, freebsd, netbsd, ... are free and well maintained. > Postfix has EOL'ed 2.4. > This poster's platform looks like a house of cards. Everybody stop > breathing or it might collapse! now the question is: is his platform owned by miscreants? may be... > >>> 3) Instead of using the mailing list software, for the time being >>> I am planning to use php classes like phpmailer and advice my >>> script to delay for say 5 seconds before sending a mail. Do you >>> foresee any issues in this approach? > > And PHP has had approximately three gazillion security issues in the > period in question, not to mention openssh, httpd, et c. > agreed. php has too many problems. perl, python, java, ... are a better choice. >> it is strongly recommended to use a list manager such as sympa or >> mailman: >> - they have delivery error detection >> - they have "well known" templates and headers >> ... >> >> if you decide to use your own tools, do that at your own risk. be >> aware that there are many opportunities to get things wrong. > > Exactly. The questions being asked indicate that the poster is well > down on the learning curve to begin with. 15K mails on a clean list > are not that much, and since they are shareholders it's evident that > money is involved. > > My recommendation to the OP is to consider outsourcing this. It will > not cost that much, and a reputable email service provider can be > well worth what they charge. > > Conversely to do it inhouse I would recommend tearing it all down and > starting over with a recent and well-supported OS. It might look > cheaper on the short-term bottom line to beg on the Internet for help > in keeping the old install running, but when things go wrong, as they > surely will, the costs will skyrocket in ways not yet imagined.
Re: Sending Bulk Mails
Am 04.06.2011 20:08, schrieb Victor Duchovni: > On Sat, Jun 04, 2011 at 11:08:10AM +0200, Reindl Harald wrote: > >> smtp_destination_recipient_limit= 15 >> smtp_initial_destination_concurrency= 5 >> smtp_destination_concurrency_limit = 5 >> smtp_destination_concurrency_failed_cohort_limit= 5 >> smtp_destination_rate_delay = 1 > > Many of these will do nothing for Postfix 2.0. The OP will need at least > Postfix 2.5.7 or so. Better of course 2.7.4 or 2.8.3. hm - i did not realize that there are so many peopole with outdated software because it takes 5 minutes to rebuild postfix 2.8.3 on redhat-based systems as rpm (taking the src.rpm, change version, put tarball in sources-folder and type "rpmbuild -bb postfix.spec" strange. signature.asc Description: OpenPGP digital signature
Re: Sending Bulk Mails
On Sat, Jun 04, 2011 at 11:08:10AM +0200, Reindl Harald wrote: > smtp_destination_recipient_limit= 15 > smtp_initial_destination_concurrency= 5 > smtp_destination_concurrency_limit = 5 > smtp_destination_concurrency_failed_cohort_limit= 5 > smtp_destination_rate_delay = 1 Many of these will do nothing for Postfix 2.0. The OP will need at least Postfix 2.5.7 or so. Better of course 2.7.4 or 2.8.3. -- Viktor.
Re: Postfix restricting local mail locally.
On Sat, Jun 04, 2011 at 10:25:37AM -0400, Kendrick wrote: > smtpd_recipient_restrictions = > permit_sasl_authenticated No, this won't work, rather: smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_sender_access hash:/etc/postfix/access_sender # Optional final permit, just to make it clear permit > or should it be > > smtpd_sender_restrictions = > check_sender_access hash:/etc/postfix/access_sender > > == access_sender: > techsoft3d.com REJECT > .techsoft3d.com REJECT > > > and on the internal side it would accept all with no restrictions? You list authorized clients in "mynetworks". -- Viktor.
Re: Postfix restricting local mail locally.
On 06/04/2011 05:06 AM, mouss wrote:
Using check_*_access before reject_unauth_destination is discouraged. it
may (accidentally) lead to open relay should "someone" add an entry that
returns OK.
better use:
smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_myneyworks
reject_unauth_destination
check_sender_access hash:/etc/postfix/access_sender
== access_sender:
techsoft3d.com REJECT
.techsoft3d.com REJECT
That makes sense now that I see an example. Lists of options like the
documentation tend to just confuse me.
Note to OP: this rejects mail with a sender in your domain unless it
comes from mynetworks or is authenticated (SASL).
a better setup is to separate inbound mail service (MX) and submission
service (MSA), for example by using port 587 for submission. then you
wouldn't need to create exception ("reject unless").
he could start with
http://www.postfix.org/SMTPD_ACCESS_README.html
http://www.postfix.org/RESTRICTION_CLASS_README.html
If i understand this right. for the mx side I could put
smtpd_recipient_restrictions =
permit_sasl_authenticated
or should it be
smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/access_sender
== access_sender:
techsoft3d.com REJECT
.techsoft3d.com REJECT
and on the internal side it would accept all with no restrictions?
the way the documentation is worded it confuses me which one would apply here.
does smtpd_sender... = out going mail or the from: box?
thanks
Kendrick
Re: Sending Bulk Mails
On Sat, Jun 04, 2011 at 11:14:42AM +0200, mouss wrote: > Le 04/06/2011 08:43, Goutam Baul a ecrit : > > 2) Can you indicate some reliable website to get the dkim-milter > > package for my RHEL 3.8? > > no idea. > PS. isn't 3.8 way too outdated? RHEL, IIUC, has EOL'ed 4.5 or thereabouts. Postfix has EOL'ed 2.4. This poster's platform looks like a house of cards. Everybody stop breathing or it might collapse! > > 3) Instead of using the mailing list software, for the time being > > I am planning to use php classes like phpmailer and advice my > > script to delay for say 5 seconds before sending a mail. Do you > > foresee any issues in this approach? And PHP has had approximately three gazillion security issues in the period in question, not to mention openssh, httpd, et c. > it is strongly recommended to use a list manager such as sympa or > mailman: > - they have delivery error detection > - they have "well known" templates and headers > ... > > if you decide to use your own tools, do that at your own risk. be > aware that there are many opportunities to get things wrong. Exactly. The questions being asked indicate that the poster is well down on the learning curve to begin with. 15K mails on a clean list are not that much, and since they are shareholders it's evident that money is involved. My recommendation to the OP is to consider outsourcing this. It will not cost that much, and a reputable email service provider can be well worth what they charge. Conversely to do it inhouse I would recommend tearing it all down and starting over with a recent and well-supported OS. It might look cheaper on the short-term bottom line to beg on the Internet for help in keeping the old install running, but when things go wrong, as they surely will, the costs will skyrocket in ways not yet imagined. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Sending Bulk Mails
Le 04/06/2011 08:43, Goutam Baul a écrit : > Dear Frank, > > Thanks a lot for responding. I am now reading through the net and trying to > implement things as suggested. Just a few queries: > > 1) As I am interested in sending bulk mails, I am contemplating modification > of my DNS zone file with SPF record. Some articles in the net talk about > reconfiguration of Postfix for SPF. I believe it is required only when I > test the incoming mails for the corresponding SPF records. Am I correct in > my understanding? yes. > 2) Can you indicate some reliable website to get the dkim-milter package for > my RHEL 3.8? no idea. PS. isn't 3.8 way too outdated? > 3) Instead of using the mailing list software, for the time being I am > planning to use php classes like phpmailer and advice my script to delay for > say 5 seconds before sending a mail. Do you foresee any issues in this > approach? it is strongly recommended to use a list manager such as sympa or mailman: - they have delivery error detection - they have "well known" templates and headers ... if you decide to use your own tools, do that at your own risk. be aware that there are many opportunities to get things wrong. > > Sorry for bothering you lots of questions. > > With regards, > > Goutam > > > >
Re: Sending Bulk Mails
Am 04.06.2011 06:03, schrieb Goutam Baul:
> 1) There could be an issue with the server performance as because these many
> numbers of mails will
> be pushed to the queue at the same time. This can, however, be addressed by
> tweaking the mail sending
> script carefully.
with 15.000 mails - how old is your server? :-)
years ago sent 250.000 (legal!) mails with phpmailer
do not bother you main-mailsystem and let postfix run
on the webserver on port 127.0.0.1 with you mail-system
as "realy_host" and the settings below should wait
one second after each mail you main-systems gets
a) your php-script can send burst
b) the webserver will queue
c) the queue on you main server will not get filled
consider a valid ptr/spf-entry for you webserver and
do not use "relay_host", so it will send the bulk-mails
by itself (the settings below are from our bulk-mailer)
and even if someone blacklists you it will not affect
the business-mails!
queue_run_delay = 240
maximal_queue_lifetime = 2d
bounce_queue_lifetime = 2d
minimal_backoff_time= 900
maximal_backoff_time= 5400
message_size_limit = 36700160
max_idle= 60
in_flow_delay = ${stress?2}${stress:0}s
smtp_destination_recipient_limit= 15
smtp_initial_destination_concurrency= 5
smtp_destination_concurrency_limit = 5
smtp_destination_concurrency_failed_cohort_limit= 5
smtp_destination_rate_delay = 1
signature.asc
Description: OpenPGP digital signature
Re: Postfix restricting local mail locally.
Le 04/06/2011 04:06, Jeroen Geilman a écrit :
> On 06/04/2011 02:50 AM, Kendrick wrote:
>> I am trying to make it so that postfix takes specific actions when
>> spam "from" my domian externally arrives.
>> smtpd_recipient_restrictions / reject_unknown_... looked prommising
>> but I dont see how to work it with the information given.
>>
>> When a new message arrives with [from: somt...@mydomain.com]
>> [to:somt...@mydomain.com] and sender ip address does not = $mynetworks
>> i want to send connecting pc's ip to external scripts if possible and
>> the least reject the message.
>>
>> reverse dns lookup from my internal dns server would work as well.
>> eventually I may be interested in having tls or something authenticate
>> external users to send from mydomian but that is not a big concern
>> right now. If need be vpn will solve that need.
>>
>> any suggestions are appriciated. If I missed a how-to or something I
>> appriciate the links. I dont always figure the best key words to find
>> these things.
>
> In main.cf:
>
> smtpd_recipient_restrictions = permit_mynetworks,
> check_sender_access hash:/etc/postfix/my_own_domains,
> reject_unauth_destination
>
Using check_*_access before reject_unauth_destination is discouraged. it
may (accidentally) lead to open relay should "someone" add an entry that
returns OK.
better use:
smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_myneyworks
reject_unauth_destination
check_sender_access hash:/etc/postfix/access_sender
== access_sender:
techsoft3d.com REJECT
.techsoft3d.com REJECT
Note to OP: this rejects mail with a sender in your domain unless it
comes from mynetworks or is authenticated (SASL).
a better setup is to separate inbound mail service (MX) and submission
service (MSA), for example by using port 587 for submission. then you
wouldn't need to create exception ("reject unless").
> and in my_own_domains:
>
> techsoft3d.com REJECT
>
> etc.
>
> Or one of the other possible actions; there are quite a few, read the
> man page for details:
>
> http://www.postfix.org/access.5.html
>
he could start with
http://www.postfix.org/SMTPD_ACCESS_README.html
http://www.postfix.org/RESTRICTION_CLASS_README.html
Re: Sending Bulk Mails
Am 04.06.2011 10:45, schrieb Robert Schetterer: > Am 04.06.2011 06:03, schrieb Goutam Baul: >> Dear List, >> >> >> >> We are running our mailing system using Postfix >> (postfix-2.0.16-14.RHEL3). We need to send communications to our >> shareholders (around 15000 of them) using the mailing system. If we >> simply send the mails using things like phpmailer etc. then we fear that >> >> >> >> 1) 1) There could be an issue with the server performance as >> because these many numbers of mails will be pushed to the queue at the >> same time. This can, however, be addressed by tweaking the mail sending >> script carefully. >> >> 2) 2) Some of the receiving domains like yahoo etc. might >> think that we are creating spam and blacklist us. >> >> >> >> We don’t have any idea on how many mails should be safe to push per hour >> so that our servers don’t face the risk of getting blacklisted. Is there >> any threshold value? >> >> >> >> Would anyone advice us on the correct approach that we should take? This >> is going to be a regular feature in our operations and we need to device >> a good solution. Any help please. >> >> >> >> With regards, >> >> >> >> Goutam >> >> >> >> >> > > 15000 news mails are no problem with recent postfix on modern hardware > so perhaps you should upgrade, anyway configure slow transports to i.e > yahoo etc , use their whitelist featuring etc > > as said before, a matching reverse dns record , spf and dkim is highly recommended -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: Sending Bulk Mails
Am 04.06.2011 06:03, schrieb Goutam Baul: > Dear List, > > > > We are running our mailing system using Postfix > (postfix-2.0.16-14.RHEL3). We need to send communications to our > shareholders (around 15000 of them) using the mailing system. If we > simply send the mails using things like phpmailer etc. then we fear that > > > > 1) 1) There could be an issue with the server performance as > because these many numbers of mails will be pushed to the queue at the > same time. This can, however, be addressed by tweaking the mail sending > script carefully. > > 2) 2) Some of the receiving domains like yahoo etc. might > think that we are creating spam and blacklist us. > > > > We don’t have any idea on how many mails should be safe to push per hour > so that our servers don’t face the risk of getting blacklisted. Is there > any threshold value? > > > > Would anyone advice us on the correct approach that we should take? This > is going to be a regular feature in our operations and we need to device > a good solution. Any help please. > > > > With regards, > > > > Goutam > > > > > 15000 news mails are no problem with recent postfix on modern hardware so perhaps you should upgrade, anyway configure slow transports to i.e yahoo etc , use their whitelist featuring etc -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: Sending Bulk Mails
Le 04/06/2011 08:43, Goutam Baul a écrit : Dear Frank, Thanks a lot for responding. I am now reading through the net and trying to implement things as suggested. Just a few queries: 1) As I am interested in sending bulk mails, I am contemplating modification of my DNS zone file with SPF record. Some articles in the net talk about reconfiguration of Postfix for SPF. I believe it is required only when I test the incoming mails for the corresponding SPF records. Am I correct in my understanding? SPF identify which servers are allowed to send emails from your domain 2) Can you indicate some reliable website to get the dkim-milter package for my RHEL 3.8? Well I dunno I use FreeBSD but I suppose RH provide such package I use opendkim milter 3) Instead of using the mailing list software, for the time being I am planning to use php classes like phpmailer and advice my script to delay for say 5 seconds before sending a mail. Do you foresee any issues in this approach? Well it looks good but who really knows gmail or hotmail policies ? Sorry for bothering you lots of questions. you're welcome this list is supposed to provide help ;-) With regards, Goutam
