advise needed: unknown mail transport error; panic: file size limit message size
Hi Folks, Need your advise on how to solve a problem related to 'unknown mail transport error'. I've narrowed the error to linked to VDA. VDA works fine for cases where (incoming mail size) + (existing mailbox file size) is greater than the quota set for the mailbox. Example: Quota set for User 'A' = 5Mb (500) Existing mailbox size = 4Mb (400) Case (A) : Incoming mail size = 2 Mb (200) . The sender gets a bounce mail as expected because 4+2mb would be greater than 5mb. However whenever an the incoming mail size by itself is greater than the set quota (5Mb), postfix panics and the mail would be stuck in the mail queue. Case (B) : Incoming mail size = 6.8 Mb (6887595) . /var/log/maillog: Aug 21 11:12:54 node1 postfix/virtual[40382]: panic: file size limit 500 message size 6887595. This causes large messages to be delivered repeatedly after they were submitted with sendmail -t or after recipients were added with the Milter SMFIR_ADDRCPT request Aug 21 11:12:55 node1 kernel: pid 40382 (virtual), uid 5000: exited on signal 6 'mailq' will show the mail is stucked in queue due to reason: unknown mail transport error Appreciate any ideas to solve or workaround this issue! Ryan == main.cf VDA config: virtual_mailbox_limit_maps = proxy:mysql:$config_directory/ vj-postfix-vboxlimit.cf virtual_mailbox_limit_override = yes virtual_overquota_bounce = yes postfix version 2.7.1 on Freebsd 8.0 (via ports). VDA version: 2.6.5
postfix + LDAP + TLS man page confusion
Hi all, The short version: I want LDAP server authenticity to Postfi without Postfix authenticity to LDAP. The long version: I wanted my Postfix to look up recipients and mail aliases in my LDAP DB. The ldap_table(5) man page states a parameter 'tls_key' which is confusing. I thought that the private server key for the LDAP host is to be secret (that is, is to remain on my LDAP host and not be given away to clients such as Postfix)?? Reading a bit more, there is a parameter 'tls_cert' which shall point to a 'client certificate'. So I presume that 'tls_key' is to point to a *client* key, am I right? If that's the case, how can I turn this off? The man page says this parameter is mandatory, but there is no point having Postfix authenticated to LDAP since LDAP does not reveal any secrets by the DN that Postfix uses to bind to LDAP anyway. Another option would be to turn off TLS all together, but that refutes the purpose of TLS, doesn't it? Thanks. Regards, Winston Smith
Re: advise needed: unknown mail transport error; panic: file size limit message size
Squeeshh Me: Aug 21 11:12:55 node1 kernel: pid 40382 (virtual), uid 5000: exited on signal 6 For details, look in your MAILLOG file. Wietse http://www.postfix.org/DEBUG_README.html#logging Look for obvious signs of trouble Postfix logs all failed and successful deliveries to a logfile. The file is usually called /var/log/maillog or /var/log/mail; the exact pathname is defined in the /etc/syslog.conf file. When Postfix does not receive or deliver mail, the first order of business is to look for errors that prevent Postfix from working properly: % egrep '(warning|error|fatal|panic):' /some/log/file | more Note: the most important message is near the BEGINNING of the output. Error messages that come later are less useful. The nature of each problem is indicated as follows: * panic indicates a problem in the software itself that only a programmer can fix. Postfix cannot proceed until this is fixed. * fatal is the result of missing files, incorrect permissions, incorrect configuration file settings that you can fix. Postfix cannot proceed until this is fixed. * error reports an error condition. For safety reasons, a Postfix process will terminate when more than 13 of these happen. * warning indicates a non-fatal error. These are problems that you may not be able to fix (such as a broken DNS server elsewhere on the network) but may also indicate local configuration errors that could become a problem later.
Selective smtpd_helo_restrictions question
So I have, smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/heloaccess.cf If I put the following into heloaccess.cf, for .cc hostnames, /^.*\.[a-z][a-z]$/ reject_unknown_helo_hostname Am I adding to the restrictions? Making it, smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/heloaccess.cf, reject_unknown_helo_hostname Or am I replacing the restrictions? Making it only, smtpd_helo_restrictions = reject_unknown_helo_hostname On a hit of the regexp rule, would the existing smtpd_sender_restrictions and smtpd_recipient_restrictions still be processed? Or am I killing off and replacing every restriction that comes after smtpd_helo_restrictions? (smtpd_sender_restrictions, smtpd_recipient_restrictions) Thanks
Re: advise needed: unknown mail transport error; panic: file size limit message size
Hi, Thanks for replying. My bad, I realised I posted the log message from /var/log/message. It's quite similar to what I get in postfix log too. Here's the postfix /var/log/mailog version of a test mail that I just sent, hope this is better (also there are no other warning/panic errors before this). :) - Aug 22 21:50:17 node1 postfix/smtpd[71236]: 4F4056EB019: client=unknown[172.31.0.181] Aug 22 21:50:17 node1 postfix/cleanup[71239]: 4F4056EB019: message-id= 4c712a92.8020...@aaa.com Aug 22 21:50:17 node1 postfix/smtpd[71236]: disconnect from unknown[172.31.0.181] Aug 22 21:50:17 node1 postfix/qmgr[59650]: 4F4056EB019: from=sen...@aaa.com, size=1498409, nrcpt=1 (queue active) Aug 22 21:50:17 node1 postfix/virtual[71240]: panic: file size limit 100 message size 1498997. This causes large messages to be delivered repeatedly after they were submitted with sendmail -t or after recipients were added with the Milter SMFIR_ADDRCPT request Aug 22 21:50:18 node1 postfix/qmgr[59650]: warning: private/virtual socket: malformed response Aug 22 21:50:18 node1 postfix/qmgr[59650]: warning: transport virtual failure -- see a previous warning/fatal/panic logfile record for the problem description Aug 22 21:50:18 node1 postfix/master[59648]: warning: process /usr/local/libexec/postfix/virtual pid 71240 killed by signal 6 Aug 22 21:50:18 node1 postfix/error[71260]: 4F4056EB019: to=r...@aaa.com, relay=none, delay=1.2, delays=0.15/1/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error) mailq command: 4F4056EB019 1498409 Sun Aug 22 21:50:17 sen...@aaa.com (unknown mail transport error) r...@aaa.com On Sun, Aug 22, 2010 at 9:24 PM, Wietse Venema wie...@porcupine.org wrote: Squeeshh Me: Aug 21 11:12:55 node1 kernel: pid 40382 (virtual), uid 5000: exited on signal 6 For details, look in your MAILLOG file. Wietse http://www.postfix.org/DEBUG_README.html#logging Look for obvious signs of trouble Postfix logs all failed and successful deliveries to a logfile. The file is usually called /var/log/maillog or /var/log/mail; the exact pathname is defined in the /etc/syslog.conf file. When Postfix does not receive or deliver mail, the first order of business is to look for errors that prevent Postfix from working properly: % egrep '(warning|error|fatal|panic):' /some/log/file | more Note: the most important message is near the BEGINNING of the output. Error messages that come later are less useful. The nature of each problem is indicated as follows: * panic indicates a problem in the software itself that only a programmer can fix. Postfix cannot proceed until this is fixed. * fatal is the result of missing files, incorrect permissions, incorrect configuration file settings that you can fix. Postfix cannot proceed until this is fixed. * error reports an error condition. For safety reasons, a Postfix process will terminate when more than 13 of these happen. * warning indicates a non-fatal error. These are problems that you may not be able to fix (such as a broken DNS server elsewhere on the network) but may also indicate local configuration errors that could become a problem later.
Re: advise needed: unknown mail transport error; panic: file size limit message size
Squeeshh Me: Hi, Thanks for replying. My bad, I realised I posted the log message from /var/log/message. It's quite similar to what I get in postfix log too. Here's the postfix /var/log/mailog version of a test mail that I just sent, hope this is better (also there are no other warning/panic errors before this). :) PLEASE RUN THE COMMAND that I posted in my earlier response. Wietse
Re: advise needed: unknown mail transport error; panic: file size limit message size
On Sun, Aug 22, 2010 at 10:21 PM, Wietse Venema wie...@porcupine.org wrote: Squeeshh Me: Hi, Thanks for replying. My bad, I realised I posted the log message from /var/log/message. It's quite similar to what I get in postfix log too. Here's the postfix /var/log/mailog version of a test mail that I just sent, hope this is better (also there are no other warning/panic errors before this). :) PLEASE RUN THE COMMAND that I posted in my earlier response. Wietse Wietse: ok, here it is: egrep '(warning|error|fatal|panic):' /var/log/maillog | more Aug 22 21:50:17 node2 postfix/virtual[71240]: panic: file size limit 100 message size 1498997. This causes large messages to be delivered repeatedly after they were submitted with sendmail -t or after recipients were added with the Milter SMFIR_ADDRCPT request Aug 22 21:50:18 node2 postfix/qmgr[59650]: warning: private/virtual socket: malformed response Aug 22 21:50:18 node2 postfix/qmgr[59650]: warning: transport virtual failure -- see a previous warning/fatal/panic logfile record for the problem description Aug 22 21:50:18 node2 postfix/master[59648]: warning: process /usr/local/libexec/postfix/virtual pid 71240 killed by signal 6 Jerry, sorry I didn't realise there are posting guidelines, I've tried to meet them, hope I did right.
Re: Selective smtpd_helo_restrictions question
On Sunday, August 22, 2010 at 16:01 CEST, p...@alt-ctrl-del.org wrote: So I have, smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/heloaccess.cf If I put the following into heloaccess.cf, for .cc hostnames, /^.*\.[a-z][a-z]$/ reject_unknown_helo_hostname Am I adding to the restrictions? Making it, smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/heloaccess.cf, reject_unknown_helo_hostname Or am I replacing the restrictions? Making it only, smtpd_helo_restrictions = reject_unknown_helo_hostname On a hit of the regexp rule, would the existing smtpd_sender_restrictions and smtpd_recipient_restrictions still be processed? A regexp match will cause the reject_unknown_helo_hostname restriction to be evaluated. If it indeed results in a rejection the mail will be rejected no matter what. If it doesn't result in a rejection Postfix will continue with the remaining restrictions in smtpd_helo_restrictions, smtpd_sender_restrictios, smtpd_recipient_restrictions and so on like nothing has happened. The only thing that's terminated is the traversal of /etc/postfix/heloaccess.cf. In other words, /^foo.example\.com$/ DUNNO /example\.com$/ REJECT would cause all hosts using any example.com hostname in HELO to be rejected except foo.example.com. Of course, if any other restriction wants to reject a message from foo.example.com it would still be rejected. [...] -- Magnus Bäck mag...@dsek.lth.se
Re: advise needed: unknown mail transport error; panic: file size limit message size
Squeeshh Me: Wietse: ok, here it is: egrep '(warning|error|fatal|panic):' /var/log/maillog | more Aug 22 21:50:17 node2 postfix/virtual[71240]: panic: file size limit 100 message size 1498997. Your Postfix version was modified with an unofficial patch that implements quota in the virtual delivery agent. This unofficial patch allows you to configure a quota limit that is smaller than the message size limit. Unfortunately, the unofficial patch mis-implements quota smaller than the message size; instead of returning the message as undeliverable, it lets Postfix fail delivery repeatedly. The panic message was added to as part of a safety mechanism that protects against broken unofficial patches. Wietse
Re: Selective smtpd_helo_restrictions question
Magnus Bäck put forth on 8/22/2010 10:04 AM: On Sunday, August 22, 2010 at 16:01 CEST, p...@alt-ctrl-del.org wrote: So I have, smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/heloaccess.cf If I put the following into heloaccess.cf, for .cc hostnames, /^.*\.[a-z][a-z]$/ reject_unknown_helo_hostname Am I adding to the restrictions? Making it, smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/heloaccess.cf, reject_unknown_helo_hostname Or am I replacing the restrictions? Making it only, smtpd_helo_restrictions = reject_unknown_helo_hostname On a hit of the regexp rule, would the existing smtpd_sender_restrictions and smtpd_recipient_restrictions still be processed? A regexp match will cause the reject_unknown_helo_hostname restriction to be evaluated. If it indeed results in a rejection the mail will be rejected no matter what. That's not necessarily true. It depends on the order of his smtpd_*_restrictions and whether he's using delayed evaluation. If he's using the multiple section restrictions style with delayed eval it's possible he may have an OK in a later table that causes the mail to be accepted even after the regexp check returned REJECT. -- Stan
Re: advise needed: unknown mail transport error; panic: file size limit message size
On Sun, Aug 22, 2010 at 11:17 PM, Wietse Venema wie...@porcupine.org wrote: Squeeshh Me: Wietse: ok, here it is: egrep '(warning|error|fatal|panic):' /var/log/maillog | more Aug 22 21:50:17 node2 postfix/virtual[71240]: panic: file size limit 100 message size 1498997. Your Postfix version was modified with an unofficial patch that implements quota in the virtual delivery agent. This unofficial patch allows you to configure a quota limit that is smaller than the message size limit. Unfortunately, the unofficial patch mis-implements quota smaller than the message size; instead of returning the message as undeliverable, it lets Postfix fail delivery repeatedly. The panic message was added to as part of a safety mechanism that protects against broken unofficial patches. Wietse Thanks Wietse for your advice and time, appreciate both. The advice sheds a great deal of light. Guess I'll seek advise from the VDA folks. Cheers.
Re: Selective smtpd_helo_restrictions question
On Sunday, August 22, 2010 at 17:26 CEST, Stan Hoeppner s...@hardwarefreak.com wrote: Magnus Bäck put forth on 8/22/2010 10:04 AM: A regexp match will cause the reject_unknown_helo_hostname restriction to be evaluated. If it indeed results in a rejection the mail will be rejected no matter what. That's not necessarily true. It depends on the order of his smtpd_*_restrictions and whether he's using delayed evaluation. If he's using the multiple section restrictions style with delayed eval it's possible he may have an OK in a later table that causes the mail to be accepted even after the regexp check returned REJECT. No. If smtpd_helo_restrictions returns REJECT nothing can save the email. smtpd_delay_reject does not affect *how* Postfix evaluates restrictions, only *when*. Whitelisting only takes place within the same restriction list, i.e. an OK in smtpd_helo_restrictions only skips rejections listed further down in smtpd_helo_restrictions. -- Magnus Bäck mag...@dsek.lth.se
Re: Selective smtpd_helo_restrictions question
Stan Hoeppner: That's not necessarily true. It depends on the order of his smtpd_*_restrictions and whether he's using delayed evaluation. If he's using the multiple section restrictions style with delayed eval it's possible he may have an OK in a later table that causes the mail to be accepted even after the regexp check returned REJECT. Stan, That is incorrect. Coming back to a post that you made a week ago: Well at least I'm batting 50% and if this were baseball that would be pretty good right. :) I wish I'd nailed your bigger issue here, but that's why this list has multiple people with varying degrees of experience and expertise. If folks like myself miss the dart board, Noel, Viktor, or Wietse will come in and hit the bullseye for you. :) I suggest that you avoid posting statements that you haven't verified first-hand (by experiment, code review, or otherwise). There is enough incorrect information on the Internet, and and there are enough people willing to repeat information without validating it first. Wietse
Re: Selective smtpd_helo_restrictions question
On Sunday, August 22, 2010 at 16:01 CEST, p...@alt-ctrl-del.org wrote: So I have, smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/heloaccess.cf If I put the following into heloaccess.cf, for .cc hostnames, /^.*\.[a-z][a-z]$/ reject_unknown_helo_hostname Am I adding to the restrictions? Making it, smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/heloaccess.cf, reject_unknown_helo_hostname Or am I replacing the restrictions? Making it only, smtpd_helo_restrictions = reject_unknown_helo_hostname On a hit of the regexp rule, would the existing smtpd_sender_restrictions and smtpd_recipient_restrictions still be processed? Magnus Bäck put forth on 8/22/2010 10:04 AM: A regexp match will cause the reject_unknown_helo_hostname restriction to be evaluated. If it indeed results in a rejection the mail will be rejected no matter what. Stan Hoeppner wrote: That's not necessarily true. It depends on the order of his smtpd_*_restrictions and whether he's using delayed evaluation. If he's using the multiple section restrictions style with delayed eval it's possible he may have an OK in a later table that causes the mail to be accepted even after the regexp check returned REJECT. smtpd_delay_reject = on smtpd_helo/client/recipient/sender_restrictions are all defined. Reading RESTRICTION_CLASS_README confused me as to whether adding a Restriction (or a defined smtpd_restriction_classes group), to the right side of an access table, would be done in Addition-To or In-Place-Of the already existing smtpd_helo/client/recipient/sender_restrictions. What i'm getting out of the responses so far is: If there's not an OK or PERMIT in my additional restriction or class group, all of the existing smtpd_helo/client/recipient/sender_restrictions will still be applied. Right? So for widely used and well defined domain mail servers like comcast.net, I could use a more restrictive rule like: /^.*\.comcast.net$/ reject_unknown_client_hostname ?Or maybe even chain rules together? check_helo_access regexp:/etc/postfix/heloaccess /^.*\.comcast.net$/ check_reverse_client_hostname_access regexp:/etc/postfix/comcast With /etc/postfix/comcast containing: /qmta01.emeryville.ca.mail.comcast.net/ DUNNO /qmta02.emeryville.ca.mail.comcast.net/ DUNNO /etc...mail.comcast.net DUNNO /.*/ REJECT
Re: How common is reverse DNS checking?
On Fri, Aug 20, 2010 at 03:39:48AM -0500, Stan Hoeppner wrote: Robert Fournerat put forth on 8/19/2010 4:46 PM: Quoting Noel Jones njo...@megan.vbhcs.org: Same here. reject_unknown_client_hostname is too strict, but reject_unknown_reverse_client_hostname rejects lots of obvious spambots without resorting to an RBL lookup. The false-positive rate is close enough to zero that I would not consider removing this restriction. Call me a BOFH, but I have no sympathy for mail servers that do not pass the FCRDNS test. Agreed. Given that the majority of consumer broadband providers in the US assign rDNS to even all their consumer IP addresses, there's no reason for a legit mail sending host to not have rDNS. Same here, in Hungary, we can reject about 80% of the incoming SMTP transactions and still only some (usually one or two) complaints per month and even that case we always make the other MTA's sysadmin to use correct rDNS settings then, so it's very usefull ... But sure, it is only my opinion ...
Re: Selective smtpd_helo_restrictions question
On 8/22/2010 11:42 AM, p...@alt-ctrl-del.org wrote: On Sunday, August 22, 2010 at 16:01 CEST, p...@alt-ctrl-del.org wrote: So I have, smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/heloaccess.cf If I put the following into heloaccess.cf, for .cc hostnames, /^.*\.[a-z][a-z]$/ reject_unknown_helo_hostname Am I adding to the restrictions? Making it, smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/heloaccess.cf, reject_unknown_helo_hostname Or am I replacing the restrictions? Making it only, smtpd_helo_restrictions = reject_unknown_helo_hostname On a hit of the regexp rule, would the existing smtpd_sender_restrictions and smtpd_recipient_restrictions still be processed? Magnus Bäck put forth on 8/22/2010 10:04 AM: A regexp match will cause the reject_unknown_helo_hostname restriction to be evaluated. If it indeed results in a rejection the mail will be rejected no matter what. Stan Hoeppner wrote: That's not necessarily true. It depends on the order of his smtpd_*_restrictions and whether he's using delayed evaluation. If he's using the multiple section restrictions style with delayed eval it's possible he may have an OK in a later table that causes the mail to be accepted even after the regexp check returned REJECT. smtpd_delay_reject = on smtpd_helo/client/recipient/sender_restrictions are all defined. Reading RESTRICTION_CLASS_README confused me as to whether adding a Restriction (or a defined smtpd_restriction_classes group), to the right side of an access table, would be done in Addition-To or In-Place-Of the already existing smtpd_helo/client/recipient/sender_restrictions. Think of a restriction class as a single restriction. If there is no match for the whole class (or DUNNO), control returns to the next restriction you've defined; OK skips to the next smtpd_*_restrictions section; REJECT will reject the mail. What i'm getting out of the responses so far is: If there's not an OK or PERMIT in my additional restriction or class group, all of the existing smtpd_helo/client/recipient/sender_restrictions will still be applied. Right? An OK or PERMIT in smtpd_helo_restrictions only skips additional smtpd_helo_restrictions. Postfix will always continue on to smtpd_sender_restrictions. If smtpd_sender_restrictions result in no match or OK, postfix continues to smtpd_recipient_restrictions. And so on for data and end-of-data. If there is a REJECT anywhere in the sequence, the mail is rejected as soon as postfix evaluates that rule. So for widely used and well defined domain mail servers like comcast.net, I could use a more restrictive rule like: /^.*\.comcast.net$/ reject_unknown_client_hostname It's unclear from the context, but I assume you mean if the HELO says comcast, reject unknown client. Yes, that's valid. Your regexp can be shortened to /\.comcast\.net$/ reject_unknown_client ?Or maybe even chain rules together? check_helo_access regexp:/etc/postfix/heloaccess /^.*\.comcast.net$/ check_reverse_client_hostname_access regexp:/etc/postfix/comcast You can't have an access table directly call another access table. Use a restriction class when you need nested lookups. With /etc/postfix/comcast containing: /qmta01.emeryville.ca.mail.comcast.net/ DUNNO /qmta02.emeryville.ca.mail.comcast.net/ DUNNO /etc...mail.comcast.net DUNNO /.*/ REJECT IF /\.comcast\.net$/ /\.mail\.comcast\.net$/ DUNNO /^/ REJECT ENDIF (This is only safe as long as comcast consistently identifies their servers in this manner.) -- Noel Jones
Milter i-macro not set at EOM stage
Hi, I wrote a small milter using Sendmail::Milter in perl. This worked okay with postfix 2.6.5, but it doesn't with 2.7.0. I use the i-macro (postfix queue-id) in the EOM-callback function. Previously, the i-macro was always set at this stage, but now this is no longer the case. I built the milter to tempfail on a missing i-macro, so that is what happens now. I checked the documentation (http://www.postfix.org/MILTER_README.html) and the changelogs, but I am unable to find any mention of a change on this subject. A lot of performance-related changes with regard to content filtering though. Given the fact that the documentation doesn't say anything about a change in behaviour, I consider this an unlikely cause of this problem. It is possible that some other change in environment may cause the change, but I am at a loss what it may be. What could cause postfix to not define the i-macro in the EOM-stage, while in the logfile of course a valid queue-id is logged by postfix? Kind regards, Erik.
Re: Milter i-macro not set at EOM stage
Erik Logtenberg:
Hi,
I wrote a small milter using Sendmail::Milter in perl. This worked okay
with postfix 2.6.5, but it doesn't with 2.7.0. I use the i-macro
(postfix queue-id) in the EOM-callback function. Previously, the i-macro
was always set at this stage, but now this is no longer the case. I
built the milter to tempfail on a missing i-macro, so that is what
happens now.
As with Postfix 2.3, Postfix sends the I macro by default, as
observed with the test Milter program (test-milter.c, included with
Postfix source code):
test_eom
macro: i=972E0547B07
macro: j=tail.porcupine.org
macro: v=Postfix 2.8-20100728
macro: {daemon_name}=tail.porcupine.org
macro: {mail_addr}=wie...@porcupine.org
macro: {rcpt_addr}=wie...@porcupine.org
test_reply 0
Also visible with verbose logging from the cleanup server:
Aug 22 17:11:34 tail postfix/cleanup[7980]: event: SMFIC_BODYEOB; macros:
i=972E0547B07
Finally, tcpdump will also capture the info but requires manual
disassembly of the data stream:
IP_HDR=20 IP_OPT=0 TCP_HDR=20 TCP_OPT=12 DATA=25 FLAGS=PUSH ACK
IP_HDR 45 00 00 4d 0b af 40 00 40 06
vhl tos len len id id off off ttl pro
IP_HDR 00 00 7f 00 00 01 7f 00 00 01
sum sum src src src src dst dst dst dst
TCP_HDR 8a 4d 27 0f cb f3 9f e4 b4 fd
src src dst dst seq seq seq seq ack ack
TCP_HDR ca 3c 80 18 23 00 7d e8 00 00
ack ack off flg win win sum sum urp urp
TCP_OPT 01 01 08 0a 03 7a 94 35 9e 5c
opt opt opt opt opt opt opt opt opt opt
TCP_OPT c9 c5
opt opt
DATA 00 00 00 10 44 45 69 00 39 37
^@ ^@ ^@ ^P D E i ^@ 9 7 DEi.97
DATA 32 45 30 35 34 37 42 30 37 00
2 E 0 5 4 7 B 0 7 ^@ 2E0547B07.
DATA 00 00 00 01 45
^@ ^@ ^@ ^A E E
00 00 00 10 is a packet length (16 bytes)
'D' means that the packet contains macros
'E' means that these are end-of-body macros (SMFIC_BODYEOB)
'i' is the name of the macro terminated by null byte
972E0547B07 is the value of the 'i' macro terminated by null byte
00 00 00 01 is a packet length (1 byte)
'E' means end of body (SMFIC_BODYEOB).
The constants are defined in the Postfix source, and in
/usr/include/libmilter/mfdef.h
Without even understanding anything about the Milter protocol you
should be able to find this. The next TCP packets are a reply from
the Milter containing one byte with 'c' meaning continue, and a
command from Postfix containing one byte with 'Q' which means
quit.
It is possible that the Milter requests that Postfix does not notify
it about certain events that it is not interested in; in that case
Postfix won't report those events (and their milter_xxx_macros) to
the Milter application.
To debug, it's probably easiest to hook in the Postfix test-milter
program first to convince yourself that Postfix sends 'i' at EOM
time.
# postconf -e {,non_}smtpd_milters=inet:127.0.0.1:
# postfix reload
$ ./test-milter -d 2 -p inet:9...@localhost
Then send some test message.
To debug the flow with the perl application, you may need to
capture a tcpdump recording.
Wietse
Re: How common is reverse DNS checking?
Noel, pf: Thanks for your suggestions and comments. I also had the same questions and its good to see that others used reject_unknown_reverse_client_hostname without too many false-positives. Now I will enable it on my production server. Regards, -- Klaus Engelmann CCNA CCDA - CSCO10971632 LPIC-2 - LPI000138061 On Thu, Aug 19, 2010 at 4:37 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 8/19/2010 2:15 PM, p...@alt-ctrl-del.org wrote: From: D G Teed Subject: How common is reverse DNS checking? Out of all of the things we do to restrict spam, the only one with a steady trickle of false positives is the host lookup not passing reverse DNS check. reject_unknown_client_hostname = gives problems reject_unknown_reverse_client_hostname = 0 complaints here Same here. reject_unknown_client_hostname is too strict, but reject_unknown_reverse_client_hostname rejects lots of obvious spambots without resorting to an RBL lookup. The false-positive rate is close enough to zero that I would not consider removing this restriction. -- Noel Jones
relayhost if fail
Hi to all In the configuration of my main.cf, I have all mail sent to an external server (relayhost) I can do to check if the server is operational and if it fails to send all mail to another server relayhost=xxx.xxx.xxx.xxx if fail send to yyy.yyy.yyy.yyy I'm using postfix 2.5 thanks in advanced
Re: Selective smtpd_helo_restrictions question
Wietse Venema put forth on 8/22/2010 11:13 AM: Stan Hoeppner: That's not necessarily true. It depends on the order of his smtpd_*_restrictions and whether he's using delayed evaluation. If he's using the multiple section restrictions style with delayed eval it's possible he may have an OK in a later table that causes the mail to be accepted even after the regexp check returned REJECT. Stan, That is incorrect. Coming back to a post that you made a week ago: Well at least I'm batting 50% and if this were baseball that would be pretty good right. :) I wish I'd nailed your bigger issue here, but that's why this list has multiple people with varying degrees of experience and expertise. If folks like myself miss the dart board, Noel, Viktor, or Wietse will come in and hit the bullseye for you. :) I suggest that you avoid posting statements that you haven't verified first-hand (by experiment, code review, or otherwise). There is enough incorrect information on the Internet, and and there are enough people willing to repeat information without validating it first. My apologies. When I first ran into this issue many months ago, I was attempting to whitelist. IIRC, an OK in say smtpd_client_restrictions could later be overridden by a REJECT in say smtpd_helo_restrictions. This is why I switched to everything under smtpd_recipient_restrictions. I guess I assumed that it worked the same both ways. So if we reverse the scenario and put the REJECT first, it's a final decision? If so, and if I've described the situation correctly, why do we have this opposite behavior between whitelisting and blacklisting? If I've not described this correctly, what am I missing? -- Stan
Re: Selective smtpd_helo_restrictions question
Stan Hoeppner put forth on 8/22/2010 7:34 PM: So if we reverse the scenario and put the REJECT first, it's a final decision? If so, and if I've described the situation correctly, why do we have this opposite behavior between whitelisting and blacklisting? If I've not described this correctly, what am I missing? Noel's post answered my question, so ignore my previous message. OK != accept_it_right_now -- Stan
Rewriting Date header for local senders, or something like that.
Hi! I got a curiosity, I have noted that the Date header the mail takes comes from the client computer, so, if my computer have a wrong date, my mail will go out with a wrong date too. I know the server will put its own timestamp when it process the message, but the destination mail client will use the Date header to order messages, and thus, if someone's computer has a date of now-3 days, there is a risk that the mail he/she sends is overseen by the receiver. I also know that there should be a policy to keep all of the company's PCs clock synchronized to a central server: but that's not the case, and there are a few PCs with failing BIOS batteries (which shouldn't happen). I have to ask: is there a way of making postfix rewrite Date header to server's time for authenticated mail? (or at list for a range of IPs), off course, a general header rewrite would not be good, because that would overwrite header for mail coming from the Internet (that would be really bad). I took a quick look at the docs, and found nothing on this matter, nevertheless, if someone can point me to a doc where this is explained, that will be enough for me. What do you think on this? Thanks in advance, sincerely, Ildefonso.
