Re: Possible reasons for lost connection after DATA
Hi Sean, Meanwhile, I've managed to record a tcpdump of such a failed session. What exactly am I looking for there? I remember a possibly similar situation back in 2008... the culprit was a not-fully-up-to-date Cisco ASA firewall that corrupted TCP SACK fields and hence had the remote site send RSET. Anyways on our end the connection seemed to starve, just as you describe it. We detected that by comparing tcpdumps from both affected ends. Of course we had been lucky enough to have that happen with a business partner with competent IT people who we got a hold of, spotted the problem and also temporarily switched the feature off on their side to prove that this actually is the problem. A firmware upgrade on my client's firewall then fixed the issue. With a server hosted somewhere and incoming connections from big clusters, you might not be as lucky as that... best regards, -hannes
Re: Attachment decoder (slightly O/T)
Hi Jeremy,
I was thinking of doing something similar to the above (re-encode
mime attachments) now but I'm not sure what the best way of handling
this is.
I'm using the following setup to modify attachments from a specific
sender only:
/etc/postfix/master.cf:
tiff2pdf unix - n n - - pipe
flags= user=nobody directory=/path/ argv=/path/tiff2pdf.pl
${nexthop} ${sender} ${recipient}
/etc/postfix/tiff2pdf:
example.com FILTER tiff2pdf:
/etc/postfix/main.cf or master.cf:
smtpd_sender_restrictions=hash:/etc/postfix/tiff2pdf
The tiff2pdf.pl file reads the message from stdin:
my $parser = new MIME::Parser;
$msg = $parser-parse(\*STDIN) or die FaxTIFF2PDF: parse failed\n;
and then does its magic iterating through the attachments, deciding what
to do, de- and re-attaching them as needed.
Finally, it uses use IPC::Open2; to issue this command:
$pid = open2(\*CHLD_OUT, \*CHLD_IN, '/usr/sbin/sendmail', '-G', '-i',
'-f', $from, $to);
$msg-print(\*CHLD_IN);
close(\*CHLD_IN);
waitpid( $pid, 0 );
my $child_exit_status = $? 8;
if ($child_exit_status ne 0){ die print Error from sendmail:
$child_exit_status};
This may not be the most elegant way to do this, but it certainly works
very well.
Best regards,
-hannes
Low cost medium-availability backup MX
Folks, I maintain a Postfix/Amavisd/Clamav front-end mail server for a customer with a time-criticial business that heavily relies on email for incoming orders. This MX itself is secured by running on redundant VMware hosts, the internet access lines are redundant, but still the MX may not be available at all times. Sure, a sending MTA would try again a bit later, but I don't have any means to influence the length of the delay and one or two hours could already render the email order useless. I thought of running another MX server at a different location, but I'd like to avoid the hassle configuring recipient verification and spam checking once more -- despite LDAP recipient verification against Exchange is also very hard when the customer's site is completely offline. So I thought I'd plug a policyd into the backup MX that checks if the primary MX is available, and if it is, rejects all mail with a 4xx temporary failure. It the primary is down, it will accept without any recipient or spam checks and queue all mail until the primary recovers. Since the queue on the backup can also be flushed by hand, the average delay should be way shorter than relying on the sending MTAs to retry at their descretion. What do you think? Is there already someone using a setup like this (with which policyd implementation)? Thank you for any insights, best regards -hannes
Re: overidding with my networks. Better way of doing it?
John, you need to properly configure the DNS entries for your systems and/or adapt the smtpd_* restrictions on the receiving system. warning: 71.39.113.15: address not listed for hostname sbs.rtgis.com $ nslookup sbs.rtgis.com Non-authoritative answer: Name: sbs.rtgis.com Address: 66.232.81.14 According to DNS, sbs.rtgis.com should be at 66.232.81.14, but the connect actually is from 71.39.113.15 . Configure that system with the proper hostname or add the 71 address as another A record to that DNS. NOQUEUE: reject: RCPT from unknown[71.39.117.85]: 554 5.7.1 Client host rejed: cannot find your hostname $ nslookup 71.39.117.85 ** server can't find 85.117.39.71.in-addr.arpa.: NXDOMAIN Make sure their reverse entries are publicly available (or, as said above, adapt the smtpd* restrictions). HTH, -hannes
Re: Maildir problem2
Ansgar Wiechers wrote: Well, according to your logfile the mail is delivered to the mailbox. Either you misconfigured the destination of that delivery As a first guess, that is the case. The config file contains home_mailbox = Mailbox while the OP's file structure does look like a Maildir/ . It furthermore seems to me the OP has mixed up the spool and home directory configuration, but I'm not familiar with virtual domain setup (if applicable here?). postconf -n will surely be of help; if there is no virtual domain setup involved, I'd suggest to check the home directory settings for the users mentioned. Does the dovecot setup already work? If yes, it might also be helpful to include that configuration to see what dovecot expects. -hannes
Re: In-queue rejections
Daniel, 5F47320CEC2 4338844 Mon Dec 28 13:12:09 idiotu...@amfes.com (host mail.fireprobymesa.com[65.40.152.138] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) jeff...@fireprobymesa.com Do you have soft_bounce=yes configured? (http://www.postfix.org/postconf.5.html#soft_bounce) That seems to be the reason why postfix isn't immediately bouncing the message to the sender. If you don't have a good reason to keep soft_bounce activated (and you shouldn't on a production machine), try if disabling solves your problem. -hannes
Re: Backscatter being generated from mail aliased to other servers.
Folks, it seems to me that there has been some misunderstanding of Jim's setup and situation. Clearly, you are *NOT* doing recipient verification, or myotherserver.com would not be rejecting it. Never accept mail which cannot be delivered. What he describes is that the final destination - after forward expansion - rejects the forwarded message NOT because of the recipient addresse, but because of its contents or whatever else. The most effective way to conquer that sort of backscatter would be, as Victor pointed out, to avoid forwarding spam. For specific scenarios it might also be possible to set up some sort of before-queue-forwarding and make the MTA an SMTP proxy? -hannes
