NetBackupのマスターサーバを新しくする場合の資料

NetBackupのサーバを新しく置き換える場合の資料に関して

基本:「How to migrate the NetBackup catalog information from one platform to another (UNIX to Windows or vice versa), rename a Master Server, cluster an existing Master Server, or merge multiple NetBackup domains.
ここに資料がまとまっている。
・Windows環境を新しくする場合「Using catalog backup and recovery to transfer NetBackup catalogs between Windows master servers as part of a hardware refresh
・Unix/Linux環境を新しくする場合「Using catalog backup and recovery to transfer NetBackup catalogs between UNIX or Linux master servers as part of a hardware refresh
・Windows環境<=>Unix/Linux環境の置き換えは、コンサルタントサービス契約が必要
なお、結構な金額と1ヶ月以上の作業工期がかかるそうです

環境を新しくする際、メディアサーバも変わることが多い。
その場合、無くなるメディアサーバは、マスタサーバが古い状態の時に、オフライン扱いにしておかないと、メディア管理上めんどうなことになる。
→「What is the process for decommissioning a NetBackup 6.5 or 7.x media server?
(NBU8.x環境では不要?)

NetBackup 8.1.2で、HP-UXとAIXがNetBackupのマスタサーバ/メディアサーバになれなくなる
このため、サポートが継続されるLinuxかSolaris環境へ移行するためのドキュメントが公開されている。
現在サポートされているNetBackup 7.7~8.1.1までのバージョンを対象としているが、それ以前でもだいたい同じとなる。
・マスタサーバ向け「NetBackup Master Server Migration Guide
・メディアサーバ向け「NetBackup Media Server Migration Guide

NetBackupのトラブル調査とログ取り

しばらくやってなかったら忘却してしまったのでメモ書き

・NetBackupサポートユーティリティ(nbsu)を使った一括収集

インストールパス/NetBackup/bin/support 以下で以下を実行する

nbsu -t -c -g OS -s OS_ODBC -s OS_currentcontrolset_reg -s OS_currentversion_reg -g NET -s NET_network_reg -s NET_services -g DEV -s DEV_scsi_reg -g MM -g NBU -s NBU_vrts_reg -s NBU_nbdb_info -s NBU_bptestnetconn

実行後、support/output/nbsu/ に結果が出力される。
なお、クライアント台数および保存期間が長いような環境では、上記コマンドをそのまま実行すると終了までかなり時間がかかることがある。

また、NetBackup 8.1.1では上記オプションを使うのはold_nbsuとなり、新しい「nbsu」はオプションいらなくなった模様
参考資料:Veritas NetBackup™ トラブルシューティングガイド「NetBackup サポートユーティリティ (nbsu) について

・nbcplogs によるログ収集

インストールパス/NetBackup/bin/support 以下で以下を実行する

nbcplogs -d 期間 出力先ディレクトリ

例: nbcplogs -d 7d /tmp/nblogs
/tmp/nblogs ディレクトリに、過去7Days分のログを出力する
なお、出力に時間がかかる場合がある

インストールパス/NetBackup/bin/admincmd 以下にある管理ツール群

・普通にエラーログなどを取得

bperror -L -hoursago 672 -columns 200

・NetBackupの全体設定確認

 bpconfig -U
 bpgetconfig

・バックアップ設定(ポリシー)確認

bppllist -L -allpolicies

・バックアップデバイス確認

bpstulist -U
nbstlutil list -l

・バックアップメディア一覧と有効期限の確認

bpmedialist -U

・バックアップされたイメージ一覧

bpimagelist -idonly -d 01/01/1970 00:00:00

・ライセンスの確認

get_license_key

・Storage Life Cycle Policy(SLP)設定

nbstl -L -all_versions

他に関連するNetBackupに関する資料。

NetBackupのGUI(jnbSA)上で行う操作をコマンドで置き換えるとしたらどのようになるのか?→「NetBackupの操作をコマンドで行う

テープチェンジャのインベントリ関連操作をコマンドで行うにはどうするのか?→「NetBackupでインベントリ操作をコマンドで実行する方法

他のNetBackupで使っていたテープメディアを読み出すには?→「NetBackupで他のNetBackupサーバから持ってきたテープメディア内のデータをリストアする

iRedMailの初期設定から変えたところ 2018/08/21版

2025/03/26追記

iredmail運用メモ 2024/12/19版」にCentOS7ベースサーバからAlmaLinux9ベースサーバに置き換えた時に実施した設定内容についてまとめた。


