ラベル protocol の投稿を表示しています。 すべての投稿を表示
ラベル protocol の投稿を表示しています。 すべての投稿を表示

2013年5月1日水曜日

SMTPのETRN(Extended TuRN)プロトコルについて



メール配送時、自分のsmtpサーバから他のsmtpサーバに対して、メールの送信や、
送信待ちメールのデキューのリクエストを行えるsmtpプロトコルが存在した。

通常はメールを送れば相手先にはすぐに届くのはずなのだが、
自分が利用するsmtpサーバの都合や、または相手先の事情で
一時的に配送処理ができないとキューに落ちるため、
利用するメールサーバの設定に従って再送処理されるのを待たざるを得ない。

しかしetrnリクエストを利用することで、 リモートサーバに格納されているメールを
指定されたホストに送信させることができる。


・自分が配送依頼するメールサーバのMX
 example.com
・リクエストする対象ドメイン
 example.net

% telnet example.com 25
Trying *.*.*.*...
Connected to localhost.
Escape character is '^]'.
220 mta01.example.com ESMTP server
ehlo example.net
250-mta01.example.net
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 10485760
etrn example.net
252 Ok, pending messages for node example.net started

エンドユーザーが任意に該当ド メインの処理を要求できるので便利なように思えるが、
サーバ管理者にしてみればメールの配送処理をユーザ操作に依存する危険なコマンドになる。
そのため通常は一般ユーザからのetrnリクエストは拒否させる設定になっているはずである。

しかしこのコマンドは使い方によってはサーバ管理者にも利点がある。
特定ドメインのキュー配送処理を手動で制御できる点である。
一般ユーザからの操作は禁止し、管理者だけに許可を、または一般ユーザがアクセスできない
キュー配送専用サーバだけは許可させる、という使い方はできるのではないか。


2011年8月18日木曜日

TCP/IP チェックサムの仕組み

【目的】
パケットを加工するプログラムを書いている際に、IPのチェックサム部分のコードの実装を理解できず混乱してしまった。ネットワークの初心者に戻ったつもりで、この機会にどういう仕組か把握しなおす。



【チェックサムを求める前の予備知識】
IPv4 パケット構造
 ----------------------------------------------------------------------
|        0        |       1        |        2        |        3        |
|----------------------------------------------------------------------|
| Version| HL※    | ServiceType    | TotalLength                       |
| ---------------------------------------------------------------------|
| Identifier                       | flag   | FragmentOffset           |
|----------------------------------------------------------------------|
| TTL             | Protocol       | CheckSum                          |
|----------------------------------------------------------------------|
| SourceIP                                                             |
|----------------------------------------------------------------------|
| DestIP                                                               |
 ----------------------------------------------------------------------
※HL : HeaderLength


チェックサムとは
チェックサムとはIPヘッダやTCP/UDPデータグラムに対し、16ビットごとの1の補数和(1の補数の加算)を取り、さらにそれの1の補数を取ることである。

補数という言葉の定義に悩まされるが、数学的な意味は脇に置き、チェックサムを計算するだけなら簡単にできる。1の補数和を求めるためには、16ビットごとの値の和を単純に加算し、オーバーフローしたぶんを足し込み、最後に論理否定を取ればいいのである。
とにもかくにも、実際に計算方法を見れば求め方はすぐに分かるだろう。


(補足)
IPはヘッダだけをチェックサムの対象にしているのにはわけがある。IPパケットがフラグメント化された場合には、すべてのデータ部分が揃わないので、チェックサムを計算することができなくなるからである。フラグメント化されてもIPヘッダはすべてのIPパケットに含まれている。

ところで、TCP/UDPにもデータの中にIPヘッダを含めたチェックサムがある。
※IPアドレスの情報はIPヘッダ中から抜き出してくるだけであり、当然TCPのパケットにはIP情報は存在しない。

ではIPプロトコルレベルでのチェックは不要なのではないか。その通りであり、IPv6では廃止されている。しかし、IPv4のICMPのチェックサムにはIPヘッダの情報は含まれないため、念のためチェックした方がいいだろう。ICMPv6ではチェックサムにIPヘッダの情報も含まれる。



