Re: warning: hostname does not resolve to address
> On Oct 2, 2019, at 6:34 PM, Christian Göttsche wrote: > > Hi, > I am getting several warning a day of the form > >postfix/smtpd[6969]: warning: hostname domain does not resolve to address > ip >postfix/smtpd[10614]: warning: hostname domain does not resolve to > address ip: Name or service not known > > My question is, why are these logged with syslog priority warning/4? Ewhn I asked almost this exact question in August, I got the following from Wietse: @lbutlr: > Are logs like the following really worthy of a warning log level? Yes, because they can result in an irreversible action: if Postfix replies with 5XX then the client will not retry the delivery attempt. -- NOTHING IS FINAL. NOTHING IS ABSOLUTE. EXCEPT ME, OF COURSE. SUCH TINKERING WITH DESTINY COULD MEAN THE DOWNFALL OF THE WORLD. THERE MUST BE A CHANCE, HOWEVER SMALL. THE LAWYERS OF FATE DEMAND A LOOPHOLE IN EVERY PROPHECY. —Sourcery
warning: hostname does not resolve to address
Hi, I am getting several warning a day of the form postfix/smtpd[6969]: warning: hostname domain does not resolve to address ip postfix/smtpd[10614]: warning: hostname domain does not resolve to address ip: Name or service not known My question is, why are these logged with syslog priority warning/4? Deriving from http://postfix.1071664.n5.nabble.com/Warning-host-name-does-not-resolve-tp84988p84989.html they are mostly for explaining the hostname string unknown in the logs. So from my view they have no importance by themselves. I mainly ask because it clutters loganalysis, e.g. journalctl -p4. Regards, Christian Göttsche
RE: outbound.protection.outlook.com
Hi, not sure if this helps but, these are the networks that my postfix server is setup to send email to O365 so users get their mail delivered # Microsoft Networks 23.103.132.0/22 23.103.136.0/21 23.103.144.0/20 23.103.198.0/23 23.103.200.0/22 23.103.212.0/22 40.92.0.0/14 40.107.0.0/17 40.107.128.0/18 52.100.0.0/14 65.55.88.0/24 65.55.169.0/24 94.245.120.64/26 104.47.0.0/17 157.55.234.0/24 157.56.110.0/23 157.56.112.0/24 207.46.100.0/24 207.46.163.0/24 213.199.154.0/24 213.199.180.128/26 216.32.180.0/23 You may need to lock things down more than me but this is the list that works for me. -ANGELO FAZZINA ang...@uconn.edu University of Connecticut, ITS, SSG, Server Systems 860-486-9075 -Original Message- From: owner-postfix-us...@postfix.org On Behalf Of Stuart Henderson Sent: Wednesday, October 2, 2019 11:04 AM To: postfix-users@postfix.org Subject: Re: outbound.protection.outlook.com On 2019/10/02 16:13, Henrik K wrote: > On Wed, Oct 02, 2019 at 02:50:23PM +0200, ratatouille wrote: > > Henrik K schrieb am 02.10.19 um 15:46:18 Uhr: > > > > > On Wed, Oct 02, 2019 at 02:20:48PM +0200, Matus UHLAR - fantomas wrote: > > > > > > > > I got rid of it, since of too many false positives related to outlook, > > > > gmail > > > > etc. > > > > > > Why would you greylist something that's easily skipped using DNSWL etc? > > > > Thank you! I'll look for that stuff. > > Just use permit_dnswl_client before your postgrey > > permit_dnswl_client list.dnswl.org > check_policy_service inet:127.0.0.1:12345 > > These should be pretty much last lines in your checks, remember that is > accepts the message at that stage when listed. > > Of course you can also create manual whitelist lookup tables. > dnswl doesn't have a good list of Microsoft servers, less than half of their deliveries to me today came from servers listed on dnswl. I make my own list from their SPF records to exempt them from greylist-type checks. Examples of some currently used that aren't on dnswl: 104.47.0.33 104.47.4.33 104.47.9.33 104.47.9.36 104.47.12.33 104.47.13.33 104.47.46.33 104.47.58.33 104.47.125.33 104.47.126.33
Re: outbound.protection.outlook.com
On 2019/10/02 16:13, Henrik K wrote: > On Wed, Oct 02, 2019 at 02:50:23PM +0200, ratatouille wrote: > > Henrik K schrieb am 02.10.19 um 15:46:18 Uhr: > > > > > On Wed, Oct 02, 2019 at 02:20:48PM +0200, Matus UHLAR - fantomas wrote: > > > > > > > > I got rid of it, since of too many false positives related to outlook, > > > > gmail > > > > etc. > > > > > > Why would you greylist something that's easily skipped using DNSWL etc? > > > > Thank you! I'll look for that stuff. > > Just use permit_dnswl_client before your postgrey > > permit_dnswl_client list.dnswl.org > check_policy_service inet:127.0.0.1:12345 > > These should be pretty much last lines in your checks, remember that is > accepts the message at that stage when listed. > > Of course you can also create manual whitelist lookup tables. > dnswl doesn't have a good list of Microsoft servers, less than half of their deliveries to me today came from servers listed on dnswl. I make my own list from their SPF records to exempt them from greylist-type checks. Examples of some currently used that aren't on dnswl: 104.47.0.33 104.47.4.33 104.47.9.33 104.47.9.36 104.47.12.33 104.47.13.33 104.47.46.33 104.47.58.33 104.47.125.33 104.47.126.33
Re: outbound.protection.outlook.com
Dnia 2.10.2019 o godz. 11:05:31 ratatouille pisze: > > Do I really have to whitelist all the IPs of outbound.protection.outlook.com > in postgrey? I just put the domain name outbound.protection.outlook.com into /etc/postgrey/whitelist_clients.local and it works for me. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: outbound.protection.outlook.com
* ratatouille : > Hello! > > Do I really have to whitelist all the IPs of outbound.protection.outlook.com > in postgrey? Yes. There's a script for that: # Postwhite - Automatic Postcreen Whitelist / Blacklist Generator # # https://github.com/stevejenkins/postwhite # # By Steve Jenkins (https://www.stevejenkins.com/)# -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: outbound.protection.outlook.com
On Wed, Oct 02, 2019 at 02:50:23PM +0200, ratatouille wrote: > Henrik K schrieb am 02.10.19 um 15:46:18 Uhr: > > > On Wed, Oct 02, 2019 at 02:20:48PM +0200, Matus UHLAR - fantomas wrote: > > > > > > I got rid of it, since of too many false positives related to outlook, > > > gmail > > > etc. > > > > Why would you greylist something that's easily skipped using DNSWL etc? > > Thank you! I'll look for that stuff. Just use permit_dnswl_client before your postgrey permit_dnswl_client list.dnswl.org check_policy_service inet:127.0.0.1:12345 These should be pretty much last lines in your checks, remember that is accepts the message at that stage when listed. Of course you can also create manual whitelist lookup tables.
Re: outbound.protection.outlook.com
Henrik K schrieb am 02.10.19 um 15:46:18 Uhr: > On Wed, Oct 02, 2019 at 02:20:48PM +0200, Matus UHLAR - fantomas wrote: > > > > I got rid of it, since of too many false positives related to outlook, gmail > > etc. > > Why would you greylist something that's easily skipped using DNSWL etc? Thank you! I'll look for that stuff. Andreas
Re: outbound.protection.outlook.com
On Wed, Oct 02, 2019 at 02:20:48PM +0200, Matus UHLAR - fantomas wrote: > > I got rid of it, since of too many false positives related to outlook, gmail > etc. Why would you greylist something that's easily skipped using DNSWL etc?
Re: outbound.protection.outlook.com
On 2019-10-02 ratatouille wrote: > Do I really have to whitelist all the IPs of > outbound.protection.outlook.com in postgrey? Ansgar Wiechers schrieb am 02.10.19 um 11:56:56 Uhr: No. You could simply stop graylisting and instead use spam protection measures without its side effects (e.g. postscreen). On 02.10.19 14:12, ratatouille wrote: I use both, postscreen and postgrey. with postscreen, postgrey is in fact obsolete. I got rid of it, since of too many false positives related to outlook, gmail etc. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I don't have lysdexia. The Dog wouldn't allow that.
Re: outbound.protection.outlook.com
Ansgar Wiechers schrieb am 02.10.19 um 11:56:56 Uhr: > On 2019-10-02 ratatouille wrote: > > Do I really have to whitelist all the IPs of > > outbound.protection.outlook.com in postgrey? > > No. You could simply stop graylisting and instead use spam protection > measures without its side effects (e.g. postscreen). I use both, postscreen and postgrey. Andreas
Re: outbound.protection.outlook.com
On 2019-10-02 ratatouille wrote: > Do I really have to whitelist all the IPs of > outbound.protection.outlook.com in postgrey? No. You could simply stop graylisting and instead use spam protection measures without its side effects (e.g. postscreen). Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
outbound.protection.outlook.com
Hello! Do I really have to whitelist all the IPs of outbound.protection.outlook.com in postgrey? Oct 2 10:57:28 bitclusive1 postfix/smtpd[20061]: NOQUEUE: reject: RCPT from mail-eopbgr680083.outbound.protection.outlook.com[40.107.68.83]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds; from= to= proto=ESMTP helo= Kind regards Andreas
Re: Postfix as backup MX
Thanks Peter for the detailed information. Given that I run this mail server just for my family and in light of your advice, I probably don't need the backup. Thanks, Leo On 23/9/19 5:49 pm, Peter wrote: On 23/09/19 1:24 PM, subscription1 wrote: I've been running my own Postfix (Dovecot, MySQL, Rspamd) server thanks to these instructions (https://thomas-leister.de/en/mailserver-debian-stretch/ ) for more than a year without any issues. I'm using a paid service (Mail Reflector) to handle the times my server is down or (initially) to get the my mail server up and running. I'd like set up another server as a backup and while there are some "How To" out there, they seem to be 'ignoring' spam and/or security issues. Could I just use the same approach I used when setting up my current server with the exception of the following: 1. No virtual mailboxes on the backup 2. with an empty smtp_recipients_maps 3. with relay_domains = $mydestination mydomain.com This is asking for trouble. Spammers target backup MXes because they typically have fewer anti-spam protections than the primary MXes. In this particular case you are accepting mail to literally anyone and when you attempt to forward mail on to your primary for a user that does not exist you will end up creating a bounce message. If the envelope sender is spoofed (and it typically is in SPAM) then your backup MX becomes a source of backscatter and exacerbates the SPAM problem greatly. If your backup MX doesn't have as good anti-spam protections as your primary, or even if they are different in any way then you end up giving spammers an easy target to bypass your best anti-spam protections. Backup MXes are a relic from times past when servers were often times on dialup connections and hence not available 24/7. Today they typically cause more problems than they solve. Submission servers should (and typically will) retry messages for up to five days if your server is offline, and so backup MXes are rarely needed. If you think you need a backup MX then rethink. If you absolutely must have a backup MX then you should follow these guidelines: * Make sure your backup MX has exactly the same anti-spam protections as your primary MX. * Keep an up to date list of valid recipients and *reject* mail to any invalid recipient on the backup MX. * If your primary MX enforces quotas of any type then you should attempt to enforce those same quotas on the backup MX. * Don't use 3rd-party services for backup MX, they will rarely, if ever, be able to copy your exact anti-spam protections and restrictions. * If you really need a high availability environment for your mail consider a 2nd primary with the same priority instead of a backup. It will serve the same purpose as a backup with the additional benenfit that it won't be sitting idle most of the time but actually be handling part of the load all of the time. All of this said, you very likely don't need a backup MX and without a lot of planning, effort and thought it can actually make things much worse for you than if you didn't have one at all, plus the benefits of having a backup MX are almost non-existent nowadays. In short, just don't do it. Peter
Re: Sending mail to Gmail users via Gmail server?
On 2019-09-29, Jaroslaw Rafa wrote: > The only thing I can't do is I cannot completely avoid > forwarding mail to Gmail accounts, because there are some addresses on my > server that need to be kept as forwarding addresses after people moved to > Gmail; but as I see from server logs, very small number of messages is > coming to these addresses and gets forwarded to Gmail. This *will* cause you problems - you'll be forwarding them mail that results in dmarc failures, and quite likely also the occasional spam email, tarnishing your IP reputation. Have those users configure gmail to pull the mail via POP3 instead, it is the only safe way to do this.