postfix+dovecotを使って複数ドメインのメールサーバを簡単にできるようにしたパッケージ「iRedMail」を利用中。

1月から流量が少ないドメインで使用を開始し、夏頃から本格利用を開始した。
中小企業相手のメールが多くなるとiRedMailの標準設定では、先方からのメール受け取りが拒否されることが増えてきた。
その他にも、メールサーバ以外の場所からメールを送信する場合に受け取り拒否が発生するということもあった。

そこで、日本で使う場合に受信出来ないということが少なくなるような設定ポイントを解説してみる


(1) メールサーバ以外の場所からメールを送信する場合、iredapdの設定を変える
メールサーバ以外にあるWebサーバや、Yahooや楽天などのシステムから自社ドメインのメールを送りたい場合、iRedMail標準設定では、メール受信がSMTP AUTHされてないサーバから送られてきてると拒否されてしまう。(Recipient address rejected: SMTP AUTH is required for users under this sender domain)
これは、iredapdのポリシーによる設定であるため、ルールを変更することで対処ができる。

なお、設定変更する前に、メール送信するサーバがSPFレコードに登録されていることを確認する。

設定は、/opt/iredapd/settings.py に「CHECK_SPF_IF_LOGIN_MISMATCH = True」を追加して、iredapd.serviceを再起動することで完了する。

参考:「postfixを使用したiredmailで他サーバで送信された自ドメインメールが受信拒否される


(2) barracudacentralを使わない
iRedMailの標準設定では「zen.spamhaus.org」と「b.barracudacentral.org」の2つがSPAM拒否データベースとして使われている。
ただ、いろいろ運用してみると、spamhaus.orgの方は一般住宅回線にあるSPAM botからのメールを効率良く排除してくれるが、
barracudacentral.orgの方は、どうも誤爆が多いようで、中小企業からのメールが良く拒否リストに入ってしまっている。
(たぶん共有サーバ運用で、他のユーザが変なことしたせい)

なので、うちではbarracudacentralを使用しないようにしました。

設定は「/etc/postfix/main.cf」で「postscreen_dnsbl_sites = 」で設定されているものから「b.barracudacentral.org=127.0.0.[2..11]*2」の記述を消すだけです。


(3) mail.goo.ne.jpからのメールが拒否されているのでコメント
/etc/postfix/helo_access.pcre にある設定によりmail.goo.ne.jpからのメールが拒否されているので、設定を変更する

変更前

/^(mail\.goo\.ne\.jp)$/ REJECT ACCESS DENIED. Your email was rejected because it appears to come from a known spamming mail server (${1})

変更後

###/^(mail\.goo\.ne\.jp)$/ REJECT ACCESS DENIED. Your email was rejected because it appears to come from a known spamming mail server (${1})

(4) ホスト名にIPアドレスが含まれていると拒否する設定があるので、設定を一部変更する。
家庭用回線などnetwork-192-168.0.100.ぷろばいだ.ne.jpという感じでIPアドレスがもろに埋め込まれたホスト名が使われている。
それに対して、メールサーバは多くの場合、ちゃんと命名されていることが多い。

が・・・AmazonのAWSでサービスを立てているようなところからのメールが、IPアドレス付きのメールサーバから送られてくる事がある。
また、それ以外でも、ちらほらと・・・

/etc/postfix/helo_access.pcre の設定によるもので、下記のbypassの後に記述を追加する

変更前