【チェックサムを手動で計算】
2つのノード間でpingを打ち、Wiresharkでそのパケットをダンプした。その結果を元にIPプロトコルヘッダのチェックサムを計算してみる。





送信側
16ビットデータなので、2バイトの変数で計算をする

Version + HeaderLength + ServiceType : 0x4500
TotalLength                  : 0x003C
Identifier                   : 0xF228
Flag + FragmentOffset        : 0x0000
TTL + Protocol               : 0x8001
CheckSum                     : 0xC1400x0000
SourceIP                     : 0xC0A8
                               0x0303
DestIP                       : 0xC0A8
                               0x0304

1) 16ビットごとに値を加算
送信時の検証時にはチェックサムのフィールドを0で埋める。
0x4500 + 0x003C + 0xF228  + 0x0000 + 0x8001 + 0x0000 +  0xC0A8 + 0x0303 + 0xC0A8 + 0x0304
= 0x33EBC

2) オーバフローした分を足しこみ
16ビットとして桁上がりした値が3である。
この桁上がり分を値を加算する。オーバーフローが3周分起きた、ということである。
0x3EBC + 0x3 = 0x3EBF

3) 1の補数
チェックサム通りの値になっているのでパケットは正常である。
~0x3EBC = 0xC140


・受信側
1) 16ビットごとに値を加算
チェックサムも含めて加算する。
0x4500 + 0x003C + 0xF228  + 0x0000 + 0x8001 + 0xC140 + 0xC0A8 + 0x0303 + 0xC0A8 + 0x0304
= 0x3FFFC

2) オーバフローした分を足しこみ
0xFFFC + 0x3 = 0xFFFF

0xFFFFであるのでパケットは正常である。



【疑問】
1の補数をとる理由
桁が上がりオーバフローした17ビット目を右に足し込める。これによりバイトオーダに依存しないコードが書ける。


最後にさらに1の補数(否定)をする理由
受信者にとってチェックサムの検証が楽になるというのが答えである。

手動でチェックサムした手順を思い出しながら考えてほしい。

1) 最後に1の補数をとらない場合
(送信時)
チェックサムのフィールドを0にする。パケット全体の1の補数和を取り(この結果をAとする)。さらにその否定した値(この結果を!Aとする)をチェックサムのフィールドに入れる。

(受信時)
受信したパケットのまずチェックサムの値をいったん脇にどける。チェックサムのフィールドを0にする。パケット全体の1の補数和を取り、チェックサムのフィールドに入れる。脇にどけたチェックサムと比較する。

受信時にも送信時と同じ計算をするはめになる。


2) 最後に1の補数をとる場合
(送信時)
上記と同じである。

(受信時)
パケット全体の1の補数和の1の補数を計算する。チェックサムのフィールドに!Aが埋まっている。

チェックサムのフィールド以外のパケットの1の補数和 = A
チェックサム部分 = !A

チェックサムのフィールドに!Cが埋まったパケット全体の1の補数和
= A + !A
= 0xFFFF



【チェックサムを自動化(プログラム化)】
1) IPプロトコルヘッダチェックサム

u_int16_t checksum(u_char *data, int len) {
  register u_int32_t sum;
  register u_int16_t *ptr;
  register int c;

  sum = 0;
  ptr = (u_int16_t *)data;

  for(c = len; c>1; c -= 2) {
    sum += (*ptr);
    // sumは32bitなので0x80000000(2進数にしたら最上位bitが1)を超えると
    // 次の足し合わせ時に桁あふれする恐れがある。
    // よってこの段階でオーバーフロー分を加算しておく。
    if(sum&0x80000000) {
      sum = (sum&0xFFFF) + (sum>>16);
    }
    ptr++;
  }

  if(c == 1) {
    u_int16_t val;
    val = 0;
    // 16bitの変数に8bitの値を前方に詰める。
    memcpy(&val, ptr, sizeof(u_int8_t));
    sum += val;
  }

  while(sum>>16) {
    sum = (sum&0xFFFF) + (sum>>16);
  }

  // この結果が0または0xFFFFであればよい。
  return(~sum);
}


2) TCP/UDPプロトコルデータグラム チェックサム
TCP/UPDプロトコルのデータグラムのチェックサムの計算以外に、
IPプロトコルヘッダにオプションがある場合にも利用する。後から説明する。

