• Boletines 25.07.2007 No Comments

    En Mac OS X, como otros sistemas operativos comerciales, en principio no se pueden hacer capturas de pantalla directamente desde el sistema cuando se está reproduciendo un DVD. Se supone que por rollo de cuestiones legales –aunque parece que nadie haya copiado aún un DVD capturando y pegando fotograma por fotograma.

    La forma habitual de sortear este impedimento es instalando programas de terceras partes como SnapZ (OS X, shareware), pero hay una forma de hacer una capturas de pantalla incluyendo la imagen del DVD en reproducción directamente desde el sistema Mac OS X. Basta con invocar el poder de la línea de comandos (abrir el Terminal) y teclear

    screencapture -i ~/Desktop/captura-dvd.png [enter]

    El cursor se convertirá en una cruz. Pulsando la barra espaciadora éste cambiará a una cámara de fotos. Selecciona la ventana del DVD, haz clic y listo –ya tienes la imagen del DVD en reproducción en forma de imagen (archivo captura-dvd.png) sobre el escritorio.

    Leído en Take a Screenshot of DVD Player in OS X donde hay una lista con las opciones del comando screencapture. También Screenshot Hacks for Mac OS X es un completo y extenso artículo con información y trucos al respecto.

    Tomado de http://www.microsiervos.com

  • Boletines 25.07.2007 No Comments

    In order to set SPF record for your domain go to the site called

     

    Â http://www.openspf.org/

     

    Select option there called SPF WIZARD

     

    Put your domain name there and say start.

     

    Select all those options you want there like A record, MX record and press “continue” button.

     

    You will get a spf record for your domain under the heading,

     

    The SPF record:

     

    v=spf1 a mx ?all

     

    Now you will have to put this record in the dns zone for that domain on the server.

     

    You will have to add the entry in dns zone for that domain, for spf record as per given below,

     

    domain.com. IN TXT v=spf1 a mx ?all

     

    You can check whether it is added correct to your domain at — http://www.dnsreport.com/tools/dnsreport.ch?domain=domain.com >> Mail >> SPF record option.

  • Boletines 25.07.2007 No Comments

    Related links:
    http://new.openspf.org/FAQ/Testing_and_validating
    http://www.dnsstuff.com/pages/spf.htm
    http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
    http://www.openspf.org/wizard.html

    Background information
    Do you get tired of getting e-mails that are sent to you, but not actually from you? What happens when a spammer e-mails 1000 people using sales@yourdomain.com and then you get a ton of kick back messages, or people complaining you are sending them spam? If you implement this method, and the server the e-mail is being sent to also takes it into account, you might be able to put a stop to that spam.

    For example, you receive an e-mail from sales@yourdomain.com, yet it isn’t actually an e-mail that you sent- it is spam.

    By implementing the method called Sender Policy Framework (SPF), you can do something about it. You can add some information to your domain name that says “all e-mails sent using anything@yourdomain.com are spam, except for e-mails that are sent from this mailserver and this mailserver.”

    Any server that checks for SPF records will help handle spam. So it is helpful for not only your e-mail account, but also other mailservers that implement SPF (such as at Hotmail/AOL). Spam software is also implementing SPF to increase/decrease the probability of an e-mail message being flagged as spam (such as Spam Assassin).

    It is also useful at helping to keep your domain out of some arbitrary blacklists run by ISPs or webhosting providers. Some will check for valid SPF records and weigh that against blacklisting you. It may show them that you are aware of the problem enough to publish such records.

    The basic way you implement this, is in regards with domain records. Every domain name keeps a list of records, where you can define certain things relating to your domain (for example, you are hosting your website with one company, yet you are handling your e-mail with another company, in order to do this you would need to edit a domain record).

    There are a few questions you need to ask yourself before you can implement this…

    1) What mailservers are you planning to send e-mails from?
    - Here’s a situation… You have a hosting account with X host, and your domain name example.com. You also use Cox as your ISP. When you send an e-mail using something like Microsoft Outlook and your ISP’s outgoing mailserver (SMTP) for example.com (which is hosted with X host), then the e-mail comes from yourname@example.com. However, it doesn’t come from the X host mailserver, but instead the ISP’s mailserver (such as smtp.west.cox.net). You will need to know every mailserver you plan to use to send e-mails from. Usually, it will just be your web host; however, some people send mail using their domain name and their ISP’s mailserver.

    2) What do you want the mailserver to do when a message is sent using example.com, but NOT from the mailservers you listed?
    ?all - Tells the receiving mailserver what to do in case of a failed test. ?all tells the server that email should come from X host but, accept it from other places too because we’re not certain where all email is coming from.

    ~all tells the server that email should all come from X host but, to not reject the emails completely.

    ~all softfails the email which means it is received but, the person it is sent to could be given a warning about the email being possibly forged or the emails could be moved to a spam box.

    -all tells the receiving server that you are certain all email for the domain will come from servers in the record and if it doesn’t it should be rejected outright as a forged email or moved to a spam box based solely on that criteria without considering what is in the email.

    How to implement this
    1) The first step is to answer the two questions above. The critical part is finding out what mailservers you plan to send e-mails from. Contact your web host and ask them what the outgoing mailserver is (usually it is something like smtp.hostname.com)
    2) Next, think about how e-mails should be handled. Should you tell the mailserver that you want to flag the message as 100% for sure spam? Or maybe just say there is a high chance that it is spam, but it might not be? The suggested setting is simply ?all. This will let the mailserver know you have implemented the SPF method, and weigh that when determining if something is or isn’t spam.
    3) Edit the DNS Zone for example.com. Since an SPF record is a TXT record, you will add something like this:
    example.com. IN TXT “v=spf1 a:smtp.example.com a:smtp.west.cox.net ?all”

    This will say “all e-mails sent from my domain: example.com are supposed to come from the mailservers smtp.example.com and smtp.west.cox.net. If the e-mail is not coming from either of the two mailservers, there is a chance it is a spam message.”

    If you are not sure how to edit a record for your domain, your web host should be able to help you do it yourself. If you are on a cPanel/WHM server, log into WHM and click on ‘Edit DNS Entry’.

    The great thing about this is that only mailservers that implement the SPF check will actually look for this. So if you have it, and the mailserver you are using doesn’t use it, it won’t hurt anything at all (it will just be ignored, or as if you didn’t even have it). If you have it enabled and the mailserver checks for it, then

    Potential drawbacks
    Let’s say that you only send e-mails using the example.com’s mailserver, and have the record setup for that mailserver only. If you decide that you want to setup e-mail for example.com on your home computer, and you use your ISP’s outgoing mailserver (such as smtp.west.cox.net), then it may or may not be flagged as spam.

    So as long as you list the mailservers you plan to use, then everything should be fine. Most people only use one or two mailservers to send e-mail, so it really isn’t a big problem to list them.

    _____________________________

    Arizona Web Design - Mr Bobs Web Design in Arizona
    The Arizona Web Hosting Challenge

  • Boletines 25.07.2007 No Comments

    Spammers frequently take advantage of a catch-all email set up on Web servers. A catch-all email account will receive every email sent to nonexistent addresses. It is unwise to use catch-all email accounts, and spam sent to nonexistent addresses should be discarded. Spam can easily clog up your SMTP server and consume resources like bandwidth and disk space in mailboxes.Most mail servers and Web hosting control panels like CPanel enable a user or admin to decide what will happen to emails with no existing recipient on the server. An admin can refuse to let emails onto the server, let the sender’s mail server deal with it (option: “:fail:”) or to accept these incoming messages but then to delete them right away (option: “:blackhole:”).The best of these options, for the health of your mail server, is :fail:.

    The :blackhole: option accepts everything sent to the domain mail server and then throws away email addressed to nonexistent accounts. This option uses the full amount of bandwidth, and also requires that the server read and write messages to disk before they are deleted. Multiply this by 1,000-or-so messages a day and you can imagine the impact onto your server resources.

    A nonexistent email address from your domain may be spoofed to send out SPAM messages that may even carry viruses. Most of these messages will bounce back and hit your mail server. Your Web server would have to deal with thousands of attachments at once. And this would unquestionably impact your performance.

    The :fail: setting stops emails addressed to invalid recipients from entering the mail server in the first place. The mail server will reject each message during the SMTP handshake conversation - therefore the actual email message will never make it to your server, and the sender’s email server will have to deal with the stuck message.

    This option is also more effective in the case of legitimate email in which the sender has actually misspelled the recipient’s email address. In the :fail: case, the sender would receive a bounce message informing him that the domain could not be reached, enabling him to correct the error. Depending on your hardware - a server can handle many more :fails: than it can :blackholes:.

    Copyright Web Hosting Resource Kit

  • Boletines 18.07.2007 No Comments

    Del Foro relacionado con el error 451 y exim.conf

    Hace unos dias me llego un correo de uno de mis clientes donde me decia que varios de sus correos no llegaban y que los que enviaban no sali­an de su Outlook, al revisar las configuraciones todo parecia que estaba en orden, incluso la autentificacion SMTP para enviar correos. Despues de 4 horas de buscar, probar y probar sin resultados, me encontre con un foro acerca del webhosting relacionado con CPANEL, al parecer no tenia nada que ver con la configuracion de las cuentas, sino con algo llamado “localdomain ” donde de una extraña manera se elimino el dominio en cuestion del listado exim.

    Bueno para los que tengan el mismo problema les anexo una forma de como adherir una nueva cuenta al servidor a traves de la consola de administracion:

    El listado de consola aparecera asi:

    root@server1 [~]# locate exim.conf
    /home/virtfs/klyder/etc/exim.conf
    /etc/log.d/conf/logfiles/exim.conf
    /etc/log.d/conf/services/exim.conf
    /etc/exim.conf.dist
    /etc/exim.conf.dist.rpmsave
    /etc/exim.conf.buildtest
    /etc/exim.conf.localopts
    /etc/exim.conf.mailman2.dist
    /etc/exim.conf
    /etc/exim.conf.mailman2.exiscan.dist
    /root/exim/exim.conf
    /root/exim/exim.conf.dist

    El archivo que buscamos es /etc —> /etc/exim.conf

    Pasos para entrar mediante consola.

    Paso 1. Entrar al root atraves de SSH y la IP en cuestion.

    ————————————————————–
    //>ssh 0.0.0.0 -l root (enter)
    ————————————————————
    Nota: si es la primera ves que te conectas a un servidor ssh te pide confirmacion de que si quieres logearte en ese equipo y te pide un yes o un no, hay que dale yes, si ya has entrado antes solo te pide el password

    ————————————————————–
    >password: aqui­ escribes el password
    #
    # vi /etc/localdomains (enter)
    ————————————————————–

    //con este comando entras al editor VI editando el archivo /etc/localdomains

    Te va parecer el listado de tus dominios.

    Aqui agregas el dominio con el cual tienes problemas.

    ~
    ~
    ~
    ~
    Si no te parece el listado y solo puros ~verifica que escribiste correctamente el nombre del archivo /etc/localdomains

    Te puedes mover en el documento con las flechas, para ingresar texto oprimes:

    Esc : i (enter), con esto vas a poder empezar a escribir el archivo y poder agregar a la lista el dominio faltante

    Para guardar los cambios oprimes Esc : w (enter) y para salir del editor VI Esc :q (enter)
    Para salir omitiendo los cambios Esc :q (enter)

    Al salir te regresan al propt #, ya solo resta desconectarse del servidor esto es con exit, y listo!.