reject_unknown_helo_hostname
Hi guys, the documentation says: "Reject the request when the HELO or EHLO hostname has no DNS A or MX record" I'm trying to understand the "or" between the "A" and "MX" words - will this test reject the transport when any of those records are missing, or when the propagated HELO/EHLO domain doesn't have any of those records? best, Istvan
Re: Postfix behind NAT -> failover IP -> wrong HELO
On 7/1/20 9:02 PM, Bill Cole wrote: On 1 Jul 2020, at 12:29, Istvan Prosinger wrote: Fix the DNS? All reverse DNS should have an A record pointed back in the DNS zone. This would be a real mess It is quite common for one name to have multiple A (and/or ) records and for more than one PTR record to point to the same name. There is no reason to restrict DNS to a simplistic one-to-one relationship between IPs and hostnames. Having one name resolve to multiple IPs is the most common mechanism used to load-balance email across multiple inbound machines. It is also formally valid to have multiple PTR records for one IP address, although some tools that try to use PTR records will not know how to handle that and a larger fraction of the humans who see it will be confused. It would be a mess. But I won't debate this with you here. best, Istvan
Re: Postfix behind NAT -> failover IP -> wrong HELO
On 7/1/20 12:40 AM, Wietse Venema wrote:
Istvan Prosinger:
On 6/30/20 10:34 PM, Wietse Venema wrote:
Istvan Prosinger:
On 6/30/20 9:49 PM, Wietse Venema wrote:
Istvan Prosinger:
Hi, I hope this letter finds you well,
I have Postfix behind NAT, and added one failover IP to the main router.
I wanted to "get by cheaply" by just doing something like
iptbales -t nat -I POSTROUTING -p tcp --dport 25 -j DNAT --to
on the firewall machine.
So, all well, the only problem is that Postfix in this case has a wrong HELO
compared to the rDNS that I have defined
for the
It does throw a warning that the doesn't resolve to it's hostname,
but I'm not sure if I can define some
kind of helo_host_maps ;) to resolve this.
At this point, I wouldn't mind if someone pinpoints me to the right direction.
Postfix does not compare the HELO command argument with forward or
reverse DNS information.
Antispam engines on the recipient side do
Thanks for clearing uo that 'It does throw a warning' is not
talking about Postfix.
Every MTA behind a NAT should send HELO to external hists using
the name of the outside NAT IP address. Use smtp_helo_name.
This is clear. But my problem is that I do the (pre)nating on the
firewall, I don't change any config for Postfix. To simplify the
question, it's - is it possible to have it use the correct HELO
depending on the outbound IP set on the firewall? I do not change
any relay maps, I just default it to anouther outbound IP on the
firewall.
Firewalls on a moving IP address? What has the world come to.
Assuming that Postfix runs on the firewall, otherwise you will need
to add telepathic vision to Postfix and also set smtp_proxy_address
to avoid "mail loops back to myself" errors.
host1_mynetworks =
output from "postconf mynetworks" with external address 1
bind1_address = 1.2.3.4
bind2_address = 1.2.3.5
smtp_helo_name = ${
{$mynetworks} == {$host1_mynetworks} ?
{$bind1_address} : {$bind2_address}
}
It's really better to execute a command that sets both the
external address AND Postfix settings.
Yeah. Thanks for this. Postfix isn't running on the same machine with
the firewall. I thought that I'll manage to avoid this, but you're
right. I'll just create the script that will walk into the Postfix
machine and change it's setting when I switch the outgoing IP on the
firewall.
Thanks again,
Istvan
Wietse
Re: Postfix behind NAT -> failover IP -> wrong HELO
On 7/1/20 1:20 AM, Bill Cole wrote: On 30 Jun 2020, at 15:40, Istvan Prosinger wrote: Hi, I hope this letter finds you well, I have Postfix behind NAT, and added one failover IP to the main router. I wanted to "get by cheaply" by just doing something like iptbales -t nat -I POSTROUTING -p tcp --dport 25 -j DNAT --to on the firewall machine. So, all well, the only problem is that Postfix in this case has a wrong HELO compared to the rDNS that I have defined for the It does throw a warning that the doesn't resolve to it's hostname, but I'm not sure if I ca n define some kind of helo_host_maps ;) to resolve this. At this point, I wouldn't mind if someone pinpoints me to the right direction. Can't you just fix the DNS? Use a HELO name that resolves to both IPs and give both IPs PTR records that point back to the name you use. Fix the DNS? All reverse DNS should have an A record pointed back in the DNS zone. This would be a real mess best, Istvan
Re: Postfix behind NAT -> failover IP -> wrong HELO
On 6/30/20 10:34 PM, Wietse Venema wrote: Istvan Prosinger: On 6/30/20 9:49 PM, Wietse Venema wrote: Istvan Prosinger: Hi, I hope this letter finds you well, I have Postfix behind NAT, and added one failover IP to the main router. I wanted to "get by cheaply" by just doing something like iptbales -t nat -I POSTROUTING -p tcp --dport 25 -j DNAT --to on the firewall machine. So, all well, the only problem is that Postfix in this case has a wrong HELO compared to the rDNS that I have defined for the It does throw a warning that the doesn't resolve to it's hostname, but I'm not sure if I can define some kind of helo_host_maps ;) to resolve this. At this point, I wouldn't mind if someone pinpoints me to the right direction. Postfix does not compare the HELO command argument with forward or reverse DNS information. Antispam engines on the recipient side do Thanks for clearing uo that 'It does throw a warning' is not talking about Postfix. Every MTA behind a NAT should send HELO to external hists using the name of the outside NAT IP address. Use smtp_helo_name. This is clear. But my problem is that I do the (pre)nating on the firewall, I don't change any config for Postfix. To simplify the question, it's - is it possible to have it use the correct HELO depending on the outbound IP set on the firewall? I do not change any relay maps, I just default it to anouther outbound IP on the firewall. best, Istvan
Re: Postfix behind NAT -> failover IP -> wrong HELO
On 6/30/20 9:49 PM, Wietse Venema wrote: Istvan Prosinger: Hi, I hope this letter finds you well, I have Postfix behind NAT, and added one failover IP to the main router. I wanted to "get by cheaply" by just doing something like iptbales -t nat -I POSTROUTING -p tcp --dport 25 -j DNAT --to on the firewall machine. So, all well, the only problem is that Postfix in this case has a wrong HELO compared to the rDNS that I have defined for the It does throw a warning that the doesn't resolve to it's hostname, but I'm not sure if I can define some kind of helo_host_maps ;) to resolve this. At this point, I wouldn't mind if someone pinpoints me to the right direction. Postfix does not compare the HELO command argument with forward or reverse DNS information. Wietse Antispam engines on the recipient side do best, Istvan
Postfix behind NAT -> failover IP -> wrong HELO
Hi, I hope this letter finds you well, I have Postfix behind NAT, and added one failover IP to the main router. I wanted to "get by cheaply" by just doing something like iptbales -t nat -I POSTROUTING -p tcp --dport 25 -j DNAT --to on the firewall machine. So, all well, the only problem is that Postfix in this case has a wrong HELO compared to the rDNS that I have defined for the It does throw a warning that the doesn't resolve to it's hostname, but I'm not sure if I can define some kind of helo_host_maps ;) to resolve this. At this point, I wouldn't mind if someone pinpoints me to the right direction. Thanks, and all the best, Istvan
Re: smtp servers port
Le me contribute to the list. The mail transport between _two servers_ is always on port 25. 587 is so called submission, it's for communication between client <-> server best, Istvan On 5/29/20 2:16 PM, Matteo Cazzador wrote: Hi, excuse a question, during the comunication between 2 mail servers there is a phase of according about che port to use to comunicate? There is a checking about port 587 or 25 during these comunication? or two servers only use 25 port by default? Sorry for the level of the question I ask you. Thanks
Re: Postfix 20 years ago
On 2017-02-12 19:06, wie...@porcupine.org wrote: Last month it was 20 years ago that I started writing Postfix code. Sorry for the late reply, but here's a Thanks from me too, to you and all the contributors. Best, Istvan
Re: Antispamming with header checks and regexp
On 2017-02-07 10:12, Ralph Corderoy wrote:
Hi Istvan,
Noel Jones wrote:
> Remember that header_checks won't match encoded subjects
We need to see the raw Subject header from the email that failed to
match. It was probably encoded.
$ scan -forma '%{subject}' .
=?UTF-8?B?VGhpcyBpcyBzcGFtLgo=?=
$ scan -forma '%(decode{subject})' .
This is spam.
$ grep -i '^subject:' `mhpath .`
Subject: =?UTF-8?B?VGhpcyBpcyBzcGFtLgo=?=
$
It's to allow non-ASCII characters in the some of the headers, e.g.
Subject.
Thanks for this. It's UTF-8, and indeed, it's encoded.
Now this puts on some limits on how to fight it.
Best,
Istvan
Re: Antispamming with header checks and regexp
On 2017-02-06 23:19, Noel Jones wrote: On 2/6/2017 3:23 PM, Istvan Prosinger wrote: Hi All, and Happy New Year with a little delay :) Comming to spam, header checks are one tool that I use frequently to prevent it. So, amongst all, I have this: if !/^Subject: (.*)[Aa]liexpress/ /^Subject:(.*)% [Oo][Ff][Ff]/ REJECT Go away spammer endif And this worked fine until _today_, when I got one email (and it wasn't from Ali) that had a subject: You’re In Luck | Up to 70% Off As for the regexp, I think this should definitely be a hit, but it got thru. First I thought that something bugged because of the | sign, but no. I've sent several tests from an external account and it's geting thru. I need a 4-eye method - what the heck am I missing here? Best, Istvan Oy, what an awkwardly awkward redundant expression that is up there above. Postfix regular expressions are case-insensitive by default, so the [Aa] nonsense is unnecessary. Encapsulating the wildcards with () This doesn't matter at all. That said, your expression probably mostly works. Ha! That helped a lot. I aleady know that it "mostly works", it just doesn't work in this case. I do respect your work on this list, bit you have completely missed my point. I'm trying to understand what happend, not looking for a "better suggestion". Remember that header_checks won't match encoded subjects, and only one action is allowed per header, so if this header hits any prior rules (such as a WARN, INFO, DUNNO) then it won't be rejected. It didn't hit anything else prior to this rule.
Re: Antispamming with header checks and regexp
On 2017-02-06 22:56, Dominic Raferd wrote: On 6 February 2017 at 21:23, Istvan Prosinger <ist...@prosinger.net> wrote: Hi All, and Happy New Year with a little delay :) Comming to spam, header checks are one tool that I use frequently to prevent it. So, amongst all, I have this: if !/^Subject: (.*)[Aa]liexpress/ /^Subject:(.*)% [Oo][Ff][Ff]/ REJECT Go away spammer endif And this worked fine until _today_, when I got one email (and it wasn't from Ali) that had a subject: You’re In Luck | Up to 70% Off As for the regexp, I think this should definitely be a hit, but it got thru. First I thought that something bugged because of the | sign, but no. I've sent several tests from an external account and it's geting thru. I need a 4-eye method - what the heck am I missing here? Try removing the round brackets... Why?
Antispamming with header checks and regexp
Hi All, and Happy New Year with a little delay :) Comming to spam, header checks are one tool that I use frequently to prevent it. So, amongst all, I have this: if !/^Subject: (.*)[Aa]liexpress/ /^Subject:(.*)% [Oo][Ff][Ff]/ REJECT Go away spammer endif And this worked fine until _today_, when I got one email (and it wasn't from Ali) that had a subject: You’re In Luck | Up to 70% Off As for the regexp, I think this should definitely be a hit, but it got thru. First I thought that something bugged because of the | sign, but no. I've sent several tests from an external account and it's geting thru. I need a 4-eye method - what the heck am I missing here? Best, Istvan
Re: Avoiding spam blacklists
On 2016-12-28 09:36, Alice Wonder wrote: On 12/28/2016 12:28 AM, John Fawcett wrote: On 12/28/2016 08:32 AM, Alice Wonder wrote: Virtual machine for a web application, it is still in testing. reverse DNS is properly set up. Postfix only listens on the local host. Linux firewall drops anything not to port 80, 443, or a custom high number port I use for SSH. This postfix is not an open relay, or a relay for anything on the Internet, it only exists so the web application can send e-mail. SPF for the domain is correctly set up, DKIM for the host is correctly set up, when it sends an e-mail and I inspect it - it passes the rDNS, SPF, and DKIM checks. So far it has only sent e-mails to addresses I control as the web application is still in testing. Yet yesterday the IP address ended up on Spamhaus blacklist. I am 100% confident that no one else was sending e-mail from that IP address, I'm a bit puzzled as to how the IP address got added to the blacklist, but I was told that Spamhaus sometimes just adds an entire subnet if more than one IP on the subnet was sending spam, and that's probably what happened. I think that is irresponsible of Spamhaus if that is what they are doing, but is there something more I can do other than correct rDNS, SPF, and DKIM to avoid getting on a blacklist? if you know which of the spamhaus lists it was you can check out its policy. Each list has its own specific criteria. Also if you were recently assigned the ip the listing may predate your activity. John The IP is relatively new to me, about two months, but it was not on the list before as I use Spamhaus on my other mail servers and mail from it was not being rejected until yesterday. I did go through the manual removal process and that worked, but I'm worried about it happening again. So what dis Spamhaus say? Why is your IP listed? Did you actually mass mail?
Re: Inserting a unique ID into the email header with Postfix alone
On 18.3.2016 15:42, /dev/rob0 wrote: On Fri, Mar 18, 2016 at 09:05:51AM -0500, Noel Jones wrote: On 3/18/2016 6:20 AM, Istvan Prosinger wrote: Hello Everyone! I need to insert something like X-MY-ID-some-unique-ID into each email's header for local tracking purposes. Why a separate header, why not just: enable_long_queue_ids = yes and use the queue ID that's already in your top Received: header? (Legacy note: that option was introduced in the now-EOL Postfix version 2.9. If you're not on 2.10 or later you should be.) I have v3.1 running on that box. A long queue was in my mind all day, but as I need that header in a specific format (I don't have control over that as that part is not my work), I was thinking of copying it, but still digging on that matter. Thanks The unique ID doesn't have to be some complicated hash, it can be something like the + or ... which would be mostly unique. Any ideas if such a thing could be done with just prepending in header checks, without external filtering? You can't do this with postfix alone. You would not need a full external filter, but you could use a policy service or a tcp table, either of which are fairly simple and lightweight. Or you could just use the Message-ID as your mostly-unique identifier.
Re: Inserting a unique ID into the email header with Postfix alone
Thanks Ben. It was a generic example On 18.3.2016 21:14, b...@bitrate.net wrote: On Mar 18, 2016, at 07.20, Istvan Prosinger <ist...@prosinger.net> wrote: Hello Everyone! I need to insert something like X-MY-ID-some-unique-ID into each email's header for local tracking purposes. The unique ID doesn't have to be some complicated hash, it can be something like the + or ... which would be mostly unique. Any ideas if such a thing could be done with just prepending in header checks, without external filtering? others have already answered the question, but as an aside, it's my understanding that rfc 6648 discourages/deprecates use of the "X-" prefix in, among a number of things, email headers. -ben
Inserting a unique ID into the email header with Postfix alone
Hello Everyone! I need to insert something like X-MY-ID-some-unique-ID into each email's header for local tracking purposes. The unique ID doesn't have to be some complicated hash, it can be something like the + or ... which would be mostly unique. Any ideas if such a thing could be done with just prepending in header checks, without external filtering?
Re: Inserting a unique ID into the email header with Postfix alone
On 19.3.2016 15:53, /dev/rob0 wrote: On Sat, Mar 19, 2016 at 03:34:28PM +0100, Istvan Prosinger wrote: I've tried what you ask, this is what I got: [root@email ~]# postmap -h -q - pcre:/etc/postfix/stamp.pcre < testheader Received: from localhost (localhost [127.0.0.1]) by email-test.server.com (Postfix) with ESMTP id 3qRyhf4pqCzKmYs for <ist...@email-test.server.com>; Sat, 19 Mar 2016 06:17:54 -0400 (EDT) Prepend X-DIYL-3qRyhf4pqCzKmYs Received: from knox.prosinger.net (knox.prosinger.net [5.44.101.107]) by email-test.server.com (Postfix) with ESMTPS id 3qRyhf0ChgzKmYq for <ist...@email-test.server.com>; Sat, 19 Mar 2016 06:17:52 -0400 (EDT) Prepend X-DIYL-3qRyhf0ChgzKmYq I think that this means two hits. If so, what comes to my mind is that these headers are not there yet, in the moment when the stamper.pcre is called. You apparently are using a post-queue content filter. If you want the post-filter queue ID as your header, adjust the expression to include "localhost \(localhost \[127\.0\.0\.1\]\)". If you want the pre-filter queue ID as your header, exclude that part from your expression. Note, that's not foolproof, if you happen to have something on localhost sending mail. Perhaps a better idea is: only apply these header_checks before (or after?) the filter. See: postconf.5.html#receive_override_options postconf.5.html#cleanup_service_name Thanks for the effort. At that stage the only intportant thing was to make the pattern the simplest possibble so I can see how it works, I have modified it similar to your suggestion now as it started working. Istvan
Re: Inserting a unique ID into the email header with Postfix alone
On 19.3.2016 16:02, Wietse Venema wrote: Istvan Prosinger: [root@email ~]# postmap -h -q - pcre:/etc/postfix/stamp.pcre < testheader Received: from localhost (localhost [127.0.0.1]) by email-test.server.com (Postfix) with ESMTP id 3qRyhf4pqCzKmYs for <ist...@email-test.server.com>; Sat, 19 Mar 2016 06:17:54 -0400 (EDT) Prepend X-DIYL-3qRyhf4pqCzKmYs Received: from knox.prosinger.net (knox.prosinger.net [5.44.101.107]) by email-test.server.com (Postfix) with ESMTPS id 3qRyhf0ChgzKmYq for <ist...@email-test.server.com>; Sat, 19 Mar 2016 06:17:52 -0400 (EDT) Prepend X-DIYL-3qRyhf0ChgzKmYq I think that this means two hits. Two Received headers match the pattern, each returns a prepend action. If so, what comes to my mind is that these headers are not there yet, in the moment when the stamper.pcre is called. Postfix's own Received: header is prepended by smtpd(8) when receiving mail from the network: Received: from client-info by server-info ... this happens BEFORE the cleanup server does the header_checks matches. Postfix's own Received: header is prepended by pickup(8) with mail from /usr/sbin/sendmail: Received: by server-info ... this happens BEFORE the cleanup server does the header_checks matches. Wietse Ye...but I was not doing header checks, I was calling to it in smtpd_recipient_restrictions It works now. I've modified the pattern to /Received:\sfrom\slocalhost\s\S+\s\S+\s+by\semail-test\.diylettering\.com\s\S+\s\S+\s\S+\s+id\s(\S+)/ Prepend X-DIYL: $1 It does not hit twice now. I had to remove the anchoring at start (as you originally suggested), because for some reason it didn't hit then. Thanks a lot, I owe you another beer
Re: Inserting a unique ID into the email header with Postfix alone
On 19.3.2016 15:13, Wietse Venema wrote: Istvan Prosinger: [ Charset windows-1252 converted... ] On 19.3.2016 1:18, Wietse Venema wrote: Istvan Prosinger: Why a separate header, why not just: enable_long_queue_ids = yes and use the queue ID that's already in your top Received: header? I would use a header_checks PREPEND action that prepends a header with the long queue ID from the Received: header. Sorry, no time to write out a complete example. Thanks. Ok, I was thinking of this, but wasn't sure how to "pass" the (long or not) queue ID (or anything else) in header_checks. Another thought is to copy one that is already there, but not sure how to do it or how far can I go in a "one-liner" /etc/postfix/main.cf: enable_long_queue_ids = yes header_checks = /etc/postfix/stamp.pcre /etc/postfix/stamp.pcre: # Pattern for /usr/sbin/sendmail submission /^Received:\sby\sserver\.example\.com\s\S+\s\S+\s\S+\s+id\s(\S+);/ Prepend X-ID $1.server.example.com # Pattern for SMTP submission /^Received:\sfrom\s\S+\.example\.com\s\S+\s\S+\s+by\sserver\.example\.com\s\S+\s\S+\s\S+\s+id\s(\S+);/ Prepend X-ID $1.server.example.com Wietse Thanks for the ideas. I need to mark the incomming mails for local storage tracking, not submission, so anyway, I ended up with a shorter version /name\.server\.com\s\S+\s\S+\s\S+\s+id\s(\S+)/ Prepend X-DIYL-$1 I recommend starting the pattern with /^Received:.*by name\.server\.com.../ That way it won't have to inspect non-"Received:" headers. And added to smtpd_recipient_restrictions = check_recipient_access pcre:/etc/postfix/stamp.pcre I'm quite sure that I have a match on the queue id, but the Prepend has no effect on the header. What am I missing? Test with: postmap -h pcre:/etc/postfix/stamp.pcre < file where the file contains an email message with Received: headers. Wietse Wietse Thanks, I'll make the pattern search detailed as you suggested. I've tried what you ask, this is what I got: [root@email ~]# postmap -h -q - pcre:/etc/postfix/stamp.pcre < testheader Received: from localhost (localhost [127.0.0.1]) by email-test.server.com (Postfix) with ESMTP id 3qRyhf4pqCzKmYs for <ist...@email-test.server.com>; Sat, 19 Mar 2016 06:17:54 -0400 (EDT) Prepend X-DIYL-3qRyhf4pqCzKmYs Received: from knox.prosinger.net (knox.prosinger.net [5.44.101.107]) by email-test.server.com (Postfix) with ESMTPS id 3qRyhf0ChgzKmYq for <ist...@email-test.server.com>; Sat, 19 Mar 2016 06:17:52 -0400 (EDT) Prepend X-DIYL-3qRyhf0ChgzKmYq I think that this means two hits. If so, what comes to my mind is that these headers are not there yet, in the moment when the stamper.pcre is called.
Re: Inserting a unique ID into the email header with Postfix alone
On 19.3.2016 1:18, Wietse Venema wrote: Istvan Prosinger: Why a separate header, why not just: enable_long_queue_ids = yes and use the queue ID that's already in your top Received: header? I would use a header_checks PREPEND action that prepends a header with the long queue ID from the Received: header. Sorry, no time to write out a complete example. Thanks. Ok, I was thinking of this, but wasn't sure how to "pass" the (long or not) queue ID (or anything else) in header_checks. Another thought is to copy one that is already there, but not sure how to do it or how far can I go in a "one-liner" /etc/postfix/main.cf: enable_long_queue_ids = yes header_checks = /etc/postfix/stamp.pcre /etc/postfix/stamp.pcre: # Pattern for /usr/sbin/sendmail submission /^Received:\sby\sserver\.example\.com\s\S+\s\S+\s\S+\s+id\s(\S+);/ Prepend X-ID $1.server.example.com # Pattern for SMTP submission /^Received:\sfrom\s\S+\.example\.com\s\S+\s\S+\s+by\sserver\.example\.com\s\S+\s\S+\s\S+\s+id\s(\S+);/ Prepend X-ID $1.server.example.com Wietse Thanks for the ideas. I need to mark the incomming mails for local storage tracking, not submission, so anyway, I ended up with a shorter version /name\.server\.com\s\S+\s\S+\s\S+\s+id\s(\S+)/ Prepend X-DIYL-$1 And added to smtpd_recipient_restrictions = check_recipient_access pcre:/etc/postfix/stamp.pcre I'm quite sure that I have a match on the queue id, but the Prepend has no effect on the header. What am I missing?
Re: Inserting a unique ID into the email header with Postfix alone
On 18.3.2016 17:27, Wietse Venema wrote: /dev/rob0: On Fri, Mar 18, 2016 at 09:05:51AM -0500, Noel Jones wrote: On 3/18/2016 6:20 AM, Istvan Prosinger wrote: Hello Everyone! I need to insert something like X-MY-ID-some-unique-ID into each email's header for local tracking purposes. Why a separate header, why not just: enable_long_queue_ids = yes and use the queue ID that's already in your top Received: header? I would use a header_checks PREPEND action that prepends a header with the long queue ID from the Received: header. Sorry, no time to write out a complete example. Wietse Thanks. Ok, I was thinking of this, but wasn't sure how to "pass" the (long or not) queue ID (or anything else) in header_checks. Another thought is to copy one that is already there, but not sure how to do it or how far can I go in a "one-liner". If I'm on a right track, a link to some document would also do, as I've spent some time diging on this and I'm probabbly "googling" the wrong keywords/thoughts No need to write me a code. Regards, Istvan
Re: Puting the Postfix's queue into RAM disk
The problem is tha there is that one VPS and I wanted 2nd opinions about my dirty plan. Thanks On 2015-11-15 19:03, Matthew McGehrin wrote: Is it possible to configure a 2nd VPS instance just for fallback_relay? That way your primary queue is only for deliveries, and your 2nd instance can handle the bounces. I was working for an Online Gaming company and we would deliver 1-2 million messages per day, we had 3 active queues, and 1 delayed queue. On the active queues we would set the fallback_relay to the delayed queue, thus ensuring only active mail was being sent first. Istvan Prosinger wrote: On 13.11.2015 22:53, Phil Stracchino wrote: On 11/13/15 14:17, Istvan Prosinger wrote: I got two options that I know of. Signifficantly shortening the queue lifetime, or (not) losing the queue from the RAM disk. Just trying to measure which is worse (or to hear something new for me) If you lack disk space for the queue, the server instance isn't up to the job in the first place. If you really think that keeping the queue in RAM is a better option than on disk, despite that you probably have far more disk than RAM, consider using a tmpfs instead of a RAMdisk, with the size of the tmpfs capped at the size RAMdisk you were plannind. A RAMdisk will use all of that RAM all of the time, whether needed for queued mail or not. A tmpfs will consume only as much RAM at any given time as it needs right then.
Untrusted TLS connection established headache
Hi, I'm trying to install the signed STARTSSL certificates to Postfix, but I'm getting this entry whatever I do: Nov 17 18:41:39 knox postfix/smtp[32153]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) I'm out of ideas, starting experimenting with certs, and that won't lead me to understanding the problem. Here's the TLS config: [root@knox certs]# postconf -n | grep tls smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem smtp_tls_CApath = /etc/ssl/certs/ smtp_tls_loglevel = 1 smtp_tls_security_level = may smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/prosinger_new_bundle.crt smtpd_tls_key_file = /etc/ssl/certs/prosinger_new.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache smtpd_use_tls = yes BTW, when I do a test with http://checktls.com/ (try ist...@prosinger.net) - I get all "green"/ Best Regards, Istvan
Re: Puting the Postfix's queue into RAM disk
On 13.11.2015 22:53, Phil Stracchino wrote: On 11/13/15 14:17, Istvan Prosinger wrote: I got two options that I know of. Signifficantly shortening the queue lifetime, or (not) losing the queue from the RAM disk. Just trying to measure which is worse (or to hear something new for me) If you lack disk space for the queue, the server instance isn't up to the job in the first place. If you really think that keeping the queue in RAM is a better option than on disk, despite that you probably have far more disk than RAM, consider using a tmpfs instead of a RAMdisk, with the size of the tmpfs capped at the size RAMdisk you were plannind. A RAMdisk will use all of that RAM all of the time, whether needed for queued mail or not. A tmpfs will consume only as much RAM at any given time as it needs right then. Thanks. It's not about a lack of space, puting it that word it's about a lack of an SSD drive. Namely, it's about processing speed.
Puting the Postfix's queue into RAM disk
Hello, I'll have a project to send 300-400k emails a day from a new IP address with one server. This can build up a signifficant mail queue on the server. We have several similar solutions already working but this time the idea is to have me do this on a VPS (no SSD drives involved), h What's your verdict about the idea from the subject? All best, Istvan
Re: Puting the Postfix's queue into RAM disk
I got two options that I know of. Signifficantly shortening the queue lifetime, or (not) losing the queue from the RAM disk. Just trying to measure which is worse (or to hear something new for me) On 13.11.2015 16:17, Phil Stracchino wrote: On 11/13/15 04:44, Istvan Prosinger wrote: Hello, I'll have a project to send 300-400k emails a day from a new IP address with one server. This can build up a signifficant mail queue on the server. We have several similar solutions already working but this time the idea is to have me do this on a VPS (no SSD drives involved), h What's your verdict about the idea from the subject? Let me pose a single question by way of answer: "How much do you care about irretrievably losing undelivered mail?"
Re: Puting the Postfix's queue into RAM disk
Ok. As I mentioned, SSD is not an option on this project. Only RAM or Raid 10 (shared with other VPSes) On 13.11.2015 20:56, Ken Simpson wrote: We deliver tens of millions per server per day using SSD spools... On Fri, Nov 13, 2015 at 11:18 AM Istvan Prosinger <ist...@prosinger.net <mailto:ist...@prosinger.net>> wrote: I got two options that I know of. Signifficantly shortening the queue lifetime, or (not) losing the queue from the RAM disk. Just trying to measure which is worse (or to hear something new for me) On 13.11.2015 16:17, Phil Stracchino wrote: > On 11/13/15 04:44, Istvan Prosinger wrote: >> Hello, >> >> I'll have a project to send 300-400k emails a day from a new IP address >> with one server. This can build up a signifficant mail queue on the >> server. >> We have several similar solutions already working but this time the idea >> is to have me do this on a VPS (no SSD drives involved), h >> >> What's your verdict about the idea from the subject? > > Let me pose a single question by way of answer: > > "How much do you care about irretrievably losing undelivered mail?" > >
Re: Puting the Postfix's queue into RAM disk
On 2015-11-13 12:53, Leonardo Rodrigues wrote: Em 13/11/15 08:09, Patrick Ben Koetter escreveu: * Istvan Prosinger <ist...@prosinger.net>: Hello, I'll have a project to send 300-400k emails a day from a new IP address with one server. This can build up a signifficant mail queue on the server. We have several similar solutions already working but this time the idea is to have me do this on a VPS (no SSD drives involved), h Let's take a look at the numbers and bring them down to something we can handle in our brains: 400.000,00 day 16.666,67 hour 277,78 minute 4,63 second Sending 4,63 msg/sec is something regular hardware can do. There's no technical need to use SSDs or even a tmpfs. That math fails because usually who send that much emails wants them to be delivered as fast as possible, so using the whole 24h account doesnt seem to be the ideal. The point here is that at the start of this, a temporary deferred mail queue will build up signifficantly pushing most of the load on the file system, and the idea is to speed up the queue processing to prevent killing the server (extending the queue size it can process in a time frame) My client wouldn't make a problem to deliver the email after a week but I'm afraid that queue lifetime is out of the question (again, because of the queue size it would build up)
Re: check_policy_service not working - need a 4eye method or..
On 2015-08-06 13:50, Istvan Prosinger wrote: Got it. I have made a small perl script as a service that would only return reject as a policy (that sould have rendered most of the mailing impossibble), and postfix was still mailing happily. Since I have recompiled Postfix from the source, it was out of the question the the process was faulty, so the only option is that Postfix couldn't connect to a local service. It was the firewall. The FORWARD chain was set to drop all, and the rest is history.. Thanks everyone for the extraordinary efforts. @Wietse Regarding this one, is it possibble to implement an error message in the log if it cannot connect to a service, like a policy service in this case? I guess any clue in the maillog would do
Re: check_policy_service not working - need a 4eye method or..
Got it. I have made a small perl script as a service that would only return reject as a policy (that sould have rendered most of the mailing impossibble), and postfix was still mailing happily. Since I have recompiled Postfix from the source, it was out of the question the the process was faulty, so the only option is that Postfix couldn't connect to a local service. It was the firewall. The FORWARD chain was set to drop all, and the rest is history.. Thanks everyone for the extraordinary efforts.
Re: check_policy_service not working - need a 4eye method or..
On 2015-08-03 16:16, Viktor Dukhovni wrote: On Mon, Aug 03, 2015 at 09:48:35AM -0400, Postfix User wrote: On Mon, 03 Aug 2015 14:52:33 +0200, Istvan Prosinger stated: Yeah when I took the server for audit, Postfix was dead and couldn't start -the config file was (and stil is) in mess. Nevertheless, accepting SMTP is not the issue at this moment. The issue is that it seems to be disregarding the policy check. I have even precompiled it from source yesterday, thinking that it might be damaged, but no effect... I assume you have read everything at http://www.postfix.org/DEBUG_README.html#mail Might I suggest you provide output from the postfinger tool. This can be found at http://ftp.wl0.org/SOURCES/postfinger. Also post the output of: ps -o pid,command -p $(pgrep -x master) along with the output of: strings $command | grep /postfix where $command is the full pathname of the master executable reported running by ps. If you can examine the process environment via /proc or by other means, also report the value of the MAIL_CONFIG environment variable of the master process. Here goes: [root@top ~]# ./postfinger postfinger - postfix configuration on Wed Aug 5 02:41:25 MDT 2015 version: 1.30 Warning: postfinger output may show private configuration information, such as ip addresses and/or domain names which you do not want to show to the public. If this is the case it is your responsibility to modify the output to hide this private information. [Remove this warning with the --nowarn option.] --System Parameters-- mail_version = 3.0.2 hostname = top.tesspot.com uname = Linux top.tesspot.com 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux --Packaging information-- looks like this postfix comes from RPM package: postfix-2.10.1-6.el7.x86_64 --main.cf non-default parameters-- alias_maps = hash:/etc/aliases allow_percent_hack = no broken_sasl_auth_clients = yes debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id sleep 5 home_mailbox = Maildir/ inet_protocols = ipv4 mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME mailbox_size_limit = 0 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost, top.tesspot.com myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES sample_directory = /usr/share/doc/postfix-2.10.1/samples sender_bcc_maps = hash:/etc/postfix/bcc sendmail_path = /usr/sbin/sendmail.postfix smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10031 smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10031, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem smtpd_tls_key_file = /etc/postfix/postfix.key.pem smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_protocols = SSLv3, TLSv1 smtpd_use_tls = yes virtual_alias_maps = hash:/etc/postfix/virtual --master.cf-- smtpinetn - n - - smtpd -o smtpd_sasl_auth_enable=yes smtps inetn - n - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING pickupunix n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr unix n - n 300 1 qmgr tlsmgrunix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounceunix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verifyunix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp showq unix n - n - - showq error unix - - n - - error retry unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix
Re: check_policy_service not working - need a 4eye method or..
Yeah when I took the server for audit, Postfix was dead and couldn't start -the config file was (and stil is) in mess. Nevertheless, accepting SMTP is not the issue at this moment. The issue is that it seems to be disregarding the policy check. I have even precompiled it from source yesterday, thinking that it might be damaged, but no effect... On 2015-08-02 23:14, Viktor Dukhovni wrote: On Sun, Aug 02, 2015 at 10:53:35PM +0200, Istvan Prosinger wrote: smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10031 smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10031, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination With the above configuration, either you never accept any SMTP email, master.cf contains an override of smtpd_recipient_restrictions and smtpd_end_of_data_restrictions, or the policy service *is* used, whether you can convince yourself of that or not. smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_protocols = SSLv3, TLSv1 smtpd_use_tls = yes Better: smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_security_level = may
Re: check_policy_service not working - need a 4eye method or..
Hi Viktor, I think I have attached postconf -n at start (at least that was the master plan). Sorry if I missed it Here goes, unaltered [root@top ~]# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases allow_percent_hack = no broken_sasl_auth_clients = yes command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id sleep 5 home_mailbox = Maildir/ html_directory = no inet_interfaces = all inet_protocols = ipv4 mail_owner = postfix mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME mailbox_size_limit = 0 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man meta_directory = /etc/postfix mydestination = $myhostname, localhost.$mydomain, localhost, top.tesspot.com mydomain = tesspot.com myhostname = top.tesspot.com myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES sample_directory = /usr/share/doc/postfix-2.10.1/samples sender_bcc_maps = hash:/etc/postfix/bcc sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop shlib_directory = no smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10031 smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10031, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem smtpd_tls_key_file = /etc/postfix/postfix.key.pem smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_protocols = SSLv3, TLSv1 smtpd_use_tls = yes unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual On 7/31/2015 4:37 PM, Viktor Dukhovni wrote: On Fri, Jul 31, 2015 at 02:28:35PM +0200, Istvan Prosinger wrote: On 2015-07-30 17:23, wie...@porcupine.org wrote: Istvan Prosinger: Hello everyone, I have this im main.cf (I'ts actually an attempt to implement cluebringer/policyd) smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10031, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination You say that's what it is set to, but show no hard evidence. Try: postconf -n | mail -s postconf -n output your-email-address Then forward the body of that email to the list (as untouched as possible, do not rewrap lines, avoid Outlook and HTML, ...).
Re: check_policy_service not working - need a 4eye method or..
Istvan Prosinger: On 2015-07-30 17:23, wie...@porcupine.org wrote: Istvan Prosinger: Hello everyone, I have this im main.cf (I'ts actually an attempt to implement cluebringer/policyd) smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10031, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination For some reason Postfix is ignoring the 1st row (the check_policy_service one) - there's no trace in policyd log that postfix even tried to contact it, while it works fine when I telnet to it. Well maybe policyd is lying. Wietse I don't think so. I've tried to give false parameters here to Postfix that sould produce an error in the maillog, but Postfix is all happy, carrying on... What is the output from: find / -name main.cf Wietse Yeah thoght of that one. [root@top ~]# find / -name main.cf /etc/postfix/main.cf /usr/libexec/postfix/main.cf
Re: check_policy_service not working - need a 4eye method or..
On 2015-07-30 17:23, wie...@porcupine.org wrote: Istvan Prosinger: Hello everyone, I have this im main.cf (I'ts actually an attempt to implement cluebringer/policyd) smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10031, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination For some reason Postfix is ignoring the 1st row (the check_policy_service one) - there's no trace in policyd log that postfix even tried to contact it, while it works fine when I telnet to it. Well maybe policyd is lying. Wietse I don't think so. I've tried to give false parameters here to Postfix that sould produce an error in the maillog, but Postfix is all happy, carrying on...
check_policy_service not working - need a 4eye method or..
Hello everyone, I have this im main.cf (I'ts actually an attempt to implement cluebringer/policyd) smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10031, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination For some reason Postfix is ignoring the 1st row (the check_policy_service one) - there's no trace in policyd log that postfix even tried to contact it, while it works fine when I telnet to it. I must be missing something simple but colorful :) Any help would be appitiated... [root@top log]# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases allow_percent_hack = no broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id sleep 5 home_mailbox = Maildir/ html_directory = no inet_interfaces = all inet_protocols = ipv4 mail_owner = postfix mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME mailbox_size_limit = 0 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost, top.tesspot.com myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES sample_directory = /usr/share/doc/postfix-2.10.1/samples sender_bcc_maps = hash:/etc/postfix/bcc sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10031 smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10031, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem smtpd_tls_key_file = /etc/postfix/postfix.key.pem smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_protocols = SSLv3, TLSv1 smtpd_use_tls = yes unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual [root@top log]# netstat -tanp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 127.0.0.1:10031 0.0.0.0:* LISTEN 16959/perl ...
Re: A simple way to restrict the number of outgoing emails/hour per domain
Wietse, thanks, but let me make it more clear - I'm not trying to limit the number of emails towards the destination domains (like yahoo.com), but from the domains the server is sending from (sender domains). The idea behind this is not a polite delivery policy towards the other servers, but to prevent spam/bulk/etc mailing from the sender domains that I'm hosting On 2015-07-23 12:55, wie...@porcupine.org wrote: Istvan Prosinger: Hi everyone, Can anyone pinpoint me to a simple way to limit the outgoing number of emails in a time frame per domain, without involving policyd and mysql, or any other 3rd party script? http://www.postfix.org/postconf.5.html#transport_destination_rate_delay http://www.postfix.org/transport.5.html /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport one_per_minute_destination_rate_delay = 60 /etc/postfix/transport yahoo.com one_per_minute: /etc/postfix/master.cf: one_per_minute unix - - n - - smtp IMPORTANT NOTE: do not set the per-destination recipient limit to 1. That would rate-limit deliveries by EMAIL ADDRESS instead of DOMAIN. http://www.postfix.org/postconf.5.html#transport_destination_recipient_limit Wietse
A simple way to restrict the number of outgoing emails/hour per domain
Hi everyone, Can anyone pinpoint me to a simple way to limit the outgoing number of emails in a time frame per domain, without involving policyd and mysql, or any other 3rd party script? I'm looking for a simple restriction with a hash table or so. Best Regards, Istvan
Re: Postfix + OpenDKIM - milter reject, come back later
On 2015-07-03 22:14, Steve Jenkins wrote: On Friday, July 3, 2015, Istvan Prosinger ist...@prosinger.net wrote: What I can tell at this moment, is that I tried all that. Although I usually delete the mail queue and then try to send one mail with mailx, same thing happens. Nevertheless, it's not about the start sequence, I'm quite sure of that. This is something very odd. Now I even tried to recompile OpenDKIM from source and the same thing happens with it. Yeah for a start I'll check why there are no OpenDKIM logs. That one is equally odd as refusing miltering. I'm quite sure that there's some permission issue that I'm missing (yes, selinux is disabled...) You referenced SELinux, so I'll assume you're using RHEL or CentOS. If so, just follow these steps: http://www.stevejenkins.com/blog/2011/08/installing-opendkim-rpm-via-yum-with-postfix-or-sendmail-for-rhel-centos-fedora/ [1] SteveJ -- STEVE JENKINS _steve@stevejenkins.com_ [2] [3] [4] [5] [6] [7] [8] Nice tutorial, Steve. Look, I have one too (without ads though!) http://www.prosinger.net/index.php/opendkim-postfix/ Still, it doesn't solve my problem...
Re: Postfix + OpenDKIM - milter reject, come back later
Ok, let's forget this since it's definitely an opendkim problem, not postfix. I connected to it as a unix socket, and it works that way. Still a mistery why TCP won't work, but ok.
Postfix + OpenDKIM - milter reject, come back later
Hi all, I think I just need a four-eye method here, because I simply can't see what am I doing wrong. I've tried to install OpenDKIM milter with Postfix - something that is usually a ruoutine work but I keep getting the same mesage all the time when I try to send a test mail: postfix/cleanup[20494]: 06E7312113A: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try again later; from=r...@tesdns.com to=istvan.prosin...@gmail.com [root@top log]# id opendkim uid=496(opendkim) gid=496(opendkim) groups=496(opendkim),12(mail),90(postdrop),89(postfix) [root@top log]# postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases allow_percent_hack = no broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 home_mailbox = Maildir/ html_directory = no inet_interfaces = all inet_protocols = all mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME mailbox_size_limit = 0 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man milter_default_action = accept milter_protocol = 2 mydestination = $myhostname, localhost.$mydomain, localhost, 209-41-87-189.c7dc.com, $mydomain mydomain = tesdns.com myhostname = top.tesdns.com mynetworks = 127.0.0.0/8 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix non_smtpd_milters = $smtpd_milters readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES sample_directory = /usr/share/doc/postfix-2.6.6/samples sender_bcc_maps = hash:/etc/postfix/bcc sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) smtpd_milters = inet:127.0.0.1:8891 smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual Any hints?
Re: Postfix + OpenDKIM - milter reject, come back later
On 2015-07-03 16:00, Benny Pedersen wrote: Istvan Prosinger skrev den 2015-07-03 14:36: postfix/cleanup[20494]: 06E7312113A: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try again later; from=r...@tesdns.com to=istvan.prosin...@gmail.com means that either opendkim is not started or listning, possible config error in opendkim.conf ? check logs smtpd_milters = inet:127.0.0.1:8891 Any hints? netstat -natpu | grep 8891 Funnily there's nothing else in the logs. Opendkim is alive and listening: tcp0 0 127.0.0.1:8891 0.0.0.0:* LISTEN 21338/opendkim
Re: Postfix + OpenDKIM - milter reject, come back later
On 2015-07-03 16:00, Benny Pedersen wrote: Istvan Prosinger skrev den 2015-07-03 14:36: postfix/cleanup[20494]: 06E7312113A: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try again later; from=r...@tesdns.com to=istvan.prosin...@gmail.com means that either opendkim is not started or listning, possible config error in opendkim.conf ? check logs smtpd_milters = inet:127.0.0.1:8891 Any hints? netstat -natpu | grep 8891 It's odd though that there are no any log entries (it's set to syslog, mail facility) from opendkim, but I even tried to telnet to it, and it seems alive. [root@top etc]# telnet 127.0.0.1 8891 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. ^] telnet quit My initial thought was that it's about Postfix.
Re: Postfix + OpenDKIM - milter reject, come back later
What I can tell at this moment, is that I tried all that. Although I usually delete the mail queue and then try to send one mail with mailx, same thing happens. Nevertheless, it's not about the start sequence, I'm quite sure of that. This is something very odd. Now I even tried to recompile OpenDKIM from source and the same thing happens with it. Yeah for a start I'll check why there are no OpenDKIM logs. That one is equally odd as refusing miltering. I'm quite sure that there's some permission issue that I'm missing (yes, selinux is disabled...) On 7/3/2015 8:27 PM, Benny Pedersen wrote: Istvan Prosinger skrev den 2015-07-03 18:11: My initial thought was that it's about Postfix. can happen if opendkim is started to late ? in that case try to solve that so opendkim is started before postfix for the mails in mailq, try postsuper -r ALL postfix reload did this resend mails in mailq to opendkim without any problem ? no logs ?, check syslog config
Re: postscreen vs. fail2ban
Hi Wietse, One benefit of using fail2ban (for me) is a definitely cleaner mail log for these cases. Regards, Istvan On 12.3.2015 2:30, Wietse Venema wrote: Michael Fox: I haven't implemented postscreen yet, but plan to. So this question is for the postscreen experts here. As I understand it from the documentation, postscreen protects postfix from having to deal with most attack vectors, including higher volume attacks. So, does it make sense to also use something like fail2ban to block IPs that postscreen (or postfix) logs repeatedly as offenders? Or is postscreen sufficient to protect posfix? I would not bother, except in extreme cases where the same IP address makes thousands and thousands of connections. Wietse
Re: Would Postfix accept decimal values in main.cf?
Thanks. I was thinking in general. On 01/29/2015 05:34 PM, Noel Jones wrote: On 1/29/2015 10:24 AM, Istvan Prosinger wrote: Hello, As in the subject. Something like, maximal_queue_lifetime = 0.5d This was the first parameter that came to my mind, for example (don't look for sense). I was wondering if Postfix would accept vaules like this. Regards, Istvan No. Only whole numbers in the range given in the docs. In the case of maximal_queue_lifetime, the unit can also be specified with h m or s, so 2.5 days could be specified as 60h Is there some specific value you need to adjust, or you just fishing? -- Noel Jones
Would Postfix accept decimal values in main.cf?
Hello, As in the subject. Something like, maximal_queue_lifetime = 0.5d This was the first parameter that came to my mind, for example (don't look for sense). I was wondering if Postfix would accept vaules like this. Regards, Istvan
Re: E-mail Log Search Engine v0.9.18 released
Oh nice! Will take a look asap On 26.1.2015 22:26, Nicolas HAHN wrote: Hello there,* *I've released *version 0.9.18 of the ELSE *as a tar.gz archive on Sourceforge: https://sourceforge.net/projects/x-itools/files/X-Itools%20releases/E-mail%20Log%20Search%20Engine/ https://sourceforge.net/projects/x-itools/files/X-Itools%20releases/E-mail%20Log%20Search%20Engine As well as an updated Virtual Machine based on CentOS 7, made for demo purpose. Availability of documentations for v0.9.18 is currently an ongoing process, but some is already available in the Sourceforge Wiki pages of this project, there: http://sourceforge.net/p/x-itools/wiki/ http://sourceforge.net/p/x-itools/wiki/Documentation%20for%20Users For this release, the biggest feature I've tried to implement is the *RTAAM* engine. If I had to define it, I would give 3 definitions: - *an E-mail flow threats detection and prevention system*, or - *an E-mail Firewall solution*, or - *a mix of Postfix/Anvil, Fail2ban, Firewall, Monitoring, Reporting* Enjoy :) -- Nicolas
Re: New year
Happy New Year all! On 31.12.2014 11:45, John wrote: Here is wishing you all a very happy and prosperous new year.
Postscreen - 450 4.3.2 forever
Hello all, I'm trying to send a test mail to my postscreened server, and postscreen should naturally rejct it for the first time. My problem is that it seems to be rejecting the mail forever even if it's comming from the same IP adress Dec 29 17:22:09 vs3163 postfix/postscreen[10262]: CONNECT from [65.55.34.27]:53020 to [89.22.98.122]:25 Dec 29 17:22:09 vs3163 postfix/postscreen[10262]: WHITELIST VETO [65.55.34.27]:53020 Dec 29 17:22:16 vs3163 postfix/tlsproxy[11833]: CONNECT from [65.55.34.27]:53020 Dec 29 17:22:17 vs3163 postfix/postscreen[10262]: NOQUEUE: reject: RCPT from [65.55.34.27]:53020: 450 4.3.2 Service currently unavailable; from=pi...@live.com, to=ist...@prosinger.net, proto=ESMTP, helo=COL004-OMC1S17.hotmail.com Dec 29 17:22:17 vs3163 postfix/postscreen[10262]: DISCONNECT [65.55.34.27]:53020 Dec 29 17:22:17 vs3163 postfix/tlsproxy[11833]: DISCONNECT [65.55.34.27]:53020 Here's my postscreen config: postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr postscreen_blacklist_action = drop postscreen_dnsbl_action = enforce postscreen_dnsbl_reply_map = pcre:$config_directory/postscreen_dnsbl_reply_map.pcre postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1 postscreen_dnsbl_threshold = 2 postscreen_greet_action = enforce postscreen_whitelist_interfaces = 127.0.0.1/32 # postscreen_bare_newline_action = enforce postscreen_bare_newline_enable = yes postscreen_non_smtp_command_enable = yes postscreen_pipelining_enable = yes I'm obviously missing something here. postscreen_cache_map = btree:$data_directory/postscreen_cache - the file is really there, and it seems to be working... Regards to all, Istvan
Re: Postscreen - 450 4.3.2 forever
Uf, indeed!! I almost looked letter-by-letter into the config and didn't notice that I removed the part for static IPs. Four eyes see more as my menthor would say back in the old days Thanks! On 2014-12-29 17:37, li...@rhsoft.net wrote: Am 29.12.2014 um 17:25 schrieb Istvan Prosinger: I'm trying to send a test mail to my postscreened server, and postscreen should naturally rejct it for the first time. My problem is that it seems to be rejecting the mail forever even if it's comming from the same IP adress Dec 29 17:22:09 vs3163 postfix/postscreen[10262]: CONNECT from [65.55.34.27]:53020 to [89.22.98.122]:25 Dec 29 17:22:09 vs3163 postfix/postscreen[10262]: WHITELIST VETO [65.55.34.27]:53020 Dec 29 17:22:16 vs3163 postfix/tlsproxy[11833]: CONNECT from [65.55.34.27]:53020 Dec 29 17:22:17 vs3163 postfix/postscreen[10262]: NOQUEUE: reject: RCPT from [65.55.34.27]:53020: 450 4.3.2 Service currently unavailable; from=pi...@live.com, to=ist...@prosinger.net, proto=ESMTP, helo=COL004-OMC1S17.hotmail.com Dec 29 17:22:17 vs3163 postfix/postscreen[10262]: DISCONNECT [65.55.34.27]:53020 Dec 29 17:22:17 vs3163 postfix/tlsproxy[11833]: DISCONNECT [65.55.34.27]:53020 look at your config postscreen_whitelist_interfaces = 127.0.0.1/32 you *explicitly* configured that behavior if the client is not localhost read again the docs of that parameter, a usage-sample below to have a backup-MX on the same machine which *always* answers 450 to kill zombies trying the backup-MX instead the primary postscreen_whitelist_interfaces = !ip-of-honeypot-mx, static:all
A transport maps dilema
Hello, Is it possibble to make Postfix relay to some specific domain using a specific relay, and relay all the other domains by default rules (put the mail to an inbox if local or relay outbound by the given restrictions etc)? I guess it'd involve a transport_maps pointer in the main.cf to a specific (let's say) hash table which will contain something like: myspecialdomain.tld.com relay:[myspecialrelay:port] * relay:[what_do_i_put_here?] If I'd relay * to my own smtp, I guess it would create an endless loop, and this is where my dilema starts.
Re: A transport maps dilema
Works like a charm, thank you all!! On 21.12.2014 14:42, Jose Borges Ferreira wrote: You allmost got it. Transport_map is used to override the default transport and the ones you don't want to override just left out. Just take the * and that should work as you intended. José Borges Ferreira On Dec 21, 2014 12:55 PM, Istvan Prosinger ist...@prosinger.net mailto:ist...@prosinger.net wrote: Hello, Is it possibble to make Postfix relay to some specific domain using a specific relay, and relay all the other domains by default rules (put the mail to an inbox if local or relay outbound by the given restrictions etc)? I guess it'd involve a transport_maps pointer in the main.cf http://main.cf to a specific (let's say) hash table which will contain something like: myspecialdomain.tld.com http://myspecialdomain.tld.com relay:[myspecialrelay:port] * relay:[what_do_i_put_here?] If I'd relay * to my own smtp, I guess it would create an endless loop, and this is where my dilema starts.
Re: A transport maps dilema
On 21.12.2014 18:21, Viktor Dukhovni wrote: On Sun, Dec 21, 2014 at 08:57:52AM -0500, Wietse Venema wrote: Istvan Prosinger: Hello, Is it possibble to make Postfix relay to some specific domain using a specific relay, and relay all the other domains by default rules (put the mail to an inbox if local or relay outbound by the given restrictions etc)? I guess it'd involve a transport_maps pointer in the main.cf to a specific (let's say) hash table which will contain something like: myspecialdomain.tld.com relay:[myspecialrelay:port] And use main.cf:relayhost for the rest. And use the documented syntax: relay:[smtp.example.net]:25 relay:[smtp.example.net]:smtp Indeed! It was a typo, thanks!
Re: Preventing Postfix queue from being filled
ah got it (always late). Maximal and bounce queue liftemes. On 2014-12-20 09:16, Istvan Prosinger wrote: Dear friends, Sometimes I have similar issues in the que: (connect to hotel-patrizietta.ch[185.53.177.20]:25: Connection timed out) i...@hotel-patrizietta.ch etc, etc, etc. As far as I can tell, Postfix would keep on trying to send these mails for some time. Is there a way to limit this time or the number of attempts? Regards, Istvan
Postfix relaying non authenticated virtual user's mails in local
test testovich