u_int16_t checksum2(u_char *data, int len) {
  register u_int32_t sum;
  register u_int16_t *ptr;
  register int c;

  sum = 0;
  ptr=(u_int16_t *)data;

  for(c = len; c>1; c -= 2) {
    sum += (*ptr);
    if(sum&0x80000000) {
      sum = (sum&0xFFFF) + (sum>>16);
    }
    ptr++;
  }

  if(c == 1) {
    u_int16_t val;
    val = 0;
    memcpy(&val, ptr, sizeof(u_int8_t));
    sum += val;
  }

  while(sum>>16) {
    sum = (sum&0xFFFF) + (sum>>16);
  }

  return(~sum);
}

u_int16_t checksum2(u_char *data1, int len1, u_char *data2, int len2) {
  register u_int32_t sum;
  register u_int16_t *ptr;
  register int c;

  sum = 0;
  ptr=(u_int16_t *)data1;

  for(c = len1; c>1; c -= 2) {
    sum += (*ptr);
    if(sum&0x80000000) {
      sum=(sum&0xFFFF) + (sum>>16);
    }
    ptr++;
  }

  if(c == 1) {
    u_int16_t val;
    val = ((*ptr)<<8) + (*data2);
    sum += val;
    if(sum&0x80000000) {
      sum = (sum&0xFFFF) + (sum>>16);
    }
    ptr = (u_int16_t *)(data2 + 1);
    len2--;
  }
  else {
    ptr = (u_int16_t *)data2;
  }

  for(c = len2; c>1; c -= 2) {
    sum += (*ptr);
    if(sum&0x80000000) {
      sum = (sum&0xFFFF) + (sum>>16);
    }
    ptr++;
  }

  if(c == 1) {
    u_int16_t     val;
    val = 0;
    memcpy(&val, ptr, sizeof(u_int8_t));
    sum += val;
  }

  while(sum>>16) {
    sum = (sum&0xFFFF) + (sum>>16);
  }

  return(~sum);
}


3) 使い方例

u_char  *ptr;

ptr = 受信したパケット

ptr += sizeof(struct iphdr);

// 実際のヘッダサイズから4割られている値が格納されているため最後に4を掛ける。
option_length=iphdr->ihl*4-sizeof(struct iphdr);

// IPパケットのオプションの存在を確認する。
if(option_length>0) {
  if(option_length >= 1500) {
    return(-1);
  }
  option = ptr;
  ptr += option_length;
}


// IPヘッダのチェックサムを求める。
if(check_ip(iphdr, option, option_length) == 0) {
  return(-1);
}


// データグラムのチェックサムを求める。
if(iphdr->protocol == IPPROTO_TCP) {
  len = ntohs(iphdr->tot_len)-iphdr->ihl*4;

  if(checksum_data(iphdr, ptr, len) == 0) {
    return(-1);
  }
}


////////////////////////////////////

int checksum_ip(struct iphdr *iphdr, u_char *option, int option_length) {
  unsigned short sum;

  if(option_length == 0) {
    sum = checksum((u_char *)iphdr, sizeof(struct iphdr));
    if(sum == 0 || sum == 0xFFFF) {
      return(1);
    }
    else {
      return(0);
    }
  }
  else{ 
    sum = checksum2((u_char *)iphdr, sizeof(struct iphdr), option, option_length);
    if(sum == 0 || sum == 0xFFFF) {
      return(1);
    }
    else {
      return(0);
    }
  }
}


////////////////////////////////////

// 疑似ヘッダである
struct pseudo_ip{
  struct in_addr  ip_src;
  struct in_addr  ip_dst;
  unsigned char   dummy;
  unsigned char   ip_p;
  unsigned short  ip_len;
};


int checksum_data(struct iphdr *iphdr, unsigned char *data, int len) {
  struct pseudo_ip p_ip;
  unsigned short sum;

  memset(&p_ip, 0, sizeof(struct pseudo_ip));
  p_ip.ip_src.s_addr = iphdr->saddr;
  p_ip.ip_dst.s_addr = iphdr->daddr;
  p_ip.ip_p = iphdr->protocol;
  p_ip.ip_len = htons(len);

  sum = checksum2((unsigned char *)&p_ip, sizeof(struct pseudo_ip), data, len);
  if(sum == 0 || sum == 0xFFFF) {
    return(1);
  }
  else {
    return(0);
  }
}