# bypass &amp;amp;quot;[IP_ADDRESS]&amp;amp;quot;
/^\[(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\]$/ DUNNO
# reject HELO which contains IP address
/(\d{1,3}[\.-]\d{1,3}[\.-]\d{1,3}[\.-]\d{1,3})/ REJECT ACCESS DENIED. Your email was rejected because the sending mail server appears to be on a dynamic IP address that should not be doing direct mail delivery (${1})

変更後

# bypass &amp;amp;quot;[IP_ADDRESS]&amp;amp;quot;
/^\[(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\]$/ DUNNO
### add by 2018/08/09 for yawata-lions.com
/^sv(\d{1,3}-\d{1,3}-\d{1,3}-\d{1,3}).*.seedshosting.jp$/ DUNNO
### add by 2018/08/09 for aws servers
/^ec2-(\d{1,3}-\d{1,3}-\d{1,3}-\d{1,3}).*.amazonaws.com$/ DUNNO
### add by 2018/08/09 for shop-pro.jp
# mail-10-200-1-137.mitaka.shop-pro.jp
/^mail-(\d{1,3}-\d{1,3}-\d{1,3}-\d{1,3})/ DUNNO
# reject HELO which contains IP address
/(\d{1,3}[\.-]\d{1,3}[\.-]\d{1,3}[\.-]\d{1,3})/ REJECT ACCESS DENIED. Your email was rejected because the sending mail server appears to be on a dynamic IP address that should not be doing direct mail delivery (${1})

(5) whitelistdomainを登録しておく
iRedMailだと、greylistを採用しており、メールが送られてくると最初の5分間はメールを受け取らず、再送されてくると受け取るようになっている。
しかし、ある程度信頼がおけるドメインのSPFレコードに登録されているサーバから送られてくるメールは、最初から受け取ってしまうようにした方がログチェックも簡単になる。

現在登録されている一覧は「/opt/iredapd/tools/spf_to_greylist_whitelists.py」を実行して確認できる。
登録は「/opt/iredapd/tools/greylisting_admin.py –whitelist-domain –from ‘@docomo.ne.jp’」というようにドメイン名を指定して行う。
ただ、コレはデータベースに登録するだけで、システムへの反映は「/opt/iredapd/tools/spf_to_greylist_whitelists.py」を実行する必要がある。
標準設定では毎時2分に実行されている。

うちのサーバで追加登録したものを下記に上げておく。便利なようにコマンドとしてそのまま実行できる状態にしておきます。

# 携帯電話のメールアドレス
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@docomo.ne.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@ezweb.ne.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@i.vodafone.ne.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@k.vodafone.ne.jp'

# ネットサービス系
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@mixi.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@magb.netmile.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@mrelay.epark.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@mta14.dmm.com'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@fmail01.gpoint.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@post.freeml.com'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@post.point.gmo.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@receive.mag2tegami.com'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@return.mag2-tayori.com'

# ショップ系
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@amazon.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@jmg.joshin.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@ma.store.uniqlo.com'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@return.nttxstore.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@webmail.askul.co.jp'

# 楽天関連
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@rakuten.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@emagazine.rakuten.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@mail.travel.rakuten.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@shop.rakuten.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@tc.api.rakuten-card.co.jp'

# Yahoo
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@err.yahoo.co.jp'

# 企業系
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@amc.ana.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@m1.kirin.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@olympus-imaging.com'

# 銀行・金融系
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@ct.shinseibank.com'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@mdbc.jibunbank.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@m.email.americanexpress.com'

# その他
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@a8.net'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@bounces1.postcarrier.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@d00.mailsystem.anser.ne.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@infomart.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@willap.jp'

いまどきメールヘッダのReceived fromに(unknown~)って出るのださくね?

メールシステムを新しくしたので、メールログの監視強化中。
そんななかで見つけたベストリザーブのDMがかなりアレ。

Received: from ptmag3.bestrsv.com (unknown [211.133.130.68])
とか
Received: from ptmag5.bestrsv.com (unknown [211.133.130.68])
とか

内部IPアドレスについて、unknownになる例はちらほらあるけど、インターネットに接続されているIPアドレスを持つメールサーバでコレは珍しい。

過去に届いたメールを漁ると、内部の実サーバ名として以下の6種類があったようだ。
ptmag.bestrsv.com
ptmag1.bestrsv.com
ptmag2.bestrsv.com
ptmag3.bestrsv.com
ptmag4.bestrsv.com
ptmag5.bestrsv.com

また、メールサーバのログを追うと、HELOコマンドでは下記のホスト名を送ってきていた。
sitsmtp.bestrsv.com

どうも内部では複数のサーバに分かれていて、sitsmtp.bestrsv.com(211.133.130.68)からインターネットに出てきているようだ。
しかし、これらのホスト名に対してIPアドレス(Aレコード,AAAAレコード)は全て設定されていない。
211.133.130.68の逆引きホスト名はsitsmtp.bestrsv.comが設定されているが、sitsmtp.bestrsv.comでは名前解決ができない。

なお、2011/12/05の「 ベストリザーブ・宿ぷらざ オープンしました☆(2011/12/05)」のメールを見ると、ちゃんとAレコードが設定されていた形跡はある。

Received: from ptmag.bestrsv.com (sitsmtp.bestrsv.com [211.133.130.68])

少なくとも2016年以降は設定されていないようだ。
(2012年半ば~2015年末まではメールが来なかった)

まともに設定できる人がいないんですかねぇ・・・

まぁ、2018/08/09現在掲載されている開発スタッフの求人内容がアレですから、まぁ・・・

応募条件
・RDBMSを利用したシステム開発経験がある方。
とくにMySQLおよびPHPの経験者を歓迎します。
・コミュニケーション能力がある方、25歳くらいまでの方を歓迎します。
<<<総合旅行業務取扱管理者優遇>>>

(25歳まででこれらの技能が身につけられているってなんだろ?)


2018/08/21追記

8/14送信のDMでは、そのままでした
8/21送信のDMではきちんと名前解決がされるようになっていました。

-bash-4.2$ nslookup 211.133.130.68
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
68.130.133.211.in-addr.arpa     canonical name = 68.64/26.130.133.211.in-addr.arpa.
68.64/26.130.133.211.in-addr.arpa       name = sitsmtp.bestrsv.com.

Authoritative answers can be found from:

-bash-4.2$ nslookup sitsmtp.bestrsv.com.
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   sitsmtp.bestrsv.com
Address: 211.133.130.68

-bash-4.2$

yahoo.co.jpのメールサーバは管轄ドメイン外でもメールが送れてしまう?

メールシステムを新しくしたのでメールログを監視中。

そんななか不審なものが・・・

Aug  9 07:48:48 サーバ名 postfix/smtpd[7394]: NOQUEUE: reject: RCPT from mta094.mail.bbt.yahoo.co.jp[182.22.12.65]: 450 4.1.8 &lt;glfruwj@zrbzzfmaewphpyi.jp>: Sender address rejected: Domain not found; from=&lt;glfruwj@zrbzzfmaewphpyi.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta094.mail.bbt.yahoo.co.jp>

Aug  9 07:55:19 サーバ名 postfix/smtpd[7394]: NOQUEUE: reject: RCPT from mta008.mail.bbt.yahoo.co.jp[182.22.12.11]: 450 4.1.8 &lt;fvawxvd@6vo07bbmyz8wa8d.jp>: Sender address rejected: Domain not found; from=&lt;fvawxvd@6vo07bbmyz8wa8d.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta008.mail.bbt.yahoo.co.jp>

yahoo.co.jpのメールサーバを使って、SPAMドメインからのメールを配信しようとしている形跡が・・・

え・・・自社ドメイン以外でも送れる設定にしてるんですか!?

もしかして、Yahooショッピングのテナントが、それぞれ自社ドメインで送れるようにそうなってるんですかね?

さすがに送信時にSMTP AUTHをしていないとは思えないし、いったいどういう処理をしてるんだかなぁ・・・


2019/06/18追記

今日も元気に、mta???.mail.bbt.yahoo.co.jpやmta???.mail.djm.yahoo.co.jpから存在していないドメインがFromに設定されているSPAMメールが送信中です。

[root@サーバ名 ~]# grep "NOQUE" /var/log/maillog|grep yahoo.co.jp|grep "Domain not"
<略>
Jun 18 14:25:52 サーバ名 postfix/smtpd[31047]: NOQUEUE: reject: RCPT from mta009.mail.bbt.yahoo.co.jp[182.22.12.12]: 450 4.1.8 &lt;nmroofhyu@wqk5z43zgjb5y.net>: Sender address rejected: Domain not found; from=&lt;nmroofhyu@wqk5z43zgjb5y.net> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta009.mail.bbt.yahoo.co.jp>
Jun 18 14:35:29 サーバ名 postfix/smtpd[32576]: NOQUEUE: reject: RCPT from mta718.mail.djm.yahoo.co.jp[183.79.16.21]: 450 4.1.8 &lt;kqqtlikg@pxnfykriyoxywkrdum.jp>: Sender address rejected: Domain not found; from=&lt;kqqtlikg@pxnfykriyoxywkrdum.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta718.mail.djm.yahoo.co.jp>
[root@サーバ名 ~]# grep "NOQUE" /var/log/maillog|grep yahoo.co.jp|grep "Domain not"|wc
     66    1518   20892
[root@サーバ名 ~]#

2020/09/23追記

yahoo.co.jpが発信源のSPAMメールは2年経過した2020年になっても止まることはありません。

Sep 23 11:05:00 サーバ名 postfix/smtpd[26185]: NOQUEUE: reject: RCPT from mta094.mail.bbt.yahoo.co.jp[182.22.12.65]: 450 4.1.8 &lt;uhspranbsbt@rjw7zascoh.ne.jp>: Sender address rejected: Domain not found; from=&lt;uhspranbsbt@rjw7zascoh.ne.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta094.mail.bbt.yahoo.co.jp>
Sep 23 11:07:22 サーバ名 postfix/smtpd[26185]: NOQUEUE: reject: RCPT from mta767.mail.djm.yahoo.co.jp[183.79.16.42]: 450 4.1.8 &lt;rxrggxjnx@zinjuepwicmfrsi.jp>: Sender address rejected: Domain not found; from=&lt;rxrggxjnx@zinjuepwicmfrsi.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta767.mail.djm.yahoo.co.jp>
Sep 23 12:24:50 サーバ名 postfix/smtpd[3025]: NOQUEUE: reject: RCPT from mta027.mail.bbt.yahoo.co.jp[182.22.12.30]: 450 4.1.8 &lt;cxlpsqtzz@ukmpvasugqpahrvi.jp>: Sender address rejected: Domain not found; from=&lt;cxlpsqtzz@ukmpvasugqpahrvi.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta027.mail.bbt.yahoo.co.jp>
Sep 23 12:44:53 サーバ名 postfix/smtpd[8648]: NOQUEUE: reject: RCPT from mta750.mail.djm.yahoo.co.jp[183.79.16.149]: 450 4.1.8 &lt;info@mail.mail.mail.mail.mail.mail.mail.mail.mail.mail.mail.depolarised.racing>: Sender address rejected: Domain not found; from=&lt;info@mail.mail.mail.mail.mail.mail.mail.mail.mail.mail.mail.depolarised.racing> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta750.mail.djm.yahoo.co.jp>
Sep 23 12:47:21 サーバ名 postfix/smtpd[8648]: NOQUEUE: reject: RCPT from mta767.mail.djm.yahoo.co.jp[183.79.16.42]: 450 4.1.8 &lt;rxrggxjnx@zinjuepwicmfrsi.jp>: Sender address rejected: Domain not found; from=&lt;rxrggxjnx@zinjuepwicmfrsi.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta767.mail.djm.yahoo.co.jp>
Sep 23 13:11:39 サーバ名 postfix/smtpd[13453]: NOQUEUE: reject: RCPT from mta094.mail.bbt.yahoo.co.jp[182.22.12.65]: 450 4.1.8 &lt;uhspranbsbt@rjw7zascoh.ne.jp>: Sender address rejected: Domain not found; from=&lt;uhspranbsbt@rjw7zascoh.ne.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta094.mail.bbt.yahoo.co.jp>
Sep 23 14:38:13 サーバ名 postfix/smtpd[28617]: NOQUEUE: reject: RCPT from mta750.mail.djm.yahoo.co.jp[183.79.16.149]: 450 4.1.8 &lt;info@mail.mail.mail.mail.mail.mail.mail.mail.mail.mail.mail.depolarised.racing>: Sender address rejected: Domain not found; from=&lt;info@mail.mail.mail.mail.mail.mail.mail.mail.mail.mail.mail.depolarised.racing> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta750.mail.djm.yahoo.co.jp>
Sep 23 14:40:51 サーバ名 postfix/smtpd[28617]: NOQUEUE: reject: RCPT from mta767.mail.djm.yahoo.co.jp[183.79.16.42]: 450 4.1.8 &lt;rxrggxjnx@zinjuepwicmfrsi.jp>: Sender address rejected: Domain not found; from=&lt;rxrggxjnx@zinjuepwicmfrsi.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta767.mail.djm.yahoo.co.jp>
Sep 23 15:11:29 サーバ名 postfix/smtpd[2026]: NOQUEUE: reject: RCPT from mta027.mail.bbt.yahoo.co.jp[182.22.12.30]: 450 4.1.8 &lt;cxlpsqtzz@ukmpvasugqpahrvi.jp>: Sender address rejected: Domain not found; from=&lt;cxlpsqtzz@ukmpvasugqpahrvi.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta027.mail.bbt.yahoo.co.jp>
Sep 23 15:31:39 サーバ名 postfix/smtpd[3799]: NOQUEUE: reject: RCPT from mta094.mail.bbt.yahoo.co.jp[182.22.12.65]: 450 4.1.8 &lt;uhspranbsbt@rjw7zascoh.ne.jp>: Sender address rejected: Domain not found; from=&lt;uhspranbsbt@rjw7zascoh.ne.jp> to=&lt;宛先メールアドレス> proto=SMTP helo=&lt;mta094.mail.bbt.yahoo.co.jp>