Re: [mailop] "unmaintained" milter (was: Help with handling backscatter)
On Fri, Jul 12, 2024, Jesse Hathaway via mailop wrote: > I am a little wary of standing it up, given the lack of maintained open > source milters. If a program just works, why should it be updated? -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Line too long
On Fri, May 17, 2024, Cyril - ImprovMX via mailop wrote: > So, I wonder, is there another RFC that specifies a bigger line length, No. > or are the RFC here just for decoration? "We don't care. We don't have to. We are the phone company". Of course you could argue to "be nice and accept invalid stuff" (which might cause problems -- see "SMTP smuggling"). Maybe you can check whether those services allow to send out lines that are too long? -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] sendmail queue retry time
On Thu, Mar 14, 2024, Marco Moock via mailop wrote: > Am 14.03.2024 schrieb Julian Bradfield via mailop : > > On 2024-03-14, Marco Moock via mailop wrote: > > > sendmail tried to deliver it 20 times during the night - this > > > morning I deleted the mail from mqueue. > That is the default in sendmail. man sendmail: -q[time] Process saved messages in the queue at given intervals. If time is omitted, process the queue once. Looks like there is no default (maybe your OS uses some startup command with a "default" retry time). If you want a non-linear retry: MaxQueueAge=age If this is set to a value greater than zero, entries in the queue will be retried during a queue run only if the individual retry time has been reached which is doubled for each attempt. The maximum retry time is limited by the specified value. -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] handling a TLS handshake failure
On Wed, Mar 13, 2024, Harald Hannelius via mailop wrote: > Are there SMTP-"clients" that actually are able to back down from STARTTLS > and continue unencrypted? Very unlikely. If the TLS handshake fails, a server usually drops the session because it is in an unknown state. What several clients can do is to try a new session without STARTTLS, e.g., TLSFallbacktoClear If set, sendmail immediately tries an out- bound connection again without STARTTLS af- ter a TLS handshake failure. -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail.com SPF false negatives?
On Tue, Feb 27, 2024, Matt Palmer via mailop wrote: > > 550-5.7.26 DKIM = did not pass 550-5.7.26 SPF [nagler.me] with ip: > Any chance of a transient/intermittent DNS failure on nagler.me? On That should not result in a permanent (550) error but just cause a temporary (4xy) error. -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
On Sat, Jan 13, 2024, Sebastian Nielsen via mailop wrote: > Why is it a problem? The server ignores commands that it don't have > capability for anyways. Says who? 555 MAIL FROM/RCPT TO parameters not recognized or not implemented -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?
On Mon, Jan 01, 2024, John Covici via mailop wrote: > I use sendmail 8.17.1.9 under gentoo -- any patch for that one to fix this? Upgrade to 8.18.0.2,: https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz.sig ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP smuggling
On Tue, Dec 19, 2023, Slavko via mailop wrote: > Please, understand i properly, that it is no vulnerabiliy in SMTP itself, > but in (some) implementations/servers only? The RFC is very precise about line endings and "end of message". Some (legacy) MTAs try to be "nice" and accept other line endings which can be abused in certain situations. -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM / slippery slope gmx.de
On Mon, Dec 18, 2023, Paul Smith* via mailop wrote: > DKIM (and SPF) aren't anti-spam measures, and have never been promoted as > such. They're anti-forgery measures. I know that -- which is why I don't use either (besides other reasons, e.g., breaking existing mail mechanisms). > spammers can piggy-back on the good reputation of big companies like Google, As I mentioned before: 90% of the spam I get is from gmail -- that's a "good reputation"? > Amazon, etc. They send mail pretending to be from someth...@amazon.com. That's why DKIM can be useful for those who want to prevent forgeries. Why should everyone else be forced to do that? -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM / slippery slope gmx.de
On Mon, Dec 18, 2023, Gellner, Oliver via mailop wrote: > On 17.12.2023 at 21:48 Michael Peddemors via mailop wrote: > > A bit off topic, but it is always amazing.. rejecting based on no DKIM? > > It's like most new requirements, ever notice that the spammers are > > implementing these requirements sooner/faster than the real email operators > > and domains? > > I still think we as an industry are going down a slippery slope.. > especially not the end users, understand DKIM, but a person who > is responsible for running a mail server should. So my take on I understand DKIM (I even implemented it in an MTA) but I don't use it. One requirement after the other... dying a slow death... (see boiling frog parable) And it seems none of the extra requirements do anything against spam, because the spammers can (and do, see above) easily implement all of those. -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hotmail complains about their own mail
On Sat, Dec 16, 2023, Thomas Walter via mailop wrote: > I still think Microsoft should not complain about NDRs, especially if the > original was from them. That's probably just the normal case of filtering mail when it is coming in, but not when it is going out (that's what those companies do, right? After all, more than 90% of the spam I get is from Google - but they reject legitimate mails from me...) -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hotmail complains about their own mail
On Sat, Dec 16, 2023, Thomas Walter via mailop wrote: > 2. Our server bounces with 550 5.1.1 User doesn't exist. Does your server generate a DSN? If the "User doesn't exist" then it seems you should be able to determine that fact when RCPT is given -- or is this just a bogus reply? -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to handle hostname and PTR mismatch?
On Fri, Oct 27, 2023, Marco M. via mailop wrote:
> Am 27.10.2023 um 15:19:33 Uhr schrieb Cyril - ImprovMX via mailop:
> > For instance, if my server has a PTR with mail1.example.com, and I
> > connect by saying "HELO send.example.com". If the receiving server
> > loads all the IPs for "send.example.com" but doesn't find my server's
> > IP, should it refuse the email or accept it ?
Accept the HELO command.
"PTR mismatch" usually refers to something else than checking the
HELO argument. For example, see the sendmail documentation:
${client_resolve}
Holds the result of the resolve call for
${client_name}. Possible values are:
OKresolved successfully
FAIL permanent lookup failure
FORGEDforward lookup doesn't match reverse lookup
TEMP temporary lookup failure
Defined in the SMTP server only. sendmail per-
forms a hostname lookup on the IP address of the
connecting client. Next the IP addresses of that
hostname are looked up. If the client IP address
does not appear in that list, then the hostname
is maybe forged. This is reflected as the value
FORGED for ${client_resolve}
> Because the big companies enforce a correct PTR, almost all servers
> sending mail have a working PTR.
But not wrt the HELO argument, right?
--
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Increase of SSL/TLS errors
On Mon, Sep 11, 2023, Camille - Clean Mailbox via mailop wrote: > 2023-09-11T22:47:26.496119+02:00 mx1 postfix/smtpd[850937]: warning: TLS > library problem: error:0AC1:SSL routines::no shared > cipher:../ssl/statem/statem_srvr.c:2220: Did you change the default TLS settings (of postfix), e.g., made any restrictions? Or did you recently upgrade to OpenSSL 3 (which loads a default openssl.cnf file which probably changes the defaults)? -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any old-school sendmail types here good with the m4?
On Wed, Aug 30, 2023, Dan Mahoney (Gushi) via mailop wrote: > I've also discovered (over on comp.mail.sendmail) that SpamHaus's > recommended, documented use of the enhdnsbl feature DOES NOT WORK, which I You should have read the fine (sendmail) documentation instead: FEATURE(`enhdnsbl', `dnsbl.example.com', `', `t', `127.0.0.2.') the trailing dot is important (check the -a option of the map). Also shown in one of the replies you got here. -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any old-school sendmail types here good with the m4?
On Wed, Aug 23, 2023, Dan Mahoney (Gushi) via mailop wrote: > It looks like the version of enhdnsbl.m4 simply checks for *any* return code Have you checked the fine documentation? cf/README: enhdnsblEnhanced version of dnsbl (see above). Further arguments (up to 5) can be used to specify specific return values ^^ from lookups. [[...]] -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Please don't Cc: me, use only the list for replies
On Wed, Jul 12, 2023, Andrew C Aitchison via mailop wrote: > Please could you indicate who you are and, Why? > if appropriate, who you work for or represent ? I do not represent anyone but myself. Hence I prefer not to give out my name because then some people might think that I speak for "someone". -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX but A: broken MTA(s)
On Wed, Jul 12, 2023, Grant Taylor via mailop wrote: > with Sendmail) send a test message to my user at the test domain. That > didn't work. I think that Sendmail in the MSA role rejected things out of Sorry, but "didn't work" is a completely useless problem description. Provide real data and real error messages -- that is, a reproducible case. > hand about the destination not having an MX record. No, it doesn't. -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX but A: broken MTA(s)
On Tue, Jul 11, 2023, Grant Taylor via mailop wrote: > I have seen a-record fallback work, as in legitimate email flow, for others > within the last two years. > I have not been able to get it to work in my testing. Maybe you can explain how you tested it and which software (MTA?) was used? -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX but A: broken MTA(s)
On Tue, Jul 11, 2023, Grant Taylor via mailop wrote: > However, I don't see any mention of a-record fallback in RFC 5321. -- I > didn't chase any updates. -- I do see four occurances of "fall" in the Maybe you should have looked for "MX" instead of "fall"? ... If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. > As such, I'd question the veracity of current SMTP needing to support > a-record fallback. "Wer lesen kann ist klar im Vorteil." -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX but A: broken MTA(s)
On Tue, Jul 11, 2023, Grant Taylor via mailop wrote: > I think that A-record fallback is dependent on the sending MTA. And which MTA are those which do not implement the RFCs properly? "We are ..., we don't care about standards" > Though if memory serves that's because my MTA of choice balks at the lack of > MX record for the recipient domain. Which MTA is that? -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] greylisting
On Sun, Jun 25, 2023, Carsten Schiefner via mailop wrote: > The question, however, is: will it ble..., erm, can one do without > greylisting? It would mean more spam is coming through - so for my case greylisting is not useless -- which was the unsubstantiated claim to which I replied. -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] greylisting
On 6/23/2023 9:13 PM, Al Iverson via mailop wrote: > What if we just got to the heart of the matter and admitted that > greylisting is useless 2023? It isn't. (it works fairly well for the way I'm using it...) -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Salesforce abuse bounces
On Mon, Apr 03, 2023, Jay Hennigan via mailop wrote: > Final-Recipient: rfc822; ab...@asalesforce.com Does that mean ab...@salesforce.com is redirected to ab...@asalesforce.com ? -- Please don't Cc: me, use only the list for replies. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP equivalent of HTTP 30x redirect ? throttling email forwards
On Tue, Feb 28, 2023, Andrew C Aitchison via mailop wrote: > Is there an SMTP equivalent of the HTTP 30x status codes ? Maybe this: RFC 5321: 551 User not local; please try (See Section 3.4) -- Please don't Cc: me, use only the list for replies. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Contact info for antispamcloud.com ?
On Sun, Dec 25, 2022, Peter Nicolai Mathias Hansteen via mailop wrote: > but since they have no valid MX record What's wrong with the MX records? dig antispamcloud.com. mx antispamcloud.com. 600 IN MX 10 filter10.antispamcloud.com. antispamcloud.com. 600 IN MX 30 filter30.antispamcloud.com. antispamcloud.com. 600 IN MX 20 filter20.antispamcloud.com. antispamcloud.com. 600 IN MX 40 filter40.antispamcloud.com. filter10.antispamcloud.com. 120 IN A 38.111.198.185 filter20.antispamcloud.com. 300 IN A 38.89.254.156 filter30.antispamcloud.com. 292 IN A 38.111.198.185 filter40.antispamcloud.com. 300 IN A 38.109.53.20 Do you mean that the IPs don't map back to the names? 185.198.111.38.in-addr.arpa. 43200 IN PTR fe2-r2-in.la10.l.antispamcloud.com. That's not a problem wrt MX records, right? -- Please don't Cc: me, use only the list for replies. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] off-topic? useless Subject tags
On Sun, Nov 27, 2022, Hans-Martin Mosner via mailop wrote: > > IMHO it would be nice if those (misleading) "tags" could be removed > > before replying, sorry if I wasn't clear: I meant removed by the person who is replying, not by some software. > Of course he could have removed that > tag by himself, but that's something easily overlooked. Too bad ... I guess I'll add a filter which removes all the "tags" from a Subject header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] off-topic? useless Subject tags
Hmm, so something "tagged" the previous mail as [Marketing Email] Subject: Re: [mailop] [Marketing Email] t-online.de Seems to be really bogus to me IMHO it would be nice if those (misleading) "tags" could be removed before replying, similar to "[External]", "[Probably Spam]", etc, esp. if they fill up the Subject: header such that the actual value is barely displayed... ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Postfix.org borked?
On Nov 21, 2022, at 18:29, John Levine via mailop wrote: > I understand why that's the conventional wisdom, but I also don't > understand why, if all the resources are on the same LAN as the name > servers, the conventional wisdom would apply. This doesn't apply to postfix.org -- the mailing list is handled by a different host and if the address doesn't resolve, some MTAs might (temporarily) rejected those mails. -- Please don't Cc: me, use only the list for replies. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else seeing email backed up to Microsoft -- only IPv6
On Thu, Oct 27, 2022, Otto J. Makela via mailop wrote: > Unfortunately sendmail doesn't seem to have anything to do this on > a permanent basis (ref: Claus AÃmann on comp.mail.sendmail), I'd be > fine with IPv4 outgoing IPv4/IPv6 incoming. A patch has been posted to comp.mail.sendmail, but seemingly no feedback (yet?). -- Please don't Cc: me, use only the list for replies. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else seeing email backed up to Microsoft -- only IPv6
On Sat, Oct 29, 2022, Benny Pedersen via mailop wrote: > https://multirbl.valli.org/fcrdns-test/2a01%3A111%3Af400%3A7d00%3A%3A33.html > such clients will not deliver email here, as the t-online.de dont accept It seems those were supposed to be servers. Do you have any evidence that they were used as clients too? -- Please don't Cc: me, use only the list for replies. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else seeing email backed up to Microsoft -- only IPv6
On Thu, Oct 27, 2022, Peter Beckman via mailop wrote: > Deferred: 451 4.7.500 Server busy. Please try again later from > [2a01:111:e400:7e0d::51]. (AS750) Doesn't the MTA (which one do you use?) also try IPv4 or were there no A records at all? Do you still have the results for the MX and A/ lookups when the problem happened? TIA. -- Please don't Cc: me, use only the list for replies. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Certificate Question
"What's the problem you are trying to solve?" Almost no MTA cares about the certificate content unless explicitly configured to do so. Some check the names (CertSubject or AltNames), and some are "misconfigured" to require a cert signed by some specific CAs. Testing with just one or two other systems won't tell you much. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] does outbound.protection.outlook.com ignore 550 for RCPT?
My system is getting spammed by outbound.protection.outlook.com mail= rcpt=, stat=550 rcpt=, stat=550 and this happens again and again. (note: it happened before with other MAIL addresses) It their MTA broken -- ignoring 550 for RCPT? Or is the sender submitting the mail again and again? the latter seems unlikely based on the logs: Sep 6 22:18:13 mail= Sep 6 22:19:16 mail= Sep 6 22:20:19 mail= Sep 6 22:21:21 mail= Sep 6 22:22:24 mail= Sep 6 22:27:26 mail= Sep 6 22:32:28 mail= Sep 6 22:37:31 mail= Sep 6 22:42:33 mail= Sep 6 22:47:36 mail= Sep 6 22:52:39 mail= Sep 6 23:02:42 mail= Sep 6 23:12:45 mail= Sep 6 23:22:49 mail= Sep 6 23:32:53 mail= Sep 6 23:42:57 mail= Sep 6 23:53:01 mail= Sep 7 00:03:05 mail= Sep 7 00:13:09 mail= Sep 7 00:23:12 mail= Sep 7 00:33:15 mail= Sep 7 00:43:18 mail= Sep 7 00:53:22 mail= Sep 7 01:03:26 mail= Sep 7 01:13:30 mail= Sep 7 01:23:34 mail= Sep 7 01:33:37 mail= Sep 7 01:43:40 mail= Sep 7 01:53:44 mail= Sep 7 02:03:47 mail= Sep 7 02:13:51 mail= Sep 7 02:23:54 mail= Sep 7 02:33:57 mail= Sep 7 02:44:01 mail= Sep 7 02:54:05 mail= Sep 7 03:04:09 mail= Sep 7 03:14:12 mail= Sep 7 03:24:17 mail= Sep 7 03:34:21 mail= Sep 7 03:44:25 mail= Sep 7 03:54:29 mail= Sep 7 04:04:32 mail= Sep 7 04:14:35 mail= Sep 7 04:24:39 mail= Sep 7 04:34:42 mail= Sep 7 04:44:45 mail= Sep 7 04:54:49 mail= Sep 7 05:04:54 mail= Sep 7 05:14:58 mail= Sep 7 05:25:02 mail= Sep 7 05:35:05 mail= Sep 7 05:45:09 mail= Sep 7 05:55:13 mail= ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] smtp dane/tlsa
On Sat, Sep 03, 2022, Carl Byington via mailop wrote: > A former client was trying to setup Fedora 36 sendmail with dane > validation. F36 comes with sendmail 8.17.1 which is supposed to support > dane, but they get verify=fail talking to my mail servers. So I googled If would have been nice if you had included that info in your first mail... SENDMAIL RELEASE NOTES: Initial support for DANE (see RFC 7672 et.al.) is available if the compile time option DANE is set. Only TLSA RR 3-1-x is currently implemented. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] smtp dane/tlsa
How did you notice that "something is now broken"? "works for me" - I just tried it with an MTA that supports DANE: server=172.102.240.42, starttls=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, verify=DANE_SEC, cert_subject=/CN=mail3.five-ten-sg.com, cert_issuer=/C=US/O=Let's+20Encrypt/CN=R3, pubkey_fp=03:00:01:83:4D:71:0B:2F:EB:79:0C:C9:B2:C6:D2:51:C6:5B:1F:ED:C2:4C:51:A4:14:9B:DF:EA:E4:D4:0E:0B:E1:18:92 mail3.five-ten-sg.com 3 0 1 C203403D293A96CC4E7ABAA2F57A12BF8D2628A955A913B91A3C798896FCD6E3 mail3.five-ten-sg.com 3 0 1 834D710B2FEB790CC9B2C6D251C65B1FEDC24C51A4149BDFEAE4D40E0BE11892 Maybe you can try posttls-finger (from postfix) and see what is shows? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] smtp dane/tlsa
> _25._tcp.mail3.five-ten-sg.com. IN TLSA 3 0 1 ( > 834d710b2feb790cc9b2c6d251c65b1fedc24c51a4149bdfeae4d40e0be11892 Are you sure you want 3 0 1 and not 3 1 1? Isn't the second number the selector: 0 -- Full certificate: the Certificate binary structure as defined in [RFC5280] 1 -- SubjectPublicKeyInfo: DER-encoded binary structure as defined in [RFC5280] ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else seeing Avast AVG doing bad modifications of emails?
On Fri, Aug 19, 2022, Michael Peddemors via mailop wrote: > Sorry, thought it was clear, they are using bare line feeds on their > injected headers.. Hmm, I've seen that bug before in some software at $WORK :-( They didn't even notice it until some DKIM verifier finally failed due to that bug. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else seeing Avast AVG doing bad modifications of emails?
On Fri, Aug 19, 2022, Michael Peddemors via mailop wrote: > The reason we are seeing this behavior for 2 antivirus: Both AVG and Can you share which "bad modifications" are made? -- Address is valid for this mailing list only, please do not reply to it directly, but to the list. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] unknown domain in MAIL (outlook.com)
My system is getting spammed by outbound.protection.outlook.com First they are sending every 10 minutes to the same two unknown addresses until I blocked the sender (@emss.gov.eg) then it stopped. Now they are sending to the same addresses using lr...@incm.gov.uk as sender -- AFAICT the domain does not exist at all. Isn't that something which should be checked by them (it seems such a trivial thing to do)? -- Address is valid for this mailing list only, please do not reply to it directly, but only to the list. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Weirdly formatted messages from AOL Webmail or Yahoo
Can you give an example which shows this behaviour? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] FW: Did Google become stricter about RFC 5322?
On Fri, Jul 15, 2022, Michael Ellis via mailop wrote: > C:\Users\philipt>nslookup -q=mx csc-emarketing.trimaxdirect.com The MX record has nothing to do with this simple check. > 7/13/2022 11:12:35 AM Mail server: 550-5.7.25 [173.160.100.85] The IP > address sending this message does not have a > 550-5.7.25 PTR record setup, or the corresponding forward DNS entry > does not > 550-5.7.25 point to the sending IP. As a policy, Gmail does not accept $ dig +short -x 173.160.100.85 csc-emarketing.trimaxdirect.com. $ dig +short csc-emarketing.trimaxdirect.com. a 173.160.100.91 That's not a match. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] FW: Did Google become stricter about RFC 5322?
On Fri, Jul 15, 2022, Michael Ellis via mailop wrote: > Am I missing something as well? Google just rejected a client due to > PTR on mailop-boun...@mailop.org but it seems fine to me What is "PTR on mailop-boun...@mailop.org"? Can you post the rejection and the relevant logs? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Did Google become stricter about RFC 5322?
On Wed, Jul 13, 2022, Philip Paeps via mailop wrote: > As far as I can tell, the message is compliant. It doesn't have any of the Can you post it so others can check? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX? use A/AAAA
On Mon, Jun 20, 2022, Grant Taylor via mailop wrote: > When was the last time that anyone has seen the fall back to A record work? Which broken software has this bug? (an obvious RFC violation -- an "MTA" of one of those companies who don't care about RFCs anyway?) It works fine in the MTAs that I maintain, and I'm sure it works in postfix etc too. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] error msg (was: gmail changes today?)
On Thu, Jun 09, 2022, Johann Klasek via mailop wrote: > The whole line may look like this: > sendmail[12403]: 259I6JFw012399: to=, delay=00:00:01, > xdelay=00:00:01, mailer=esmtp, pri=139340, relay=gmail-smtp-in.l.google.com. > [IPv6:2a00:1450:400c:c00::1b], dsn=5.0.0, stat=Service unavailable > This is the common type of logging a DATA stage reject. Alas, the > rejecting message from the receiving MTA is not logged. sendmail logs it unless an old version is used: 8.16.1/8.16.1 2020/07/05 Log the actual reply of a server when an SMTP delivery problem occurs in a "reply=" field if possible. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Our experience on Gmail blacklisting our IPs range
On Tue, Apr 05, 2022, Paul Vixie via mailop wrote: > google e-mail addresses were signing up en masse for mailman lists here, and > the resulting confirmation e-mail from mailman was seen by google as spam. > i've since turned off confirmation e-mail, and i've added SPF checking to "confirmation e-mail": that would be the mail "please confirm that you want to subscribe to this list"? If you turned it off, does that mean anyone can subscribe addresses of all domains which do not use SPF? And all of that because Google has $#%!^! spam filtering -- way too many false positives. BTW: AFAIK "don't be evil" is not Google's motto anymore. -- Don't Cc: me, use only the list for replies. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What the f**k, Google?
On Thu, Mar 03, 2022, Bill Cole via mailop wrote: > Did I miss something? Maybe... I provided examples before. > I have no idea what GMail is rejecting in SMTP See Message-ID: <20220302163128.ga95...@veps.esmtp.org> I have no idea why GMail rejected those mails at the final dot. > and no one with a valid excuse to be mailing me there wouldn't have > other better contact means. So you have a "fallback" mechanism -- the guy who is trying to sell his house didn't provide one on the website. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What the f**k, Google?
On Thu, Mar 03, 2022, Bill Cole via mailop wrote: > Interestingly, none of my GMail accounts has ever had ham misclassified as > spam. Again: how do you know whether you didn't even receive a "ham" e-mail because it was "misclassified as spam" and rejected during the SMTP dialogue? Do you get a list of mails which didn't reach you? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What the f**k, Google?
On Wed, Mar 02, 2022, Graeme Fowler via mailop wrote: > Whilst I may occasionally - like 5 or 6 times a year - have something that > lands in the Junk folder, I almost _never_ receive âobviousâ spam in the > Inbox, and neither do they. How do you know you are not missing (important) mail? Some guy with an e-mail address @gmail wants to sell a house -- my mails don't reach him Announcements of a new version of an open source software were recently rejected by gmail, all the previous years there was no problem. How would those people know they did not get some mail? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IPv6 reverse DNS from office365
On Thu, Feb 10, 2022, Bill Cole via mailop wrote: > Yes, Microsoft has a chronic endemic problem of broken reverse DNS, > in both IPv4 and IPv6. It cannot be relied upon. So does Google reject mail from those misconfigured Microsoft systems? -- Please don't Cc: me, use only the list for replies. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] postmaster: envelope vs header
On Sun, Dec 05, 2021, Slavko via mailop wrote: > I think a little about it, but i cannot find other way than do not use > To: header at all, which will be penalized in my anti-spam SW latter. "What's the problem you are trying to solve?" Is this about the differences between envelope and header(s)? > My understanding the To: header syntax is, that it must be qualified, > but then there is no reason to not use that address in RCPT command > too. Or i miss something? The RFCs don't care much about your "anti-spam SW". AFAICT this was done as the most simple way to reach the postmaster at a host -- reducing the chance of being rejected due to some misconfiguration where a host does not accept mail for its own name or its own MX. (for more detail it's probably best to check the history of that special treatment in the ietf-smtp mailing list?) Of course there are those systems which are misconfigured in other ways as comcast demonstrates. -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] postmaster: envelope vs header
On Sun, Dec 05, 2021, Slavko via mailop wrote: > But, please, what about header: > To: postmaster > ... rejected after DATA: header syntax: unqualified address not > permitted: failing address in "To:" header is: postmaster The syntax for envelope addresses and header addresses is "a bit" different, and is a special case for SMTP but not for headers. Anyway, my mail was only about a clear violation of the (SMTP) RFC by comcast. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXTERNAL] comcast.net MX
On Sun, Dec 05, 2021, Alessandro Vesely via mailop wrote: > 220 resimta-h1p-037571.sys.comcast.net resimta-h1p-037571.sys.comcast.net > ESMTP server ready > rcpt to: > 550 5.1.1 Not our customer RFC 5321 SMTP October 2008 o The reserved mailbox name "postmaster" may be used in a RCPT command without domain qualification (see Section 4.1.1.3) and MUST be accepted if so used. Oh well... -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
I am not criticizing qmail for this behaviour. If you need another example: The Postfix smtp(8) client normally does not wait for the server's reply to the QUIT command, and it never waits for the TCP final handshake to complete. So now you have two people, who know that they are doing, having implemented the same behaviour. That's why I suggested the RFC should probably be changed (AFAICT there is currently work on a new revision?) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?
On Wed, Nov 24, 2021, Michael Peddemors via mailop wrote: > And then it terminates the connection, SSL collapses, without waiting for > the remote mail server to acknowledge the QUIT. Just like qmail? Maybe it's time to change the RFC? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] how to notify someone of an invalid MX?
On Sat, Jul 03, 2021, John Levine via mailop wrote: > >Mail from this host was rejected by a strict check: > >citaprevia.maspalomas.com. 300 IN MX 10 82.98.157.67. > To ask a fairly obvious question, since they clearly don't care whether they > ever get > any mail, why would anyone else care? Anyone whose MTA performs a strict check on the sender address will not get an e-mail confirmation of an appointment that they tried to schedule via the website of the local townhall. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] how to notify someone of an invalid MX?
Mail from this host was rejected by a strict check: citaprevia.maspalomas.com. 300 IN MX 10 82.98.157.67. I sent mail to postmas...@citaprevia.maspalomas.com postmas...@maspalomas.com dnsad...@tsai.es the latter due to: maspalomas.com. 300 IN SOA nsjc8hos10.telefonica.es. dnsadmin.tsai.es. 2013050359 86400 7200 2592000 300 the first two are unknown addresses... the third finally came back with "mailbox full". For now I disabled the strict check for that domain, but it would be nice if it would be possible to notify someone to fix the MX record, e.g., citaprevia.maspalomas.com. 300 IN MX 10 citaprevia.maspalomas.com. -- Please don't Cc: me, use only the list for replies. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM+DMARC at t-online.de (Deutsche Telekom's ISP branche)
On Tue, Apr 06, 2021, Michael Grimm via mailop wrote: > Will you at t-online.de accept DANE/TSLA as an alternative? How does DANE/TLSA help the recipient (server) to "verify" the sending host? > Or do I need to add DKIM signing in addition? coming next: "you must include a copy of your passport ..." "you must pay us money if you want to send us e-mail" "you can only send us e-mail via Google or Apple" just like in the bad old times when you were only allowed to connect "official" phones/modems/... to their phone lines? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] PRDR (was: Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?)
On Fri, Jan 22, 2021, Patrick Ben Koetter via mailop wrote: > The only reference to PRDR I could find, is an expired RFC draft. Is that what > you are referring to? Yes. Something like this: Eric A. Hall. Smtp service extension for per-recipient data responses (prdr). Draft, Internet Engineering Task Force, 2007. exim might have some documentation too. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?
On Fri, Jan 22, 2021, Benot Panizzon via mailop wrote: > Now Assume two recipients with different Anti-Spam Settings: ... That's what PRDR is for, but it isn't supported by many MTAs or setups :-( ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 17.12.20 23:07, Mark Fletcher via mailop wrote: > If this is really an issue, why don't we have backup A records as well? > My website is just as important as my MXes, yet I do just fine without A > record priorities... This is somewhat off-topic here, but I guess you would use multiple A records for such a case. -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the reply-to header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailop.org: using STARTTLS for outgoing mail?
On Wed, Sep 30, 2020, Tim Bray via mailop wrote: > Should it be using TLS for outbound connections??? I'm not seeing that? Received: from mx.mailop.org (mx.mailop.org. [91.132.147.157]) by ... with ESMTPS (TLS=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, verify=OK) > Received: from mx.mailop.org ([2a03:4000:37:599:d8ce:dff:fee1:81c2]) > by herm.doylem.co.uk with esmtps (Exim 4.92 #3 (Debian)) ^ Doesn't the "s" mean STARTTLS was used? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Website down?
On Mon, Aug 31, 2020, Mark E. Jeftovic via mailop wrote: > So the list archives are still down then? I tried to contact owner- about it but got a bounce, while request- was at least delivered. > I was hoping to link to a thread. I was looking for that too and found https://www.mail-archive.com/ [now let's see whether some SW screws up Reply-To: again - replies should go to the list...] ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"
On Wed, Aug 26, 2020, Michael Peddemors via mailop wrote:
> There SHOULD be a URL associated with the domain ('mydomain.com') in the PTR..
Ah, the stuff you suggested on ietf-smtp and which got "rejected" by
pretty one every one who replied?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"
> But it was enough to have the imprint visible for them just for the Sorry for a stupid question: What is "the imprint"? Does that mean you have to operate a web server with an "Impressum" (I guess that's the German word?) if you want to send mail? ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Unable to receive email from WeTransfer and Facebook (only for a specific domain)
On Sun, May 17, 2020, Alessio Cecchi via mailop wrote: > the domain name is stefanoboschi.it and after the transfer from one dig stefanoboschi.it. mx stefanoboschi.it. 3500IN MX 10 mx01.cbsolt.net. stefanoboschi.it. 3500IN MX 20 mx02.cbsolt.net. connecting to mx01.cbsolt.net ... RCPT TO: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) Looks like the MX record is wrong or the server is misconfigured. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] DNS issues: mta*.ealerts.bankofamerica.com
Talking about RDNS issues: Since Saturday bankofamerica.com seems to have a problem with their DNS too -- I tried to contact them directly but (so far) nothing happened. Their "alerts" are sent by hosts with IPs like 68.232.194.1 - 68.232.194.14 (exacttarget?) which map to mta*.ealerts.bankofamerica.com. but those names do no longer resolve in DNS. dig -x 68.232.194.1 ... 1.194.232.68.in-addr.arpa. 16487 IN PTR mta.ealerts.bankofamerica.com. dig mta.ealerts.bankofamerica.com. ... ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39478 ealerts.bankofamerica.com. 353 IN SOA ns10.bac.com. domain\.administrator.bankofamerica.com. 2020042499 1800 900 604800 600 Maybe someone who can fix the problem reads this? ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] correos.es unreachable?
On Mon, Feb 17, 2020, ngel via mailop wrote: > I contacted them in order to warn them about the issue. They are not > aware of any email issue and asked for the destination mailbox that had > problems. I was given the e-mail address correosduap...@correos.es from a local post office and it worked fine from Nov 2019 to end of Jan 2020. I just checked my mailbox again and also found the .com address, so I will use that from now if needed. Many thanks for your help! ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] correos.es unreachable?
I hope this is the right place to ask questions like this. I've been in contact with correos.es for a while about a problem with a package the is on the way to me. But for about two weeks now their mailserver is no longer reachable from my hosts (I tried 3 different hosts in 3 different countries). correos.es. IN MX 5 mx.cep.correos.es. mx.cep.correos.es. IN A 193.148.128.133 Is this a general problem? If so, can someone please notify correos.es to fix it? ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
Usually I don't reply to top-posted mails... 1. Try with openssl s_client -connect other.host:25 -state -debug -crlf -starttls smtp ... and add parameters to match your sendmail setup. 2. See cf/README how to set the option in your mc file: confCIPHER_LIST CipherList [undefined] Cipher list for TLS. 3. If you post changes you made, then post real data, not something like tls_srv_featuresCipherList=... because that doesn't tell someone else whether you used the right key(s). 4. you can use the same openssl command against your server to see whether your config changes actually have the desired effect. 5. If the problem persist, you need to provide more data, e.g., real hostnames, your .mc file, and so on. PS: there's a usenet group for sendmail questions :-) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
On Thu, Jan 23, 2020, John Covici via mailop wrote: > Jan 23 17:51:33 debian-2 sm-mta[7625]: STARTTLS=client, error: connect > failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1 AFAICT it's the key from "the other side" that openssl is complaining about -- did you recently upgrade it? You could disable the DHE ciphers, e.g. something like this (note: you have to "match" this with your openssl version and the ciphers it supports): O CiphersList=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:AES128-SHA:DES-CBC3-SHA Note that that must be one very long line. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Reasons to add plain text alternative to email?
I don't read HTML mail unless absolutely necessary (i.e., I "need" the information that the mail contains); I don't want to trigger all the tracking stuff in the HTML part. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [FOR THE RECORD] Large Scale Windows Bot traffic..
> MAIL FROM: @marketplace.amazon.in A strict syntax check would reject this :-) (e.g., no space after : allowed) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Best strategy to prune address list
On Sun, Nov 24, 2019, Michael Orlitzky via mailop wrote: > For the same reason, I would recommend verifying the addresses against a > simple regular expression to catch typos, rather than against the full > rfc5322 grammar which allows basically anything. Hopefully not the one which is used on most websites that excludes the use of + in localpart :-) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Best strategy to prune address list
On Sat, Nov 23, 2019, Tom Ivar Helbekkmo via mailop wrote: > In the olden days, one would simply write a script, using expect(1) or > similar, to go through the addresses, connect to the target MTAs, and do > an SMTP VRFY on the recipient address. Today, I suspect that most MTAs Some MTAs have a "sender verification/callback" functionality (also available in "milters"), AFAICT they simply use "RCPT". There are most likely standalone versions/tools too (I have one). ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] delivery problems from mimecast.com
On Thu, Nov 21, 2019, Carl Byington via mailop wrote: > My servers have Let's Encrypt certs for sendmail, and receive a fair bit > of mail from mimecast. Just to clarify: If I understand it correctly, there are configuration options how to handle STARTTLS which mimecast customers can modify, e.g., maybe something like access map entries in sendmail: TLS_Srv:example.com VERIFY My server also receives a lot of mail from mimecast without problems (e.g., RedHat notifications). ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Best Re-engagement Email
On Wed, Sep 18, 2019, Michael Rathbun via mailop wrote: > opened or clicked within the past four months, and says, essentially, "If you > want to continue to receive email from us, click here. Otherwise, you won't I hate that stuff... beside the annoyance of requiring web stuff to receive info via e-mail, there's also the security problem of clicking links in e-mails -- isn't that something people are being told for ages NOT to do? ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