2011年2月17日木曜日

サポートされているSSL/TLSのバージョンの確認方法



SSL 2.0にはいくつかの脆弱性があるため、セキュリティを要求される通信の
プロトコルとして使われていることはなくなってきている、はず。

サービスが"SSL2.0"、"SSL3,0"、"TLS1.0"のどのバージョンに対応しているか、
確認する方法をメモしておく。
SoftBankのEmail(i)のimap sslを試験に使わせてもらいます。


◆ SSL2.0 がサポートされているか確認
$ openssl s_client -ssl2 -connect imap.softbank.jp:993
SSL2.0 がサポートされていない場合下記のようになる
CONNECTED(00000003)
write:errno=104

◆ SSL3.0 がサポートされているか確認
$ openssl s_client -ssl3 -connect imap.softbank.jp:993
SSL3.0 がサポートされている場合下記のようになる
CONNECTED(00000003)
depth=2 /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
verify return:1
depth=1 /C=JP/O=Betrusted Japan Co., Ltd./CN=Cybertrust Japan Public CA
verify return:1
depth=0 /C=JP/ST=Tokyo/L=Minato-ku/O=SOFTBANK MOBILE Corp./OU=Server Operation Department 1/CN=imap.softbank.jp
verify return:1
---
Certificate chain
 0 s:/C=JP/ST=Tokyo/L=Minato-ku/O=SOFTBANK MOBILE Corp./OU=Server Operation Department 1/CN=imap.softbank.jp
   i:/C=JP/O=Betrusted Japan Co., Ltd./CN=Cybertrust Japan Public CA
 1 s:/C=JP/O=Betrusted Japan Co., Ltd./CN=Cybertrust Japan Public CA
   i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEBTCCA26gAwIBAgIDAPY+MA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAkpQ
MSIwIAYDVQQKExlCZXRydXN0ZWQgSmFwYW4gQ28uLCBMdGQuMSMwIQYDVQQDExpD
eWJlcnRydXN0IEphcGFuIFB1YmxpYyBDQTAeFw0xMDAzMDIxMTAzMDJaFw0xMzA2
MDIxNDU5MDBaMIGUMQswCQYDVQQGEwJKUDEOMAwGA1UECBMFVG9reW8xEjAQBgNV
BAcTCU1pbmF0by1rdTEeMBwGA1UEChMVU09GVEJBTksgTU9CSUxFIENvcnAuMSYw
JAYDVQQLEx1TZXJ2ZXIgT3BlcmF0aW9uIERlcGFydG1lbnQgMTEZMBcGA1UEAxMQ
aW1hcC5zb2Z0YmFuay5qcDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtZ3L
gAvpts9RJhTeDFhu8mxQ/IcGQmElrdubBLoSQVlBgH79Nop1fXoYgnCsKvsOcqHW
FUy+zuHN0DowASUDiSx2DHonyefRecCRVSVNql+OfbdaaEMKrw9vimdXFIn3pTn8
JLkEKnIx/celB3oEgpmz5c4PpMshLPbDh03erCUCAwEAAaOCAaAwggGcMAkGA1Ud
EwQCMAAwTAYJYIZIAYb4QgEIBD8WPWh0dHBzOi8vd3d3LmN5YmVydHJ1c3QubmUu
anAvU3VyZVNlcnZlci9yZXBvc2l0b3J5L2luZGV4Lmh0bWwwgb8GA1UdIASBtzCB
tDCBsQYIKoMIjJsRAQEwgaQwVwYIKwYBBQUHAgIwSxpJRm9yIG1vcmUgZGV0YWls
cywgcGxlYXNlIHZpc2l0IG91ciB3ZWJzaXRlIGh0dHA6Ly93d3cuY3liZXJ0cnVz
dC5uZS5qcC8gLjBJBggrBgEFBQcCARY9aHR0cHM6Ly93d3cuY3liZXJ0cnVzdC5u
ZS5qcC9TdXJlU2VydmVyL3JlcG9zaXRvcnkvaW5kZXguaHRtbDALBgNVHQ8EBAMC
BaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMFMGA1UdHwRMMEowSKBG
oESGQmh0dHA6Ly9zdXJlc2VyaWVzLWNybC5jeWJlcnRydXN0Lm5lLmpwL1N1cmVT
ZXJ2ZXIvMjAxOF9jdGovY2RwLmNybDANBgkqhkiG9w0BAQUFAAOBgQCvU3ycB5uk
fnthZZ88cNqhFRnCkpzdQlhnt2xMDtNe5g+m2YyOlp2zELWEv9lWVXJTbqJ/HeIL
7mUQYBzhtoFLSRcVHTycIit9i4dTDIY6aoI6eoepvz9bN0MDeTQ262mN6Xi3WNJ6
3sK+pTQKpmW/FB4biy7t+kppGQsrg/npgA==
-----END CERTIFICATE-----
subject=/C=JP/ST=Tokyo/L=Minato-ku/O=SOFTBANK MOBILE Corp./OU=Server Operation Department 1/CN=imap.softbank.jp
issuer=/C=JP/O=Betrusted Japan Co., Ltd./CN=Cybertrust Japan Public CA
---
No client certificate CA names sent
---
SSL handshake has read 2569 bytes and written 301 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 88716C7BA30BF1D53FC7F92E00007D2C1E65B0766EF7BDDF815A40B241D7CB33
    Session-ID-ctx:
    Master-Key: 8FD66EA91ACAC20B84F8551DD8D1EA46559001E91F1EF2E95FD0AE524028EAB90DAC8F47FF01E3D23A7F78654110F709
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1297909814
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
* OK IMAP4



