Re: Trouble with STARTTLS...Connection lost
>> smtpd_tls_exclude_ciphers=MD5,SRP,PSK,aDSS,kECDH,kDH,SEED,IDEA,RC2,RC5,RC4,3DES >> smtpd_tls_mandatory_exclude_ciphers=aNULL > >Mostly harmless, but not necessary. On Fri, Jan 29, 2021 at 06:53:09PM +0100, Matus UHLAR - fantomas wrote: yes, but when the policy is encryption required for client-server connections, aNULL would break that IIUC - please correct me if I'm wrong On 29.01.21 15:09, Viktor Dukhovni wrote: You're wrong. The "a" in aNULL ciphers stands for "authentication". These ciphers just do anonymous Diffie-Hellman, but do not authenticate either party. They encrypt the traffic just as well as the ciphers that present certificates that you ignore anyway. so, the connection/encryption would work, but with aNULL will be unauthenticated, which means certificates won't be checked? -- 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. Micro random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
Re: batching all mails to one or more domains to a non-permanently-powered machine with dynamic addresses
Dnia 29.01.2021 o godz. 19:29:14 Matus UHLAR - fantomas pisze: yes, but OTOH I'm not sure if fetchmail or getmail support single mail for multiple recipients. On 29.01.21 22:24, Jaroslaw Rafa wrote: From fetchmail website: "Fetchmail can be used as a POP/IMAP-to-SMTP gateway for an entire DNS domain, collecting mail from a single drop box on an ISP and SMTP-forwarding it based on header addresses. (We don't really recommend this, though, as it may lose important envelope-header information. ETRN or a UUCP connection is better.)" from single drop box does not necessarily mean it supports mail to multiple recipients (To: and Cc: not counted because of above). it can parse X-Original-To: header but I'm not sure whether it can send mail to multiple recipients if there are multiple headers or mmultiple recipients. -- 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. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
Re: batching all mails to one or more domains to a non-permanently-powered machine with dynamic addresses
On 30/01/2021 18:53, Matus UHLAR - fantomas wrote: >> Dnia 29.01.2021 o godz. 19:29:14 Matus UHLAR - fantomas pisze: >>> yes, but OTOH I'm not sure if fetchmail or getmail support single >>> mail for >>> multiple recipients. > > On 29.01.21 22:24, Jaroslaw Rafa wrote: >>> From fetchmail website: >> "Fetchmail can be used as a POP/IMAP-to-SMTP gateway for an entire DNS >> domain, collecting mail from a single drop box on an ISP and >> SMTP-forwarding >> it based on header addresses. (We don't really recommend this, >> though, as it >> may lose important envelope-header information. ETRN or a UUCP >> connection is >> better.)" > > from single drop box does not necessarily mean it supports mail to > multiple > recipients (To: and Cc: not counted because of above). > > it can parse X-Original-To: header but I'm not sure whether it can > send mail > to multiple recipients if there are multiple headers or mmultiple > recipients. The mailbox my ISP provides me with has a number of aliases associated with it. Fetchmail is able to establish which of these aliases an email was sent to and is able to deliver it to different local mail accounts. Here is an obfuscated extract from my fetchmailrc file: user "mainaccountn...@isp.example.com" to "localaccount1" "ali...@isp.example.com"="localaccount1" "ali...@isp.example.com"="localaccount2" "ali...@isp.example.com"="localaccount1" "ali...@isp.example.com"="localaccount1" "ali...@isp.example.com"="localaccount3" "ali...@isp.example.com"="localaccount1" HTH, Jan
Re: rejecting 'fancy' TLDs, allowing a specified one ?
On 12/18/20 8:38 AM, @lbutlr wrote: > On 16 Dec 2020, at 04:14, Dominic Raferd wrote: >> /etc/postfix/reject_domains: >> >> /@abcd\.biz$/ DUNNO >> /\.bid$/ REJECT We reject all .bid domains >> /\.biz$/ REJECT We reject all .biz domains > > I do this: > > /.*automators\.fm$/ DUNNO > /.*counter\.social/ DUNNO > /.*ometria.email/ DUNNO > /.*\.(com|net|org|edu|gov|ca|mx|de|dk|fi|fr|uk|us|tv|info|eu|es|il|it|nl|name|jp|host|au|nz|ch|tv)$/ > DUNNO > /.*\.*$/ 550 Mail to or from this TLD is not allowed > > Fourth line passes all the "good" TLDs that I accept mail from, based on my > server's mail. The first three accept specific domains. The last tells > everyone else to go away, and why. Revisiting this ... where exactly do you apply this ruleset? I'm looking at implementing a rule to discard all four-letter-and-above TLDs except whitelisted ones, because I'm tired of playing whack-a-mole. Are you using header_checks rule, or something else? -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: Trouble with STARTTLS...Connection lost
On Sat, Jan 30, 2021 at 06:49:42PM +0100, Matus UHLAR - fantomas wrote: > >On Fri, Jan 29, 2021 at 06:53:09PM +0100, Matus UHLAR - fantomas wrote: > >> yes, but when the policy is encryption required for client-server > >> connections, aNULL would break that IIUC > >> - please correct me if I'm wrong > > On 29.01.21 15:09, Viktor Dukhovni wrote: > >You're wrong. The "a" in aNULL ciphers stands for "authentication". > >These ciphers just do anonymous Diffie-Hellman, but do not authenticate > >either party. They encrypt the traffic just as well as the ciphers > >that present certificates that you ignore anyway. > > so, the connection/encryption would work, but with aNULL will be > unauthenticated, which means certificates won't be checked? No, with aNULL certificates are not even *sent* (exchanged between client and server). With opportunistic TLS (security level "may") the "!aNULL" ciphers send server certificates the client never checks (sends mail anyway, regardless of the content of the certificate). When the Postfix TLS security level requires authentication (mandatory TLS stronger than just "encrypt"), Postfix automatically disables the aNULL ciphers internally. You never need to do explicitly, except to satisfy some clueless auditor's checklist. That said, my support for aNULL ciphers in Postfix is a losing battle against said clueless auditors and even not so clueless maximalists, who frown on the opportunistic use-case. In particular, there are no anonymous E(EC)DH ciphers in TLS 1.3, the server MUST send a certificate, even when the client is going to ignore it. The server also has no mechanism to learn that the client intends to ignore the server's certificate. I think that leaving out the aNULL ciphers from TLS 1.3 is a bad idea, but despite RFC7435, the maximalists have not really changed their attitudes. -- Viktor.
Re: rejecting 'fancy' TLDs, allowing a specified one ?
On Sat, Jan 30, 2021 at 01:20:13PM -0500, Phil Stracchino wrote: > I'm looking at implementing a rule to discard all > four-letter-and-above TLDs except whitelisted ones, because I'm tired > of playing whack-a-mole. I'd like to strongly advise against filtering by TLD. This is a very low quality signal. There is no shortage of abuse mail from the traditional gTLDs, and also a non-trivial quantity of legitimate email from new gTLDs. Most of the ".brand" gTLDs are not open for public registration of subdomains, and if say citibank decided to send email from a ".citi" subdomain, that'd be just fine. They should be able to use the gTLD they control. For example, the ".info" and ".name" gTLDs are established sources of legitimate email. Looking at DANE-enabled domains, which junk mail senders are unlikely to bother setting up, I see the following top 30 domain counts by TLD, indicating a population of non-abusive domains. 6389 info 3397 online 1231 shop 941 email 825 amsterdam 784 site 715 cloud 561 tech 531 store 402 world 360 swiss 330 name 283 work 248 space 235 studio 229 club 212 agency 197 blog 190 academy 185 family 164 rocks 158 design 153 link 150 live 144 network 138 media 127 tips 122 company 120 solutions 113 life ... To filter junk mail, deploy better content-based filters. -- Viktor.
Stucked with "unable to look up host"
Messages log this error , relay=none, delay=1.2, delays=0.15/0.01/1/0, dsn=5.3.0, status=bounced (unable to look up host host.domain.com: No address associated with hostname) However, DNS resolution works as expected and has a PTR record associated with it. Any pointers would be greatly appreciated! ___ Daniel A. Rodriguez Departamento de Tecnología para la Gestión Escuela Provincial de Educación Técnica N° 1 Posadas - Misiones - Argentina (0376) 443-8578 www.epet1.edu.ar
Re: Stucked with "unable to look up host"
Daniel Armando Rodriguez wrote: > , relay=none, delay=1.2, delays=0.15/0.01/1/0, dsn=5.3.0, status=bounced > (unable to look up host host.domain.com: No address associated with > hostname) > > However, DNS resolution works as expected and has a PTR record associated > with it. It is very common for postfix to be run with a chroot configuration specified in the master.cf file. It's the default for many software distributions. Your description fits a case where you can look up the name in the host system outside the chroot but postfix inside the chroot cannot. You can check the configuration this way. $ postconf -F smtp/unix/chroot $ postconf -F relay/unix/chroot The first thing I would try is stopping postfix and then starting it again. Because many start up scripts sync the host DNS configuration into the chroot at startup. This can "just fix it" for many of the problems that might cause this. Try that first. And the detail is that the /etc/resolv.conf file is copied into the chroot location. In other words these two files should have the same contents. And since it is a chroot the chroot version should be a copy (not a symlink) to the main one outside the chroot. $ echo diff /etc/resolv.conf $(postconf -h queue_directory)/etc/resolv.conf diff /etc/resolv.conf /var/spool/postfix/etc/resolv.conf $ diff /etc/resolv.conf $(postconf -h queue_directory)/etc/resolv.conf ...no output...sameno differences... My best guess is that your chroot does not have a working resolv.conf file. Bob
Re: Stucked with "unable to look up host"
On Sat, Jan 30, 2021 at 09:39:01PM -0700, Bob Proulx wrote: > My best guess is that your chroot does not have a working resolv.conf file. Certainly a good place to start. The only odd detail is that the errors are 5.3.0 errors, so the lookup returned a definitive "no such host", rather than just failing to get an answer. Another possibility therefore, is that the OP (who failed to post "postconf -nf" and "postconf -Mf" details) has disabled DNS lookups entirely, either in main.cf or in master.cf. The correct (default) values of the relevant parameters are: # "yes" is almost never the right setting. # disable_dns_lookups = no # For MTAs setting mail directly to the Internet, # "dns" is the only correct value # smtp_host_lookup = dns The OP should probably post "postconf -nf" and "postconf -Mf" output as explained in: http://www.postfix.org/DEBUG_README.html#mail -- Viktor.
