pamiętnik programisty » linux

GMail as relayhost in Postfix – without certs

pejotr — Tue, 27 Dec 2011 23:23:04 +0000

There are many articles describing how to setup GMail as a relayhost in Postfix mail server. Most of them involve creating local CA certificate and generation of client certificate. There is absolutely no need to! Just think, how GMail would be able to validate your own certificate created by your own CA available only on your local drive? What would be a purpose?

To make Postfix work with GMail you just need to add these lines to main.cf:
relayhost = [smtp.gmail.com]:587


# SASL

smtp_sasl_auth_enable=yes

smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd

# TLS smtp_use_tls = yes smtp_tls_CAfile=/etc/pki/tls/cert.pem # CentOS path smtp_tls_loglevel=2 smtp_sasl_tls_security_options = noanonymous tls_random_source = dev:/dev/urandom

And put just one line in sasl_passwd
[smtp.gmail.com]:587 username@gmail.com:password

After issuing following commands a connection between GMail and Postfix should work fine. You can test it using mail or sendmail program:
$ postmap hash:/etc/postfix/sasl_passwd $ /etc/init.d/postfix restart $ mail test@example.com Subject: Test main Test message . Cc:

You should have something like this in your /var/log/maillog file:
Dec 29 00:49:48 localhost postfix/smtp[5942]: setting up TLS connection to smtp.gmail.com Dec 29 00:49:48 localhost postfix/smtp[5942]: certificate verification depth=2 subject=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority Dec 29 00:49:48 localhost postfix/smtp[5942]: verify return: 1 Dec 29 00:49:48 localhost postfix/smtp[5942]: certificate verification depth=1 subject=/C=US/O=Google Inc/CN=Google Internet Authority Dec 29 00:49:48 localhost postfix/smtp[5942]: verify return: 1 Dec 29 00:49:48 localhost postfix/smtp[5942]: certificate verification depth=0 subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com Dec 29 00:49:48 localhost postfix/smtp[5942]: verify return: 1 Dec 29 00:49:48 localhost postfix/smtp[5942]: SSL_connect:SSLv3 read server certificate A Dec 29 00:49:48 localhost postfix/smtp[5942]: SSL_connect:error in SSLv3 read server key exchange A Dec 29 00:49:48 localhost postfix/smtp[5942]: SSL_connect:error in SSLv3 read server key exchange A Dec 29 00:49:48 localhost postfix/smtp[5942]: SSL_connect:SSLv3 read server done A Dec 29 00:49:48 localhost postfix/smtp[5942]: SSL_connect:SSLv3 write client key exchange A Dec 29 00:49:48 localhost postfix/smtp[5942]: SSL_connect:SSLv3 write change cipher spec A Dec 29 00:49:48 localhost postfix/smtp[5942]: SSL_connect:SSLv3 write finished A Dec 29 00:49:48 localhost postfix/smtp[5942]: SSL_connect:SSLv3 flush data Dec 29 00:49:48 localhost postfix/smtp[5942]: SSL_connect:error in SSLv3 read finished A Dec 29 00:49:48 localhost last message repeated 3 times Dec 29 00:49:48 localhost postfix/smtp[5942]: SSL_connect:SSLv3 read finished A Dec 29 00:49:48 localhost postfix/smtp[5942]: Verified: subject_CN=smtp.gmail.com, issuer=Google Internet Authority Dec 29 00:49:48 localhost postfix/smtp[5942]: TLS connection established to smtp.gmail.com: TLSv1 with cipher RC4-SHA (128/128 bits) Dec 29 00:49:50 localhost postfix/smtp[5942]: 955CE3D48A06: to= , relay=smtp.gmail.com[74.125.79.108]:587, delay=2.2, delays=0.12/0.03/0.9/1.2, dsn=2.0.0, status=sent (250 2.0.0 OK 1325116190 t59sm126911139eeh.10) Dec 29 00:49:50 localhost postfix/qmgr[5923]: 955CE3D48A06: removed

Problem with timestamps in libnetfilter_queue solved

pejotr — Mon, 27 Dec 2010 21:45:09 +0000