◆ TSL1.0 がサポートされているか確認
$ openssl s_client -tls1 -connect imap.softbank.jp:993
TLS1.0 がサポートされている場合下記のようになる
CONNECTED(00000003)
depth=2 /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
verify return:1
depth=1 /C=JP/O=Betrusted Japan Co., Ltd./CN=Cybertrust Japan Public CA
verify return:1
depth=0 /C=JP/ST=Tokyo/L=Minato-ku/O=SOFTBANK MOBILE Corp./OU=Server Operation Department 1/CN=imap.softbank.jp
verify return:1
---
Certificate chain
 0 s:/C=JP/ST=Tokyo/L=Minato-ku/O=SOFTBANK MOBILE Corp./OU=Server Operation Department 1/CN=imap.softbank.jp
   i:/C=JP/O=Betrusted Japan Co., Ltd./CN=Cybertrust Japan Public CA
 1 s:/C=JP/O=Betrusted Japan Co., Ltd./CN=Cybertrust Japan Public CA
   i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEBTCCA26gAwIBAgIDAPY+MA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAkpQ
MSIwIAYDVQQKExlCZXRydXN0ZWQgSmFwYW4gQ28uLCBMdGQuMSMwIQYDVQQDExpD
eWJlcnRydXN0IEphcGFuIFB1YmxpYyBDQTAeFw0xMDAzMDIxMTAzMDJaFw0xMzA2
MDIxNDU5MDBaMIGUMQswCQYDVQQGEwJKUDEOMAwGA1UECBMFVG9reW8xEjAQBgNV
BAcTCU1pbmF0by1rdTEeMBwGA1UEChMVU09GVEJBTksgTU9CSUxFIENvcnAuMSYw
JAYDVQQLEx1TZXJ2ZXIgT3BlcmF0aW9uIERlcGFydG1lbnQgMTEZMBcGA1UEAxMQ
aW1hcC5zb2Z0YmFuay5qcDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtZ3L
gAvpts9RJhTeDFhu8mxQ/IcGQmElrdubBLoSQVlBgH79Nop1fXoYgnCsKvsOcqHW
FUy+zuHN0DowASUDiSx2DHonyefRecCRVSVNql+OfbdaaEMKrw9vimdXFIn3pTn8
JLkEKnIx/celB3oEgpmz5c4PpMshLPbDh03erCUCAwEAAaOCAaAwggGcMAkGA1Ud
EwQCMAAwTAYJYIZIAYb4QgEIBD8WPWh0dHBzOi8vd3d3LmN5YmVydHJ1c3QubmUu
anAvU3VyZVNlcnZlci9yZXBvc2l0b3J5L2luZGV4Lmh0bWwwgb8GA1UdIASBtzCB
tDCBsQYIKoMIjJsRAQEwgaQwVwYIKwYBBQUHAgIwSxpJRm9yIG1vcmUgZGV0YWls
cywgcGxlYXNlIHZpc2l0IG91ciB3ZWJzaXRlIGh0dHA6Ly93d3cuY3liZXJ0cnVz
dC5uZS5qcC8gLjBJBggrBgEFBQcCARY9aHR0cHM6Ly93d3cuY3liZXJ0cnVzdC5u
ZS5qcC9TdXJlU2VydmVyL3JlcG9zaXRvcnkvaW5kZXguaHRtbDALBgNVHQ8EBAMC
BaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMFMGA1UdHwRMMEowSKBG
oESGQmh0dHA6Ly9zdXJlc2VyaWVzLWNybC5jeWJlcnRydXN0Lm5lLmpwL1N1cmVT
ZXJ2ZXIvMjAxOF9jdGovY2RwLmNybDANBgkqhkiG9w0BAQUFAAOBgQCvU3ycB5uk
fnthZZ88cNqhFRnCkpzdQlhnt2xMDtNe5g+m2YyOlp2zELWEv9lWVXJTbqJ/HeIL
7mUQYBzhtoFLSRcVHTycIit9i4dTDIY6aoI6eoepvz9bN0MDeTQ262mN6Xi3WNJ6
3sK+pTQKpmW/FB4biy7t+kppGQsrg/npgA==
-----END CERTIFICATE-----
subject=/C=JP/ST=Tokyo/L=Minato-ku/O=SOFTBANK MOBILE Corp./OU=Server Operation Department 1/CN=imap.softbank.jp
issuer=/C=JP/O=Betrusted Japan Co., Ltd./CN=Cybertrust Japan Public CA
---
No client certificate CA names sent
---
SSL handshake has read 2553 bytes and written 285 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 7AF04F9E5B02157EE2AC563A5FDD533AEF49ED054293357C6BB1DB5E7144570A
    Session-ID-ctx:
    Master-Key: 159FD603C7CCB5C0F67F4B8916BCDCB7054BB0014AFBFAA956D60E5D2F94C2DE0160C69471AE7E4D5D447BF07D909697
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1297909887
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
* OK IMAP4



