Everybody talks about doing it, but very few developers follow through - you guessed it, data backups! Perhaps it's a matter of getting burnt at least once, or having proper company policies in place (aka have a boss breath down your neck about it), but the practice remains surprisingly elusive. In either case, over the weekend I had to research how to migrate a sizable MySQL database, and hence below are a few tips from the trenches. In the end, the entire process is surprisingly simple.
MySQL tools & strategies
As popular as MySQL is there aren't many third party backup tools that will do a proper backup of your data. If you want to avoid data corruption, half-committed transactions, and many other problems, your best to go with one of the bundled backup utilities: mysqldump, mysqlhotcopy, mysqlsnapshot, and if you have the bucks, ibbackup. To select the proper tool for the job, first determine the answers to the following questions: online vs. offline backup, and data dump vs. raw.
Online vs. Offline backups
Online backups are often the preferred method as database downtime may be an unacceptable option. Having said that, offline backups are usually faster and less error prone as we do not have to worry about running transactions, table locks, orphaned processes, and other consistency problems. If you can afford to have a brief period of downtime, or if you're lucky enough to have master-slave replication, offline is the way to go.
Data dump vs. Raw backups
A data dump results in a sequence of SQL statement which can be ran against any database to recreate the database structure and the data itself. mysqldump is the premier tool in this space, and it can be used on any table type locally and even over the network. However, data dumps incur a lot of overhead with extra SQL syntax, result in larger data files, are much more CPU intensive, and most importantly, they require a full index rebuild when the data is being restored!
Arguably the most efficient way to backup your database is through a raw snapshot of the MySQL files as they exist on disk. Because we are skipping all the conversion steps, the process is much more efficient than dumps. To perform a proper backup of a MyISAM table, you will have to copy the data and the index files; for InnoDB you will need to backup the entire tablespace and the associated transaction logs.
mysqldump / mysqlhotcopy / mysqlsnapshot / ibbackup
mysqldump - (online, dump) - most commonly used tool in our toolkit. It will perform a full data dump from an online database by locking the tables and writing a hefty file to disk or a network location. It is ideally suited for small databases as the process is not very efficient.
> mysqldump
# typical mysql dump backup and restore usage
mysqldump -u root -pPassword -x --all-databases > db_dump.sql
mysql -u root -pPassword < db_dump.sql
# dump into 'backup' folder (local machine), into two text files
mysqldump -T backup --fields-terminated-by=',' database-name -u root -pPassword
# compress the dumped data on the fly
mysqldump -u root -pPassword --all-databases | bzip2 -c > db_dump.bz2
mysqlhotcopy - (online, raw) - will perform a full raw backup of any database consisting of ISAM or MyISAM tables. It operates by acquiring a read lock on all tables, copying them, and then releasing the lock.
> mysqlhotcopy
# perform an online backup into /backup/location
mysqlhotcopy -u root -p password database_name /backup/location
mysqlsnapshot - (online, raw) - a great tool to obtain a full database snapshot of any MySQL database without taking it offline. You can configure it to compress the data, and/or provide separate tar files for each database. The only downside: MyISAM only as well.
> mysqlsnapshot
# save a full database snapshot of an online database into /backup/location
mysqlsnapshot -u root -pPassword -s /backup/location
# restore a snapshot
tar -xvf /backup/location/db.tar
ibbackup - (online, raw) - will perform an online backup of InnoDB and MyISAM tables on any MySQL database. A great tool, but it comes with a price tag. Then again, if you're a heavy InnoDB user, it may well be worth the price.
> ibbackup
# perform online backup of MyISAM / InnoDB tables
ibbackup /etc/my.cnf /etc/ibbackup.cnf
# restore recent backup (as configured in ibbackup.cnf)
ibbackup --restore /etc/ibbackup.cnf
cp, scp, nc - (offline, raw) - if you can afford to take your database offline, raw backups are as simple as doing a copy, or a remote transfer to a different machine. It may sound crude, but it is arguably the safest way to get a snapshot of your data!
Network backups: Netcat & mysqldump
For full safety you should backup your data on multiple drives, and even better, on multiple computers. Thankfully, this process is remarkably simple with the help of netcat, or even mysqldump itself:
> mysqlnetwork
# Replicate / populate a remote database in a single step (redirect data dump)
mysqldump --opt --compress --user=username database | mysql --user=username2 --password=p2 --host=hostB -D database -C database
# data backup with netcat
# backup recipient - listen on port 6000, write recieved data to backup.bz2
nc -l 6000 > backup.bz2
# backup initiator - dump the database, compress, and send to hostB:6000
mysqldump --opt -u user1 -t database | bzip2 -c | nc -w1 hostB 6000
A little overwhelming at first, but once you wrap your head around online vs. offline, and raw vs. dump, it's not all that bad. And let me tell you, once automated, you also tend to sleep far better at night!
Reference: http://www.igvita.com/2007/10/10/hands-on-mysql-backup-migration/
Saturday, September 5, 2009
Friday, September 4, 2009
HOWTO: Sendmail tips for Ensim
Category:
Sendmail
— SkyHi @ Friday, September 04, 2009
Okay, I've mooched off everyone else for too long without "giving back", so here goes, my tips for Sendmail on Ensim:
1) Backup your /usr/lib/opcenter/sendmail/install/sendmail.mc and /etc/sendmail.cf and /etc/mail/access and /etc/mail/access.db and /etc/aliases files before you start!
2) These changes go in the sendmail.mc file
Security enhancements:
CODE
#FL20031125 start mods
#define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun,needmailhelo')dnl
define(`confMAX_DAEMON_CHILDREN',50)
define(`confSMTP_LOGIN_MSG',$j Sendmail Secure/Rabid; $b)
define(`confMIN_FREE_BLOCKS', `4000')
define(`confMAX_HEADERS_LENGTH', `32000')
define(`confMAX_MIME_HEADER_LENGTH', `1024')
define(`confMAX_RCPTS_PER_MESSAGE', `100')
#FL20031125 end mods
This requires a HELO or EHLO greeting from the sending SMTP server; puts limits on Sendmail forks and other settings to stop a DOS attack from overwhelming your server; Munges the Sendmail server identification to make it harder to hack (since you don't know the version of Sendmail); limits the number of recipients in a single message.
My blocklists. I put different numbers in each blocklist reject message, so I can identify & count them out of /var/log/maillog and get stats on each one...
CODE
#FL20030930 our blocklists
FEATURE(`dnsbl', `relays.ordb.org', `551 Rejected - see [url]http://ordb.org/[/url]')dnl
FEATURE(dnsbl, `bl.spamcop.net', `"552 Spam blocked see: [url]http://spamcop.net/bl.shtml?[/url]" $&{client_addr}')dnl
FEATURE(`dnsbl', `dnsbl.sorbs.net', `"554 Rejected " $&{client_addr} " found in dnsbl.sorbs.net"')dnl
FEATURE(`dnsbl', `rhsbl.sorbs.net', `"555 Rejected " $&{client_addr} " found in rhsbl.sorbs.net"')dnl
FEATURE(dnsbl,`dnsbl.njabl.org',`559 Message from $&{client_addr} rejected - see [url]http://njabl.org/[/url]')
FEATURE(`dnsbl', `sbl.spamhaus.org', `"556 Rejected " $&{client_addr} " - see [url]http://www.spamhaus.org/SBL/[/url]"')dnl
FEATURE(`dnsbl', `cbl.abuseat.org', `"557 Rejected " $&{client_addr} " - see [url]http://cbl.abuseat.org[/url]"')dnl
FEATURE(dnsbl,`dnsbl.ahbl.org', `"558 Host is on the AHBL - Please see [url]http://www.ahbl.org/tools/lookup.php?ip=[/url]"$&{client_addr}')dnl
FEATURE(`dnsbl', `chinanet.blackholes.us', `"560 Rejected " $&{client_addr} " - listed by chinanet.blackholes.us"')dnl
#don't bounce errors back to me
define(`confDOUBLE_BOUNCE_ADDRESS', `dev-null')
#delay checks, so we see the intended recipient
FEATURE(`delay_checks')dnl
#FL20030930 end of our blocklists
all of the above go before the line:
FEATURE(`blacklist_recipients')dnl
Other notes:
create an alias in /etc/alias called dev-null and point it to /dev/null:
dev-null: /dev/null
the above Double Bounce Address is where someone sends email to a bogus mailbox on YOUR server, and YOUR server bounces it back to the FROM address, which then bounces back to you, because of course it was from a spammer! This throws the double bounce into the bit bucket ;-)
The delay_checks feature causes it to log the sender from address and other info, when it rejects spam.
In file /etc/mail/access:
Connect:xxx.xxx.xxx.xxx OK
where xxx.xxx.xxx.xxx is YOUR server IP. This keeps you from blocking yourself, if you happen to get listed in one of the blocklists you use!
To apply this, run:
m4 /usr/lib/opcenter/sendmail/install/sendmail.mc > /etc/sendmail.cf
/sbin/service sendmail restart
If you have a problem, restore your /etc/sendmail.cf and restart sendmail. You DID back it up, right?
Any others with some tips?
Reference: http://forums.theplanet.com/lofiversion/index.php/t37434.html
1) Backup your /usr/lib/opcenter/sendmail/install/sendmail.mc and /etc/sendmail.cf and /etc/mail/access and /etc/mail/access.db and /etc/aliases files before you start!
2) These changes go in the sendmail.mc file
Security enhancements:
CODE
#FL20031125 start mods
#define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun,needmailhelo')dnl
define(`confMAX_DAEMON_CHILDREN',50)
define(`confSMTP_LOGIN_MSG',$j Sendmail Secure/Rabid; $b)
define(`confMIN_FREE_BLOCKS', `4000')
define(`confMAX_HEADERS_LENGTH', `32000')
define(`confMAX_MIME_HEADER_LENGTH', `1024')
define(`confMAX_RCPTS_PER_MESSAGE', `100')
#FL20031125 end mods
This requires a HELO or EHLO greeting from the sending SMTP server; puts limits on Sendmail forks and other settings to stop a DOS attack from overwhelming your server; Munges the Sendmail server identification to make it harder to hack (since you don't know the version of Sendmail); limits the number of recipients in a single message.
My blocklists. I put different numbers in each blocklist reject message, so I can identify & count them out of /var/log/maillog and get stats on each one...
CODE
#FL20030930 our blocklists
FEATURE(`dnsbl', `relays.ordb.org', `551 Rejected - see [url]http://ordb.org/[/url]')dnl
FEATURE(dnsbl, `bl.spamcop.net', `"552 Spam blocked see: [url]http://spamcop.net/bl.shtml?[/url]" $&{client_addr}')dnl
FEATURE(`dnsbl', `dnsbl.sorbs.net', `"554 Rejected " $&{client_addr} " found in dnsbl.sorbs.net"')dnl
FEATURE(`dnsbl', `rhsbl.sorbs.net', `"555 Rejected " $&{client_addr} " found in rhsbl.sorbs.net"')dnl
FEATURE(dnsbl,`dnsbl.njabl.org',`559 Message from $&{client_addr} rejected - see [url]http://njabl.org/[/url]')
FEATURE(`dnsbl', `sbl.spamhaus.org', `"556 Rejected " $&{client_addr} " - see [url]http://www.spamhaus.org/SBL/[/url]"')dnl
FEATURE(`dnsbl', `cbl.abuseat.org', `"557 Rejected " $&{client_addr} " - see [url]http://cbl.abuseat.org[/url]"')dnl
FEATURE(dnsbl,`dnsbl.ahbl.org', `"558 Host is on the AHBL - Please see [url]http://www.ahbl.org/tools/lookup.php?ip=[/url]"$&{client_addr}')dnl
FEATURE(`dnsbl', `chinanet.blackholes.us', `"560 Rejected " $&{client_addr} " - listed by chinanet.blackholes.us"')dnl
#don't bounce errors back to me
define(`confDOUBLE_BOUNCE_ADDRESS', `dev-null')
#delay checks, so we see the intended recipient
FEATURE(`delay_checks')dnl
#FL20030930 end of our blocklists
all of the above go before the line:
FEATURE(`blacklist_recipients')dnl
Other notes:
create an alias in /etc/alias called dev-null and point it to /dev/null:
dev-null: /dev/null
the above Double Bounce Address is where someone sends email to a bogus mailbox on YOUR server, and YOUR server bounces it back to the FROM address, which then bounces back to you, because of course it was from a spammer! This throws the double bounce into the bit bucket ;-)
The delay_checks feature causes it to log the sender from address and other info, when it rejects spam.
In file /etc/mail/access:
Connect:xxx.xxx.xxx.xxx OK
where xxx.xxx.xxx.xxx is YOUR server IP. This keeps you from blocking yourself, if you happen to get listed in one of the blocklists you use!
To apply this, run:
m4 /usr/lib/opcenter/sendmail/install/sendmail.mc > /etc/sendmail.cf
/sbin/service sendmail restart
If you have a problem, restore your /etc/sendmail.cf and restart sendmail. You DID back it up, right?
Any others with some tips?
Reference: http://forums.theplanet.com/lofiversion/index.php/t37434.html
Sendmail blocking spam email id, ips with access database
Category:
Sendmail
— SkyHi @ Friday, September 04, 2009
Q. How do I block some1@domain.com or IP address for Sendmail spammers?
A. Sendmail offers various options to block an email address, domain name or IP address using access database.
File /etc/mail/access act as an access control for your Sendmail smtp server. With this file you can define:
1. Who we accept mail from
2. Who we accept relaying from
3. Who we will not send to etc
Configuration
# vi /etc/mail/sendmail.cf
Make sure following line exists in your configuration file (otherwise you need to add/append following line):
FEATURE(`access_db')dnl
Save the file and exit to shell prompt. Now, open /etc/mail/access file:
# vi /etc/mail/access
To block junk or spam mail use following format
spam@domain.com REJECT
192.168.1.100 REJECT
202.54.1.100/255.0.0.0 REJECT
Save the file. Once sendmail.mc or access file is modified, you need to regenerate /etc/mail/sendmail.cf or rebuild the access database. Type any one of the following commands:
# cd /etc/mail
# make
OR
# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Restart the sendmail:
# /etc/init.d/sendmail restart
Other options supported by access database
* OK - Accept email FROM: or TO: specified address
* DISCARD - Do not accept email FROM: or TO: specified address
* REJECT - Drop email with an error FROM: or TO: specified address
* HATER - Use check_mail and check_realy rules for email
* FRIEND - Do not use check_mail and check_realy rules for email
* ERROR:ecode:etext - Drop email with specified error code (ecode) and error text message (etext).
Examples
abc.com ERROR:550:Relay denied
FROM:mail@fack.net REJECT
TO:foo@bar.com REJECT
Spam:abuse@ FRIEND
Connect:202.54.1.1 ERROR:5.7.1:550: Relay denied
How do I test access database is working or not?
Use sendmail with -bt option as follows:
# sendmail รข€“bt
> check_mail user@abc.com
OR use telnet command:
# telnet localhost 25
HELO localhost
MAIL FROM:user@abc.com
In both case you should get relay denied error.
See also:Test mail server for an open relay (http://www.cyberciti.biz/nixcraft/vivek/blogger/2006/04/test-mail-server-for-open-relay.php)
Reference: http://www.cyberciti.biz/faq/sendmail-blocking-spam-email-id-ips-with-access-database/
A. Sendmail offers various options to block an email address, domain name or IP address using access database.
File /etc/mail/access act as an access control for your Sendmail smtp server. With this file you can define:
1. Who we accept mail from
2. Who we accept relaying from
3. Who we will not send to etc
Configuration
# vi /etc/mail/sendmail.cf
Make sure following line exists in your configuration file (otherwise you need to add/append following line):
FEATURE(`access_db')dnl
Save the file and exit to shell prompt. Now, open /etc/mail/access file:
# vi /etc/mail/access
To block junk or spam mail use following format
spam@domain.com REJECT
192.168.1.100 REJECT
202.54.1.100/255.0.0.0 REJECT
Save the file. Once sendmail.mc or access file is modified, you need to regenerate /etc/mail/sendmail.cf or rebuild the access database. Type any one of the following commands:
# cd /etc/mail
# make
OR
# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Restart the sendmail:
# /etc/init.d/sendmail restart
Other options supported by access database
* OK - Accept email FROM: or TO: specified address
* DISCARD - Do not accept email FROM: or TO: specified address
* REJECT - Drop email with an error FROM: or TO: specified address
* HATER - Use check_mail and check_realy rules for email
* FRIEND - Do not use check_mail and check_realy rules for email
* ERROR:ecode:etext - Drop email with specified error code (ecode) and error text message (etext).
Examples
abc.com ERROR:550:Relay denied
FROM:mail@fack.net REJECT
TO:foo@bar.com REJECT
Spam:abuse@ FRIEND
Connect:202.54.1.1 ERROR:5.7.1:550: Relay denied
How do I test access database is working or not?
Use sendmail with -bt option as follows:
# sendmail รข€“bt
> check_mail user@abc.com
OR use telnet command:
# telnet localhost 25
HELO localhost
MAIL FROM:user@abc.com
In both case you should get relay denied error.
See also:Test mail server for an open relay (http://www.cyberciti.biz/nixcraft/vivek/blogger/2006/04/test-mail-server-for-open-relay.php)
Reference: http://www.cyberciti.biz/faq/sendmail-blocking-spam-email-id-ips-with-access-database/
Thursday, September 3, 2009
How to use Gmail as your SMTP server
Category:
Sendmail
— SkyHi @ Thursday, September 03, 2009
One of the little-known freebies Gmail offers is a portable SMTP server to send mail from any network for any email address.
Travellers who use their ISP's SMTP server to send mail with their email program (like Thunderbird or Outlook Express) can find themselves in a bind if they're on another network away from home, like at a coffee shop, airport or visiting relatives. But if you've got a free Gmail account (get one here) you can use Google's SMTP server to send mail through Thunderbird from you@example.com Update: Google rewrites the from address to your Gmail address.. Here's how to set it up:
1. In your email client software, under Outgoing mail, set the SMTP server to smtp.gmail.com.
2. Set the your username is yourgooglemailname@gmail.com and make sure "Use username and password" is checked.
3. Also check off "TLS" under "Use secure connection."
And voila! You can send mail for any email address from any network (that lets you connect to an outside SMTP server) using your Gmail account - be sure to enter your Gmail password when prompted.
Check out Gmail's help section on POP access for Gmail for specific instructions for setting this up with your email program. If you only want to use the SMTP server, skip the POP bits and only set up SMTP to work with your existing email account.
Update 1: I was remiss not to point out that Gmail will set the from address for messages sent through smtp.google.com to yourgoogleemailname@gmail.com when using this method. Profuse apologies.
A reader says: "Some clarification: I set up Gmail for a client for SMTP access, and we discovered the following huge drawback: Gmail automatically rewrites the "from" line of any e-mail you send via their SMTP gateway to your Gmail address, and it overrides any Reply-To settings you may have in your e-mail software in favor of the one in Gmail's web interface. So while Gmail's SMTP access sure is handy, it's not a perfect solution for everybody.
On the plus side, Gmail also stores and indexes anything you send via SMTP as if you had sent it using the website, so all your e-mail is still searchable and in one place. Also, since Gmail SMTP does not use port 25, I've yet to see an ISP that won't allow me to send mail through it." Thanks, David!
Update 2: The Gmail spooler is no longer available, but a reader says Gmail invites can be had at bytetest.com. Thanks, Darin!
Update 3: Reader Derek Bennett says, "The solution is to go into your gmail Settings:Accounts and "Make default" an account other than your gmail account. This will cause gmail to re-write the From field with whatever the default account's email address is."
Reference: http://lifehacker.com/111166/how-to-use-gmail-as-your-smtp-server
Travellers who use their ISP's SMTP server to send mail with their email program (like Thunderbird or Outlook Express) can find themselves in a bind if they're on another network away from home, like at a coffee shop, airport or visiting relatives. But if you've got a free Gmail account (get one here) you can use Google's SMTP server to send mail through Thunderbird from you@example.com Update: Google rewrites the from address to your Gmail address.. Here's how to set it up:
1. In your email client software, under Outgoing mail, set the SMTP server to smtp.gmail.com.
2. Set the your username is yourgooglemailname@gmail.com and make sure "Use username and password" is checked.
3. Also check off "TLS" under "Use secure connection."
And voila! You can send mail for any email address from any network (that lets you connect to an outside SMTP server) using your Gmail account - be sure to enter your Gmail password when prompted.
Check out Gmail's help section on POP access for Gmail for specific instructions for setting this up with your email program. If you only want to use the SMTP server, skip the POP bits and only set up SMTP to work with your existing email account.
Update 1: I was remiss not to point out that Gmail will set the from address for messages sent through smtp.google.com to yourgoogleemailname@gmail.com when using this method. Profuse apologies.
A reader says: "Some clarification: I set up Gmail for a client for SMTP access, and we discovered the following huge drawback: Gmail automatically rewrites the "from" line of any e-mail you send via their SMTP gateway to your Gmail address, and it overrides any Reply-To settings you may have in your e-mail software in favor of the one in Gmail's web interface. So while Gmail's SMTP access sure is handy, it's not a perfect solution for everybody.
On the plus side, Gmail also stores and indexes anything you send via SMTP as if you had sent it using the website, so all your e-mail is still searchable and in one place. Also, since Gmail SMTP does not use port 25, I've yet to see an ISP that won't allow me to send mail through it." Thanks, David!
Update 2: The Gmail spooler is no longer available, but a reader says Gmail invites can be had at bytetest.com. Thanks, Darin!
Update 3: Reader Derek Bennett says, "The solution is to go into your gmail Settings:Accounts and "Make default" an account other than your gmail account. This will cause gmail to re-write the From field with whatever the default account's email address is."
Reference: http://lifehacker.com/111166/how-to-use-gmail-as-your-smtp-server
PHP 5.2.10 with suhosin bug
Category:
PHP
— SkyHi @ Thursday, September 03, 2009
Thu Sep 03 10:36:32 2009] [notice] child pid 28161 exit signal Segmentation fault (11)
http://www.dotdeb.org/2009/06/25/php-5-2-10-packages-for-lennyetch-are-now-available/
works fine here for a big wordpress with lot of plugins, i only add suhosin.session.encrypt=0 to make it work.
http://www.dotdeb.org/2009/06/25/php-5-2-10-packages-for-lennyetch-are-now-available/
works fine here for a big wordpress with lot of plugins, i only add suhosin.session.encrypt=0 to make it work.
Wednesday, September 2, 2009
Samba permission
Category:
Samba
— SkyHi @ Wednesday, September 02, 2009
samba change everyone permission to write, the log shows
user1 opened file html/airport/data/test.rtf read=No write=No (numopen=2)
set_canon_ace_list: sys_acl_set_file type file failed for file html/airport/data/test.rtf (Operation not supported).
root closed file html/airport/data/test.rtf (numopen=1)
open and change the file over samba
user1 opened file html/airport/data/test.rtf read=Yes write=Yes (numopen=2)
root closed file html/airport/data/test.rtf (numopen=1)
user1 opened file html/airport/data/test.rtf read=Yes write=Yes (numopen=2)
root closed file html/airport/data/test.rtf (numopen=1)
user1 opened file html/airport/data/test.rtf read=No write=No (numopen=2)
set_canon_ace_list: sys_acl_set_file type file failed for file html/airport/data/test.rtf (Operation not supported).
root closed file html/airport/data/test.rtf (numopen=1)
open and change the file over samba
user1 opened file html/airport/data/test.rtf read=Yes write=Yes (numopen=2)
root closed file html/airport/data/test.rtf (numopen=1)
user1 opened file html/airport/data/test.rtf read=Yes write=Yes (numopen=2)
root closed file html/airport/data/test.rtf (numopen=1)
Linux change or rename user name and UID (user-id)
Category:
Linux
— SkyHi @ Wednesday, September 02, 2009
Q. How do I change user name (rename user name) or UID under Linux operating system?
A. Use the usermod command to change user name under Linux. it modifies the system account files to reflect the changes that are specified on the command line.
Syntax is as follows
usermod -l login-name old-name
Where,
=> The name of the user will be changed from old-name to login_name. Nothing else is changed. In particular, the user's home directory name should probably be changed to
reflect the new login name.
usermod -u UID username
Where,
=> The numerical value of the user's ID (UID) . This value must be unique, unless the -o option is used. The value must be non-negative. Values between 0 and 99 are typically reserved for system accounts. Any files which the user owns and which are located in the directory tree rooted at the user's home directory will have the file user ID changed automatically. Files outside of the user's home directory must be altered
manually.
Task: Change username from tom to jerry
Type usermod command as follows:
# id tom
# usermod -l jerry tom
# id jerry
# id tom
Task: Change user tom UID from 5001 to 10000
Type usermod command as follows
# id tom
# usermod -u 10000 tom
# id tom
Read man page of usermod for more information.
killall -u old
id old
usermod -l new old
groupmod -n new old
usermod -d /home/new -m new
usermod -c “New Real Name” new
id new
Reference: http://www.cyberciti.biz/faq/howto-change-rename-user-name-id/
A. Use the usermod command to change user name under Linux. it modifies the system account files to reflect the changes that are specified on the command line.
Syntax is as follows
usermod -l login-name old-name
Where,
=> The name of the user will be changed from old-name to login_name. Nothing else is changed. In particular, the user's home directory name should probably be changed to
reflect the new login name.
usermod -u UID username
Where,
=> The numerical value of the user's ID (UID) . This value must be unique, unless the -o option is used. The value must be non-negative. Values between 0 and 99 are typically reserved for system accounts. Any files which the user owns and which are located in the directory tree rooted at the user's home directory will have the file user ID changed automatically. Files outside of the user's home directory must be altered
manually.
Task: Change username from tom to jerry
Type usermod command as follows:
# id tom
# usermod -l jerry tom
# id jerry
# id tom
Task: Change user tom UID from 5001 to 10000
Type usermod command as follows
# id tom
# usermod -u 10000 tom
# id tom
Read man page of usermod for more information.
killall -u old
id old
usermod -l new old
groupmod -n new old
usermod -d /home/new -m new
usermod -c “New Real Name” new
id new
Reference: http://www.cyberciti.biz/faq/howto-change-rename-user-name-id/
Sendmail Anti-Spam Configuration Control
Category:
Sendmail
— SkyHi @ Wednesday, September 02, 2009
1. Overview
2. relay_* Features
3. Access Database
4. Fine Control In The Access Database
5. Delay All Checks
6. Header Checks
Overview
The primary anti-spam features available in sendmail are:
* Relaying is denied by default.
* Better checking on sender information.
* Access database.
* Header checks.
Relaying (transmission of messages from a site outside your host (class {w}) to another site except yours) is denied by default. Note that this changed in sendmail 8.9; previous versions allowed relaying by default. If you really want to revert to the old behaviour, you will need to use FEATURE(`promiscuous_relay'). You can allow certain domains to relay through your server by adding their domain name or IP address to class {R} using RELAY_DOMAIN() and RELAY_DOMAIN_FILE() or via the Access Database. Note that IPv6 addresses must be prefaced with "IPv6:". The file consists (like any other file based class) of entries listed on separate lines, e.g.,
sendmail.org
128.32
IPv6:2002:c0a8:02c7
IPv6:2002:c0a8:51d2::23f4
host.mydomain.com
[UNIX:localhost]
Notice: the last entry allows relaying for connections via a UNIX socket to the MTA/MSP. This might be necessary if your configuration doesn't allow relaying by other means in that case, e.g., by having localhost.$m in class {R} (make sure $m is not just a top level domain).
relay_* Features
If you use
FEATURE(`relay_entire_domain')
then any host in any of your local domains (that is, class {m}) will be relayed (that is, you will accept mail either to or from any host in your domain).
You can also allow relaying based on the MX records of the host portion of an incoming recipient address by using
FEATURE(`relay_based_on_MX')
For example, if your server receives a recipient of user@domain.com and domain.com lists your server in its MX records, the mail will be accepted for relay to domain.com. This feature may cause problems if MX lookups for the recipient domain are slow or time out. In that case, mail will be temporarily rejected. It is usually better to maintain a list of hosts/domains for which the server acts as relay. Note also that this feature will stop spammers from using your host to relay spam but it will not stop outsiders from using your server as a relay for their site (that is, they set up an MX record pointing to your mail server, and you will relay mail addressed to them without any prior arrangement). Along the same lines,
FEATURE(`relay_local_from')
will allow relaying if the sender specifies a return path (i.e. MAIL FROM:) domain which is a local domain.
This is a dangerous feature as it will allow spammers to spam using your mail server by simply specifying a return address of user@your.domain.com. It should not be used unless absolutely necessary.
A slightly better solution is
FEATURE(`relay_mail_from')
which allows relaying if the mail sender is listed as RELAY in the access map. If an optional argument `domain' (this is the literal word `domain', not a placeholder) is given, the domain portion of the mail sender is also checked to allowing relaying. This option only works together with the tag From: for the LHS of the access map entries (see below: Finer control).
This feature allows spammers to abuse your mail server by specifying a return address that you enabled in your access file. This may be harder to figure out for spammers, but it should not be used unless necessary.
Instead use SMTP AUTH or STARTTLS to allow relaying for roaming users.
If source routing is used in the recipient address (e.g., RCPT TO:), sendmail will check user@site.com for relaying if othersite.com is an allowed relay host in either class {R}, class {m} if FEATURE(`relay_entire_domain') is used, or the access database if FEATURE(`access_db') is used. To prevent the address from being stripped down, use:
FEATURE(`loose_relay_check')
If you think you need to use this feature, you probably do not. This should only be used for sites which have no control over the addresses that they provide a gateway for. Use this FEATURE with caution as it can allow spammers to relay through your server if not setup properly.
NOTICE: It is possible to relay mail through a system which the anti-relay rules do not prevent:
the case of a system that does use FEATURE(`nouucp', `nospecial') (system A) and relays local messages to a mail hub (e.g., via LOCAL_RELAY or LUSER_RELAY) (system B). If system B doesn't use FEATURE(`nouucp') at all, addresses of the form would be relayed to .
System A doesn't recognize `!' as an address separator and therefore forwards it to the mail hub which in turns relays it because it came from a trusted local host. So if a mailserver allows UUCP (bang-format) addresses, all systems from which it allows relaying should do the same or reject those addresses.
As of 8.9, sendmail will refuse mail if the MAIL FROM: parameter has an unresolvable domain (i.e., one that DNS, your local name service, or special case rules in ruleset 3 cannot locate). This also applies to addresses that use domain literals, e.g.,, if the IP address can't be mapped to a host name. If you want to continue to accept such domains, e.g., because you are inside a firewall that has only a limited view of the Internet host name space (note that you will not be able to return mail to them unless you have some "smart host" forwarder), use
FEATURE(`accept_unresolvable_domains')
Alternatively, you can allow specific addresses by adding them to the access map, e.g.,
From:unresolvable.domain OK
From:[1.2.3.4] OK
From:[1.2.4] OK
Notice: domains which are temporarily unresolvable are (temporarily) rejected with a 451 reply code. If those domains should be accepted (which is discouraged) then you can use
LOCAL_CONFIG
C{ResOk}TEMP
sendmail will also refuse mail if the MAIL FROM: parameter is not fully qualified (i.e., contains a domain as well as a user). If you want to continue to accept such senders, use
FEATURE(`accept_unqualified_senders')
Setting the DaemonPortOptions modifier 'u' overrides the default behavior, i.e., unqualified addresses are accepted even without this FEATURE. If this FEATURE is not used, the DaemonPortOptions modifier 'f' can be used to enforce fully qualified domain names.
Access Database
An ``access'' database can be created to accept or reject mail from selected domains. For example, you may choose to reject all mail originating from known spammers. To enable such a database, use
FEATURE(`access_db')
Notice: the access database is applied to the envelope addresses and the connection information, not to the header.
The FEATURE macro can accept as second parameter the key file definition for the database; for example
FEATURE(`access_db', `hash -T /etc/mail/access_map')
Notice: If a second argument is specified it must contain the option `-T' as shown above. The optional third and fourth parameters may be `skip' or `lookupdotdomain'. The former enables SKIP as value part (see below), the latter is another way to enable the feature of the same name.
Remember, since /etc/mail/access is a database, after creating the text file as described below, you must use makemap to create the database map. For example:
makemap hash /etc/mail/access < /etc/mail/access
The table itself uses e-mail addresses, domain names, and network numbers as keys. Note that IPv6 addresses must be prefaced with "IPv6:". For example,
spammer@aol.com REJECT
cyberspammer.com REJECT
TLD REJECT
192.168.212 REJECT
IPv6:2002:c0a8:02c7 RELAY
IPv6:2002:c0a8:51d2::23f4 REJECT
would refuse mail from spammer@aol.com, any user from cyberspammer.com (or any host within the cyberspammer.com domain), any host in the entire top level domain TLD, 192.168.212.* network, and the IPv6 address 2002:c0a8:51d2::23f4. It would allow relay for the IPv6 network 2002:c0a8:02c7::/48.
The value part of the map can contain:
OK Accept mail even if other rules in the running ruleset would reject it, for example, if the domain name is unresolvable. "Accept" does not mean "relay", but at most acceptance for local recipients. That is, OK allows less than RELAY.
RELAY Accept mail addressed to the indicated domain or received from the indicated domain for relaying through your SMTP server. RELAY also serves as an implicit OK for the other checks.
REJECT Reject the sender or recipient with a general purpose message.
DISCARD Discard the message completely using the $#discard mailer. If it is used in check_compat, it affects only the designated recipient, not the whole message as it does in all other cases. This should only be used if really necessary.
SKIP This can only be used for host/domain names and IP addresses/nets. It will abort the current search for this entry without accepting or rejecting it but causing the default action.
### any text where ### is an RFC 821 compliant error code and "any text" is a message to return for the command. The string should be quoted to avoid surprises, e.g., sendmail may remove spaces otherwise. This type is deprecated, use one the two ERROR: entries below instead.
ERROR:### any text as above, but useful to mark error messages as such.
ERROR:D.S.N:### any text where D.S.N is an RFC 1893 compliant error code and the rest as above.
For example:
cyberspammer.com ERROR:"550 We don't accept mail from spammers"
okay.cyberspammer.com OK
sendmail.org RELAY
128.32 RELAY
IPv6:1:2:3:4:5:6:7 RELAY
[127.0.0.3] OK
[IPv6:1:2:3:4:5:6:7:8] OK
would accept mail from okay.cyberspammer.com, but would reject mail from all other hosts at cyberspammer.com with the indicated message. It would allow relaying mail from and to any hosts in the sendmail.org domain, and allow relaying from the 128.32.*.* network and the IPv6 1:2:3:4:5:6:7:* network. The latter two entries are for checks against ${client_name} if the IP address doesn't resolve to a hostname (or is considered as "may be forged"). That is, using square brackets means these are host names, not network numbers.
Warning: if you change the RFC 821 compliant error code from the default value of 550, then you should probably also change the RFC 1893 compliant error code to match it.
For example, if you use
user@example.com ERROR:450 mailbox full
the error returned would be "450 5.0.0 mailbox full" which is wrong. Use "ERROR:4.2.2:450 mailbox full" instead.
Note, UUCP users may need to add hostname.UUCP to the access database or class {R}.
If you also use:
FEATURE(`relay_hosts_only')
then the above example will allow relaying for sendmail.org, but not hosts within the sendmail.org domain. Note that this will also require hosts listed in class {R} to be fully qualified host names.
You can also use the access database to block sender addresses based on the username portion of the address. For example:
FREE.STEALTH.MAILER@ ERROR:550 Spam not accepted
Note that you must include the @ after the username to signify that this database entry is for checking only the username portion of the sender address.
If you use:
FEATURE(`blacklist_recipients')
then you can add entries to the map for local users, hosts in your domains, or addresses in your domain which should not receive mail:
badlocaluser@ ERROR:550 Mailbox disabled for this username
host.mydomain.com ERROR:550 That host does not accept mail
user@otherhost.mydomain.com ERROR:550 Mailbox disabled for this recipient
This would prevent a recipient of badlocaluser@mydomain.com, any user at host.mydomain.com, and the single address user@otherhost.mydomain.com from receiving mail.
Please note: a local username must be now tagged with an @ (this is consistent with the check of the sender address, and hence it is possible to distinguish between hostnames and usernames). Enabling this feature will keep you from sending mails to all addresses that have an error message or REJECT as value part in the access map. Taking the example from above:
spammer@aol.com REJECT
cyberspammer.com REJECT
Mail can't be sent to spammer@aol.com or anyone at cyberspammer.com.
There are several DNS based blacklists, the first of which was the RBL (``Realtime Blackhole List'') run by the MAPS project, see http://mail-abuse.org/. These are databases of spammers maintained in DNS. To use such a database, specify
FEATURE(`dnsbl')
This will cause sendmail to reject mail from any site in the original Realtime Blackhole List database. This default DNS blacklist, blackholes.mail-abuse.org, is a service offered by the Mail Abuse Prevention System (MAPS). As of July 31, 2001, MAPS is a subscription service, so using that network address won't work if you haven't subscribed. Contact MAPS to subscribe (http://mail-abuse.org/).
You can specify an alternative RBL server to check by specifying an argument to the FEATURE. The default error message is
Rejected: IP-ADDRESS listed at SERVER
where IP-ADDRESS and SERVER are replaced by the appropriate information. A second argument can be used to specify a different text. By default, temporary lookup failures are ignored and hence cause the connection not to be rejected by the DNS based rejection list. This behavior can be changed by specifying a third argument, which must be either `t' or a full error message. For example:
FEATURE(`dnsbl', `dnsbl.example.com', `', `"451 Temporary lookup failure for " $&{client_addr} " in dnsbl.example.com"')
If `t' is used, the error message is:
451 Temporary lookup failure of IP-ADDRESS at SERVER
where IP-ADDRESS and SERVER are replaced by the appropriate information.
This FEATURE can be included several times to query different DNS based rejection lists, e.g., the MAPS Dial-Up User List (DUL).
Notice: to avoid checking your own local domains against those blacklists, use the access_db feature and add:
Connect:10.1 OK
Connect:127.0.0.1 RELAY
to the access map, where 10.1 is your local network. You may want to use "RELAY" instead of "OK" to allow also relaying instead of just disabling the DNS lookups in the backlists.
The features described above make use of the check_relay, check_mail, and check_rcpt rulesets. Note that check_relay checks the SMTP client hostname and IP address when the connection is made to your server. It does not check if a mail message is being relayed to another server. That check is done in check_rcpt. If you wish to include your own checks, you can put your checks in the rulesets Local_check_relay, Local_check_mail, and Local_check_rcpt. For example if you wanted to block senders with all numeric usernames (i.e. 2312343@bigisp.com), you would use Local_check_mail and the regex map:
LOCAL_CONFIG
Kallnumbers regex -a@MATCH ^[0-9]+$
LOCAL_RULESETS
SLocal_check_mail
# check address against various regex checks
R$* $: $>Parse0 $>3 $1
R$+ < @ bigisp.com. > $* $: $(allnumbers $1 $)
R@MATCH $#error $: 553 Header Error
These rules are called with the original arguments of the corresponding check_* ruleset. If the local ruleset returns $#OK, no further checking is done by the features described above and the mail is accepted. If the local ruleset resolves to a mailer (such as $#error or $#discard), the appropriate action is taken. Otherwise, the results of the local rewriting are ignored.
Finer control by using tags for the LHS of the access map
Read this section only if the options listed so far are not sufficient for your purposes. There is now the option to tag entries in the access map according to their type. Three tags are available:
Connect: connection information (${client_addr}, ${client_name})
From: envelope sender
To: envelope recipient
If the required item is looked up in a map, it will be tried first with the corresponding tag in front, then (as fallback to enable backward compatibility) without any tag, unless the specific feature requires a tag. For example,
From:spammer@some.dom REJECT
To:friend.domain RELAY
Connect:friend.domain OK
Connect:from.domain RELAY
From:good@another.dom OK
From:another.dom REJECT
This would deny mails from spammer@some.dom but you could still send mail to that address even if FEATURE(`blacklist_recipients') is enabled. Your system will allow relaying to friend.domain, but not from it (unless enabled by other means). Connections from that domain will be allowed even if it ends up in one of the DNS based rejection lists. Relaying is enabled from from.domain but not to it (since relaying is based on the connection information for outgoing relaying, the tag Connect: must be used; for incoming relaying, which is based on the recipient address, To: must be used). The last two entries allow mails from good@another.dom but reject mail from all other addresses with another.dom as domain part.
Delay all checks
By using FEATURE(`delay_checks') the rulesets check_mail and check_relay will not be called when a client connects or issues a MAIL command, respectively. Instead, those rulesets will be called by the check_rcpt ruleset; they will be skipped if a sender has been authenticated using a "trusted" mechanism, i.e., one that is defined via TRUST_AUTH_MECH(). If check_mail returns an error then the RCPT TO command will be rejected with that error. If it returns some other result starting with $# then check_relay will be skipped. If the sender address (or a part of it) is listed in the access map and it has a RHS of OK or RELAY, then check_relay will be skipped.
This has an interesting side effect: if your domain is my.domain and you have
my.domain RELAY
in the access map, then any e-mail with a sender address of will not be rejected by check_relay even though it would match the hostname or IP address. This allows spammers to get around DNS based blacklist by faking the sender address. To avoid this problem you have to use tagged entries:
To:my.domain RELAY
Connect:my.domain RELAY
if you need those entries at all (class {R} may take care of them).
FEATURE(`delay_checks') can take an optional argument:
FEATURE(`delay_checks', `friend') enables spamfriend test
FEATURE(`delay_checks', `hater') enables spamhater test
If such an argument is given, the recipient will be looked up in the access map (using the tag Spam:). If the argument is `friend', then the default behavior is to apply the other rulesets and make a SPAM friend the exception. The rulesets check_mail and check_relay will be skipped only if the recipient address is found and has RHS FRIEND. If the argument is `hater', then the default behavior is to skip the rulesets check_mail and check_relay and make a SPAM hater the exception. The other two rulesets will be applied only if the recipient address is found and has RHS HATER.
This allows for simple exceptions from the tests, e.g., by activating the friend option and having
Spam:abuse@ FRIEND
in the access map, mail to abuse@localdomain will get through (where "localdomain" is any domain in class {w}). It is also possible to specify a full address or an address with +detail:
Spam:abuse@my.domain FRIEND
Spam:me+abuse@ FRIEND
Spam:spam.domain FRIEND
Note: The required tag has been changed in 8.12 from To: to Spam:.
This change is incompatible to previous versions. However, you can (for now) simply add the new entries to the access map, the old ones will be ignored. As soon as you removed the old entries from the access map, specify a third parameter (`n') to this feature and the backward compatibility rules will not be in the generated .cf file.
Header Checks
You can also reject mail on the basis of the contents of headers. This is done by adding a ruleset call to the 'H' header definition command in sendmail.cf. For example, this can be used to check the validity of a Message-ID: header:
LOCAL_CONFIG
HMessage-Id: $>CheckMessageId
LOCAL_RULESETS
SCheckMessageId
R< $+ @ $+ > $@ OK
R$* $#error $: 553 Header Error
The alternative format:
HSubject: $>+CheckSubject
that is, $>+ instead of $>, gives the full Subject: header including comments to the ruleset (comments in parentheses () are stripped by default).
A default ruleset for headers which don't have a specific ruleset defined for them can be given by:
H*: $>CheckHdr
Notice:
1. All rules act on tokens as explained in doc/op/op.{me,ps,txt}. That may cause problems with simple header checks due to the tokenization. It might be simpler to use a regex map and apply it to $&{currHeader}.
2. There are no default rulesets coming with this distribution of sendmail. You can either write your own or you can search the WWW for examples.
After all of the headers are read, the check_eoh ruleset will be called for any final header-related checks. The ruleset is called with the number of headers and the size of all of the headers in bytes separated by $|. One example usage is to reject messages which do not have a Message-Id: header. However, the Message-Id: header is not a required header and is not a guaranteed spam indicator. This ruleset is an example and should probably not be used in production.
LOCAL_CONFIG
Kstorage macro
HMessage-Id: $>CheckMessageId
LOCAL_RULESETS
SCheckMessageId
# Record the presence of the header
R$* $: $(storage {MessageIdCheck} $@ OK $) $1
R< $+ @ $+ > $@ OK
R$* $#error $: 553 Header Error
Scheck_eoh
# Check the macro
R$* $: < $&{MessageIdCheck} >
# Clear the macro for the next message
R$* $: $(storage {MessageIdCheck} $) $1
# Has a Message-Id: header
R< $+ > $@ OK
# Allow missing Message-Id: from local mail
R$* $: < $&{client_name} >
R< > $@ OK
R< $=w > $@ OK
# Otherwise, reject the mail
R$* $#error $: 553 Header Error
Reference: http://www.sendmail.org/m4/anti_spam.htmlse
2. relay_* Features
3. Access Database
4. Fine Control In The Access Database
5. Delay All Checks
6. Header Checks
Overview
The primary anti-spam features available in sendmail are:
* Relaying is denied by default.
* Better checking on sender information.
* Access database.
* Header checks.
Relaying (transmission of messages from a site outside your host (class {w}) to another site except yours) is denied by default. Note that this changed in sendmail 8.9; previous versions allowed relaying by default. If you really want to revert to the old behaviour, you will need to use FEATURE(`promiscuous_relay'). You can allow certain domains to relay through your server by adding their domain name or IP address to class {R} using RELAY_DOMAIN() and RELAY_DOMAIN_FILE() or via the Access Database. Note that IPv6 addresses must be prefaced with "IPv6:". The file consists (like any other file based class) of entries listed on separate lines, e.g.,
sendmail.org
128.32
IPv6:2002:c0a8:02c7
IPv6:2002:c0a8:51d2::23f4
host.mydomain.com
[UNIX:localhost]
Notice: the last entry allows relaying for connections via a UNIX socket to the MTA/MSP. This might be necessary if your configuration doesn't allow relaying by other means in that case, e.g., by having localhost.$m in class {R} (make sure $m is not just a top level domain).
relay_* Features
If you use
FEATURE(`relay_entire_domain')
then any host in any of your local domains (that is, class {m}) will be relayed (that is, you will accept mail either to or from any host in your domain).
You can also allow relaying based on the MX records of the host portion of an incoming recipient address by using
FEATURE(`relay_based_on_MX')
For example, if your server receives a recipient of user@domain.com and domain.com lists your server in its MX records, the mail will be accepted for relay to domain.com. This feature may cause problems if MX lookups for the recipient domain are slow or time out. In that case, mail will be temporarily rejected. It is usually better to maintain a list of hosts/domains for which the server acts as relay. Note also that this feature will stop spammers from using your host to relay spam but it will not stop outsiders from using your server as a relay for their site (that is, they set up an MX record pointing to your mail server, and you will relay mail addressed to them without any prior arrangement). Along the same lines,
FEATURE(`relay_local_from')
will allow relaying if the sender specifies a return path (i.e. MAIL FROM:
This is a dangerous feature as it will allow spammers to spam using your mail server by simply specifying a return address of user@your.domain.com. It should not be used unless absolutely necessary.
A slightly better solution is
FEATURE(`relay_mail_from')
which allows relaying if the mail sender is listed as RELAY in the access map. If an optional argument `domain' (this is the literal word `domain', not a placeholder) is given, the domain portion of the mail sender is also checked to allowing relaying. This option only works together with the tag From: for the LHS of the access map entries (see below: Finer control).
This feature allows spammers to abuse your mail server by specifying a return address that you enabled in your access file. This may be harder to figure out for spammers, but it should not be used unless necessary.
Instead use SMTP AUTH or STARTTLS to allow relaying for roaming users.
If source routing is used in the recipient address (e.g., RCPT TO:
FEATURE(`loose_relay_check')
If you think you need to use this feature, you probably do not. This should only be used for sites which have no control over the addresses that they provide a gateway for. Use this FEATURE with caution as it can allow spammers to relay through your server if not setup properly.
NOTICE: It is possible to relay mail through a system which the anti-relay rules do not prevent:
the case of a system that does use FEATURE(`nouucp', `nospecial') (system A) and relays local messages to a mail hub (e.g., via LOCAL_RELAY or LUSER_RELAY) (system B). If system B doesn't use FEATURE(`nouucp') at all, addresses of the form
System A doesn't recognize `!' as an address separator and therefore forwards it to the mail hub which in turns relays it because it came from a trusted local host. So if a mailserver allows UUCP (bang-format) addresses, all systems from which it allows relaying should do the same or reject those addresses.
As of 8.9, sendmail will refuse mail if the MAIL FROM: parameter has an unresolvable domain (i.e., one that DNS, your local name service, or special case rules in ruleset 3 cannot locate). This also applies to addresses that use domain literals, e.g.,
FEATURE(`accept_unresolvable_domains')
Alternatively, you can allow specific addresses by adding them to the access map, e.g.,
From:unresolvable.domain OK
From:[1.2.3.4] OK
From:[1.2.4] OK
Notice: domains which are temporarily unresolvable are (temporarily) rejected with a 451 reply code. If those domains should be accepted (which is discouraged) then you can use
LOCAL_CONFIG
C{ResOk}TEMP
sendmail will also refuse mail if the MAIL FROM: parameter is not fully qualified (i.e., contains a domain as well as a user). If you want to continue to accept such senders, use
FEATURE(`accept_unqualified_senders')
Setting the DaemonPortOptions modifier 'u' overrides the default behavior, i.e., unqualified addresses are accepted even without this FEATURE. If this FEATURE is not used, the DaemonPortOptions modifier 'f' can be used to enforce fully qualified domain names.
Access Database
An ``access'' database can be created to accept or reject mail from selected domains. For example, you may choose to reject all mail originating from known spammers. To enable such a database, use
FEATURE(`access_db')
Notice: the access database is applied to the envelope addresses and the connection information, not to the header.
The FEATURE macro can accept as second parameter the key file definition for the database; for example
FEATURE(`access_db', `hash -T
Notice: If a second argument is specified it must contain the option `-T
Remember, since /etc/mail/access is a database, after creating the text file as described below, you must use makemap to create the database map. For example:
makemap hash /etc/mail/access < /etc/mail/access
The table itself uses e-mail addresses, domain names, and network numbers as keys. Note that IPv6 addresses must be prefaced with "IPv6:". For example,
spammer@aol.com REJECT
cyberspammer.com REJECT
TLD REJECT
192.168.212 REJECT
IPv6:2002:c0a8:02c7 RELAY
IPv6:2002:c0a8:51d2::23f4 REJECT
would refuse mail from spammer@aol.com, any user from cyberspammer.com (or any host within the cyberspammer.com domain), any host in the entire top level domain TLD, 192.168.212.* network, and the IPv6 address 2002:c0a8:51d2::23f4. It would allow relay for the IPv6 network 2002:c0a8:02c7::/48.
The value part of the map can contain:
OK Accept mail even if other rules in the running ruleset would reject it, for example, if the domain name is unresolvable. "Accept" does not mean "relay", but at most acceptance for local recipients. That is, OK allows less than RELAY.
RELAY Accept mail addressed to the indicated domain or received from the indicated domain for relaying through your SMTP server. RELAY also serves as an implicit OK for the other checks.
REJECT Reject the sender or recipient with a general purpose message.
DISCARD Discard the message completely using the $#discard mailer. If it is used in check_compat, it affects only the designated recipient, not the whole message as it does in all other cases. This should only be used if really necessary.
SKIP This can only be used for host/domain names and IP addresses/nets. It will abort the current search for this entry without accepting or rejecting it but causing the default action.
### any text where ### is an RFC 821 compliant error code and "any text" is a message to return for the command. The string should be quoted to avoid surprises, e.g., sendmail may remove spaces otherwise. This type is deprecated, use one the two ERROR: entries below instead.
ERROR:### any text as above, but useful to mark error messages as such.
ERROR:D.S.N:### any text where D.S.N is an RFC 1893 compliant error code and the rest as above.
For example:
cyberspammer.com ERROR:"550 We don't accept mail from spammers"
okay.cyberspammer.com OK
sendmail.org RELAY
128.32 RELAY
IPv6:1:2:3:4:5:6:7 RELAY
[127.0.0.3] OK
[IPv6:1:2:3:4:5:6:7:8] OK
would accept mail from okay.cyberspammer.com, but would reject mail from all other hosts at cyberspammer.com with the indicated message. It would allow relaying mail from and to any hosts in the sendmail.org domain, and allow relaying from the 128.32.*.* network and the IPv6 1:2:3:4:5:6:7:* network. The latter two entries are for checks against ${client_name} if the IP address doesn't resolve to a hostname (or is considered as "may be forged"). That is, using square brackets means these are host names, not network numbers.
Warning: if you change the RFC 821 compliant error code from the default value of 550, then you should probably also change the RFC 1893 compliant error code to match it.
For example, if you use
user@example.com ERROR:450 mailbox full
the error returned would be "450 5.0.0 mailbox full" which is wrong. Use "ERROR:4.2.2:450 mailbox full" instead.
Note, UUCP users may need to add hostname.UUCP to the access database or class {R}.
If you also use:
FEATURE(`relay_hosts_only')
then the above example will allow relaying for sendmail.org, but not hosts within the sendmail.org domain. Note that this will also require hosts listed in class {R} to be fully qualified host names.
You can also use the access database to block sender addresses based on the username portion of the address. For example:
FREE.STEALTH.MAILER@ ERROR:550 Spam not accepted
Note that you must include the @ after the username to signify that this database entry is for checking only the username portion of the sender address.
If you use:
FEATURE(`blacklist_recipients')
then you can add entries to the map for local users, hosts in your domains, or addresses in your domain which should not receive mail:
badlocaluser@ ERROR:550 Mailbox disabled for this username
host.mydomain.com ERROR:550 That host does not accept mail
user@otherhost.mydomain.com ERROR:550 Mailbox disabled for this recipient
This would prevent a recipient of badlocaluser@mydomain.com, any user at host.mydomain.com, and the single address user@otherhost.mydomain.com from receiving mail.
Please note: a local username must be now tagged with an @ (this is consistent with the check of the sender address, and hence it is possible to distinguish between hostnames and usernames). Enabling this feature will keep you from sending mails to all addresses that have an error message or REJECT as value part in the access map. Taking the example from above:
spammer@aol.com REJECT
cyberspammer.com REJECT
Mail can't be sent to spammer@aol.com or anyone at cyberspammer.com.
There are several DNS based blacklists, the first of which was the RBL (``Realtime Blackhole List'') run by the MAPS project, see http://mail-abuse.org/. These are databases of spammers maintained in DNS. To use such a database, specify
FEATURE(`dnsbl')
This will cause sendmail to reject mail from any site in the original Realtime Blackhole List database. This default DNS blacklist, blackholes.mail-abuse.org, is a service offered by the Mail Abuse Prevention System (MAPS). As of July 31, 2001, MAPS is a subscription service, so using that network address won't work if you haven't subscribed. Contact MAPS to subscribe (http://mail-abuse.org/).
You can specify an alternative RBL server to check by specifying an argument to the FEATURE. The default error message is
Rejected: IP-ADDRESS listed at SERVER
where IP-ADDRESS and SERVER are replaced by the appropriate information. A second argument can be used to specify a different text. By default, temporary lookup failures are ignored and hence cause the connection not to be rejected by the DNS based rejection list. This behavior can be changed by specifying a third argument, which must be either `t' or a full error message. For example:
FEATURE(`dnsbl', `dnsbl.example.com', `', `"451 Temporary lookup failure for " $&{client_addr} " in dnsbl.example.com"')
If `t' is used, the error message is:
451 Temporary lookup failure of IP-ADDRESS at SERVER
where IP-ADDRESS and SERVER are replaced by the appropriate information.
This FEATURE can be included several times to query different DNS based rejection lists, e.g., the MAPS Dial-Up User List (DUL).
Notice: to avoid checking your own local domains against those blacklists, use the access_db feature and add:
Connect:10.1 OK
Connect:127.0.0.1 RELAY
to the access map, where 10.1 is your local network. You may want to use "RELAY" instead of "OK" to allow also relaying instead of just disabling the DNS lookups in the backlists.
The features described above make use of the check_relay, check_mail, and check_rcpt rulesets. Note that check_relay checks the SMTP client hostname and IP address when the connection is made to your server. It does not check if a mail message is being relayed to another server. That check is done in check_rcpt. If you wish to include your own checks, you can put your checks in the rulesets Local_check_relay, Local_check_mail, and Local_check_rcpt. For example if you wanted to block senders with all numeric usernames (i.e. 2312343@bigisp.com), you would use Local_check_mail and the regex map:
LOCAL_CONFIG
Kallnumbers regex -a@MATCH ^[0-9]+$
LOCAL_RULESETS
SLocal_check_mail
# check address against various regex checks
R$* $: $>Parse0 $>3 $1
R$+ < @ bigisp.com. > $* $: $(allnumbers $1 $)
R@MATCH $#error $: 553 Header Error
These rules are called with the original arguments of the corresponding check_* ruleset. If the local ruleset returns $#OK, no further checking is done by the features described above and the mail is accepted. If the local ruleset resolves to a mailer (such as $#error or $#discard), the appropriate action is taken. Otherwise, the results of the local rewriting are ignored.
Finer control by using tags for the LHS of the access map
Read this section only if the options listed so far are not sufficient for your purposes. There is now the option to tag entries in the access map according to their type. Three tags are available:
Connect: connection information (${client_addr}, ${client_name})
From: envelope sender
To: envelope recipient
If the required item is looked up in a map, it will be tried first with the corresponding tag in front, then (as fallback to enable backward compatibility) without any tag, unless the specific feature requires a tag. For example,
From:spammer@some.dom REJECT
To:friend.domain RELAY
Connect:friend.domain OK
Connect:from.domain RELAY
From:good@another.dom OK
From:another.dom REJECT
This would deny mails from spammer@some.dom but you could still send mail to that address even if FEATURE(`blacklist_recipients') is enabled. Your system will allow relaying to friend.domain, but not from it (unless enabled by other means). Connections from that domain will be allowed even if it ends up in one of the DNS based rejection lists. Relaying is enabled from from.domain but not to it (since relaying is based on the connection information for outgoing relaying, the tag Connect: must be used; for incoming relaying, which is based on the recipient address, To: must be used). The last two entries allow mails from good@another.dom but reject mail from all other addresses with another.dom as domain part.
Delay all checks
By using FEATURE(`delay_checks') the rulesets check_mail and check_relay will not be called when a client connects or issues a MAIL command, respectively. Instead, those rulesets will be called by the check_rcpt ruleset; they will be skipped if a sender has been authenticated using a "trusted" mechanism, i.e., one that is defined via TRUST_AUTH_MECH(). If check_mail returns an error then the RCPT TO command will be rejected with that error. If it returns some other result starting with $# then check_relay will be skipped. If the sender address (or a part of it) is listed in the access map and it has a RHS of OK or RELAY, then check_relay will be skipped.
This has an interesting side effect: if your domain is my.domain and you have
my.domain RELAY
in the access map, then any e-mail with a sender address of
To:my.domain RELAY
Connect:my.domain RELAY
if you need those entries at all (class {R} may take care of them).
FEATURE(`delay_checks') can take an optional argument:
FEATURE(`delay_checks', `friend') enables spamfriend test
FEATURE(`delay_checks', `hater') enables spamhater test
If such an argument is given, the recipient will be looked up in the access map (using the tag Spam:). If the argument is `friend', then the default behavior is to apply the other rulesets and make a SPAM friend the exception. The rulesets check_mail and check_relay will be skipped only if the recipient address is found and has RHS FRIEND. If the argument is `hater', then the default behavior is to skip the rulesets check_mail and check_relay and make a SPAM hater the exception. The other two rulesets will be applied only if the recipient address is found and has RHS HATER.
This allows for simple exceptions from the tests, e.g., by activating the friend option and having
Spam:abuse@ FRIEND
in the access map, mail to abuse@localdomain will get through (where "localdomain" is any domain in class {w}). It is also possible to specify a full address or an address with +detail:
Spam:abuse@my.domain FRIEND
Spam:me+abuse@ FRIEND
Spam:spam.domain FRIEND
Note: The required tag has been changed in 8.12 from To: to Spam:.
This change is incompatible to previous versions. However, you can (for now) simply add the new entries to the access map, the old ones will be ignored. As soon as you removed the old entries from the access map, specify a third parameter (`n') to this feature and the backward compatibility rules will not be in the generated .cf file.
Header Checks
You can also reject mail on the basis of the contents of headers. This is done by adding a ruleset call to the 'H' header definition command in sendmail.cf. For example, this can be used to check the validity of a Message-ID: header:
LOCAL_CONFIG
HMessage-Id: $>CheckMessageId
LOCAL_RULESETS
SCheckMessageId
R< $+ @ $+ > $@ OK
R$* $#error $: 553 Header Error
The alternative format:
HSubject: $>+CheckSubject
that is, $>+ instead of $>, gives the full Subject: header including comments to the ruleset (comments in parentheses () are stripped by default).
A default ruleset for headers which don't have a specific ruleset defined for them can be given by:
H*: $>CheckHdr
Notice:
1. All rules act on tokens as explained in doc/op/op.{me,ps,txt}. That may cause problems with simple header checks due to the tokenization. It might be simpler to use a regex map and apply it to $&{currHeader}.
2. There are no default rulesets coming with this distribution of sendmail. You can either write your own or you can search the WWW for examples.
After all of the headers are read, the check_eoh ruleset will be called for any final header-related checks. The ruleset is called with the number of headers and the size of all of the headers in bytes separated by $|. One example usage is to reject messages which do not have a Message-Id: header. However, the Message-Id: header is not a required header and is not a guaranteed spam indicator. This ruleset is an example and should probably not be used in production.
LOCAL_CONFIG
Kstorage macro
HMessage-Id: $>CheckMessageId
LOCAL_RULESETS
SCheckMessageId
# Record the presence of the header
R$* $: $(storage {MessageIdCheck} $@ OK $) $1
R< $+ @ $+ > $@ OK
R$* $#error $: 553 Header Error
Scheck_eoh
# Check the macro
R$* $: < $&{MessageIdCheck} >
# Clear the macro for the next message
R$* $: $(storage {MessageIdCheck} $) $1
# Has a Message-Id: header
R< $+ > $@ OK
# Allow missing Message-Id: from local mail
R$* $: < $&{client_name} >
R< > $@ OK
R< $=w > $@ OK
# Otherwise, reject the mail
R$* $#error $: 553 Header Error
Reference: http://www.sendmail.org/m4/anti_spam.htmlse
Tuesday, September 1, 2009
Windows Computer Browser
Category:
Windows Server
— SkyHi @ Tuesday, September 01, 2009
MRxSmb - " The master browser has received a server announcement from
the computer computer1 that believes that it is the master browser for the domain on transport NetBT_Tcpip_{A610E23D-5C0A-45BF-80A.
The master browser is stopping or an election is being forced. "
Default Description:
Maintains an updated list of computers on the network and supplies this list to computers designated as browsers. If this service is stopped, this list will not be updated or maintained. If this service is disabled, any services that explicitly depend on it will fail to start.
Additional Information:
Computer Browser service maintains a listing of computers and resources located on the network. This service is not required on a standalone system. In fact, even if you want to browse the network (workgroup or domain) or have mapped network shares as local hard drives, you can still do so. On a large network, one computer is designated the "master" browser and another one is the "backup" browser. All others just announce they are available every 12 minutes to "take over" duties if one of the other computers fail. No lag time is discernable if this service remains disabled on all but one computer. Honestly, I do not even believe one needs to be running. You could, "just in case," but it sure does not need to be running on all computers, all of the time.
Additional Reading:
None at this time.
Discussion Topic Link:
Windows XP Services Forum
Defaults Startup Type:
Default XP Home: Automatic (Not Started)
Default XP MCE 2005: Automatic (Not Started)
Default XP Pro: Automatic (Not Started)
Default XP Tablet PC 2005: Automatic (Not Started)
Other Settings:
Safe Setting: Automatic
Service Names:
Service Name (registry): Browser
Display Name: Computer Browser
Default Path and Command Line Options:
C:\WINDOWS\system32\svchost.exe -k netsvcs
Log On As:
Account: Local System Account
Dependencies:
What service Computer Browser needs to function properly:
* Server (H, M. P, T)
* Workstation (H, M, P, T)
What other service require Computer Browser to function properly:
* None (H, M, P, T)
Reference: http://www.blackviper.com/WinXP/Services/Computer_Browser.htm
the computer computer1 that believes that it is the master browser for the domain on transport NetBT_Tcpip_{A610E23D-5C0A-45BF-80A.
The master browser is stopping or an election is being forced. "
Default Description:
Maintains an updated list of computers on the network and supplies this list to computers designated as browsers. If this service is stopped, this list will not be updated or maintained. If this service is disabled, any services that explicitly depend on it will fail to start.
Additional Information:
Computer Browser service maintains a listing of computers and resources located on the network. This service is not required on a standalone system. In fact, even if you want to browse the network (workgroup or domain) or have mapped network shares as local hard drives, you can still do so. On a large network, one computer is designated the "master" browser and another one is the "backup" browser. All others just announce they are available every 12 minutes to "take over" duties if one of the other computers fail. No lag time is discernable if this service remains disabled on all but one computer. Honestly, I do not even believe one needs to be running. You could, "just in case," but it sure does not need to be running on all computers, all of the time.
Additional Reading:
None at this time.
Discussion Topic Link:
Windows XP Services Forum
Defaults Startup Type:
Default XP Home: Automatic (Not Started)
Default XP MCE 2005: Automatic (Not Started)
Default XP Pro: Automatic (Not Started)
Default XP Tablet PC 2005: Automatic (Not Started)
Other Settings:
Safe Setting: Automatic
Service Names:
Service Name (registry): Browser
Display Name: Computer Browser
Default Path and Command Line Options:
C:\WINDOWS\system32\svchost.exe -k netsvcs
Log On As:
Account: Local System Account
Dependencies:
What service Computer Browser needs to function properly:
* Server (H, M. P, T)
* Workstation (H, M, P, T)
What other service require Computer Browser to function properly:
* None (H, M, P, T)
Reference: http://www.blackviper.com/WinXP/Services/Computer_Browser.htm
Monday, August 31, 2009
Troubleshoot 550, 553, and relay-prohibited errors
Category:
Windows Outlook
— SkyHi @ Monday, August 31, 2009
Troubleshoot 550, 553, and relay-prohibited errors
Applies to: Microsoft Office Outlook 2003
Show AllShow All
Hide AllHide All
Applies to
Microsoft Office Outlook® 2003
Relaying occurs when an e-mail message is sent to an e-mail address whose domain (the name after the @ symbol, such as adatum.com) is not processed by the Simple Mail Transfer Protocol (SMTP) (Simple Mail Transfer Protocol (SMTP): A common protocol that is used to send e-mail messages across the Internet.)or outgoing server that the sender is requesting to deliver the message. The SMTP server must connect to another SMTP server to relay the message.
When you send an e-mail message that encounters a relay error, your SMTP (outgoing) e-mail server might return your e-mail message with an error message such as one of the following:
* The message could not be sent because one of the recipients was rejected by the server. The rejected e-mail address was ''. Subject: '', Account: '', Server: '', Protocol: SMTP, Server Response: '550 ... Relaying Denied', Port: 25, Secure (SSL): No, Server Error: 550, Error Number: 0x800CCC79.
* "The message could not be sent because one of the recipients was rejected by the server. The rejected e-mail address was ''. Subject '', Account: '', Server: '', Protocol: SMTP, Server Response: '553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)', Port: 25, Secure(SSL): No, Server Error: 553, Error Number: 0x800CCC79.
The exact error message might vary, depending on your Internet service provider (ISP) (ISP: A business that provides access to the Internet for such things as electronic mail, chat rooms, or use of the World Wide Web. Some ISPs are multinational, offering access in many locations, while others are limited to a specific region.). Some ISPs might not return an error message when they detect outgoing messages as unsolicited commercial e-mail. In such cases, your message might appear to be sent normally — it leaves the Outlook Outbox and appears in Sent Items — but it is never actually delivered to the recipient.
Your message was rejected because the SMTP (outgoing) e-mail server did not recognize you as an authorized user.
SMTP is the protocol — standards that computers use to communicate with each other — that most e-mail servers use to send e-mail messages across the Internet. When you use an e-mail program, such as Outlook, that lets you store your e-mail messages on your computer, you need access to an SMTP server to send e-mail messages.
Note Web e-mail systems similar to MSN® Hotmail® and Yahoo! Mail are used differently, and this article does not apply to those e-mail accounts.
Junk e-mail and open relays
Unsolicited commercial e-mail is sometimes called junk mail or spam. The main reason that junk e-mail continues to increase in volume is that it costs the person who sends it virtually nothing to send — in fact the senders don't even have to send the junk e-mail through the SMTP (outgoing) e-mail server of their own ISP.
The basic structure of the Internet was designed before anyone considered the implications of providing the ability to send millions of pieces of junk e-mail for little cost. Spammers use the relaying ability of SMTP servers to mask the true origin of the junk e-mail by relaying it through third-party servers that permit such open relays. This makes the junk e-mail appear to come from the site that relays the message and conceals the identity of the real sender.
Until recently, most SMTP e-mail servers worked on an open trust system. Under this system, anyone, anywhere could submit an e-mail message to an SMTP server, and the server would accept it and forward to a recipient or to another e-mail server where the recipient's mailbox was located. Under a so-called open relay server, there were no restrictions on who was allowed to send via the SMTP server.
Your ISP to the rescue
As junk e-mail volumes increased, network administrators — the people responsible for managing your ISP servers — began placing restrictions on their SMTP e-mail servers. These restrictions help prevent just anyone from using, or abusing, an e-mail server. Think of it like this — a telephone in the lobby of your organization was available for anyone to use whether they worked at your organization or not. Now only the employees are permitted to use that phone.
There are several types of restrictions in use today:
* Require SMTP authentication Just as you must use a password to access your POP3 (incoming) server for your e-mail messages, this option requires that you provide a user name and password to send e-mail messages through the SMTP server. Usually, these are the same user name and password used for the POP3 server; however, they can be unique.
* Require that you connect to the ISP POP3 (incoming) e-mail server first When you connect to retrieve your new e-mail messages, you typically connect to a POP3 (incoming) e-mail server. You are required to provide a user name and password to access your mailbox. A network administrator can configure the server so that if you first connect and authenticate with the POP3 e-mail server, it will approve any request that you make to send an e-mail message through the normally restricted SMTP outbound server.
* Require that you connect from an authorized network location When you are at home and you dial your ISP or if you have a cable or DSL modem, you are directly connecting to the ISP network. You are trusted in that you have an account with the ISP with a user name and password. You are authorized to use the SMTP server to send e-mail messages because you are a customer.
* Require that you connect from a specific IP address or range of IP addresses Your ISP might authorize access to the SMTP server to people who are not connected directly to the network. A remote user at an office can use this option. However, a major problem is that many places have what are called dynamic IP addresses. Each time that you connect, you are not assured of having the same IP address. Some companies might have a reserved block or range of IP addresses. Your ISP can authorize connections from those IP addresses as approved users. Your ISP can provide you with additional information.
There are many possible scenarios for relaying. The following are the most common situations. See if one matches your situation.
Reference: http://office.microsoft.com/en-us/outlook/HA011128331033.aspx
Applies to: Microsoft Office Outlook 2003
Show AllShow All
Hide AllHide All
Applies to
Microsoft Office Outlook® 2003
Relaying occurs when an e-mail message is sent to an e-mail address whose domain (the name after the @ symbol, such as adatum.com) is not processed by the Simple Mail Transfer Protocol (SMTP) (Simple Mail Transfer Protocol (SMTP): A common protocol that is used to send e-mail messages across the Internet.)or outgoing server that the sender is requesting to deliver the message. The SMTP server must connect to another SMTP server to relay the message.
When you send an e-mail message that encounters a relay error, your SMTP (outgoing) e-mail server might return your e-mail message with an error message such as one of the following:
* The message could not be sent because one of the recipients was rejected by the server. The rejected e-mail address was '
* "The message could not be sent because one of the recipients was rejected by the server. The rejected e-mail address was '
The exact error message might vary, depending on your Internet service provider (ISP) (ISP: A business that provides access to the Internet for such things as electronic mail, chat rooms, or use of the World Wide Web. Some ISPs are multinational, offering access in many locations, while others are limited to a specific region.). Some ISPs might not return an error message when they detect outgoing messages as unsolicited commercial e-mail. In such cases, your message might appear to be sent normally — it leaves the Outlook Outbox and appears in Sent Items — but it is never actually delivered to the recipient.
Your message was rejected because the SMTP (outgoing) e-mail server did not recognize you as an authorized user.
SMTP is the protocol — standards that computers use to communicate with each other — that most e-mail servers use to send e-mail messages across the Internet. When you use an e-mail program, such as Outlook, that lets you store your e-mail messages on your computer, you need access to an SMTP server to send e-mail messages.
Note Web e-mail systems similar to MSN® Hotmail® and Yahoo! Mail are used differently, and this article does not apply to those e-mail accounts.
Junk e-mail and open relays
Unsolicited commercial e-mail is sometimes called junk mail or spam. The main reason that junk e-mail continues to increase in volume is that it costs the person who sends it virtually nothing to send — in fact the senders don't even have to send the junk e-mail through the SMTP (outgoing) e-mail server of their own ISP.
The basic structure of the Internet was designed before anyone considered the implications of providing the ability to send millions of pieces of junk e-mail for little cost. Spammers use the relaying ability of SMTP servers to mask the true origin of the junk e-mail by relaying it through third-party servers that permit such open relays. This makes the junk e-mail appear to come from the site that relays the message and conceals the identity of the real sender.
Until recently, most SMTP e-mail servers worked on an open trust system. Under this system, anyone, anywhere could submit an e-mail message to an SMTP server, and the server would accept it and forward to a recipient or to another e-mail server where the recipient's mailbox was located. Under a so-called open relay server, there were no restrictions on who was allowed to send via the SMTP server.
Your ISP to the rescue
As junk e-mail volumes increased, network administrators — the people responsible for managing your ISP servers — began placing restrictions on their SMTP e-mail servers. These restrictions help prevent just anyone from using, or abusing, an e-mail server. Think of it like this — a telephone in the lobby of your organization was available for anyone to use whether they worked at your organization or not. Now only the employees are permitted to use that phone.
There are several types of restrictions in use today:
* Require SMTP authentication Just as you must use a password to access your POP3 (incoming) server for your e-mail messages, this option requires that you provide a user name and password to send e-mail messages through the SMTP server. Usually, these are the same user name and password used for the POP3 server; however, they can be unique.
* Require that you connect to the ISP POP3 (incoming) e-mail server first When you connect to retrieve your new e-mail messages, you typically connect to a POP3 (incoming) e-mail server. You are required to provide a user name and password to access your mailbox. A network administrator can configure the server so that if you first connect and authenticate with the POP3 e-mail server, it will approve any request that you make to send an e-mail message through the normally restricted SMTP outbound server.
* Require that you connect from an authorized network location When you are at home and you dial your ISP or if you have a cable or DSL modem, you are directly connecting to the ISP network. You are trusted in that you have an account with the ISP with a user name and password. You are authorized to use the SMTP server to send e-mail messages because you are a customer.
* Require that you connect from a specific IP address or range of IP addresses Your ISP might authorize access to the SMTP server to people who are not connected directly to the network. A remote user at an office can use this option. However, a major problem is that many places have what are called dynamic IP addresses. Each time that you connect, you are not assured of having the same IP address. Some companies might have a reserved block or range of IP addresses. Your ISP can authorize connections from those IP addresses as approved users. Your ISP can provide you with additional information.
There are many possible scenarios for relaying. The following are the most common situations. See if one matches your situation.
Reference: http://office.microsoft.com/en-us/outlook/HA011128331033.aspx
Outlook SMTP authentication
Category:
Windows Outlook
— SkyHi @ Monday, August 31, 2009
The message could not be sent. The authentication setting might not be correct for your outgoing e-mail [SMTP] server. For help solving this problem, go to Help, search for "Troubleshoot Windows Mail", and read the "I'm having problems sending e-mail" section. If you need help determining the proper server settings, please contact your e-mail service provider.
The rejected e-mail address was 'test@yahoo.com' Subject 'test', Account: 'mail.pro.net', Server: 'smtp.yahoo.com', Protocol: SMTP, Server Response: '553 5.3.0 Rejected - See http://www.spamhaus.org/ZEN', Port: 2500, Secure(SSL): No, Server Error: 553, Error Number: 0x800CCC78
Aug 31 02:17:25 yahoo sendmail[18037]: n7V9HNci018037: from=, size=23883, class=0, nrcpts=1, msgid=<51121515859843046517261@home-PC>, proto=SMTP, daemon=MTA, relay=94.sub-75-26-49.myvw.com [75.26.49.294]
The rejected e-mail address was 'test@yahoo.com' Subject 'test', Account: 'mail.pro.net', Server: 'smtp.yahoo.com', Protocol: SMTP, Server Response: '553 5.3.0 Rejected - See http://www.spamhaus.org/ZEN', Port: 2500, Secure(SSL): No, Server Error: 553, Error Number: 0x800CCC78
Aug 31 02:17:25 yahoo sendmail[18037]: n7V9HNci018037: from=
Subscribe to:
Posts (Atom)