how to configure Postfix/DNS to avoid being considered a spammer
Hello, one of our clients wants to offer mass mailing services for his clients. The problem is, that our client wants to send emails with the sender domains of his clients from his own postfix server. As far as I know, some anti spam measure rely on the check, whether the sending e-mailserver is the official MX for this domain. In this case the check will of course fail, causing the emails to be blocked or at least marked as spam. Is it possible to have 2 sending e-mailservers, one for the "normal" smtp traffic and one for the "mass" smtp traffic? Is this just a question of two MX entries in DNS configuration and is there any special to be considered about the postfix configuration? Thanks for any hints & suggestions, Stefan
Re: how to configure Postfix/DNS to avoid being considered a spammer
* Stefan Michael Guenther : > Hello, > > one of our clients wants to offer mass mailing services for his clients. > > The problem is, that our client wants to send emails with the sender domains > of his clients from his own postfix server. 1. Make sure the sending server has matching forward/reverse DNS resolution for the hosts that send. 2. The client must list the sending servers IP in his DNS SPF record. 3. The client must publish a DKIM record in his DNS. The sending server must use the apropriate DKIM signing key. p@rick > As far as I know, some anti spam measure rely on the check, whether the > sending e-mailserver is the official MX for this domain. In this case the > check will of course fail, causing the emails to be blocked or at least > marked as spam. > > Is it possible to have 2 sending e-mailservers, one for the "normal" smtp > traffic and one for the "mass" smtp traffic? Is this just a question of two > MX entries in DNS configuration and is there any special to be considered > about the postfix configuration? > > Thanks for any hints & suggestions, > > Stefan > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Postfix doubling up as SMTP load balancer
Hi, I have an email receiving setup with one Postfix instance mapped to one instance of Amavisd-new (spamassassin, ClamAV), Now to prepare for increasing traffic, I am looking on to scale out strategies of my setup. So with that in mind, is it possible that one instance of Postfix can itself distribute email load on two or more Amavisd-new instances spread over different locations over the network ? In essence can postfix work as an SMTP load balancer ? Thanks in advance Ashish Sharma
Re: how to configure Postfix/DNS to avoid being considered a spammer
Patrick Ben Koetter:
> * Stefan Michael Guenther :
> > Hello,
> >
> > one of our clients wants to offer mass mailing services for his clients.
> >
> > The problem is, that our client wants to send emails with the sender domains
> > of his clients from his own postfix server.
>
> 1. Make sure the sending server has matching forward/reverse DNS resolution
>for the hosts that send.
>
> 2. The client must list the sending servers IP in his DNS SPF record.
>
> 3. The client must publish a DKIM record in his DNS. The sending server must
>use the apropriate DKIM signing key.
I would add one: configure the myhostname parameter such that it
matches the PTR name for the SMTP client IP address. Postfix uses
this name when sending EHLO.
If you are going to send mail on behalf of different customers you
can configure different SMTP client configurations ("transports"
in Postfix parlance) in master.cf each with its unique settings for
smtp_bind_address and smtp_helo_name.
http://www.postfix.org/master.5.html
Then you can use Postfix >=2.7 SMTP server access maps to invoke
actions of the form "FILTER transport-name:" (note final ":") to
choose the SMTP client IP address based on the sender address.
http://www.postfix.org/access.5.html (see "FILTER" action note 3).
Wietse
Re: how to configure Postfix/DNS to avoid being considered a spammer
On 07 Feb 2014, at 01:12 , Stefan Michael Guenther wrote: > The problem is, that our client wants to send emails with the sender domains > of his clients from his own postfix server. There si no legitimate reason to do this. In fact, my servers (and I suspect many servers) block all email from outside that claims to be from our domains. -- 'Good and bad is tricky, she [Esme] said. 'I ain't too certain about where people stand. P'raps what matters is which way you face.'
Re: Postfix doubling up as SMTP load balancer
On Fri, Feb 07, 2014 at 11:24:22AM +, Sharma, Ashish wrote: > In essence can postfix work as an SMTP load balancer ? Yes. Either pre-queue with smtpd_proxy_filter or post-queue with content_filter. In either case the filter host can be a multi-homed SMTP service. With content_filter the target can also be an MX RRset. -- Viktor.
Re: how to configure Postfix/DNS to avoid being considered a spammer
Am 07.02.2014 16:26, schrieb LuKreme: > On 07 Feb 2014, at 01:12 , Stefan Michael Guenther > wrote: > >> The problem is, that our client wants to send emails with the sender domains >> of his clients from his own postfix server. > > There is no legitimate reason to do this. In fact, my servers (and I suspect > many servers) block all email from > outside that claims to be from our domains *there is a GOOD reason* software running on that server directly talking SMTP and not handling connection problems proper which it does not need to, in all that cases you have a local postfix and your application talks to 127.0.0.1 *but* that does not mean you have to deliver the messages directly to the final destination, better said: you should never do so if you are not the responsible server of the sender domain that's why the features below exists to queue messages local and send them out with the smtp server responsible for the sending domain and having proper SPF records that's what i expect from our customers and on the other how i handle any sender which my server is not destination for smtp_sasl_auth_enable = yes smtp_sender_dependent_authentication = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd sender_dependent_relayhost_maps = hash:/etc/postfix/sasl_relay_maps
Re: Postfix doubling up as SMTP load balancer
>I have an email receiving setup with one Postfix instance mapped to one >instance of Amavisd-new (spamassassin, ClamAV), > >Now to prepare for increasing traffic, I am looking on to scale out strategies >of my setup. > >So with that in mind, is it possible that one instance of Postfix can itself >distribute email load on two or more Amavisd-new instances spread over >different locations over the network >? > >In essence can postfix work as an SMTP load balancer ? not load balancer, but (dumb) load distributor via DNS round-robin. My envelope-only-filter mx1 relays to cs.mydomain.net, a domain record set which has 3 IPs, one for each of our content-scanner boxes. I shown several times that DNS round-robin on an internal network like above sends splits the load to target IP +/- 2%. For intelligent load balancing, you could have a looping script that SMTP-connects to each IP in the target record set every minute, to remove a slow-responding IP from the record set with nsupdate, or to add an IP that returns to quick SMTP responding. Above, cs.mydomain.net would have to be defined as a dynamic zone with allow-update from the IP running the monitor script. Len
Does this have side effects?
(I'm sorry if this is a duplicate post. If the earlier one got through I haven't seen it.) Here's what I want to do: When (incoming) mail is addressed to user@hostname.domain I want to change that to: user@domain before I deliver it. in main.cf: recipient_canonical_maps=regexp:/etc/postfix/pfrecipient_canonical [root@davis postfix]# more pfrecipient_canonical /^gl@.*\.arlut\.utexas\.edu$/ g...@arlut.utexas.edu /^a@.*\.arlut\.utexas\.edu$/a...@arlut.utexas.edu /^b@.*\.arlut\.utexas\.edu$/b...@arlut.utexas.edu /^c@.*\.arlut\.utexas\.edu$/c...@arlut.utexas.edu This does what I want it to: it strips out the host part of the address. (Yes, those are trivial test users, a,b,c,gl.) Does this have consequences/side effects that I might not expect? In particular, I have transport_maps = hash:/etc/postfix/pftransport also in main.cf . Transport_maps will still be honored, won't it? I'd test it, but I don't control the other machines in the transport map, and I have a feeling management will frown on me sending test messages to other than myself. Thx, j. -- Jay Scott 512-835-3553g...@arlut.utexas.edu Head of Sun Support, Sr. System Administrator Applied Research Labs, Computer Science Div. S224 University of Texas at Austin
Re: Does this have side effects?
This will do what you're looking for, much easier. in main.cf: mydomain = arlut.utexas.edu # SENDING MAIL # # The myorigin parameter specifies the domain that locally-posted # mail appears to come from. The default is to append $myhostname, # which is fine for small sites. If you run a domain with multiple # machines, you should (1) change this to $mydomain and (2) set up # a domain-wide alias database that aliases each user to # user@that.users.mailhost. # myorigin = $mydomain Best, --Glenn
Re: Problems receiving mail from outlook.com
On Thu, Feb 06, 2014 at 05:37:16PM +, Alan Munday wrote: > My certificate creation process also followed the old way of doing > things. I've updated this to also follow the HowTo. In doing so I > needed to edit two values in the openssl.cnf namely: > > [ CA_default ] > unique_subject = no > > [ usr_cert ] > basicConstraints=CA:TRUE > > I did try CA:FALSE but this was causing outlook.com mail to fail > (and, as Viktor stated, mail from other domains as well). Usually, the CA certificate is created using a different extension section (not "usr_cert"). You then have "CA:FALSE" in "usr_cert", and "CA:TRUE" in the CA extension section. > Just from a technical perspective I'd to understand and resolve > what?s going on. Though I can see it might just be easier to turn > TLS off. You now have working TLS on mx1, so that's fine. As for mx3 its problem is not TLS. Almost certainly any large packets sent by mx3 will run into the same MTU issue. For example, it likely can't send bounces... Try to send a large message from mx3 to the outside world. If that works, but sending a TLS certificate to the client does not, I'll be surprised (a less obvious explanation will be required for the reported symptoms, perhaps hardware problems with the NIC that corrupt some data and not other data, ...). -- Viktor.
Re: how to configure Postfix/DNS to avoid being considered a spammer
On 07 Feb 2014, at 09:16 , li...@rhsoft.net wrote: > Am 07.02.2014 16:26, schrieb LuKreme: >> On 07 Feb 2014, at 01:12 , Stefan Michael Guenther >> wrote: >> >>> The problem is, that our client wants to send emails with the sender >>> domains of his clients from his own postfix server. >> >> There is no legitimate reason to do this. In fact, my servers (and I suspect >> many servers) block all email from >> outside that claims to be from our domains > > *there is a GOOD reason* I understood the original post to be asking to send mail to users with the source domain set to the same domain as the users being sent to. Is that not what was meant? -- I don't believe there's a power in the 'verse can stop Kaylee from bein' cheerful. Sometimes you just wanna duct-tape her mouth and dump her in the hold for a month.
Re: how to configure Postfix/DNS to avoid being considered a spammer
Am 07.02.2014 22:51, schrieb LuKreme: > On 07 Feb 2014, at 09:16 , li...@rhsoft.net wrote: >> Am 07.02.2014 16:26, schrieb LuKreme: >>> On 07 Feb 2014, at 01:12 , Stefan Michael Guenther >>> wrote: >>> The problem is, that our client wants to send emails with the sender domains of his clients from his own postfix server. >>> >>> There is no legitimate reason to do this. In fact, my servers (and I >>> suspect many servers) block all email from >>> outside that claims to be from our domains >> >> *there is a GOOD reason* > > I understood the original post to be asking to send mail to users with the > source domain set to the same domain as the users being sent to > > Is that not what was meant? it is and if you read what i wrote instead of strip it out you see the solution there: sender-dependent-realyhost and authentication because sasl-auth is the key to not block them - in other words: let the postfix server on the otehr end act like any MUA on port 587
Re: Problems receiving mail from outlook.com
Viktor Dukhovni wrote the following on 07/02/14 19:07: On Thu, Feb 06, 2014 at 05:37:16PM +, Alan Munday wrote: >> I did try CA:FALSE but this was causing outlook.com mail to fail >> (and, as Viktor stated, mail from other domains as well). > > Usually, the CA certificate is created using a different extension > section (not "usr_cert"). You then have "CA:FALSE" in "usr_cert", > and "CA:TRUE" in the CA extension section. I'll try this. You now have working TLS on mx1, so that's fine. As for mx3 its problem is not TLS. Almost certainly any large packets sent by mx3 will run into the same MTU issue. For example, it likely can't send bounces... Try to send a large message from mx3 to the outside world. If that works, but sending a TLS certificate to the client does not, I'll be surprised (a less obvious explanation will be required for the reported symptoms, perhaps hardware problems with the NIC that corrupt some data and not other data, ...). I did follow-up with the results of some tcpdumps which showed where the problem was. The ISP suggested taking the MTU down to 1400 and if that did not work to try changing the encapsulation type from PPPoA to PPPoE. Moving to PPoE was the option that worked. That was at about 17:00 and I've not seen any TLS establishment failures since. Thank you. Alan
Re: Problems receiving mail from outlook.com
On Fri, Feb 07, 2014 at 10:40:37PM +, Alan Munday wrote: > > Usually, the CA certificate is created using a different extension > > section (not "usr_cert"). You then have "CA:FALSE" in "usr_cert", > > and "CA:TRUE" in the CA extension section. > > I'll try this. Should not be too hard. In your case, as I suggested upstream, a simple self-signed certificate with no issuing CA is quite sufficient: Assuming a suitable private key in key.pem, a self-signed cert is just one command: openssl req -x509 -sha1 -new -key key.pem -out newcert.pem \ -subj "/CN=$(uname -n)" -days 3650 > The ISP suggested taking the MTU down to 1400 and if that did not > work to try changing the encapsulation type from PPPoA to PPPoE. > Moving to PPoE was the option that worked. > > That was at about 17:00 and I've not seen any TLS establishment > failures since. Indeed, looks like you're done. The below is not self-signed, but nobody cares really. No need to post-pend an issuer CA nobody trusts to the chain. $ openssl s_client -showcerts -starttls smtp \ -connect "mx3.brightheadtechnology.com:25" 2>/dev/null | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -text Certificate: Data: Version: 3 (0x2) Serial Number: aa:a7:18:c2:d0:a6:8d:40 Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, ST=Suffolk, O=Brighthead Technology Limited, OU=Mailserver, CN=mx3.brightheadtechnology.com/emailAddress=postmas...@brightheadtechnology.com Validity Not Before: Feb 7 22:47:21 2014 GMT Not After : Feb 7 22:47:21 2015 GMT Subject: C=GB, ST=Suffolk, O=Brighthead Technology Limited, OU=Mailserver, CN=mx3.brightheadtechnology.com/emailAddress=postmas...@brightheadtechnology.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c0:5c:d0:93:38:64:1c:7a:86:44:df:16:cb:d8: 6a:93:ce:3c:f1:6a:7b:f9:a0:d5:52:ea:27:3f:81: 83:4f:e1:57:49:f1:c3:96:cd:86:08:60:af:aa:26: 58:34:32:91:45:41:b6:b9:09:29:50:17:2c:2b:90: 88:8d:c7:a7:8c:30:8b:ed:3e:03:d1:d6:e9:ac:4e: 57:d8:56:49:3c:50:c8:c1:10:72:ac:83:3d:08:74: 54:2b:69:79:d0:30:73:e4:b7:75:4d:46:6f:d6:09: 53:3d:50:aa:ab:c8:43:b9:be:1d:0e:46:70:09:fb: f3:aa:93:64:1e:63:de:4e:75:70:64:72:d7:23:41: 3d:db:99:75:38:c5:6a:cd:92:73:8d:57:9b:e6:01: e3:66:a3:27:56:67:c7:8b:b8:8f:ca:64:b5:bf:57: 30:d7:04:f8:22:72:b1:26:c9:66:de:1a:65:bf:ac: 6e:c5:06:c9:4d:de:41:10:83:01:2d:49:1b:fc:ad: 8f:d6:87:d1:94:0a:2b:6d:7d:1f:c1:9f:3a:d3:7b: 40:06:a3:f0:94:a1:e8:3f:dd:e7:4b:10:af:51:ef: ae:f2:bb:85:0b:de:42:78:fb:e3:1f:ec:a9:1d:d7: 79:aa:b8:b2:43:5c:50:ea:24:a1:e0:eb:0c:88:69: ba:f3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: EC:13:5F:DC:48:44:72:8C:F1:E1:84:C0:C0:58:46:B9:CF:C8:03:64 X509v3 Authority Key Identifier: keyid:F3:4C:36:F3:3F:B4:3A:8B:12:AF:2B:DE:37:2E:10:55:9A:6A:5C:A6 Signature Algorithm: sha1WithRSAEncryption 83:ff:72:0e:35:98:72:1f:3d:40:73:52:dd:52:c9:bd:40:2f: c8:23:d8:9f:5d:13:95:a9:71:05:09:28:46:1c:4f:77:e5:83: 10:ca:a5:b0:c5:fa:4a:97:5e:e4:bf:2d:c8:60:69:48:ab:0d: f8:6c:9b:58:28:a9:ac:3e:c6:74:e8:3b:af:ce:ee:ab:93:f2: d6:41:15:74:47:ac:2c:00:cf:fd:7e:5e:64:30:57:b6:cd:26: 9c:88:54:6b:2a:9a:66:db:af:27:e9:94:f0:c9:ec:c4:76:e1: 1f:a5:a3:f9:d9:a2:09:58:c1:e9:bb:ec:f2:56:e8:9f:c2:83: 52:63:d9:24:d4:cb:44:46:30:f2:2b:67:5e:22:e6:cb:ee:61: b6:66:07:88:d7:08:ea:df:50:94:6d:a9:4e:d3:09:38:11:33: 84:9c:1f:1c:17:76:bb:62:e8:5d:13:c3:f5:f5:f7:86:29:24: bb:46:48:1a:aa:d3:88:1e:06:d0:43:2c:d6:cb:ac:a3:5a:8c: db:cc:d5:c7:ee:9c:48:c8:96:69:96:49:d6:0e:0b:42:10:df: d4:03:c6:ca:ee:f5:9e:e2:70:a9:c7:4b:5b:30:21:86:8f:fd: 61:ac:54:05:e6:f1:9c:c5:18:05:b9:5f:f6:ed:55:5e:b9:b1: af:c5:5f:21 -BEGIN CERTIFICATE- MIIEbjCCA1agAwIBAgIJAKqnGMLQpo1AMA0GCSqGSIb3DQEBBQUAMIG3MQswCQYD VQQGEwJHQjEQMA4GA1UECAwHU3VmZm9sazEmMCQGA1UECgwdQnJpZ2h0aGVhZCBU ZWNobm9sb2d5IExpbWl0ZWQxEzARBgNVBAsMCk1haWxzZXJ2ZXIxJTAjBgNVBAMM HG14My5icmlnaHRoZWFkdGVjaG5vbG9neS5jb20xMjAwBgkqhkiG9w0BCQEWI3Bv c3RtYXN0ZXJAYnJpZ2h0aGVhZHRlY2hub2xvZ3kuY29tMB4XDTE0MDIwNzIyNDcy MVoXDTE1MDIwNzIyNDcyMVowgbcxCzAJBgNVBAYTAkdCMRAwDgYDVQQIDAdTdWZm b2xrMSYwJAYDVQQKDB1CcmlnaHRoZWFkIFRlY2hub2xvZ3
Re: Problems receiving mail from outlook.com
Viktor Dukhovni wrote the following on 07/02/14 23:13: On Fri, Feb 07, 2014 at 10:40:37PM +, Alan Munday wrote: Should not be too hard. In your case, as I suggested upstream, a simple self-signed certificate with no issuing CA is quite sufficient: Assuming a suitable private key in key.pem, a self-signed cert is just one command: openssl req -x509 -sha1 -new -key key.pem -out newcert.pem \ -subj "/CN=$(uname -n)" -days 3650 Not difficult at all. Indeed, looks like you're done. The below is not self-signed, but nobody cares really. No need to post-pend an issuer CA nobody trusts to the chain. Does this imply that, for users like me, the "Getting started, quick and dirty" section of the Postfix TLS support could be further simplified? Thanks Alan
Re: Postfix doubling up as SMTP load balancer
In $PREVIOUSJOB, we had a number of internet facing SMTP machines, which looked up accounts/mailboxes/transport maps etc from MySQL; all changes were done on a master database on a separate machine, and synced out with MySQL replication to all of the SMTP machines. This way we could take any single machine offline, be it an SMTP server or the master database, and nothing would break. Load balancing was done by a pair of atom-based machines running Linux and Keepalived. I'm not sure the Atoms would have scaled well past 100M of traffic, but if you have more than 100M of SMTP traffic coming in you can likely put in whatever you like for load balancers. The whole setup worked extremely well, almost to the point where it was boring. Just as it should be. On 14-02-07 01:10 PM, Len Conrad wrote: >> I have an email receiving setup with one Postfix instance mapped to one >> instance of Amavisd-new (spamassassin, ClamAV), >> >> Now to prepare for increasing traffic, I am looking on to scale out >> strategies of my setup. >> >> So with that in mind, is it possible that one instance of Postfix can itself >> distribute email load on two or more Amavisd-new instances spread over >> different locations over the network >> ? >> >> In essence can postfix work as an SMTP load balancer ? > not load balancer, but (dumb) load distributor via DNS round-robin. > > My envelope-only-filter mx1 relays to cs.mydomain.net, a domain record set > which has 3 IPs, one for each of our content-scanner boxes. > > I shown several times that DNS round-robin on an internal network like above > sends splits the load to target IP +/- 2%. > > For intelligent load balancing, you could have a looping script that > SMTP-connects to each IP in the target record set every minute, to remove a > slow-responding IP from the record set with nsupdate, or to add an IP that > returns to quick SMTP responding. > > Above, cs.mydomain.net would have to be defined as a dynamic zone with > allow-update from the IP running the monitor script. > > Len > > > > > -- Looking for (employment|contract) work in the Internet industry, preferably working remotely. Building / Supporting the net since 2400 baud was the hot thing. Ask for a resume! ispbuil...@gmail.com
Re: Problems receiving mail from outlook.com
On Fri, Feb 07, 2014 at 11:49:55PM +, Alan Munday wrote:
> >Assuming a suitable private key in key.pem, a self-signed cert is just
> >one command:
> >
> > openssl req -x509 -sha1 -new -key key.pem -out newcert.pem \
> > -subj "/CN=$(uname -n)" -days 3650
> >
>
> Not difficult at all.
>
> >Indeed, looks like you're done. The below is not self-signed, but
> >nobody cares really. No need to post-pend an issuer CA nobody
> >trusts to the chain.
>
> Does this imply that, for users like me, the "Getting started, quick
> and dirty" section of the Postfix TLS support could be further
> simplified?
Yes. I did not write that section. It always looked a bit too
fancy to me. For a complete self-signed key + cert combination:
# cd /etc/postfix
# tmp=$(mktep .tmpcert.XX)
# certfile=certkey-$(date +"%Y-%m-%d.pem")
# umask 077
# openssl req -new -newkey rsa:2048 -keyout /dev/stdout -nodes \
-x509 -sha1 -subj "/CN=$(uname -n)" -days 3650 >> "$tmp" &&
mv "$tmp" "$certfile" &&
postconf -e \
'smtpd_tls_cert_file = ${config_directory}/'"${certfile}" \
'smtpd_tls_key_file = ${smtpd_tls_cert_file}'
Note, you need ">> $tmp" not "> $tmp", because on some platforms
opening /dev/stdout is surprisingly not a dup() operation and the
resulting file descriptor does not share the file offset of the
original stdout. Since the key is written to /dev/stdout and the
cert to the actual stdout, you don't want the latter to overwrite
the former. Opening with O_APPEND (>>) takes care of that.
--
Viktor.
Re: Will this have side effects?
On Thu, 2014-02-06 at 17:24:06 -0600, Jay G. Scott wrote: > recipient_canonical_maps=regexp:/etc/postfix/pfrecipient_canonical > > [root@davis postfix]# more pfrecipient_canonical > /^gl@.*\.arlut\.utexas\.edu$/ g...@arlut.utexas.edu > /^a@.*\.arlut\.utexas\.edu$/a...@arlut.utexas.edu > /^b@.*\.arlut\.utexas\.edu$/b...@arlut.utexas.edu > /^c@.*\.arlut\.utexas\.edu$/c...@arlut.utexas.edu > > Does this have consequences/side effects that I might not expect? > In particular, I have > transport_maps = hash:/etc/postfix/pftransport > > also in main.cf . Transport_maps will still be honored, won't it? Yes, but remember that transport mapping occurs after address rewriting; take care to accordingly specify the lookup keys in your transport table. -- Sahil Tandon