◆ cipherの確認
サーバ側がどのciperを利用できるかも確認できる。
クライアント側が利用するciperの一覧(接続元クライアント側に依存する)。
$ openssl cipher -v
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5
KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5
KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5
KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
KRB5-DES-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=DES(56) Mac=MD5
KRB5-DES-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=DES(56) Mac=SHA1
EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1
EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1
DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1
DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5
EXP-KRB5-RC2-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC2(40) Mac=MD5 export
EXP-KRB5-DES-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=DES(40) Mac=MD5 export
EXP-KRB5-RC2-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC2(40) Mac=SHA1 export
EXP-KRB5-DES-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=DES(40) Mac=SHA1 export
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export
EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(40) Mac=MD5 export
EXP-KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(40) Mac=SHA1 export
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export


コマンド結果の一行目を、opensslコマンドの-cipherオプションで指定すれば、サポートの有無を判断できる。
$ openssl s_client -tls1 -connect 接続先:ポート -ciper サイファ


2010年7月23日金曜日

imap プロトコル

imapのプロトコルで一般的なものをメモ。


$ telnet example.com 143

001 CAPABILITY
002 LOGIN ユーザ名 パスワード
003 NOOP
004 LIST "" "*"
005 STATUS "INBOX" (MESSAGES RECENT UNSEEN)
006 SELECT INBOX
007 APPEND INBOX {74}
From: xxxxxxxx
To: yyyyyyyy
Subject: EXAM MAIL

This is an exam mail.
008 STATUS "INBOX" (MESSAGES RECENT UNSEEN)
009 SEARCH unseen
010 uid SEARCH charset utf-8 body "exam"
011 uid SEARCH charset utf-8 body {4}
exam
012 FETCH $num RFC822
013 CREATE "hoge_directory"
014 COPY $num "hoge_directory"
015 DELETE "hoge_directory"
016 STORE $num +FLAGS (\Deleted)
017 EXPUNGE
018 LOGOUT


