Re: [mailop] opendkim bad signature data from mx.mailop.org
Hi Mary, At 08:05 AM 06-11-2020, Mary via mailop wrote: Anyone knows why emails from the list are rejected by opendkim? [snip] On-BadSignature reject The message body is modified as it goes through the list. The DKIM signature verification fails because of that. The above configuration setting tells OpenDKIM to reject the message. Regards, -sm ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Just how does SendGrid fail this badly?
Hello, At 05:23 AM 18-08-2020, Atro Tossavainen via mailop wrote: The SendGrid account sending these yesterday is 13999362. I am receiving emails from Sendgrid about "Nedbank Credit Card monthly Charges eStatement". The account is 17343945. It looks like a phishing attempt. Those emails originate from 149.72.32.249. Regards, S. Moonesamy ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
Hi Chris, At 09:52 AM 02-02-2020, Chris Adams via mailop wrote: Just an idle Sunday question... how long do you have your mail server(s) configured to queue and retry messages before bouncing them back to the sender? I use five days. That may need to be tuned if the queue is filling up because of delivery issues. I also use "DELIVERBY" for some messages. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Are there any de facto standards around no-reply@ addresses?
Hi Grant, At 05:12 PM 10-04-2019, Grant Taylor via mailop wrote: The back story in this case involved two such systems that were naively replying to each others no-reply address. I'm used to things like Auto-Generated: and X-Loop* headers. But I'm not aware of any de facto standard around no-reply addresses. The "Auto-Submitted" header field might help (RFC 3834) to avoid a loop. I guess that nore...@example.com is intended to inform the person reading the email that he/she should not reply to it. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] What should an MTA do when receiving 452 4.5.3 (aka too many recipients)
Hi Benoit, At 12:29 AM 13-12-2018, Benoit Panizzon wrote: So based on my observation I wonder... Upon receiving a 452 4.5.3 error, what should the sending MTA do? Reconnect immediately and re-try the soft failed recipients as would be done with the usual 'too many recipients' situation? Or is it correct to wait for the backoff timer? Is there an RFC defining the reaction to specific error codes? What is the sending MTA exactly looking at when receiving an error code? Only the first 452? Combination of "452 4.5.3" or even trying to parse the text behind usually 'too many recipients' which we changed this to 'incompatible recipient settings' and this may cause this issue? The enhanced status code reports the error condition, e.g. "too many recipients". The status code in the above is defined as "insufficient system storage". It does not make sense to immediately reconnect if the receiver says that it has insufficient storage space. Please see RFC 3463 and RFC 5321 for more information. Regards, S. Moonesamy ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?
Hi Rob, At 01:08 PM 06-06-2018, Rob McEwen wrote: Here is an article I posted on Linkedin about spam filtering IPv6-sent email. "Should mail servers publish IPv6 MX records? Could this harm your spam filtering?" In other words, DNSBLs have a scalability problem. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
Hi Paul, At 03:40 AM 25-05-2018, Paul Smith wrote: I wish that was the case, but it's not what GDPR says, certainly for SMTP relay services The organization running the service would be the "processor". Did you ask the ICO whether there is any guidance for a SMTP service? Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail & TLS SNI
Hi Phil, At 11:28 AM 17-04-2018, Phil Pennock wrote: RFC 3207 is the closest to a profile document which SMTP MX delivery has, since RFC 7817 explicitly excludes MX coverage. 3207 doesn't explicitly cover SNI since it predates the earliest RFC I know of covering SNI. The only standards-track document I know of touching this topic for SMTP/MX is RFC 7672 for DANE, and for the DANE case, Exim always sends SNI. There is some information in RFC 6125. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] question regarding support for international characters
Hi Annalivia, At 03:22 AM 09-04-2018, Annalivia Ford wrote: I've been tasked with finding out what the general consensus is on the support in email headers for International characters such as UTF-8 Charcacters and including things like accented characters like é and å and can also include Asian and Cyrillic characters. I know there's an RFC from 2012, but my Product Dev people are interested in knowing how wide-spread the actual adoption is. There was a report about it: https://cnnic.com.cn/IC/Events/201511/t20151110_53004.htm Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Issues delivering to Hotmail addresses
Hi Michael, At 12:20 PM 24-01-2018, Michael Wise via mailop wrote: Hack: an in-elegant solution that one personally doesn't like, but that appears to work. As to the retry interval, I feel a bit out of my depth on that one, and I guess it all depends on exactly WHY the 452 was thrown, but ... the implication seems to be that an immediate retry (maybe give it a few seconds?) would be the preferred way to handle it, maybe with some sort of exponential back-off? The "immediate retry" could be read as "immediate". From a receiver's perspective, that does not sound like a good idea. Why would the receiver's implementation require segmented delivery? Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] 550 sending to hotmail.com
Hi Michael, At 12:47 PM 26-10-2017, Michael Wise wrote: Ticket numbers are ALWAYS helpful... even if not for me. The ticket number is SRX1402095036ID Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] 550 sending to hotmail.com
Hi Chris, At 12:32 PM 26-10-2017, Chris Truitt wrote: Had this happen a coule of weeks ago. Highly unusual for us. No spikes in complaints and no real explanation from Outlook for it. To their credit, the team was responsive to my removal request. I found it unusual given that there wasn't any complaint. Did you substantially increase sending volume? No, the sending volume to hotmail.com is very low. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] 550 sending to hotmail.com
Hello, The hotmail.com mail server is rejecting messages from my mail server with the following error message: "550 5.7.1 Unfortunately, messages from [162.213.2.210] weren't sent. Please contact your Internet se...ail.live.com/mail/troubleshooting.aspx#errors. [SN1NAM04FT051.eop-NAM04.prod.protection.outlook.com]" Would it be possible to have the IP address mitigated [1] as it is not used for sending "unwanted" emails? Regards, -sm 1. I'll provide a ticket number if it that would be useful. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Best rate limiting response?
Hi Luis, At 05:22 PM 11-09-2017, Luis E. Munoz via mailop wrote: Over the years I've seen rate limiting responses as 421 and 451 (with the first being the most frequent). Is there a consensus in what the correct code should be? I'm going through RFC-5821 and none of the codes mentioned there seem to be a perfect match to "hitting a rate limit for an authenticated user" in my submission servers. Given the above, I'm leaning towards using 421, returned after each and every MAIL TO command. This is about mail submission (RFC 6409). 550 would be the closest (SMTP) reply code for what the MSA is trying to communicate to the MUA [1]. Regards, -sm 1. I assume that you meant "MAIL FROM" ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] CBL & c_sludge
Hi Kirk, At 06:37 07-07-2017, Kirk MacDonald wrote: Struggling a bit to understand a development this morning about MTAs being listed on Spamhaus for a CBL listing for something called c_sludge. The Googles has really nothing helpful about what c_sludge is. It might be about a spambot ( https://forums.att.com/t5/AT-T-Internet-Email-Security/ATT-outgoing-email-is-being-blocked-by-spam-filter/m-p/5199721 ). Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] RFC question on smtp replies...
Hi David, At 02:27 07-07-2017, David Hofstee wrote: I've an interesting RFC question. In an SMTP reply, one can have single line or multiline replies. E.g. 521 single line reply or 521-Line one 521-Line two 521 Line three See also <https://tools.ietf.org/html/rfc821#page-50>https://tools.ietf.org/html/rfc821#page-50 . My question is: The reply is an answer that is, necessarily, formatted for SMTP. But how should the multiline answer be interpreted? What is its 'value'. The reply "text" is text except in some cases (see RFC 5321) where a string with a mailbox name is returned. Sometimes, the "text" is used to convey some unstructured information which might be useful to the other end. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] autoresponders & envelope-from/return-path
Hi Autumn At 14:57 05-06-2017, Autumn Tyr-Salvia wrote: Any idea what the impact of turning on the return-path for autoresponders would be? Colleagues tell me that the hosted mail service (Proofpoint) tells their clients not to use a return-path address for autoresponders because this is the RFC-correct way to do it. We could probably get them to make an exception here, but I'm curious if there is any real world impact to that. The "Return-path" header is appended at the message delivery stage. The is a discussion of autoresponder in RFC 3834. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] dkim signature failures sendmail/opendkim
Hi Carl, At 08:00 26-05-2017, Carl Byington wrote: I have been unable to reproduce this by sending test messages to my google test account. It may not be specific to sendmail/opendkim, since I also see the same infrequent errors with another domain: Can you capture the message at the receiving end where DKIM verification failed and compare it to the message which was sent out? Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF record
Hi Frank, At 06:52 21-05-2017, frnk...@iname.com wrote: Do you think the sending domain was not aware of that when they wrote the policy? I have come across cases where the sending domain was not aware of the impact of its SPF policy. That does not mean that sending domains are not aware of what will happen because of their policies. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF record
Hi Kurt, At 05:25 21-05-2017, Kurt Jaeger wrote: Can you tell more about this ? Why is '-all' bad ? You are assuming that when the message is delivered to the receiver, it will see a connection from the sending IP address. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] False positive on spoofing
Hi Scott, At 08:06 05-01-2017, Scott E Bonacker CPA wrote: Since upgrading to a new laptop with OEM Win10x64, and OL2016 connected to an Office365 account, I have also been sending messages to various lists via POP using a domain The messages are sent via SMTP. different than the one registered with Office365. That has resulted in false positive alerts when messages are distributed by some systems - the alert below was inserted by LISTSERV-TCP/IP release 16.0. Interestingly, msgs distributed by Yahoo Groups don't get There is a SPF record for your domain name. The record does not permit messages to be sent through Office365. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] lists.opendkim.org?
Hi Andreas, At 07:55 07-10-2016, Andreas Schamanek wrote: Does anyone know what is down with lists.opendkim.org? I cannot reach it, however http://lists.elandsys.com seems to work fine except that all links point to lists.opendkim.org. Sorry about that. I'll try and get it fixed. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] ADSP query: '_adsp._domainkey.live.com' reply was unresolved CNAME
Hi Jim, At 07:27 02-05-2016, Jim Popovitch wrote: Why am I seeing a hostname as the reply for an ADSP lookup? ~$ dig TXT _adsp._domainkey.live.com rds.live.com.nsatc.net. ;; ANSWER SECTION: _adsp._domainkey.live.com. 3600 IN CNAME rds.live.com.nsatc.net. ;; QUESTION SECTION: ;test.live.com. IN TXT ;; ANSWER SECTION: test.live.com. 3600IN CNAME rds.live.com.nsatc.net. http://www.rfc-editor.org/info/rfc5617 says that the status of ADSP is "Historic". Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail throttles anyway
Hi Michael, At 17:27 04-02-2016, Michael Wise wrote: If you're going to do something that will break the DKIM signature as a matter of course, You should remove the DKIM signature, and maybe re-sign it with your own. You shouldn't break the signature and then forward what was once goodmail with a now busted signature. The issue with removing a DKIM signature which would get broken is that it is not easy to reverse the removal in future. It is better [1] to treat the "broken" DKIM signature as unsigned. Regards, -sm 1. This depends on the receivers you are sending mail to. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Delivery to gmail via IPv6
Hi Tony, At 05:39 08-12-2015, Tony Finch wrote: This isn't competing standards, this is a fundamental feature of one standard. Ian is prefering to use exactly the same terminology as RFC 5321 section 6.2: If they cannot be delivered, and cannot be rejected by the SMTP server during the SMTP transaction, they should be "bounced" (returned with non-delivery notification messages) as described above. The discussion was about what to do when there is a DNSSEC failure. You mentioned treating that condition the same way as a DNS failure. The receiving side can treat it as a temporary condition or reject the message to avoid retries as the DNS failure would not be fixed. As you pointed out, it is not about competing standards. There was this question from Brandon Long: "Are you even going to know there's an issue if the message is just sitting in a queue instead of delivering or bouncing?" It depends on whether the sender is monitoring the logs or getting complaints from his/her users. The complaints might come in faster when there is a rejection. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Delivery to gmail via IPv6
Hi Ted, At 18:00 03-12-2015, Ted Cooper wrote: So whomever runs 0.4.2.ip6.arpa has screwed up their key roll over and the entire branch is now unsigned?! organisation: APNIC Anyone know who to poke to get that fixed? APNIC is a RIR. You can send an email to their helpdesk. Feel free to drop me an email if that does not work. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Canonicalization
Hello, At 13:22 16-10-2015, Luke M wrote: I was wondering if anyone would share their thoughts on RFC 1123 section 5.2.2. It states: The domain names that a Sender-SMTP sends in MAIL and RCPT commands MUST have been "canonicalized," i.e., they must be fully-qualified principal names or domain literals, not nicknames or domain abbreviations. A canonicalized name either identifies a host directly or is an MX name; it cannot be a CNAME. Does anyone know the reasoning behind this guideline? It seems like it is widely ignored. That section of RFC 1123 is no longer used. Are there any benefits to following this guideline? Or pitfalls for not following it? Will some receiving servers have trouble finding the MX record if the MAIL FROM domain has a CNAME? Please see Section 5.1 of RFC 5321. There are two issues in the text which you quoted: (a) the name is not a FQDN (b) CNAME If I recall correctly, (a) is about whether the delivery is local or not. The second issue is about email addresses rewrites. There has been quite a lot of discussion about (b) over the years. The benefit of following the guideline is that you don't have to worry about edge cases. Regards, -sm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Microsoft sending multiple Message-ID headers in password reset links..
Hi Michael, At 11:44 15-09-2015, Michael Wise wrote: No, it doesn't. After all, technically Message-ID is an optional field. I bitch and moan about that, but nobody cares... They all end up pointing to, "SHOULD", and I can't really do anything but :'( It is recommended to add a "Message-ID" field if there isn't one in a message. There are reasons why that is not always done. You did your part; that's good enough. Regards, -sm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Help with definitions in RFC5598
Hi Matthew, At 10:08 09-07-2015, Matthew Black wrote: SINK, used in Section 2.1.4 (paragraph 2). It appears to have a mathematical meaning that does not appear as one the 40 definitions in my dictionary. I grasp what they mean, but I want a dictionary type definition. It's been more than 30 years since I studies Calculus, so please avoid use of higher math in your definition. My reading of "sink" in that paragraph is that it does not have a mathematical meaning. The term has been used in other RFCs; there is a distinction between "source" and "sink", e.g. output sink. ADMD, Administrative Management Domain. The document dances around the term. However, it is never explicitly defined. I suggest viewing ADMDs in terms of administrative boundaries. Section 2.3, Paragraph 2 discusses about that. Regards, -sm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to A record if MX exists ?
Hi Kurt, At 01:16 17-06-2015, Kurt Jaeger wrote: 5.1. Locating the Target Host can be read that MX records have preference, but it explizitly avoids mentioning "A or " records if no MX is found. The sentence: [...] If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. [...] implies a A/ DNS query, but does not explicitly state so. That section explains how to locate the target host. The section also has the following: 'the "implicit MX" rule above applies only if there are no MX records present' Regards, -sm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
