Re: can not telnet port 25
1) Postfix has NO impact on telnet. If you cannot telnet outbound to a remote port 25 the problem is that something on your host is blocking port 25 or something upstream from you is blocking port 25. Can you perform the following: telnet localhost 25 If this works, you CAN telnet to port 25 locally. Then try a known Good SMTP server, such as Google: # nslookup -q=MX gmail.com Server: 209.172.41.202 Address:209.172.41.202#53 Non-authoritative answer: gmail.com mail exchanger = 5 gmail-smtp-in.l.google.com. gmail.com mail exchanger = 30 alt3.gmail-smtp-in.l.google.com. gmail.com mail exchanger = 20 alt2.gmail-smtp-in.l.google.com. gmail.com mail exchanger = 10 alt1.gmail-smtp-in.l.google.com. gmail.com mail exchanger = 40 alt4.gmail-smtp-in.l.google.com. Authoritative answers can be found from: alt3.gmail-smtp-in.l.google.com internet address = 173.194.70.27 gmail-smtp-in.l.google.com internet address = 173.194.76.26 alt4.gmail-smtp-in.l.google.com internet address = 173.194.69.27 alt1.gmail-smtp-in.l.google.com internet address = 173.194.66.27 alt2.gmail-smtp-in.l.google.com internet address = 74.125.136.27 [root@cl-t159-360cl ~]# telnet gmail-smtp-in.l.google.com 25 Trying 173.194.76.26... Connected to gmail-smtp-in.l.google.com (173.194.76.26). Escape character is '^]'. 220 mx.google.com ESMTP a3si2597941qao.15 - gsmtp quit Connection closed by foreign host. Make sure you actually have a service sunning on port 25, i.e.: netstat -an | grep 25 tcp0 0 0.0.0.0:25 0.0.0.0:* LISTEN i Make sure you do not have the inet service set to private in your master.cf: When I first started troubleshooting I got an error in the /var/log/maillog Jan 30 11:34:45 list postfix/master[20710]: fatal: /etc/postfix/master.cf: line 40: inet service cannot be private. went into master.cf found this "smtp inet - - n - - smtp" Changed first "-" to n "smtp inet n - n - - smtp" restarted post fix worked. Hope it helps. On 2/20/2014 9:31 PM, Feel Zhou wrote: Hello, My friend This is Tom, I'm sending my greeting from China. Today, one of my postfix server can not telnet any other mail server's port 25. It's working before 9:00am(bejing time CHina), I have restart the mail server and reinstall the postfix. but it's looks like not working. How can I fix this problem. Thanks for your help TOM -- Eric Kimminau, Troop #284 Recruiting e...@kimminau.org cell: 248-766-5353 home: 248-393-8036
Re: can not telnet port 25
On 2014-02-21 03:41, Feel Zhou wrote: -A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT it might be geoip blocking you see to the recipient mailservers if you not see it to all recipient ips if that is it, then you can just remove recipient domain from dns with bind9 rpz zone until recipient domains begins to learn :=)
Re: FreeBSD ports OpenSSL with zlib issue?
On Thu, Feb 20, 2014 at 09:45:06PM -0500, Sahil Tandon wrote: > > Viktor Dukhovni: > > > On Sun, Feb 16, 2014 at 07:45:24AM -0500, Wietse Venema wrote: > > > > > > > This looks like the same problem that Viktor referred to yesterday. > > > > Same symptom (crash in zlib+openssl), same resolution. > > > > > > Perhaps Sahil can comment on what the status of this issue is in > > > FreeBSD? It has not to my knowledge been seen in other systems. > > > > I can run some tests inside a FreeBSD 10 VM (or give you a copy > > of the VirtualBox VM). The smaller the test program, the better. > > If there is a test program, I would also be happy to try it. I think the test is to compile Postfix against a libssl/libcrypto from ports in which SSL compression is not disabled at compile-time (or by default). Then connect with an SSL client that similarly enabled SSL compression and send a large message. With "luck" it'll crash. The thread on Postfix-users from ~2007 was also FreeBSD with OpenSSL from ports. Perhaps users are getting compilation flags wrong, mixing headers from the base system with libraries from ports? Or linking with the wrong compression library? I really don't have enough detail to say what they are doing wrong. -- Viktor.
Re: can not telnet port 25
On Fri, Feb 21, 2014 at 10:31:18AM +0800, Feel Zhou wrote: > Today, one of my postfix server can not telnet any other mail server's port > 25. If you cannot make a TCP connection to port 25, your problem is outside Postfix. Your ISP may have blocked port 25 outbound. > It's working before 9:00am(bejing time CHina), I have restart the mail > server and reinstall the postfix. but it's looks like not working. How can > I fix this problem. Thanks for your help Postfix relies on working TCP/IP infrastructure. Postfix cannot configure away problems in the network stack. -- Viktor.
Re: can not telnet port 25
On Thu, Feb 20, 2014 at 9:31 PM, Feel Zhou wrote: > Hello, My friend > This is Tom, I'm sending my greeting from China. > Today, one of my postfix server can not telnet any other mail server's port > 25. It's working before 9:00am(bejing time CHina), I have restart the mail > server and reinstall the postfix. but it's looks like not working. How can I > fix this problem. Thanks for your help > TOM Did you check the logs?
Re: FreeBSD ports OpenSSL with zlib issue?
On Sun, 2014-02-16 at 11:02:08 -0500, Wietse Venema wrote: > Viktor Dukhovni: > > On Sun, Feb 16, 2014 at 07:45:24AM -0500, Wietse Venema wrote: > > > > > This looks like the same problem that Viktor referred to yesterday. > > > Same symptom (crash in zlib+openssl), same resolution. > > > > Perhaps Sahil can comment on what the status of this issue is in > > FreeBSD? It has not to my knowledge been seen in other systems. > > I can run some tests inside a FreeBSD 10 VM (or give you a copy > of the VirtualBox VM). The smaller the test program, the better. If there is a test program, I would also be happy to try it. FWIW, I recall reports about zlib+openssl problems with ejabberd in FreeBSD, but nothing in the context of Postfix. In fact, the most recent report I saw was filed by someone who noted that his zlib+openssl setup did not hiccup with Postfix, only ejabberd. http://www.freebsd.org/cgi/query-pr.cgi?pr=181994 -- Sahil Tandon
Re: can not telnet port 25
-A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT firewall is ok 2014-02-21 10:37 GMT+08:00 Venkat : > On Thu, Feb 20, 2014 at 6:31 PM, Feel Zhou wrote: > >> Hello, My friend >> This is Tom, I'm sending my greeting from China. >> Today, one of my postfix server can not telnet any other mail server's >> port 25. It's working before 9:00am(bejing time CHina), I have restart the >> mail server and reinstall the postfix. but it's looks like not working. How >> can I fix this problem. Thanks for your help >> TOM >> > > Check your firewall settings to see if the connection is being blocked. >
Re: can not telnet port 25
On Thu, Feb 20, 2014 at 6:31 PM, Feel Zhou wrote: > Hello, My friend > This is Tom, I'm sending my greeting from China. > Today, one of my postfix server can not telnet any other mail server's > port 25. It's working before 9:00am(bejing time CHina), I have restart the > mail server and reinstall the postfix. but it's looks like not working. How > can I fix this problem. Thanks for your help > TOM > Check your firewall settings to see if the connection is being blocked.
can not telnet port 25
Hello, My friend This is Tom, I'm sending my greeting from China. Today, one of my postfix server can not telnet any other mail server's port 25. It's working before 9:00am(bejing time CHina), I have restart the mail server and reinstall the postfix. but it's looks like not working. How can I fix this problem. Thanks for your help TOM
Re: Domain lookup fails for exactly one domain
On 19 Feb 2014, at 8:57, Svoop wrote: Hmmm, the problem has vanished, I can't reproduce it anymore. However, I keep your instructions. If the problem occurs again, I'll have the tools in place. This is almost certainly due to the way bluewin.ch has set up their DNS. Note: bluewin.ch. 43200 IN SOA adnso1.bluewin.ch. hostmaster.bluewin.ch. 2014021801 36000 3600 1814400 300 That zone serial number probably indicates that they made changes 2014-02-18, i.e. when your trouble vanished. Their current records include a 20-second TTL for the A to which their lowest-cost MX points, with the 4 NS for that name handing out different records without a zone serial number change. In short: they are violating both the DNS spec and best practices. I don't know what they were doing when you had trouble, but if they are playing these sorts of games now, they probably were doing similar bad and/or wrong behavior a few days ago in a slightly worse way that caused intermittent failures.
Re: Logging TLS info as part of mail transactions
On Thu, Feb 20, 2014 at 11:50:19AM -0500, Wietse Venema wrote: > WHAT STATUS INFORMATION TO LOG > == > If cost is not a concern, then we could log everything like this: > > ... tls_protocol=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 > tls_keysize=256/256 ... > > This format is fully extensible, but it adds a lot to the logfile, > and it repeats all the information that is already logged when the > TLS handshake is completed. > > Currently people seem to care primarily whether mail was delivered > in plaintext or not, so we could suffice with just the TLS cipher. > > tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 > > Alternatively we could use a non-extensible format such as > > tls_status=TLSv1/ECDHE-RSA-AES256-GCM-SHA384/256/256 For an SMTP client per-record log entry I'd suggest a very condensed format: smtp[pid]: QUEUE-ID: to=, [orig_to=,] [security=none|passive|active,] in which "passive" protects against passive attacks and consolidates Anonymous, Untrusted and Trusted, while "active" protects against MITM attacks and handles "Verified" connections (success at security level "fingerprint", "verify", "secure" or "dane"). My guess is that the protocol version, cipher bits, ... are rarely interesting at this level. People just want to know the overall channel security status. The "security" element can either be always present, with "none" to signal non-TLS delivery, or simply absent to signal the same. For the SMTP server, if the server actually makes use of a client certificate, it can be reasonably confident that its connection with that client resists active MITM attacks. More generally, one would expect to see one of: security=none|passive channel integrity for SMTP is generally the sender's job. -- Viktor.
Re: postfix TLS question
On Thu, Feb 20, 2014 at 06:51:09AM -0500, Wietse Venema wrote:
> To fully understand what happens with a particular message requires
> a stateful logfile processor.
I tend to use the admittedly imperfect, but sufficiently useful
"collate" Perl script I slapped together. A fancier version would
checkpoint data about messages not fully processed at the end of
the current input stream, and allow a future invocation to pick up
where the previous one left off. One might generate such checkpoints
at the end of each day of logs, ...
The simple version below my signature does not accurately report
on messages whose lifetime straddles log file boundaries.
Its output is blank-line delimited, in order of queue exit time.
One can search for messages matching some patter (e.g. a queue-id)
via:
gunzip -c logfile.gz |
perl collate |
perl -ne 'BEGIN {$/="\n\n"} print if m{some-pattern};'
--
Viktor.
#! /usr/bin/perl
use strict;
use warnings;
# Postfix delivery agents
my @agents = qw(discard error lmtp local pipe smtp virtual);
my $instre = qr{(?x)
\A # Absolute line start
(?:\S+ \s+){3} # Timestamp, adjust for other time formats
\S+ \s+ # Hostname
(postfix(?:-\S+)?)/ # postfix instance
};
my $cmdpidre = qr{(?x)
\G # Continue from previous match
(\S+)\[(\d+)\]:\s+ # command[pid]:
};
my %smtpd;
my %smtp;
my %transaction;
my %isagent = map { ($_, 1) } @agents;
while (<>) {
next unless m{$instre}ogc; my $inst = $1;
next unless m{$cmdpidre}ogc; my $command = $1; my $pid = $2;
if ($command eq "smtpd") {
if (m{\Gconnect from }gc) {
# Start new log
$smtpd{$pid}->{"log"} = $_; next;
}
$smtpd{$pid}->{"log"} .= $_;
if (m{\G(\w+): client=}gc) {
# Fresh transaction
my $qid = "$inst/$1";
$smtpd{$pid}->{"qid"} = $qid;
$transaction{$qid} = $smtpd{$pid}->{"log"};
next;
}
my $qid = $smtpd{$pid}->{"qid"};
$transaction{$qid} .= $_ if (defined($qid));
delete $smtpd{$pid} if (m{\Gdisconnect from}gc);
next;
}
if ($command eq "pickup") {
if (m{\G(\w+): uid=}gc) {
my $qid = "$inst/$1";
$transaction{$qid} = $_;
}
next;
}
# bounce(8) logs transaction start after cleanup(8) already logged
# the message-id, so the cleanup log entry may be first
#
if ($command eq "cleanup") {
next unless (m{\G(\w+): }gc);
my $qid = "$inst/$1";
$transaction{$qid} .= $_;
next;
}
if ($command eq "qmgr") {
next unless (m{\G(\w+): }gc);
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
if (m{\Gremoved$}gc) {
print delete $transaction{$qid}, "\n";
}
}
next;
}
# Save pre-delivery messages for smtp(8) and lmtp(8)
#
if ($command eq "smtp" || $command eq "lmtp") {
$smtp{$pid} .= $_;
if (m{\G(\w+): to=}gc) {
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $smtp{$pid};
}
delete $smtp{$pid};
}
next;
}
if ($command eq "bounce") {
if (m{\G(\w+): .*? notification: (\w+)$}gc) {
my $qid = "$inst/$1";
my $newid = "$inst/$2";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
}
$transaction{$newid} =
$_ . $transaction{$newid};
}
next;
}
if ($isagent{$command}) {
if (m{\G(\w+): to=}gc) {
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
}
}
next;
}
}
Re: domain not found
> > ON THE SAME SERVER if I type > > $ host mail15.wdc01.mcdlv.net > > > > I get > > > > mail15.wdc01.mcdlv.net has address 205.201.129.15 > > mail15.wdc01.mcdlv.net mail is handled by 10 mail.mail15.wdc01.mcdlv.net. > > > > So why Postfix says "Domain not found"? > > * maybe your smtpd is runnign chroot (Debian?) See http://www.postfix.org/DEBUG_README.html#no_chroot for instructions. Wietse
Re: postfix TLS question
Salvatore Palazzolo: > there is no link between the line related to the TLS connection > and the subsequent queue message ID. The link is the combination of SMTP server process ID (21492) and the client name+address (unknown[10.204.61.131]) as shown below: > Feb 20 11:05:47 sgsnoimsva002lx postfix/smtpd[21492]: connect from > unknown[10.204.61.131] > Feb 20 11:05:47 sgsnoimsva002lx postfix/smtpd[21492]: Anonymous TLS > connection established from unknown[10.204.61.131]: TLSv1 with cipher > DHE-RSA-AES256-SHA (256/256 bits) > Feb 20 11:06:06 sgsnoimsva002lx postfix/smtpd[21492]: F0C30178125: > client=unknown[10.204.61.131] To fully understand what happens with a particular message requires a stateful logfile processor. Note that one SMTP session can convey more than one email message, and that one SMTP daemon process can service more than one SMTP client. Wietse
Logging TLS info as part of mail transactions
As implemented many years ago, Postfix SMTP client and server processes log TLS status information like this: postfix/smtp[process-id]: Untrusted TLS connection established to host.example.com[192.168.0.2]:25: TLSv1 with cipher cipher-name (actual-key-size/raw-key-size bits) postfix/smtpd[process-id]: Anonymous TLS connection established from host.example.com[192.168.0.2]: TLSv1 with cipher cipher-name (actual-key-size/raw-key-size bits) That is a lot of information, but that is OK because it is logged once per SMTP session. It is logged soon as the handshake completes, to simplify trouble shooting. One consequence of this terseness is that you can't use grep to find out whether a mail delivery transaction was encrypted. You need a stateful logfile parser instead. Nowadays people seem to care more about whether or their connections are encrypted, so this may be the time to elevate the status of TLS status information to something that is logged with every mail delivery transaction (i.e. with the queue ID). SMTP SERVER === This is an example of how the SMTP server currently logs SASL status information for each inbound mail transaction: postfix/smtpd[process-id]: QUEUEID: client=hostname[address], sasl_method=xxx, sasl_username=yyy, sasl_sender=zzz It seems natural to add some name=value attribute to this record to indicate that a particular mail delivery transaction used an encrypted session. Once per mail delivery transaction, adding to an existing record: postfix/smtpd[process-id]: QUEUEID: client=hostname[address], sasl_method=xxx, sasl_username=yyy, sasl_sender=zzz, The alternative is to introduce a new logfile record that is logged once per inbound mail delivery transaction: New record, once per mail delivery transaction: postfix/smtpd[process-id]: QUEUEID: The new record would be logged in addition to the per-session TLS status information that is shown in the introduction of this message. SMTP CLIENT === On the SMTP client side we have basically the same choice: log TLS status information once per mail delivery transaction or add some name=value attributes to an existing logfile record. Once per recipient, adding to an existing record: postfix/smtp[process-id]: QUEUEID: to=, relay=host[address], , delay=xxx, delays=a/b/c/d, dsn=2.0.0, status=sent (server reply) New record, once per mail delivery transaction: postfix/smtp[process-id]: QUEUEID: The new record would be logged in addition to the per-session TLS status information that is shown in the introduction of this message. WHAT STATUS INFORMATION TO LOG == If cost is not a concern, then we could log everything like this: ... tls_protocol=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 tls_keysize=256/256 ... This format is fully extensible, but it adds a lot to the logfile, and it repeats all the information that is already logged when the TLS handshake is completed. Currently people seem to care primarily whether mail was delivered in plaintext or not, so we could suffice with just the TLS cipher. tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 Alternatively we could use a non-extensible format such as tls_status=TLSv1/ECDHE-RSA-AES256-GCM-SHA384/256/256 This basically repeats the information in a less-verbose format, but also makes adding information more difficult (for example how the remote peer was authenticated). Of course the ultimate solution is to make logging fully configurable and leave the problem in the hands of the capable administrator. Wietse
Re: domain not found
Am 20.02.2014 14:46, schrieb Luigi Rosa: > Feb 20 12:27:28 services postfix/smtpd[3054]: connect from > unknown[205.201.129.15] > Feb 20 12:27:29 services postfix/smtpd[3054]: NOQUEUE: reject: RCPT from > unknown[205.201.129.15]: 450 4.1.8 > : > Sender address rejected: Domain not found; > from= > to= proto=ESMTP helo= > > ON THE SAME SERVER if I type > $ host mail15.wdc01.mcdlv.net > > I get > > mail15.wdc01.mcdlv.net has address 205.201.129.15 > mail15.wdc01.mcdlv.net mail is handled by 10 mail.mail15.wdc01.mcdlv.net. > > So why Postfix says "Domain not found"? * maybe your smtpd is runnign chroot (Debian?) * maybe there was a temporary error in name resloving in case 1: fix that in case 2: where is your problem? 450 is a *temporary reject* as the docs say " The response is always 450 in case of a temporary DNS error" reject_unknown_sender_domain Reject the request when Postfix is not final destination for the sender address, and the MAIL FROM domain has 1) no DNS MX and no DNS address record, or 2) a malformed MX record such as a record with a zero-length MX hostname (Postfix version 2.3 and later). The unknown_address_reject_code parameter specifies the numerical response code for rejected requests (default: 450). The response is always 450 in case of a temporary DNS error.
domain not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have a Postfix 2.11.0 with this recipient policy smtpd_recipient_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/whitelist reject_invalid_hostname reject_non_fqdn_hostname reject_non_fqdn_sender reject_non_fqdn_recipient reject_unknown_sender_domain reject_unknown_recipient_domain reject_unauth_destination reject_rbl_client zen.spamhaus.org permit The messages from MailChimp to a legitimate local users are rejected with this status: Feb 20 12:27:27 services postfix/smtpd[3042]: connect from unknown[205.201.129.15] Feb 20 12:27:28 services postfix/smtpd[3042]: NOQUEUE: reject: RCPT from unknown[205.201.129.15]: 450 4.1.8 : Sender address rejected: Domain not found; from= to= proto=ESMTP helo= Feb 20 12:27:28 services postfix/smtpd[3054]: connect from unknown[205.201.129.15] Feb 20 12:27:29 services postfix/smtpd[3054]: NOQUEUE: reject: RCPT from unknown[205.201.129.15]: 450 4.1.8 : Sender address rejected: Domain not found; from= to= proto=ESMTP helo= ON THE SAME SERVER if I type $ host mail15.wdc01.mcdlv.net I get mail15.wdc01.mcdlv.net has address 205.201.129.15 mail15.wdc01.mcdlv.net mail is handled by 10 mail.mail15.wdc01.mcdlv.net. So why Postfix says "Domain not found"? Thank you. Ciao, luigi - -- / +--[Luigi Rosa]-- \ Be careful of reading health books, you might die of a misprint. --Mark Twain -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTBgcWAAoJEO5WT/qgw4yKT+0QAJ83ElvzKlLU+ER8wv4XTjQO /MN0AbseYArDGHNNLr4MRTDld9c1DqARL9r97SkuI91YP5EaxV6GJWWKhZnpvEWB SshCdusX9bIwl95cNpBeotPL9wdPJrq16Vfbm6E8MCJHra+zBzZkjoDbbXOqtJpT 6N5T9xsIkqgMqwOenYGE4Y6Dz4HZ0kdll0aXVwVTWsSROykf5Dv0/fVBA+28I1CD Fyp0VEHM6sNndoDZDNsZIuBo2tDmh9J3vC3TOCJDaCaVyfXp7FM/3DhS7HFTbHk6 Sr2UBM0flGDF4N7Q9XLXLJTYXIKxfpd4sKljtwOXontPuOxgUpFvrISwAxB8np+z 9ud/hLETjh3hEgjlj/bDGhde6HoGbq6tCvWpM+NXESzGnP4F4ZJpxaPsqSnH1zkR PsEA/sEu+6Y/yfTQwyJVEn7mnkAnDtQvjygBlR9dHwYOSq/kqUv54/0PStnCSwjg Td2DJC5P/Q9gdcJZSFOGxYpLSWVs1SApF6ZlBq9yhDnQgWx5kIneAMhi6/HOxlmq zvvv94rZDHwNcHGH1OiZCtQzj1/py6p6N4c6LVQCSI59/6wS09h+XHOiIfOa0N8m zvScM6nmiHtXYEUtf9CURRPvijQ1zB71jHKtWkh5E6++7TGDQAR99kLOJ818qXhb w4S8yBETr9hSjlzzi1qJ =1CFx -END PGP SIGNATURE-