左行の数字は行数を表すために書いたものではない。
プロトコル上必須である。数字ではなくとも、A、B、Cなどでもよい。

007の"74"というのはヘッダとボディのサイズである。
誤差なく指定する必要がる。
いちいち数えていられないので、この辺りははツール化した方がいいだろう。


010と011(とその下)は同じことをしている文字列検索である。
IMAP4では文字列として「Literal」と「Quoted」という2種類の表現形式を持っているので、
2通りの検索方法を示した。

・ Quotedは文字列を"(ダブルクォーテーション)で囲む形式である。
"exam"

・ Literalは次のように扱う。
{文字数}CRLF 実際の文字列


また、複数条件で検索する場合は下記のように行う。
imapは前置記法である。
uid SEARCH charset utf-8 or or subject "MAIL" body "exam" body "mail"


012、014、016に現れる$numは変数である。
検索の結果表示される、各メールに割り振られたユニークな番号(UID)を入れること。


DSN( Delivery Status Notification:配送状況通知) について

DSN(Delivery Status Notification:配送状況通知) についての備忘録。

送信者に送信したメッセージの状況について知らせるために
MTA や MDAが自動的に作成するメッセージである。
DSNでは例えば、 元メッセージが一時的あるいは恒久的な問題のために
配送できなかったことや、 配送の試行がどのくらいの間続くのか、
あるいは続かないのかを 送信者に知らせることができる。

このようなメール用プロトコルがあったとは知らなかった。

クライアント側の設定によりDSN要求の有無を設定できる。

(例 : Outlookの場合)

1.「ツール」から、「オプション」を選択
2.「初期設定」のタブの電子メールの箇所の、「メールオプション」を選択
3. メッセージの取り扱いの中から「確認オプション」を選択
4. すべての送信メッセージに対して、以下の確認メッセージを要求するの箇所から、
「配信済みメッセージ」にチェックを入れる

※この設定方法は、全メールに対しての設定であり、
1通1通のメールでの設定も可能です。
その場合は、各メールの「表示」内の「オプション」にて設定可能。


メール送信後の流れは、以下の2通りである。

① 送信先がDSN要求に対応している場合
正常に着信したという応答を送信元メールシステムに返し、
送信元メールシステム側で、DSNメールを作成し、送信元に着信させる。


② 送信先がDSN要求未対応の場合
送信先から応答がないというDSNメールを送信元で作成し、送信元に着信させる。

※どちらにしろ、送信ユーザにメールが着信することになる。

手動でsmtp authしてメールを配送



手動でsmtp authしてメールを配送する際のプロトコルをメモ。

◆ 認証用のユーザ名をBase64でエンコードする
$ perl -MMIME::Base64 -e 'print encode_base64("$user");'
XXXXXXXXXXXX

◆ 認証用のパスワードをBase64でエンコードする
$ perl -MMIME::Base64 -e 'print encode_base64("$password");'
YYYYYYYYYYYY

◆ サブミッション(submission)用587ポートへtelnet
手動でsmtp authしてメールを配送する際のプロトコルをメモメモ。
プロとコロルにしたがって、文字列を入力する(青色, 赤字部分)

$ telnet smtp.softbank.jp 587
Trying 126.240.66.7...
Connected to smtp.softbank.jp.
Escape character is '^]'.
220 server101.expample.com ESMTP server ready Mon, 7 Nov 2011 21:36:02 +0900
EHLO localhost
250-server101.example.com
250-AUTH=LOGIN PLAIN
250-AUTH LOGIN PLAIN
250-PIPELINING
250-DSN
250-8BITMIME
250-SIZE 1048576
250 STARTTLS
AUTH LOGIN
334 VXNlcm5hbWU6
XXXXXXXXXXXX
334 UGFzc3dvcmQ6
YYYYYYYYYYYY
235 Authentication successful
MAIL FROM :from アドレス
250 ok
RCPT TO:to アドレス
250 ok
DATA
354 go ahead
Subject: test
From : me
To: you

test mail
.
.250 ok 1277537370 qp 32169
quit
Connection closed by foreign host.