My BSc Thesis is to implement steganography algorithm that use VoIP packets as a transport. The main aim is to modify delay of RTP packets without noticeable impact on transmission quality. I create hidden channel by sending two packets that average delay is 20ms. For example if we send 1 packet 10ms after previous and second 30ms after first the average delay is 20ms. Calling parties will not notice so small difference, but software should recognize such situation as sending the bit with value 1. When we want to send bit 0 we can just switch delays, then first packet will be sent after 30ms and another 10ms later. The time the packet was received is very important for Receiver. The network can add a random delay but Receiver should still be able to collect all sent bits.
For implementation I used libnetfilter_queue and iptables. This two powerful tools are more than enough for my need. Everything was fine until and got to point where I had to read packet delay. Although libnetfilter_queue provide function for reading timestamp when packet was queued (nfq_get_timestamp) it’s not working without additional tweaks. For kernel performance reason timestamping network packets is by default disabled. After digging through kernel source I found functions responsible from toggling this setting, it’s a net_enable_timestamp() and net_disable_timestamp(). I had no idea how to execute each of them but MarkR from stackoverflow.org helped me. There is no need to enable timestamping globally for all packets instead it can be enabled for particular socket by using setsockopt. The call sequence is then setsockopt() -> sock_setsockopt() -> sock_enable_timestamp(…) -> net_enable_timestamp(). It is possible to get file descriptor connected with particular queue and treat it as it would be socket. This means that following code is valid and can be used to enable timestamping incoming packets:

int ena = 1;
if( setsockopt(queuefd, SOL_SOCKET, SO_TIMESTAMP, &ena, sizeof(ena)) )
{
    SYS_LOG(E_WARNING, "Unable to enable timestamping");
}

and then in queue handle function:

int handle_queue(struct nfq_q_handle *pQh, struct nfgenmsg *pNfmsg, struct nfq_data *pNfa, void *pData)
{
    struct nfqnl_msg_packet_hdr *ph;
    struct timeval tv;
    int id;

    ph = nfq_get_msg_packet_hdr(pNfa);
    if(ph)
    {
        id = ntohl(ph->packet_id);
    }

    nfq_get_timestamp(pNfa, &tv);
    /* do sth. with read timestamp */

    return nfq_set_verdict(pQh, id, NF_ACCEPT, 0, NULL);
}

This is a solution for a issue, that as far as i know, have not been solved since this post:
„So far the biggest issues I’ve run into are that marking doesn’t work in 2.6.15 (I think it should in 2.6.16), and I can’t seem to ever read the timestamp for a packet, no matter hat hook it comes in on. I’ve just been using gettimeofday for that for now.”
http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023490.html

Ustawienie sieci wewnętrznej VirtualBox

pejotr — Tue, 16 Nov 2010 22:18:17 +0000

Korzystając z okazji że pozbywam się Oracle VirtualBox na rzecz VM Player’a wrzucam stworzony przeze mnie dawno dawno filmik pokazujący w jaki sposób stworzyć sieć wewnętrzną w VirtualBox wraz z automatycznym przydzielaniem adresów. Przedstawiona przykładzie systemu Windows XP i QNX. Enjoy.

www.youtube.com/watch?v=iDzcELJisHs

Karta X100P i Kernel Panic

pejotr — Mon, 21 Sep 2009 10:14:43 +0000

Mimo nowych wersji zarówno Trixboxa i Astersika, problem nadaj pozostaje. Po skonfigurowaniu karty, w czasie wyłączania systemu kernel dostaje zadyszki o czym informuje znienawidzonym komunikatem „KERNEL PANIC”. Od ostatniego wpisu na ten temat ( jeszcze na stary blogu, który trafił szlag podczas aktualizacji WP) trochę się zmieniło. Nie ma już co szukać pliku KXXZaptel, bo znalezienie go oznacza że nasz system jest lekko zacofany – Zaptel jest obecnie znany jako DAHDI. Również zawartość odpowiedniego pliku jest lekko inna, ale mimo wszystko można problem rozwiązać.
Co należy zrobić to w /etc/rc6.d odnaleźć plik KXXdahdi, u mnie jest to K92dahdi i zakomentować poniższy fragment, okolice linii 235:

# Unload drivers
#shutdown_dynamic
#echo -n „Unloading DAHDI hardware modules: ”
#if unload_module dahdi; then
# echo „done”
#else
# echo „error”
#fi
#if [ "$LOCKFILE" != '' ]; then
# [ $RETVAL -eq 0 ] && rm -f $LOCKFILE
#fi

i zamykanie systemu zaczyna działać jak należy. Może sam problem nie jest zbyt uciążliwy gdyż działający serwer VoIP nie jest często resetowany. Ale zabawa zaczyna się gdy zaistnieje potrzeba przeprowadzenia takiej operacji zdalnie…