Re: Understanding concurrency limits
On Wed, Jan 18, 2023 at 12:45:02AM +, Sean Hennessey wrote: > Thanks,I did realize after I sent the email that what was probably > happening was the delay was the overiding controller, and not working > as in addition as I thought it would. Once you have multi-second delays, concurrency is pointless. If you want more throughput scale down the delay. -- Viktor.
Re: Understanding concurrency limits
Thanks,I did realize after I sent the email that what was probably happening was the delay was the overiding controller, and not working as in addition as I thought it would. Is there a way to do combine the delay w/ the concurrency? Like two simultaneous connections each doing one email per rate delay? I'm trying to help some folks out w/ sending to yahoo and trying to see what options I have as far as rate control. From: owner-postfix-us...@postfix.org on behalf of Wietse Venema Sent: Tuesday, January 17, 2023 7:17 PM To: Postfix users Subject: Re: Understanding concurrency limits Sean Hennessey: > In master.cf > smtp-tar unix -- y - 1 smtp > -o syslog_name=postfix/$service_name > > In main.cf > smtp-tar_destination_rate_delay = 600s RTFM, this puts 600s delay between deliveries as in: deliver one meessage wait 600s deliver one meessage etc. The scheuler could warn when concurrency >1 will be ignored, but given that "default_destination_concurrency_limit = 20", that would create a lot of noise. Wietse
Re: SPF fail and domain fail, why?
Maurizio Caloro skrev den 2023-01-17 19:55: # opendmarc-check caloro.ch DMARC record for caloro.ch: Sample percentage: 100 DKIM alignment: strict SPF alignment: relaxed Domain policy: none Subdomain policy: unspecified Aggregate report URIs: mailto:etczb...@ag.dmarcian-eu.com Failure report URIs: (none) remove opendmarc in non_smtp_milters opendkim is fine there, but opendmarc is not, problem is non_smtp_milters have no ips, so spf will fail
Re: Understanding concurrency limits
Sean Hennessey: > In master.cf > smtp-tar unix -- y - 1 smtp > -o syslog_name=postfix/$service_name > > In main.cf > smtp-tar_destination_rate_delay = 600s RTFM, this puts 600s delay between deliveries as in: deliver one meessage wait 600s deliver one meessage etc. The scheuler could warn when concurrency >1 will be ignored, but given that "default_destination_concurrency_limit = 20", that would create a lot of noise. Wietse
Re: SPF fail and domain fail, why?
On Tue, Jan 17, 2023 at 07:55:08PM +0100, Maurizio Caloro wrote: > > Am 17.01.2023 um 03:34 schrieb Scott Kitterman: > > > > On January 17, 2023 2:25:34 AM UTC, raf wrote: > > > On Mon, Jan 16, 2023 at 08:01:10PM +0100, Maurizio > > > Caloro wrote: > > > > > > > Hello > > > > > > > > Please one more thing about Opendmarc, if send any email to any where > > > > i see in log SPF fail, domain.ch fail ? > > > > > > > > Jan 16 19:43:39 nmail opendkim[16490]: B6090404C3: DKIM-Signature field > > > > added (s=nmail, d=caloro.ch) > > > > Jan 16 19:43:39 nmail opendmarc[16483]: B6090404C3: SPF(mailfrom): > > > > caloro.ch > > > > fail > > > > Jan 16 19:43:39 nmail opendmarc[16483]: B6090404C3: caloro.ch fail > > > > > > > > if recieve any mail from any where, any thing pass > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: mailc-bb.linkedin.com > > > > [A.B.C.D] not internal > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: not authenticated > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: message has > > > > signatures > > > > from linkedin.com, mailc.linkedin.com > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: signature=muv88Rcz > > > > domain=linkedin.com selector=d2048-201806-01 result="no signature > > > > error"; > > > > signature=IKaXoyzS domain=mailc.linkedin.com selector=proddkim1024 > > > > result="no signature error" > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: DKIM verification > > > > successful > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: s=d2048-201806-01 > > > > d=linkedin.com SSL > > > > Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3 ignoring > > > > Authentication-Results at 2 from nmail.caloro.ch > > > > Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3: SPF(mailfrom): > > > > bounce.linkedin.com pass > > > > Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3: linkedin.com pass > > > > > > > > -- > > > > on the header from any mail that i send will appair following > > > > Authentication-Results-Original: caloro.ch, calm-ness.ch; spf=fail > > > > > > > > # cat opendmarc.conf > > > > AuthservID caloro.ch, calm-ness.ch > > > > AuthservIDWithJobID false > > > > AutoRestart false > > > > AutoRestartRate 10/1h > > > > Background true > > > > DNSTimeout 5 > > > > HistoryFile > > > > /var/spool/postfix/opendmarc/opendmarc.dat > > > > *IgnoreAuthenticatedClients true* > > > > IgnoreHosts /etc/opendmarc/ignore.hosts > > > > PidFile /var/run/opendmarc/opendmarc.pid > > > > RejectFailures false > > > > RequiredHeaders true > > > > PublicSuffixList /etc/opendmarc/effective_tld_names.dat > > > > Socketinet:8892@127.0.0.1 > > > > SoftwareHeader true > > > > SPFSelfValidate true > > > > SPFIgnoreResults false > > > > Syslog true > > > > SyslogFacility mail > > > > # TrustedAuthservIDs nmail.caloro.ch, nmail.calm-ness.ch > > > > TrustedAuthservIDs caloro.ch, calm-ness.ch > > > > UMask 077 > > > > UserID opendmarc:opendmarc > > > > > > > > if checking online dmarc, dkim, spf from domain appair anything correct! > > > > please why me email will fail? > > > > > > > > thanks for any hint > > > > Mauri > > > I could be wrong, but I suspect that the problem is > > > that you haven't configured OpenDMARC to not check > > > locally originating mail. According to the first > > > Received: header, the mail is coming from 37.120.190.188 > > > (which is mentioned in multiple ways in the SPF record), > > > but your mail server at that IP address shouldn't be > > > performing this check on outgoing mail. > > > > > > Perhaps you need to add this to your /etc/opendmarc.conf: > > > > > > IgnoreAuthenticatedClients true > > > > > > Unfortunately, the code doing the SPF check doesn't > > > explain why it failed. Some do. For example, the > > package on debian would > > > probably show the IP address that caused the failure. > > > Maybe it's 127.0.0.1 (or the IP address of an > > > authenticated submission client). > > > > The internal SPF implementation in OpenDMARC is not a full > > implementation of the protocol. In general, you are likely to be > > better off having something SPF specific check SPF and then have > > OpenDMARC consume that result for it's DMARC processing. If you > > are inclined towards Perl, then postfix-policyd-spf-perl is a good > > choice. SPF Engine supports either a milter (pyspf-milter) or > > policy server (postfix-policyd-spf-python) interface with Postfix, > > depending on which you prefer, if you're up for a Python based > > solution. > > > > Scott K > this was bevor always in opendmarc.conf present >
Re: Enabling both redirection and local (virtual) delivery for catch-all email addresses?
On Tue, Jan 17, 2023 at 03:31:43PM +, sa212+post...@cyconix.com wrote: > I've been doing some tests with normal (foo@domain), catch-all (@domain), > and plussed (foo+foo@domain) addresses, with the virtual(8) delivery agent, > and virtual_alias_maps and virtual_mailbox_maps. > > The idea is to check the setup of users who want both redirection and > delivery to a local mailbox (with Dovecot, and Maildir format). > This worked as I expected, except in one case: when mail is sent to an > unknown recipient, and the catch-all setup is used, it's not possible to > both redirect the incoming mail, *and* have it delivered to a local mailbox. > Is this expected? It looks like a bug, because the destination MTA (the one > that receives the redirect) gets a badly-formed RCPT. > Tests as follows, with the virtual_alias_maps file being 'valias', and the > virtual_mailbox_maps file being 'vmailbox', and the local domain being > example.com: > > (1) Mail to known user 'f...@example.com': > > valias: "f...@example.com f...@example.com, f...@external.org" > vmailbox: "f...@example.com example.com/foo/" > > This works: external.org gets the mail, and Dovecot also gets the mail from > mailbox 'foo/'. > > (2) Mail to unknown user 'unkn...@example.com': > > valias: "@example.com @example.com, f...@external.org" > vmailbox: "@example.com example.com/foo/" > > This fails: external.org doesn't get the mail, but Dovecot does get the mail > from mailbox 'foo/'. > > The mail log at external.org shows that Postfix did try to redirect the > mail, but sent it to an invalid address: > > Recipient address rejected: User unknown in virtual mailbox table; > from= to=<"unkn...@example.com, foo"@external.org> I'm not suprised that it didn't work. I would have thought that "@example.com" is not a valid alias target since it's not a valid email address. That might not be the reason that it didn't work, but it would make sense. > Second question: with my current setup, an entry is created in virtual_alias > maps even if the user doesn't want redirection, but only wants local > delivery. In other words, if user 'bar' wants local delivery, then the file > entries are: > > valias: "b...@example.com b...@example.com" > vmailbox: "b...@example.com example.com/bar/" > > This works, and doesn't seem to cause a problem. I don't really want to > change the software to remove this (unnecessary) entry in valias. Are there > likely to be any problems with this? I don't know, but if it works, it will probably continue to work. cheers, raf
Understanding concurrency limits
In master.cf smtp-tar unix -- y - 1 smtp -o syslog_name=postfix/$service_name In main.cf smtp-tar_destination_rate_delay = 600s smtp-tar_destination_concurrency_limit = 3 smtp-tar_destination_recipient_limit = 2 smtp-tar_initial_destination_concurrency=2 In transports yahoo.com smtp-tar: My understanding is that w/ the above settings, the first sends going to @yahoo.com should fire off two simultaneous smtp connections. Then at some point, it'll build up to three. I don't see that. I reload postfix at 21:48 and this is what I see in the logs for outbound yahoo.com Jan 17 21:48:01 postfix2 postfix/smtp-tar/smtp[2541820]: B142044CB2: to=, relay=mta5.am0.yahoodns.net[98.136.96.74]:25, delay=4255, delays=4255/0.06/0.15/0.4, dsn=2.0.0, status=sent (250 ok dirdel) Jan 17 21:58:06 postfix2 postfix/smtp-tar/smtp[2542451]: EC44B44751: to=, relay=mta6.am0.yahoodns.net[67.195.204.79]:25, delay=17699, delays=17093/601/0.23/5.1, dsn=2.0.0, status=sent (250 ok dirdel) Jan 17 22:08:07 postfix2 postfix/smtp-tar/smtp[2543075]: 1135144D94: to=, relay=mta6.am0.yahoodns.net[98.136.96.91]:25, delay=2122, delays=914/1206/0.16/0.67, dsn=2.0.0, status=sent (250 ok dirdel) I'm only seeing one outbound at a time, every ten minutes. Am I doing something wrong here?
Re: SPF fail and domain fail, why?
Am 17.01.2023 um 03:34 schrieb Scott Kitterman: On January 17, 2023 2:25:34 AM UTC, raf wrote: On Mon, Jan 16, 2023 at 08:01:10PM +0100, Maurizio Caloro wrote: Hello Please one more thing about Opendmarc, if send any email to any where i see in log SPF fail, domain.ch fail ? Jan 16 19:43:39 nmail opendkim[16490]: B6090404C3: DKIM-Signature field added (s=nmail, d=caloro.ch) Jan 16 19:43:39 nmail opendmarc[16483]: B6090404C3: SPF(mailfrom): caloro.ch fail Jan 16 19:43:39 nmail opendmarc[16483]: B6090404C3: caloro.ch fail if recieve any mail from any where, any thing pass Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: mailc-bb.linkedin.com [A.B.C.D] not internal Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: not authenticated Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: message has signatures from linkedin.com, mailc.linkedin.com Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: signature=muv88Rcz domain=linkedin.com selector=d2048-201806-01 result="no signature error"; signature=IKaXoyzS domain=mailc.linkedin.com selector=proddkim1024 result="no signature error" Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: DKIM verification successful Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: s=d2048-201806-01 d=linkedin.com SSL Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3 ignoring Authentication-Results at 2 from nmail.caloro.ch Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3: SPF(mailfrom): bounce.linkedin.com pass Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3: linkedin.com pass -- on the header from any mail that i send will appair following Authentication-Results-Original: caloro.ch, calm-ness.ch; spf=fail # cat opendmarc.conf AuthservID caloro.ch, calm-ness.ch AuthservIDWithJobID false AutoRestart false AutoRestartRate 10/1h Background true DNSTimeout 5 HistoryFile /var/spool/postfix/opendmarc/opendmarc.dat *IgnoreAuthenticatedClients true* IgnoreHosts /etc/opendmarc/ignore.hosts PidFile /var/run/opendmarc/opendmarc.pid RejectFailures false RequiredHeaders true PublicSuffixList /etc/opendmarc/effective_tld_names.dat Socketinet:8892@127.0.0.1 SoftwareHeader true SPFSelfValidate true SPFIgnoreResults false Syslog true SyslogFacility mail # TrustedAuthservIDs nmail.caloro.ch, nmail.calm-ness.ch TrustedAuthservIDs caloro.ch, calm-ness.ch UMask 077 UserID opendmarc:opendmarc if checking online dmarc, dkim, spf from domain appair anything correct! please why me email will fail? thanks for any hint Mauri I could be wrong, but I suspect that the problem is that you haven't configured OpenDMARC to not check locally originating mail. According to the first Received: header, the mail is coming from 37.120.190.188 (which is mentioned in multiple ways in the SPF record), but your mail server at that IP address shouldn't be performing this check on outgoing mail. Perhaps you need to add this to your /etc/opendmarc.conf: IgnoreAuthenticatedClients true Unfortunately, the code doing the SPF check doesn't explain why it failed. Some do. For example, the package on debian would probably show the IP address that caused the failure. Maybe it's 127.0.0.1 (or the IP address of an authenticated submission client). The internal SPF implementation in OpenDMARC is not a full implementation of the protocol. In general, you are likely to be better off having something SPF specific check SPF and then have OpenDMARC consume that result for it's DMARC processing. If you are inclined towards Perl, then postfix-policyd-spf-perl is a good choice. SPF Engine supports either a milter (pyspf-milter) or policy server (postfix-policyd-spf-python) interface with Postfix, depending on which you prefer, if you're up for a Python based solution. Scott K this was bevor always in opendmarc.conf present IgnoreAuthenticatedClients true # opendmarc-check caloro.ch DMARC record for caloro.ch: Sample percentage: 100 DKIM alignment: strict SPF alignment: relaxed Domain policy: none Subdomain policy: unspecified Aggregate report URIs: mailto:etczb...@ag.dmarcian-eu.com Failure report URIs: (none) but please why "fail" appair, i think this will post from opendmarc Jan 17 19:17:50 nmail opendkim[801]: 6A2F040132: DKIM-Signature field added (s=nmail, d=caloro.ch) Jan 17 19:17:50 nmail opendmarc[766]: 6A2F040132: SPF(mailfrom): caloro.ch fail Jan 17 19:17:50 nmail opendmarc[766]: 6A2F040132: caloro.ch fail # dig caloro.ch txt ; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> caloro.ch txt ;; global options: +cmd ;; Got answer: ;;
Enabling both redirection and local (virtual) delivery for catch-all email addresses?
I've been doing some tests with normal (foo@domain), catch-all (@domain), and plussed (foo+foo@domain) addresses, with the virtual(8) delivery agent, and virtual_alias_maps and virtual_mailbox_maps. The idea is to check the setup of users who want both redirection and delivery to a local mailbox (with Dovecot, and Maildir format). This worked as I expected, except in one case: when mail is sent to an unknown recipient, and the catch-all setup is used, it's not possible to both redirect the incoming mail, *and* have it delivered to a local mailbox. Is this expected? It looks like a bug, because the destination MTA (the one that receives the redirect) gets a badly-formed RCPT. Tests as follows, with the virtual_alias_maps file being 'valias', and the virtual_mailbox_maps file being 'vmailbox', and the local domain being example.com: (1) Mail to known user 'f...@example.com': valias: "f...@example.com f...@example.com, f...@external.org" vmailbox: "f...@example.com example.com/foo/" This works: external.org gets the mail, and Dovecot also gets the mail from mailbox 'foo/'. (2) Mail to unknown user 'unkn...@example.com': valias: "@example.com @example.com, f...@external.org" vmailbox: "@example.com example.com/foo/" This fails: external.org doesn't get the mail, but Dovecot does get the mail from mailbox 'foo/'. The mail log at external.org shows that Postfix did try to redirect the mail, but sent it to an invalid address: Recipient address rejected: User unknown in virtual mailbox table; from= to=<"unkn...@example.com, foo"@external.org> Second question: with my current setup, an entry is created in virtual_alias maps even if the user doesn't want redirection, but only wants local delivery. In other words, if user 'bar' wants local delivery, then the file entries are: valias: "b...@example.com b...@example.com" vmailbox: "b...@example.com example.com/bar/" This works, and doesn't seem to cause a problem. I don't really want to change the software to remove this (unnecessary) entry in valias. Are there likely to be any problems with this?
