Yahoo/hotmail blocks on mails

Yahoo/hotmail blocks on mails

Issues in sending mails yahoo/hotmail/gmail

Ckeck below some steps that need to be taken to bypass issues when sending
mails to yahoo/hotmail

make sure that you have

  • disabled openrelay
  • set spf record
  • Set up DomainKeys
  • set rDNS for mail servers IP and the domain is resolving to rght IP

Openrelay

mail server which does not verify that it is authorised to send a mail from
an addredd a user is trieng to send rom.
Ie a third party can send a mail through your mailserver ithout
autherisation. Spammers usually make use of open relayed servers to dump
bulk of emails. so the memory/cpu of the server will be exploited by third
party.
Also this causes the mail server/IP to b blacklisted by a lot of
organisations.
Ie your IP will be added by organisations like DNSBL and the mails sent by
the users of server will be rejected.

exim configuration to block this

ACL – Access control list

Its good to go through acl configurationsfor better security

Access Control Lists (ACLs) are defined in a separate section of the run time
configuration file, headed by “begin acl”. Each ACL definition starts with
a name, terminated by a colon.
check the format below.A sample configuration

begin acl

small_acl:
accept   hosts = one.host.only

Relay Configuration Options

1)

set local_domains to the domains hosted in the server
local_domains  = /etc/localdomains will do ( by default )

relay_domains_include_local_mx ( this is another option, but the above
explained one is preferable

2)

The control of hosts that can relay can be set by setting following options
accourrdingly.

accept_8bitmime
accept_timeout
admin_groups
allow_mx_to_ip
always_bcc
auth_always_advertise
auth_hosts
auto_thaw
bi_command

Over 50 parameteres like this need to be checked.You can find the details
here

Following command could be used for fixing openrelay in cpanel servers.

/scripts/fixrelayd

finally you could check if openrelay is enabled through the following link

http://www.abuse.net/relay.html

Using DNSB and RBL Configuration Options in EXIM

DNSBL Usage

# Add a warning header if the sending host is in these
# DNSBLs but acccept the message (or rather leave it for
# later ACLs to accept/deny
warn message = X-blacklisted-at: $dnslist_domain
dnslists = blackholes.mail-abuse.org : \
dialup.mail-abuse.org

# Reject messages from senders listed in these DNSBLs
deny dnslists = blackholes.mail-abuse.org

RBL usage

# reject messages whose sending host is in MAPS/RBL & MAP/DUL
# add warning to messages whose sending host is in RSS
rbl_domains = blackholes.mail-abuse.org/reject : \
dialups.mail-abuse.org/reject : \
relays.mail-abuse.org/warn
# check all hosts other than those on internal network
rbl_hosts = !192.168.0.0/24:0.0.0.0/0
# but allow mail to [email protected] even from rejected host
recipients_reject_except = [email protected]
# change some logging actions (collect more data)
rbl_log_headers  # log headers of accepted RBLed messages
rbl_log_rcpt_count # log recipient info of accepted RBLed messages

set spf record

In the envelope, first there is the “HELO” identity, which names the mail
server (MTA) that is sending the message. The “MAIL FROM” identity is the
e-mail address that is responsible for sending the message and where delivery
errors (bounces) will eventually be reported. And the “RCPT TO” identity is
the message’s recipient address

SPF authenticates the envelope HELO and MAIL FROM identities by comparing the
sending mail server’s IP address to the list of authorized sending IP
addresses published by the sender domain’s owner in a “v=spf1″ DNS record.
SPF has succeeded several older envelope sender authentication protocols.
Currently SPF is the only widely deployed envelope authentication protocol.

sample SPF record below <-|

example.net.  TXT  “v=spf1 mx a:pluto.example.net include:gmail.com -all”

parts of the SPF record given below

v=spf1    ———     SPF version 1
mx          ———-  the incoming mail servers (MXes) of the domain are
authorized to also send mail for example.net
a:pluto.example.net ————        the machine pluto.example.net is authorized,
too
include:gmail.com         ———- everything considered legitimate by gmail.com
is legitimate for example.net, too
-al ——— all other machines are not authorized
DOMAIN KEY

DOMAIN KEYS:
——————-

DomainKeys is an e-mail authentication system designed to verify the DNS
domain of an e-mail sender and the message integrity.

How it works:
—————–

DomainKeys adds a header named “DomainKey-Signature” that contains a digital
signature of the contents of the mail message. The default parameters for the
authentication mechanism are to use SHA-1 as the cryptographic hash and RSA
as the public key encryption scheme, and encode the encrypted hash using
Base64.

The receiving SMTP server then uses the name of the domain from which the
mail originated, the string _domainkey, and a selector from the header to
perform a DNS lookup. The returned data includes the domain’s public key.
The receiver can then decrypt the hash value in the header field and at the
same time recalculate the hash value for the mail body that was received,
from the point immediately following the “DomainKey-Signature:” header. If
the two values match, this cryptographically proves that the mail originated
at the purported domain and has not been tampered with in transit.

Advantages:
—————-

There are three primary advantages of this system for e-mail recipients:

* It allows the originating domain of an e-mail to be positively
identified, allowing domain-based blacklists and whitelists to be more
effective. This is also likely to make phishing attacks easier to detect.
* It allows forged e-mail messages to be discarded on sight, either by
end-user e-mail software (mail user agents), or by ISPs’ mail transfer
agents.
* It allows abusive domain owners to be tracked more easily.

There are some incentives for mail senders to authenticate outgoing e-mail:

* It allows a great reduction in abuse desk work for DomainKeys-enabled
domains if e-mail receivers use the DomainKeys system to automatically drop
forged e-mail messages claiming to be from that domain.
* The domain owner can then focus their abuse team energies on their own
users who actually are abusing their use of that domain.

INSTALLATION PROCESS:
——————————–

In order for DomainKeys to work, one must complete two steps: set up the MTA
with the private key, and publish a DNS record that will hold the public key.

For step one of this, you would use the ‘MTA’ tab in the DKeyEvent setup app;
you would select the options for signing, and then create a selector for your
domain, and generate a private key for it. Let’s say you create a selector
called ‘mail1′.

For step two, you can use the ‘Domain’ tab to generate the DNS entry for the
selector you created in step one; you would select the domain, the selector,
the options you want, and the program will give you a text string like
this: “k=rsa; t=y; p=MHww…IDAQAB”. Now, you will need to create a new IN
TXT record in your domain’s DNS to publish this information. This new TXT
record must be called selector._domainkey, and its value should be the string
generated by the DKeyEvent setup. So in the example above, if your domain
was, say, mydomain.com, the complete DNS record would be:
mail1._domainkey.mydomain.com and this would have the value “k=rsa; t=y;
p=MHww…IDAQAB”

Installation of DomainKeys (cPanel Server):

1> For a specific user:
——————————
# Run the script

/usr/local/cpanel/bin/domain_keys_installer username

Where username is the cPanel user.

If you get an error similar to “Domain keys are not installed on this
machine.” you either are not running the latest release or current version of
cPanel or you have not converted yet to maildir. Maildir conversion is
required before you install DomainKeys.

2> For all the current cPanel users on the Server:
—————————————————————

# Run the script

for i in
`ls /var/cpanel/users` ;do /usr/local/cpanel/bin/domain_keys_installer
$i ;done

3> For all the newly creating users on the Server: ( Not yet Tested )
—————————————————————-

Edit /scripts/postwwwacct and adding:

my %OPTS = @ARGV;
my $user = $OPTS{’user’};
/usr/local/cpanel/bin/domain_keys_installer $user

NOTE:
——–
if any mail is sent to a local user from the mail server(or any
aplication/web application) itself, it is left untouched by the domain
keys..

For more details about Domain Keys, please refer the following link

Bypassing yahoo’s graylisting policy
————————————————-

yahoo greylists almost all the mailservers.
Graylisting is yahoos policy where they temporary blocks mails.
you get something like “temperorily differed” when you try sending mail
once an IP is graylisted graylisting stays for some time
say 30 mins.If you retry within this ime yahoo acepts the mail.After  30 mins
this IP will be removed from the greylist.Again when you try mail It’l be
bloked.They consider that spammers dont ‘retry’ which is why they use
greylisting methord.

twaek—->

You can set Number of minutes between mail server queue runs (default is
60).: in WHM -> Server Configuration -> Tweak Settings and scrolling down to
the Mail section.

have a look at following link

#########################################################################

check below HOTMAIL staff’s reply :D

Hotmail bases its spam rating not just on the content of a message but also
on the reputation of the sending IP address. Also based on the reputation,
Hotmail limits the number of e-mail messages a particular IP can send within
a time period. Your IP has repeatedly exceeded our daily/hourly limit
thresholds. This does negatively impact the reputation of the IP and can
eventually lead to a block as the above mentioned.

By examining your SMTP logs you will be able to determine when your volume
exceeds the limit. We highly recommend reducing the volume below that limit,
to help improving the reputation of your IP address. As your reputation
improves so will the throttling limit. After some time you will be able to
gradually increase the volume that you are sending to Hotmail servers.

We reviewed your SPF record and note that it terminates with ?all. To
maximize deliverability we recommend changing it to -all.

You may also wish to reference RFC 4406, “Sender ID: Authenticating E-Mail”,
which defines the Sender ID specification. It is available at:

http://www.ietf.org/rfc/rfc4406.txt

We recommend using the hard fail (-all) closing mechanisms for reliability
and security reasons.  The soft fail should be used when you having IP’s
that are coming in through an Open DNS.

If all sending IP’s that you will use are included in the SPF record it is
best to use a hard fail (-all) because it is more secure and will help lower
the spam weight of your mail.

Please do not forget to add your new SPF as a TXT entry into your public DNS
records, if you do not have access to the DNS consult with your hosting
company or ISP.

Once you update your domains with valid SPF records you will not need to
notify us when you make this or any revision to your SPF record since we will
automatically pull the current record from the DNS daily.  Thanks again for
your support in improving online trust and confidence and if you have any
questions or comments please feel free to contact us directly.

########################################################################

3 Responses »

  1. That is fantastic. I learned so much from your post and am looking over the rest of your blog now. I will let others know about your blog. Arnold

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>