Re: Samsung printer stopped working w/ opensmtpd - Message is not RFC 2822 compliant"
On Wednesday, April 17th, 2024 at 11:51, Philipp wrote: [...] > > Looking at the new trace I see the reason[0] for the error. Other then > I supected it's the body seperator, which does in your case start with > a WSP. A wild guess is that the boundery parameter of the working mails > contain ':'. > > A workaround for your problem would be a filter which detects these > mails and remove the WSP from the body seperator. But be carefull with > such a filter, because it might break other mails quite easy. So make > sure you only make changes to mails from your scanner. Thank Philipp for looking into this! At this point I think I'm just going to live with this and retry rather than trying bend space-time around the printer's broken output :) Daniel
Re: Samsung printer stopped working w/ opensmtpd - Message is not RFC 2822 compliant"
On Tuesday, April 16th, 2024 at 13:52, Philipp wrote: > > > Hi > > [2024-04-15 10:11] Lévai, Dániel l...@ecentrum.hu > > > I've been using this Samsung C480FW printer/scanner forever with OpenSMTPD > > and suddenly (no upgrades to OpenSMTPD or changes in the > > configuration) it started to complain (it's trying to send scanned > > documents via e-mail): > > > Has something on the scanner changed? Like a firmwareupdate or changed > settings. Something must have changed, when it has worked and now it > doesn't work anymore. Yeah I know it's always suspicious when someone says "nothing changed" :) Really nothing changed on the smtpd server or the printer. The last successful scan was from the 12th of April and the next time I tried on the 15th it failed. Today, all of them succeeded again. I suspect it depends on the content of the message, somehow - as the only variable is the actual document I'm scanning. Idk, probably some weird characters, spacing or weird lines - I know, at this point it just sounds sorcery. Anyway, I was just wondering if there was an option to somehow relax some checks, but I can live with retrying until it succeeds. > > It's somewhere after DATA smtpd doesn't like what it's seeing. > > Actually I don't see why this message is not accepted. Only think I can > imagen is that the Content-features field is not properly folded. So that > the character used to indent is not WSP (space or horizontal tab). But > this is only a guess. I have the same suspicion (or let's call it feeling), but can't reproduce this willingly, unfortunately. > The attached patch adds a few more tracing information for the parser. Can > you apply this patch and try again? I've applied it to OpenBSD 7.4. The only thing I can reproduce this with reliably is the SMTP test function on the printer admin page - so this is not an actual scanned document e-mail that is sometimes failing: smtp: 0x59783b55000: connected to listener 0x598059cd000 [hostname=xxx, port=xxx, tag=INSECURE] mproc: dispatcher -> lka: realloc 0 -> 128 mproc: dispatcher -> lka : 28 IMSG_GETNAMEINFO mproc: dispatcher -> control: realloc 0 -> 128 mproc: dispatcher -> control : 46 IMSG_STAT_INCREMENT mproc: dispatcher -> control : 52 IMSG_STAT_INCREMENT imsg: control <- dispatcher: IMSG_STAT_INCREMENT (len=46) imsg: lka <- dispatcher: IMSG_GETNAMEINFO (len=28) ramstat: increment: smtp.session ramstat: smtp.session (0x8c602729211): 0 -> 1 imsg: control <- dispatcher: IMSG_STAT_INCREMENT (len=52) ramstat: increment: smtp.session.inet4 ramstat: smtp.session.inet4 (0x8c5a23055c1): 0 -> 1 mproc: lka -> dispatcher: realloc 0 -> 128 mproc: lka -> dispatcher : 49 IMSG_GETNAMEINFO imsg: dispatcher <- lka: IMSG_GETNAMEINFO (len=49) mproc: dispatcher -> lka : 51 IMSG_GETADDRINFO imsg: lka <- dispatcher: IMSG_GETADDRINFO (len=51) mproc: lka -> dispatcher : 41 IMSG_GETADDRINFO mproc: lka -> dispatcher : 8 IMSG_GETADDRINFO_END imsg: dispatcher <- lka: IMSG_GETADDRINFO (len=41) imsg: dispatcher <- lka: IMSG_GETADDRINFO_END (len=8) smtp: 0x59783b55000: STATE_NEW -> STATE_CONNECTED 6a2027eee3c2a5c4 smtp connected address=xxx.xxx.xxx.xxx host=xxx.xxx.xxx.xxx.hu mproc: dispatcher -> ca: realloc 0 -> 128 mproc: dispatcher -> ca: realloc 128 -> 256 mproc: dispatcher -> ca : 188 IMSG_CA_RSA_PRIVENC (flush) imsg: ca <- dispatcher: IMSG_CA_RSA_PRIVENC (len=188) mproc: ca -> dispatcher: realloc 0 -> 128 mproc: ca -> dispatcher: realloc 128 -> 1024 mproc: ca -> dispatcher : 532 IMSG_CA_RSA_PRIVENC imsg: dispatcher <- ca: IMSG_CA_RSA_PRIVENC (len=532) smtp: 0x59783b55000: IO_TLSREADY 6a2027eee3c2a5c4 smtp tls ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 mproc: dispatcher -> control : 44 IMSG_STAT_INCREMENT smtp: 0x59783b55000: >>> 220 xxx ESMTP OpenSMTPD imsg: control <- dispatcher: IMSG_STAT_INCREMENT (len=44) ramstat: increment: smtp.smtps ramstat: smtp.smtps (0x8c5879cd151): 0 -> 1 smtp: 0x59783b55000: IO_LOWAT smtp: 0x59783b55000: IO_DATAIN smtp: 0x59783b55000: <<< EHLO SEC84251976C2A5 smtp: 0x59783b55000: STATE_CONNECTED -> STATE_HELO smtp: 0x59783b55000: >>> 250-xxx Hello SEC84251976C2A5 [xxx.xxx.xxx.xxx], pleased to meet you smtp: 0x59783b55000: >>> 250-8BITMIME smtp: 0x59783b55000: >>> 250-ENHANCEDSTATUSCODES smtp: 0x59783b55000: >>> 250-SIZE 36700160 smtp: 0x59783b55000: >>> 250-DSN smtp: 0x59783b55000: >>> 250-AUTH PLAIN LOGIN smtp: 0x59783b55000: >>> 250 HELP smtp: 0x59783b55000: IO_LOWAT smtp: 0x59783b55000: IO_DATAIN smtp: 0x59783b55000: <<< AUTH LOGIN smtp: 0x59783b55000: STATE_HELO -> STATE_AUTH_USERNAME smtp: 0x59783b55000: >>> 334 XXX smtp: 0x59783b55000: IO_
Samsung printer stopped working w/ opensmtpd - Message is not RFC 2822 compliant"
Hi all, I've been using this Samsung C480FW printer/scanner forever with OpenSMTPD and suddenly (no upgrades to OpenSMTPD or changes in the configuration) it started to complain (it's trying to send scanned documents via e-mail): 7e1c0e5b97e7aad0 smtp connected address=xxx.xxx.xxx.xxx host=xxx.xxx.xxx.hu 7e1c0e5b97e7aad0 smtp tls ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 7e1c0e5b97e7aad0 smtp authentication user=user result=ok 7e1c0e5b97e7aad0 smtp failed-command command="DATA" result="550 5.7.1 Delivery not authorized, message refused: Message is not RFC 2822 compliant" 7e1c0e5b97e7aad0 smtp disconnected reason=disconnect When I issue an SMTP test on the printer admin page, this is what happens in smtpd: # smtpd -d -Tall smtp: 0xa146908b000: connected to listener 0xa14af58b000 [hostname=xxx.xxx.hu, port=xxx, tag=INSECURE] mproc: dispatcher -> lka: realloc 0 -> 128 mproc: dispatcher -> lka : 28 IMSG_GETNAMEINFO mproc: dispatcher -> control: realloc 0 -> 128 mproc: dispatcher -> control : 46 IMSG_STAT_INCREMENT mproc: dispatcher -> control : 52 IMSG_STAT_INCREMENT imsg: lka <- dispatcher: IMSG_GETNAMEINFO (len=28) imsg: control <- dispatcher: IMSG_STAT_INCREMENT (len=46) ramstat: increment: smtp.session ramstat: smtp.session (0x4d6fd5c7e11): 0 -> 1 imsg: control <- dispatcher: IMSG_STAT_INCREMENT (len=52) ramstat: increment: smtp.session.inet4 ramstat: smtp.session.inet4 (0x4d660bf63c1): 0 -> 1 mproc: lka -> dispatcher: realloc 0 -> 128 mproc: lka -> dispatcher : 49 IMSG_GETNAMEINFO imsg: dispatcher <- lka: IMSG_GETNAMEINFO (len=49) mproc: dispatcher -> lka : 51 IMSG_GETADDRINFO imsg: lka <- dispatcher: IMSG_GETADDRINFO (len=51) mproc: lka -> dispatcher : 41 IMSG_GETADDRINFO mproc: lka -> dispatcher : 8 IMSG_GETADDRINFO_END imsg: dispatcher <- lka: IMSG_GETADDRINFO (len=41) imsg: dispatcher <- lka: IMSG_GETADDRINFO_END (len=8) smtp: 0xa146908b000: STATE_NEW -> STATE_CONNECTED 1d1e5bc4223e33ab smtp connected address=xxx.xxx.xxx.xxx host=xxx.xxx.xxx.hu mproc: dispatcher -> ca: realloc 0 -> 128 mproc: dispatcher -> ca: realloc 128 -> 256 mproc: dispatcher -> ca : 188 IMSG_CA_RSA_PRIVENC (flush) imsg: ca <- dispatcher: IMSG_CA_RSA_PRIVENC (len=188) mproc: ca -> dispatcher: realloc 0 -> 128 mproc: ca -> dispatcher: realloc 128 -> 1024 mproc: ca -> dispatcher : 532 IMSG_CA_RSA_PRIVENC imsg: dispatcher <- ca: IMSG_CA_RSA_PRIVENC (len=532) smtp: 0xa146908b000: IO_TLSREADY 1d1e5bc4223e33ab smtp tls ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 mproc: dispatcher -> control : 44 IMSG_STAT_INCREMENT smtp: 0xa146908b000: >>> 220 xxx.xxx.hu ESMTP OpenSMTPD imsg: control <- dispatcher: IMSG_STAT_INCREMENT (len=44) ramstat: increment: smtp.smtps ramstat: smtp.smtps (0x4d6b663d0f1): 0 -> 1 smtp: 0xa146908b000: IO_LOWAT smtp: 0xa146908b000: IO_DATAIN smtp: 0xa146908b000: <<< EHLO SEC84251976C2A5 smtp: 0xa146908b000: STATE_CONNECTED -> STATE_HELO smtp: 0xa146908b000: >>> 250-xxx.xxx.hu Hello SEC84251976C2A5 [xxx.xxx.xxx.xxx], pleased to meet you smtp: 0xa146908b000: >>> 250-8BITMIME smtp: 0xa146908b000: >>> 250-ENHANCEDSTATUSCODES smtp: 0xa146908b000: >>> 250-SIZE 36700160 smtp: 0xa146908b000: >>> 250-DSN smtp: 0xa146908b000: >>> 250-AUTH PLAIN LOGIN smtp: 0xa146908b000: >>> 250 HELP smtp: 0xa146908b000: IO_LOWAT smtp: 0xa146908b000: IO_DATAIN smtp: 0xa146908b000: <<< AUTH LOGIN smtp: 0xa146908b000: STATE_HELO -> STATE_AUTH_USERNAME smtp: 0xa146908b000: >>> 334 VXNlcm5hbWU6 smtp: 0xa146908b000: IO_LOWAT smtp: 0xa146908b000: IO_DATAIN smtp: 0xa146908b000: <<< c2Ftc3VuZ19jNDgwZnc= smtp: 0xa146908b000: STATE_AUTH_USERNAME -> STATE_AUTH_PASSWORD smtp: 0xa146908b000: >>> 334 UGFzc3dvcmQ6 smtp: 0xa146908b000: IO_LOWAT smtp: 0xa146908b000: IO_DATAIN smtp: 0xa146908b000: <<< ZGVLVHpndlB6ZTZ2 mproc: dispatcher -> lka : 55 IMSG_SMTP_AUTHENTICATE imsg: lka <- dispatcher: IMSG_SMTP_AUTHENTICATE (len=55) lookup: lookup "user" as CREDENTIALS in table proc:ecentrum.hu-sql -> "user:$2b$08$..." mproc: lka -> dispatcher : 12 IMSG_SMTP_AUTHENTICATE imsg: dispatcher <- lka: IMSG_SMTP_AUTHENTICATE (len=12) 1d1e5bc4223e33ab smtp authentication user=user result=ok smtp: 0xa146908b000: >>> 235 2.0.0 Authentication succeeded smtp: 0xa146908b000: STATE_AUTH_PASSWORD -> STATE_HELO smtp: 0xa146908b000: IO_LOWAT smtp: 0xa146908b000: IO_DATAIN smtp: 0xa146908b000: <<< mail from: mproc: dispatcher -> queue: realloc 0 -> 128 mproc: dispatcher -> queue : 8 IMSG_SMTP_MESSAGE_CREATE imsg: queue <- dispatcher: IMSG_SMTP_MESSAGE_CREATE (len=8) queue-backend: queue_message_create() -> 1 (b666cd59) mproc: queue -> dispatcher: realloc 0 -> 128 mproc: queue -> dispatcher : 16 IMSG_SMTP_MESSAGE_CREATE imsg: dispatcher <- queue: IMSG_SMTP_MESSAGE_CREATE (len=16) smtp: 0xa146908b000: >>> 250 2.0.0 Ok smtp: 0xa146908b000: IO_LOWAT smtp: 0xa146908b000: IO_DATAIN smtp: 0xa146908b000: <<< rcpt to: mproc: dispatcher -> lka: realloc 128 -> 512 mproc: dispatcher -> lka : 344 IMSG_SMTP_EXPAND_RCPT imsg: lka <- dispatcher: IMSG_SMTP_EXPAND_RCPT
Re: forcing SMTP authentication
No it doesn't, that's the whole point... Eredeti üzenet Be 2019. aug. 21. 8:47, Selmeci Tamás írta: > On Wed, 21 Aug [2019 08](tel:201908):19:24 +0200 Martijn van Duren > wrote: > >> From smtpd.conf(5): >> >> auth-optional [] >> Support SMTPAUTH optionally: clients need not >> authenticate, but may do so. This allows a listen on >> directive to both accept incoming mail from untrusted >> senders and permit outgoing mail from authenticated users >> (using match auth). It can be used in situations where >> it is not possible to listen on a separate port (usually >> the submission port, 587) for users to authenticate. > > Sounds good, but unauthenticated relaying still works with this... > -- > Selmeci Tamás > http://www.486.hu/
Re: smtpd accept client certificate only from a specific CA
Cheers, and appreciate the work you do! Dani Eredeti üzenet Be 2019. júl. 29. 10:13, Gilles Chehade írta: > On Sun, Jul 28, 2019 at 08:37:54PM +, L??vai, D??niel wrote: >> Hi Gilles, >> >> Did you by any chance have time to look at #926? It there something wrong >> with my setup or is this a kind of a regression? >> Thanks for any info on this! >> > > Nope, if I had you would know ;-) > > I'm working pretty much alone on smtpd these days and I'm not full-time, > so unless an issue is security related, it can take a bit of time before > I tackle it. > > Patience. > > -- > Gilles Chehade @poolpOrg > > https://www.poolp.org patreon: https://www.patreon.com/gilles
Re: smtpd accept client certificate only from a specific CA
Hi Gilles, Did you by any chance have time to look at #926? It there something wrong with my setup or is this a kind of a regression? Thanks for any info on this! Dani ‐‐‐ Original Message ‐‐‐ On Friday, 26 July 2019 13:51, Gilles Chehade wrote: > On Fri, Jul 26, 2019 at 08:19:33AM +, L??vai, D??niel wrote: > > > Hi all! > > Running OpenBSD 6.5-stable, I have this on my relay host: > > smtpd.conf: > > ca myCA cert "/path/to/myCA.pem" > > listen on egress port submission \ > > tls-require verify \ > > ca myCA > > Now with that I expected that it'll only accept smtp clients that provide a > > certificate signed by myCA, but it turns out it accepts any certificate > > that is trusted based on the default /etc/ssl/certs.pem file. > > Besides (re)moving the stock certs file or any other intrusive/ugly > > workaround, is there any way I could force a CA for those connections? > > Your expectations are also mine. > > Please open an issue on our bug tracker, I'll have a look at it shortly > as I recently did work in that area and it worked as I expected, so I'm > a bit surprised. > > - > > Gilles Chehade @poolpOrg > > https://www.poolp.org patreon: https://www.patreon.com/gilles
smtpd accept client certificate only from a specific CA
Hi all! Running OpenBSD 6.5-stable, I have this on my relay host: smtpd.conf: ca myCA cert "/path/to/myCA.pem" listen on egress port submission \ tls-require verify \ ca myCA Now with that I expected that it'll only accept smtp clients that provide a certificate signed by myCA, but it turns out it accepts any certificate that is trusted based on the default /etc/ssl/certs.pem file. Besides (re)moving the stock certs file or any other intrusive/ugly workaround, is there any way I could force a CA for those connections? Thanks for any hints, Dani -- Lévai, Dániel -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: filter dkim signer
Edgar Pettijohn @ 2016-04-19T01:30:22 +0200: > Using a dkim testing tool I get the following: > > DKIM result: fail (wrong body hash: > 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=) > [...] You config (and maybe dns record) is messed up: > DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; > d=pettijohn-web.com -p /etc/mail/private.key -s selector1; > h=to:from:message-id:date; s=default; > bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; > b=L37Kq/L5Mqlvgnrgt3SIGjkikiYwNfJz03DEx21E2Ec8exkdObqKOJuitWKVMeW/CUZGIE7lgEhq93AFIqvtwrGJdLyZ2daxXGGIXnVHn1k0+uiYDssYxLm3UFhq3sA77BCo7hASu29FVTLPnNIWtAoJyIxyxWmiJEPW9pShKO8= -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: filter-spamassassin fails to deliver with large messages
Joerg Jung @ 2016-04-05T12:58:23 +0200: [...] > > Indeed, this was because of the --timeout-child option to spamd(1). > > However, raising this limit just because it might cover every message > > size doesn't really make sense. Even with 600 secs, there will be a > > message large enough for smtpd to spit back (given, depending on eg. the > > connection speed -- I could easily scan a ~10MB mail submitting from > > localhost, but not from a remote site eg. gmail). > > A 10 MB mail should be no problem within the default 300s. Even with a slow > link. > I have remote sites sending me 20-30MB mails taking about 1-3s to scan. > > As I wrote earlier, you may want to double-check your spamassassin config to > figure out why it takes so long to check. I don't think I should have to bend over spamassassin to an smtpd filter that fails to implement a basic check for the message size. With eg. filter-clamav, it is a bit easier, because you define the size limit for clamd. But with the the spamd/spamc duo, you'd do that with spamc (and in this case, filter-spamassassin is the 'client'). > > > So the only option I have is to set the global message size in > > smtpd.conf, and hope for the best? > > What’s wrong with the message size setting in smtpd.conf? It's not the solution to the problem. I *want to* receive "large" messages. I just don't want them to be *scanned* by spamassassin. See the difference? > > Am I correct in that a client doesn't > > necesarrily have to specify the message size at the beginning of a > > transaction? > > Yes. But it depends, ESMTP supports the SIZE command. > There are also reasonable timeout values specified in RFC for SMTP > transactions. > > > What if smtpd doesn't know the message size beforehand — > > No “what if” here. It may not know. Okay, understood, so the (my) use-case still stands. > > then it'll just 4xx messages seemingly random times based on how fast > > the connection can push lines into it? > > Yes, which is fine. 4xx means: try again later (maybe your line is fast > enough then). But it really is not (in my case) :) See, my connection to a remote site doesn't get upgraded after a 4xx respone... But I see your point. If *my* link was saturated, there'll be more chance for delivery next time. > > Doesn't seem this spamassassin filter was thought through properly :-/ > > (seeing this option present in spamc (--max-size)) > > As the author of the filter, I feel a bit offended by this statement now. > The filter works fine for me in larger production environments. It does more > or less exactly the same as the similar sendmail milters, which also work > fine for many people in production since years. > > I’m trying to help you with some vague issue here in this thread: > For some reason you want a max-size option for the filter, but fail to > explain why. Okay, okay. Sorry about that. Naturally I saw your name in the source; didn't want to offend you of course (but I tend to have a big mouth). This is simply my use-case. I can understand why no one else sees this as a problem; I'm not saying that the filter is useless. > > Anyway, I just injected a hacky patch in spamassassin_on_dataline() with > > a basic test of a `static size_t' that records the lines' length… > > So now you drop the message earlier, once the size limit is reached instead > of running into the timeout later. I fail to see how this helps you? You get > less > mail and even more 4xx replies this way. Nope. Why would I drop the message? Of course that wouldn't make sense. I just push the first n bytes to spamd(1), then when it reaches the configured limit, it just bypasses spamd(1) for the rest of the lines. So basically, I get only the first n bytes scanned by spamd(1) and not the rest. See, this is arguably not a good solution for a lot of people, but for my use-case, this is perfect. I'm willing to sacrifice getting large spam mails because of this. I won't try to bore you with statistics from google about how big a spam message is, in average, but they rarely hit 1+ megabytes. > > Equally hacky as the filter itself... :-P > > No need to become annoying. I have not seen any code or diff from you yet. All right... I see we got off on the wrong foot here, and it is my fault. So, I'm saying sorry, and how about just start off with a clean slate. I won't send my diff to the list, because as I've said, it's a hackity-hack, and don't want someone to find it in the archives, and god forbid use it. If you're interested, or want to get an idea of what I was explaining, I'll gladly send it to you in private. Daniel -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: filter-spamassassin fails to deliver with large messages
Joerg Jung @ 2016-04-04T20:42:03 +0200: > On Mon, Apr 04, 2016 at 11:53:47AM +0200, LÉVAI Dániel wrote: > > Hi! > > > > filter-spamassassin doesn't have a parameter to specify a maximum > > message size like spamc(1), and when it encounters a message weighing in at > > a > > few MBs, it fails, and drops back the message with a 4xx. > > > > Is this like a caveat, a known limitation or something? > > Not really, the filter just pipes everything through towards spamd(1). > The message size can be adjusted in smtpd.conf. > > > smtpd: > > Apr 4 10:40:48 malcolm smtpd[12759]: smtp-in: New session f49a69df17bc3046 > > from host hostname [ip_address] > > Apr 4 10:40:49 malcolm smtpd[12759]: smtp-in: Started TLS on session > > f49a69df17bc3046: version=TLSv1.2, cipher=ECDHE-RSA-CHACHA20-POLY1305, > > bits=256 > > Apr 04 10:40:49 malcolm spamd[540]: spamd: connection from localhost > > [127.0.0.1]:46081 to port 783, fd 6 > > Apr 04 10:40:59 malcolm spamd[540]: spamd: timeout: (10 second timeout > > while trying to PROCESS) > > Your message does not really fail because of size, spamd run into > timeout while processing. This can have various reasons depending on > your spamassassin config, e.g. additional dnsbl/pyzor/razor/whatever > checks might take a while. > > But yes, this might also be related to size, longer mails take longer to > transfer and to check and will run more likely into a timeout. > > You seemed to have tweaked the timeouts: the default is 300s and makes > sense -- not the 10s mentioned in your log above. > So You get what you requested ;) Indeed, this was because of the --timeout-child option to spamd(1). However, raising this limit just because it might cover every message size doesn't really make sense. Even with 600 secs, there will be a message large enough for smtpd to spit back (given, depending on eg. the connection speed -- I could easily scan a ~10MB mail submitting from localhost, but not from a remote site eg. gmail). So the only option I have is to set the global message size in smtpd.conf, and hope for the best? Am I correct in that a client doesn't necesarrily have to specify the message size at the beginning of a transaction? What if smtpd doesn't know the message size beforehand -- then it'll just 4xx messages seemingly random times based on how fast the connection can push lines into it? Doesn't seem this spamassassin filter was thought through properly :-/ (seeing this option present in spamc (--max-size)) Anyway, I just injected a hacky patch in spamassassin_on_dataline() with a basic test of a `static size_t' that records the lines' length... Equally hacky as the filter itself... :-P Daniel -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
filter-spamassassin fails to deliver with large messages
Hi! filter-spamassassin doesn't have a parameter to specify a maximum message size like spamc(1), and when it encounters a message weighing in at a few MBs, it fails, and drops back the message with a 4xx. Is this like a caveat, a known limitation or something? smtpd: Apr 4 10:40:48 malcolm smtpd[12759]: smtp-in: New session f49a69df17bc3046 from host hostname [ip_address] Apr 4 10:40:49 malcolm smtpd[12759]: smtp-in: Started TLS on session f49a69df17bc3046: version=TLSv1.2, cipher=ECDHE-RSA-CHACHA20-POLY1305, bits=256 Apr 04 10:40:49 malcolm spamd[540]: spamd: connection from localhost [127.0.0.1]:46081 to port 783, fd 6 Apr 04 10:40:59 malcolm spamd[540]: spamd: timeout: (10 second timeout while trying to PROCESS) Apr 04 10:40:59 malcolm spamd[31082]: prefork: child states: II Apr 4 10:41:00 malcolm spamassassin[27316]: warn: write: iobuf_flush: Broken pipe Apr 4 10:42:32 malcolm spamassassin[27316]: warn: response: shutdown: Bad file descriptor Apr 4 10:42:53 malcolm smtpd[12759]: smtp-in: Failed command on session f49a69df17bc3046: "DATA" => 451 4.7.1 Spam filter failed Apr 4 10:48:03 malcolm smtpd[12759]: smtp-in: Disconnecting session f49a69df17bc3046: session timeout meanwhile in spamd(1): Apr 4 10:40:49.910 [31082] dbg: prefork: ordered 540 to accept Apr 4 10:40:49.910 [540] dbg: spamd: select() on fd bit field 0110, timeout 0.5, not locked Apr 4 10:40:49.910 [31082] dbg: prefork: sysread(11) not ready, wait max 300.0 secs Apr 4 10:40:49.911 [540] dbg: spamd: accept() on fd 6 Apr 4 10:40:49.911 [31082] dbg: prefork: child 540: entering state 2 Apr 4 10:40:49.912 [31082] dbg: prefork: new lowest idle kid: 4873 Apr 4 10:40:49.914 [540] dbg: netset: patricia lookup on 127.0.0.1, 2 networks, result: 1, 0.321 ms Apr 4 10:40:49.914 [540] info: spamd: connection from localhost [127.0.0.1]:46081 to port 783, fd 6 Apr 4 10:40:49.915 [540] dbg: spamd: running as uid 506 Apr 4 10:40:59.923 [540] warn: spamd: timeout: (10 second timeout while trying to PROCESS) Apr 4 10:40:59.925 [540] dbg: config: copying current conf from backup Apr 4 10:40:59.962 [540] dbg: timing: total 37 ms - copy_config: 37 (100.0%) Apr 4 10:40:59.962 [540] dbg: prefork: sysread(12) not ready, wait max 300.0 secs Apr 4 10:40:59.962 [31082] dbg: prefork: child 540: entering state 1 Apr 4 10:40:59.963 [31082] dbg: prefork: new lowest idle kid: 540 Apr 4 10:40:59.963 [31082] dbg: prefork: child reports idle Apr 4 10:40:59.963 [31082] info: prefork: child states: II Daniel -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: backup mx -- delivery loop
Michael Morak @ 2015-11-02T11:36:18 +0100:
> Hi,
>
> I meant that you specify a value as a *number* like this:
>
> "relay backup 20"
That is really meant to be a server name, not a number:
/usr/src/usr.sbin/smtpd/parse.y:645
opt_relay : BACKUP STRING {
rule->r_value.relayhost.flags |= F_BACKUP;
if (strlcpy(rule->r_value.relayhost.hostname, $2,
^
sizeof (rule->r_value.relayhost.hostname))
>= sizeof (rule->r_value.relayhost.hostname)) {
[...]
Daniel
--
LÉVAI Dániel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: backup mx -- delivery loop
Michael Morak @ 2015-11-01T18:40:01 +0100: > Hi Daniel, > > as far as I've seen from the manual, the syntax is "relay [backup > [mx]]" and the description says: "Accepted mails are only relayed > through servers with a lower preference value in the MX record for the > domain than the one specified in mx. If mx is not specified, the > default server name will be assumed." <- I read this to say "If mx is > not specified, relay to the default server name." Hm, not quite. It says that it relays the mail to a server *with a lower preference value* than the one specified as mx, or got from other sources (mailname, gethostname(3), etc...). And that is what it should do, because the mx1 will have a lower preference, than the mx2 (and I'm configuring the mx2). Unfortunately, it doesn't act per the man page; it seems it doesn't do the MX lookup, and relays through itself again and again... > > Further on in the manual it says this: > > "/etc/mail/mailname If this file exists, the first line is used as > the server name. Otherwise, the server name is derived from the local > hostname returned by gethostname(3), either directly if it is a fully > qualified domain name, or by retrieving the associated canonical name > through getaddrinfo(3)." > > I guess, since you didn't supply an mx value, OpenSMTPD tries to relay > mail to the default server name, which in your case seems to resolve > to the server running the backup MX (which is not unusual, and one can > argue whether this is therefore a good default for the "backup" option > without an "mx" value supplied). > > TL;DR: I guess you need to supply an mx value in your smtpd.conf for > this to work as intended. Again, even if I had specified a value for 'mx', it must've only routed the the mail through a server with a lower preference number. So if I had specified mx1, then there wouldn't have been any servers that are with a lower pref. value, in turn, if I had specified the mx2, it would've acted like the same as with the default value. Daniel > On 1 November 2015 at 13:57, LÉVAI Dániel wrote: > > LÉVAI Dániel @ 2015-10-31T10:24:35 +0100: > >> Hi! > >> > >> I'm trying to setup a simple backup mx on OpenBSD 5.8-stable, but so far > >> it seems more of a burden than a "simple" task :) > >> > >> smtpd.conf: > >> 8< > >> pki hostname certificate "/etc/ssl/smtpd_cert.pem" > >> pki hostname key "/etc/ssl/private/smtpd_key.pem" > >> > >> listen on pppoe0 tls pki hostname > >> > >> table aliases db:/etc/mail/aliases.db > >> > >> accept for local alias deliver to mbox > >> > >> accept from any for domain "example.com" relay backup tls verify expire 30d > >> > >> accept from local for any relay > >> 8< > > > > Alright, so the backup mx handling is clearly broken in opensmtpd. > > Using "relay via" instead of "relay backup" works: > > > > accept from any for domain "example.com" \ > > relay via "tls://mx1.example.com" pki hostname verify \ > > expire 30d > > > > > > Anyway, it would nice to hear some words on this from one of the devs. > > Is this intended? How can one debug this further? > > > > > > Daniel > > > > -- > > You received this mail because you are subscribed to misc@opensmtpd.org > > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org > > > > -- > You received this mail because you are subscribed to misc@opensmtpd.org > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org > -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: backup mx -- delivery loop
LÉVAI Dániel @ 2015-10-31T10:24:35 +0100: > Hi! > > I'm trying to setup a simple backup mx on OpenBSD 5.8-stable, but so far > it seems more of a burden than a "simple" task :) > > smtpd.conf: > 8< > pki hostname certificate "/etc/ssl/smtpd_cert.pem" > pki hostname key "/etc/ssl/private/smtpd_key.pem" > > listen on pppoe0 tls pki hostname > > table aliases db:/etc/mail/aliases.db > > accept for local alias deliver to mbox > > accept from any for domain "example.com" relay backup tls verify expire 30d > > accept from local for any relay > 8< Alright, so the backup mx handling is clearly broken in opensmtpd. Using "relay via" instead of "relay backup" works: accept from any for domain "example.com" \ relay via "tls://mx1.example.com" pki hostname verify \ expire 30d Anyway, it would nice to hear some words on this from one of the devs. Is this intended? How can one debug this further? Daniel -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
backup mx -- delivery loop
lay: Ok for 86d4de5a4eb3651a: session=f7f7a55764209204, from=, to=, rcpt=<->, source=ip, relay=ip (hostname), delay=1s, stat=250 2.0.0: b676ae8e Message accepted for delivery [...] many more of these [...] Oct 31 09:11:06 host smtpd[1612]: warn: loop detected Oct 31 09:11:06 host smtpd[1612]: smtp-in: Failed command on session f7f7a558578d8e10: "DATA" => 500 5.4.6 Routing loop detected: Loop detected Oct 31 09:11:06 host smtpd[1612]: relay: PermFail for 1c7e2c42fadc367e: session=f7f7a55764209204, from=, to=, rcpt=<->, source=ip, relay=ip (hostname), delay=1s, stat =500 5.4.6 Routing loop detected: Loop detected -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
