Re: [mailop] SMTP noise from *.bouncer.cloud

[Luis E . Muñoz via mailop]

On 5 Sep 2022, at 18:07, Atro Tossavainen via mailop wrote:

>> This is a bit less clear, but I'd say that is fine because you have
>> every reason to believe that you are acting on behalf of the address
>> owner, not some 3rd party who may not have acquired the address
>> legitimately.
>
> This, too, can be co-opted by people who aren't your users.

And then, typos. I currently count at 7 the number of persons that believe that 
my 10+ years old Gmail account is theirs. I routinely receive bank, telecom and 
government communications from citizens of 4 Latin American countries.

The address verification would still work in this case—after all, it is a valid 
email—just not for the person filling the form / providing the data.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging MTA-STS sending

[Luis E . Muñoz via mailop]

On 9 Aug 2022, at 10:27, Tobias Fiebig via mailop wrote:

> This is interesting. The certificate for tls-invalid should a) not match the 
> CN, and b) be expired. The ": b'84:OK secure 
> match=tls-invalid.measurement.email-security-scans.org servername=hostname,'" 
> is hence a bit confusing. Also just tested it with 'openssl s\_client 
> -starttls smtp -crlf -connect 
> tls-invalid.measurement.email-security-scans.org:25' just now, and the CN 
> does indeed not match.

https://esmtp.email/tools/mta-sts/ also is reporting on a missing DNS policy. 
The cert is reported as expired as well.

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] HR 8160 and SB 4409: The "You're not allowed to run political campaign email through your spam filter" act

[Luis E . Muñoz via mailop]

On 29 Jul 2022, at 14:32, Anne Mitchell via mailop wrote:

I want to be sure that everyone here is aware of a piece of pending 
legislation in the U.S. that is in committee in both the House and the 
Senate right now. It's called the Political BIAS Emails Act of 2022 
(BIAS is short for “Bias In Algorithm Sorting”), and it requires 
that, and I quote:


Just in case others are inclined to try and convince their 
representatives, I drafted and sent the below, use as desired.


```
I am sending this communication to request your support by opposing H. 
R. 8160 ("Political Bias In Algorithm Sorting Emails Act of 2022"). I 
have been a registered voter for [years] and intend to continue actively 
participating in all upcoming elections.


Unsolicited electronic communications—spam—constitute a very serious 
problem to all users of communication services regardless of social or 
economic distinction. The industry has responded by creating a plethora 
of mechanisms that help mitigate this issue, returning some semblance of 
normality to our electronic mailboxes and phones.


An unfortunate reality is that in their efforts to reach as wide an 
audience as possible, the political campaigns—or its 
collaborators—very often step over industry best practices and end up 
sending vast amounts of unsolicited communications. The special 
treatment that political actors receive from CAN-SPAM further reduces 
the remedies available for operators, tasked with handling the barrage 
of unsolicited messages as well as the complaints of the disgruntled 
public that gets targeted during the electoral season.


H. R. 8160 introduces the notion that users must directly apply a 
"label" to an email prior to the operator being able to act accordingly. 
This proposed arrangement would be detrimental to the user because it 
requires  an action to respond to what is in essence an unsolicited 
message. Of note, said user has likely chosen the operator that provides 
its email services consciously, considering factors that often include 
the ability to block spam. By forcing users to receive these unsolicited 
messages prior to any labeling, H. R. 8160 attacks individual choice.


Furthermore, well-funded political campaigns can produce an endless 
stream of ephemeral "collaborators"—e.g.: connected organization or 
joint fundraising committees—that could relentlessly send email 
communications to users that have not solicited them. Even diligent 
users promptly labeling those messages as spam, would continue to 
receive them, without even the ability to have the operator assist with 
its automated filters. This type of behavior has been considered abusive 
for a long time in the email industry.


H. R. 8160 also introduces a loophole that could be exploited by 
malicious third parties, which acting as political campaigns, could use 
the special status granted by this legislation as a way to send spam and 
phishing email—email designed to trick the recipient into some 
nefarious activity—in vast quantities. Combined with the massive data 
breaches that have been reported in the last few years alone, the 
consequences of such exceptions as described in H. R. 8160 are 
terrifying.


As currently written, H. R. 8160 will only serve to worsen the status 
quo, by forcing operators to process and deliver the high volume of 
unsolicited communications. Passing this unfortunate piece of 
legislation is akin to providing a license to spam to all political 
campaigns—and impostors—which will result in more user complaints 
and additional costs for US-based operators.


Furthermore, by preempting US-based operators to take action against 
unsolicited political communications, H. R. 8160 will cause users to 
migrate to service providers outside the US, with the potential to 
impact jobs, competitiveness and value generation within our own 
economy.


In closing, please consider blocking H. R. 8160 and contrary to this 
legislation, pushing for regulations that restore the ability of email 
users to use their mailboxes.


Sincerely,


```

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Luis E . Muñoz via mailop]

On 25 Jul 2022, at 11:00, Laura Atkins via mailop wrote:

>> In the current state of affairs, ESPs presume they know more than the 
>> receivers, so they keep trying to send. Since the ESPs essentially disregard 
>> the 5xx codes using the line of reasoning that you described,
>
> The ESPs are not disregarding the 5xx. They’re actively respecting it, and 
> not attempting a second delivery of the message that received the 5xx.

Of that message, sure. A new message from the same sender will be attempted. A 
new message from a different sender will also be attempted.

With the current state of affairs, a steady stream of 550 5.7.1 responses does 
not guarantee that the ESP will stop sending to the email address. This 
scenario is untenable, regardless of which party wants to keep it as is.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Luis E . Muñoz via mailop]

On 23 Jul 2022, at 4:17, Laura Atkins via mailop wrote:

> I agree, it would have been nice if the authors of 821 and 822 had considered 
> this use case and provided us with semantics. Unfortunately, the semantics 
> described in those RFCs (and their successors) only talk about what to do 
> with the message that is rejected. There are no semantics or recommendations 
> about what to do with future messages to the addresses that failed to accept 
> the mail.

True. But 821 has been revised multiple times just as 822. Perhaps this is 
something to bear in mind in their next revision.

> And on the receiving side it’s not much better. All too many receiving 
> mailservers don’t use the codes specified in the RFCs and decide to use their 
> own implementation. A very large ISP, for instance, uses “451 this message 
> will never deliver” as part of their repertoire of bounces. Another widely 
> used filter rejects everything with 571 5.7.1 and in order to determine what 
> the problem is, the sender needs to visit a webpage to search for a specific 
> code in the text string of the bounce.

And I bet there are colleagues at those ISPs that are not happy with that 
implementation. Giving them incentives to drive the change would help.

> Consider the case where Microsoft spits out a incorrect and false 550 user 
> unknown (which happens every couple years). What you’re suggesting is that 
> when this happens the next time, Gmail block every gmail user from ever 
> sending to those hotmail users at any point in the future. That’s what you’re 
> asking for. Unfortunately, it doesn’t take into account the actual realities 
> of sending at scale.

Perhaps if ESPs responded to that issue by effectively marking Microsoft 
addresses as undeliverable, would provide the incentive for MS to actively 
avoid that issue.

One of the lessons I've learned over the years is that protecting organizations 
from the consequences of their own errors does not necessarily produce the 
intended effect. Again, incentives.

> This is actually a problem, one I’m working with various folks in the 
> industry to address in a way that preserves the functionality of email. I’m 
> probably going to step away from this discussion now, though. There’s nothing 
> being suggested here that hasn’t been tried and failed in the past.

I for one, am happy to have people of your stature working on that issue. I 
just hope that you take away the idea that while incentives are not placed 
where they need to be, there will be no improvement, just more half-solutions.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Luis E . Muñoz via mailop]

On 24 Jul 2022, at 4:38, Laura Atkins via mailop wrote:

> We’re trying to pull ‘what to do with a completely different message that 
> might be sent in the future, possibly by a completely different sender' out 
> of a signalling system that was never designed to convey that signal. And, 
> yes, even the eSMTP codes RFCs are about this message in this SMTP 
> transaction. They don’t convey what to do with future mail, either.

This poses a (perverse?) choice on the sender side.

In the current state of affairs, ESPs presume they know more than the 
receivers, so they keep trying to send. Since the ESPs essentially disregard 
the 5xx codes using the line of reasoning that you described, there is less 
incentive for ISPs to implement enhanced codes. Clearly the ESPs chose the 
interpretation that maximized short term gains to them, no surprises here.

Had the ESPs chose to actually stop sending on 5xx codes, ISPs would have been 
forced to implement the enhanced codes—or engineer their rules/filter engines 
differently—so that recipients wanting to stop only a specific stream would 
have a means to do that. Taken this a bit further, we could even have enhanced 
status codes to signal conditions transcending the single in-flight message. 
Even list unsubscribes would be simpler if we had an enhanced code to signal 
this condition!

Nowadays the ecosystem responds by counting errors and applying more stringent 
blocks (drop packets, terminate sessions at HELO, etc.); or with explicit list 
unsubscribe mechanisms, with both eating up more resources from all parties 
involved. I don't think this is an optimal state. By thinking in isolation we 
will continue to paint ourselves in the corner.

>> Recipient systems don't have a whole lot of incentive to provide those codes
>> because they correctly believe that most senders will ignore them, and some
>> senders will use them to try to game their filters.
>
> And many recipient systems don’t have enhanced SMTP codes at all. Yahoo 
> doesn’t, for instance. Mimecast handles a lot of SMB mail and they don’t 
> provide them, either. A bunch of the German mailbox providers don’t provide 
> them. In fact, I’d say that eSMTP codes are the exception, not the rule.
>
> At the risk of derailing the conversation by providing actual facts and 
> numbers:
>
> Client 1 B2B list: short excerpt of bounce logs. 882 entries, 734 do not have 
> eSMTP codes (84%) .
>
> Client 2 B2C list: short excerpt of bounce logs. 141,142 entries. 116,243 do 
> not have eSMTP codes (82%)

My data looks even worse than yours in terms of enhanced SMTP code support. To 
me this is a sorry state of affairs.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Luis E . Muñoz via mailop]

On 24 Jul 2022, at 22:09, Ángel via mailop wrote:

> Now, if we instead have the hash bbbaa1af939a01d0e22286c63827d936
> If you can hash multiple emails until finding who that refers to, then
> it's equivalent to the email. But if it is also the hash of other email
> addresses jsmith@hotmail.example and janedoe@gmail.example then itwould be 
> considered to be anonymized.

But in this case, you already have the email address so there is no value in 
finding the corresponding hash value. You already have the PII.

The value in using hashes is that having a collection of hashes is not 
equivalent to having a collection of emails. You would still need to use brute 
force—e.g., try every possible email address—to determine if the hash for that 
address is present. And even this would not help in determining which person is 
referenced by the identifier (the email address).

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Luis E . Muñoz via mailop]

On 22 Jul 2022, at 13:10, Atro Tossavainen via mailop wrote:

[✄ but thoroughly read]

> Becoming a data controller entails needing a legitimate basis for
> processing the personal data of the customer's customers, with whom
> the ESP does not have any kind of a direct business relationship so
> it's really very hard to justify. You can probably pull the notes on
> "so, you want to be a data controller" from the past conference
> proceedings from the members area.

I love this angle!

If we agree that IP addresses, email addresses and real names are all PII as 
per GDPR, your example is comparable to Cloudflare.

The end-user browsing a website is sending PII (its IP address, along with 
cookies and whatnot) to CF, which it then forwards to the proxied website. The 
visitor that does not know how to block cookies on their browser, also cannot 
know it is sending its PII to CF.

Does this turn CF into a data controller? If CF decides that the end user is 
indeed a bot because of data gathered among various CF clients, does it become 
a data controller?

Going back to the example of an ESP, does the hash of the email address equate 
the email address as per GDPR?

Happy weekend!

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Luis E . Muñoz via mailop]

On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote:

>> This would allow the ESP to quickly "fail" the API request to send to that 
>> email address. There are other metrics that could be tied into those 
>> addresses and used to provide a more expedite response to the caller, which 
>> incidentally would also help deter abuse.
>
> In many, many cases the issue is that other customers are mailing to the same 
> address - and just because an address bounces for X sender doesn’t mean that 
> it shouldn’t be mailed for Y sender. One clear example is when senders push 
> individual user blocks out to the SMTP transaction.

I question your assertion that "bounces for X sender doesn’t mean that it 
shouldn’t be mailed for Y sender". If recipient R has a history of blocking 
many senders, continuing to send from other senders is not worth it in the long 
run for the ESP. Just as receivers reject with errors such as "this account is 
receiving email at a rate that...", the ESP could respond to its client with 
"this receiver has a history of bounces / rejections / complaints that is 
incompatible with our policies...". Forcing a COI at that stage would revert 
this status and return to the status quo. Implementation in small steps. But 
this require the ESPs to willingly step out of the box to want to make things 
better.

The economic incentives are likely not there, unfortunately.

> This is another “simple” solution that demonstrates a significant lack of 
> understanding of how bulk email is sent.

It could be argued that your response demonstrates a significant resistance to 
change. The status quo is not cutting it for a growing number of participants 
while the only ones making money, are the ones selling filters and consulting.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Luis E . Muñoz via mailop]

On 22 Jul 2022, at 6:31, Laura Atkins via mailop wrote:

> I’m agreeing there is a problem with ESPs and have said so to ESPs 
> individually and as a group over the last few weeks.

Something that I don't see mentioned often enough and that would help, is to 
retain records of bounces—even of hashed email addresses vs the bounce. This 
would allow the ESP to quickly "fail" the API request to send to that email 
address. There are other metrics that could be tied into those addresses and 
used to provide a more expedite response to the caller, which incidentally 
would also help deter abuse.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Paging Cloudmark

[Luis E . Muñoz via mailop]

I would appreciate any pointers to a colleague at Cloudmark. I need assistance 
with a false positive and the regular contact / delisting process seems to not 
be working.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Contact at NameCheap?

[Luis E . Muñoz via mailop]

On 15 Jun 2022, at 12:37, Anne Mitchell via mailop wrote:

> Does anyone have a technical contact or an abuse contact at NameCheap?

The contact information they publish in their WHOIS (for domains they sponsor) 
is accurate. It might not yield the result you wish for though.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] *LIKELY SPAM 27.9* Re: Any reason to NOT block the entire .cam domain?

[Luis E . Muñoz via mailop]

On 27 May 2022, at 16:57, Hans-Martin Mosner via mailop wrote:

> Whether blocking a whole ASN is more advisable than blocking a whole TLD is a 
> matter of opinion - I've often seen that past spammer hosting in an ASN's IP 
> space was a good predictor for future spamminess, but of course as with TLDs 
> you will always have some legitimate servers in the mix...

I would argue that ASN blocks have a greater chance of hitting the actual 
operators of the spam campaigns rather than the namespace that they happen to 
have abused recently.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] *LIKELY SPAM 29.9* Any reason to NOT block the entire .cam domain?

[Luis E . Muñoz via mailop]

On 27 May 2022, at 15:28, Michael Rathbun via mailop wrote:

> The same gang has been trying out .mom and .lol, of late.

According to my notes, they are one of the groups actively following TLD 
operators' promotions. I just saw .cam names selling for under 2.5$/reg

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Paging 3cx.com/3cx.net

[Luis E . Muñoz via mailop]

If someone has a technical contact with them, I would like to discuss a 
misconfiguration on their end.

Thanks!

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Help with identifying invalid email domains

[Luis E . Muñoz via mailop]

On 26 May 2022, at 6:18, Ken O'Driscoll via mailop wrote:

> People should be validating email input fields as a matter of course.

And then, do it correctly. One of my pet peeves is finding out forms that still 
think that there is no such thing as a .click email address. Tends to work 
better for TLDs 4 characters or less in length.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Luis E . Muñoz via mailop]

On 19 May 2022, at 12:29, Dave Crocker via mailop wrote:

> oh. gosh. we've been wrong about this. for 20 years.

Would you care to enlighten me on how the DNC "technological requirements" 
differ from the hypothetical "DNE" list we have been discussing, and in 
particular, pertaining to the simplified use case I provided?

With gratitude

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Luis E . Muñoz via mailop]

On 19 May 2022, at 10:11, Dave Crocker via mailop wrote:

> Telephone-level DNC is a different category of technological requirement. 
> Very different.

In this case, not really. As implemented in practice, you have to run your list 
of phone numbers through a filter that will remove matching phones. Doesn't 
need to touch the actual phone network to implement.

The reason it seems to work better is that technical providers for bulk dialing 
services take this seriously. They have incentives to do this—fines and 
scaremongering prospective clients into not doing it themselves.

Also, let's not forget that it is national in scope and design. This, I agree, 
would make a substantial difference in the applicability. Still would not call 
it "technological requirement" though.

If implemented, the proposal for email could work similarly, if the large ESPs 
took the same approach. This would only leave us with the "other" type of spam 
to deal with. I would think that a spamtrap included in the "do not spam" 
registry could be used to identify non-compliant senders and other classes of 
spammers.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Luis E . Muñoz via mailop]

On 19 May 2022, at 9:41, Dave Crocker via mailop wrote:

> So, sure. We haven't been able to do individual-level blocking, so let's add 
> a requirement for an additional bit of complexity. That will probably make 
> this mechanism work a lot better...

Heh, appreciate the humor. It certainly won't make it work worse.

My point if you will, is that requirements are more complex than what's stated. 
The reason we won't get them fulfilled—simple or complex—is because there is no 
incentive for the bad guys to follow the rules.

IIRC, there is (was?) a "National Do Not Call List" implemented in the US at 
the federal level. Telemarketers and other organizations are required by law to 
scrub their own lists against this federal registry. This has not made a dent 
in the amount of spam calls that I get on my various lines.

The response / recommendation to establish this new registry, IMO, is simply a 
way to admit defeat with some grace.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Luis E . Muñoz via mailop]

On 19 May 2022, at 8:42, Dave Crocker via mailop wrote:

> [⋯] Domain level is not sufficient.

But is it though? A corporate providing email to its own users should certainly 
be able to express a policy that it does not want to allow any form of mailing 
list email to its users.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Luis E . Muñoz via mailop]

On 17 May 2022, at 21:59, Dave Crocker via mailop wrote:

> I keep enjoying that it has the style of satire, but is so well done is it 
> /extremely/ useful for legitimate use.

I wonder if this one

( ) Public reluctance to accept weird new forms of money

should be complemented with a crypto version, to avoid triggering those that 
hate cryptos being compared with money?

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Luis E . Muñoz via mailop]

On 6 May 2022, at 3:48, Dan Mahoney via mailop wrote:

> If you’re already doing DKIM and SPF anyway, arc is another milter in the 
> chain that gives you that benefit. (You want it after your DKIM and DMARC 
> validators). You can leverage your same DKIM keys to use arc (or a different 
> one), but it’s largely the same idea. Right now nobody is validating arc, but 
> this is largely because nobody’s signing/sealing with it…because nobody is 
> validating it…because nobody is signing/sealing with it….someone needs to 
> move first.

I think there's slightly more at play. Besides "trusting" the big ones, how 
would gushi.org know that it can trust libertad.link's ARC signatures? Or posed 
in a different way, what prevents spammer.co to make a false attestation to 
send spam made to look like it was sent from some innocent bystander?

How do we make this scale?

I think the response to those issues are in part the cause for the loop you 
cleverly explained before.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Luis E . Muñoz via mailop]

On 26 Apr 2022, at 13:18, Robert L Mathews via mailop wrote:

> 4\. Postfix wraps the message at 998 bytes when forwarding it due to 
> <[https://www.postfix.org/postconf.5.html#smtp\_line\_length\_limit](https://www.postfix.org/postconf.5.html#smtp_line_length_limit)\>;
>
> 5\. This breaks the DKIM signature in the forwarded copy, because addition of 
> the "CR-LF-SP" changes the DKIM body hash;

As others indubitably will recommend, don't do that. You are not the ESMTP 
police :-)

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG. Domain age?

[Luis E . Muñoz via mailop]

On 24 Apr 2022, at 19:08, Ángel via mailop wrote:

> The age of a domain has long been an important feature when measuring
> the worthiness of domain. Typically a domain registered last month
> would be seen more suspiciously than one registered 15 years ago.

More than this, you also want to pay attention to domains that are close to 
their anniversary day (renewal). Bonus points if the domains are "parked".

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Luis E . Muñoz via mailop]

On 21 Apr 2022, at 11:45, Anne Mitchell via mailop wrote:

Until Google manages to shut down outfits like MailShake and 
Woodpecker and Gmass, instead of turning a blind eye to it, Google 
will never get a handle on the abuse that goes through the Gmail API, 
in fact it feels as if they are tacitly approving it. (I suppose "shut 
down" s/b "care about". I know that my inquiries about it, and offers 
to assist, have fallen on unresponsive ears.)


The idea behind Mailshake is not bad in itself. Many CRMs also use their 
customer's mail servers. There are some things that these outfits should 
do better though:


* Verify with the domain operator that they (the ESP, via the user that 
signed up for the service) are indeed authorized to use the ESP's 
services. I've found a number of instances where an end user with an 
email account on a given domain, signed up to a certain CRM using this 
MO and started to email "prospects" from their (ahem) "lead database". 
Hilarity tends to ensue shortly after.
* Do a (much!) better job at vetting customers, including real rate 
limiting.
* Take ownership of the responsibility to _stop_ mail to whomever 
unsubscribed/complained/bounced from their mailings. And then, keep 
track of ratios and take their clients to task when thresholds are 
exceeded.


After rereading the above, I realize how delusional it sounds :-(

Happy Friday.

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Odd delay at Gmail ?

[Luis E . Muñoz via mailop]

On 20 Apr 2022, at 13:06, Bill Cole via mailop wrote:

> When I looked at this phenomenon I didn't see any clumping of delay times, 
> but I only had a few dozen with delays 10m-10h so they were pretty sparsely 
> scattered.

Matches me—few and apart—observations.

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Odd delay at Gmail ?

[Luis E . Muñoz via mailop]

On 20 Apr 2022, at 12:35, Cyril - ImprovMX via mailop wrote:

> That idea also crossed my mind, that it would only be displayed when the
> actual time is > than the Date in the email.
> Unfortunately, that's something I cannot tell, I don't know and since it is
> occurring rarely, it's hard to ask the user to "try again".

Depending on how curious you are, you can always take a message, edit on disk 
to have a timestamp in the future, and them move to Gmail storage via IMAP :-)

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Luis E . Muñoz via mailop]

On 19 Apr 2022, at 11:02, Russell Clemings via mailop wrote:

> Several users have reported this and I've seen it myself with a couple of
> messages to my gmail from my website. Still troubleshooting, and it's not
> happening consistently, but a missing DKIM in "show original" seems to be
> the common factor.

FWIW, I have observed this on domains that recently changed their mailbox 
provider and have otherwise short sending history or very low volume.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] FYI - Google/Gmail hard enforcing SPF presence

[Luis E . Muñoz via mailop]

On 19 Apr 2022, at 10:54, Kevin A. McGrail via mailop wrote:

> Interesting note that we also saw this a few weeks ago too and had to add 
> DKIM to get mail to work to domains that only had SPF.

Same here.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Luis E . Muñoz via mailop]

On 15 Apr 2022, at 12:50, Jaroslaw Rafa via mailop wrote:


Dnia 15.04.2022 o godz. 16:53:11 Laura Atkins via mailop pisze:


"EU.org, free domain names since 1996”


You quoted that. Eu.org is a *domain registrar*. Only. They don't 
offer any

email service and never did. So how can they "police users for email"?

Do you know any paid domain registrar - for example for .com domain - 
that

"polices users for email", if they don't host any email for the user?


There are many who claim that there's a correlation between easily, 
cheap (or free) domain names and spam. Their rationale is that spammers 
can secure disposable domain names for very low price.


Therefore, they claim, domain names meeting that criteria need to be 
subjected to additional scrubbing. Less sophisticated receivers could 
simply opt to reject while providers with more sophisticated mechanisms 
could implement that "additional scrubbing" in the form of tighter 
tolerances, starting the "reputation calculation" from a lower value or 
whatever makes sense to them.


Their common goal according to this narrative, is to reduce the amount 
of spam these mailbox providers have to deliver to their 
products/clients.


There is bound to be conflict on this _operational_ decision. 
Registrants of those cheap domains face an uphill battle with their 
deliverability to those providers following the above process, while 
these same providers see a net improvement on their situation by taking 
a simple (to them) step to curb spam.


This is more or less the same line of thought as when discussing about 
who is in charge of the network where your mail service sends from.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG - IPv6 aside

[Luis E . Muñoz via mailop]

On 15 Apr 2022, at 12:02, Al Iverson via mailop wrote:

> On Fri, Apr 15, 2022 at 10:36 AM Grant Taylor via mailop
>  wrote:
>>
>> On 4/15/22 8:24 AM, Al Iverson via mailop wrote:
>>> Don't send to Gmail over IPv6.
>>
>> Drive by comment.
>>
>> It is possible to send to Google via IPv6.  My personal / small /
>> bespoke server sends to my Google hosted work address all the time over
>> IPv6.
>
> You're not wrong. Depends on email volume level and server config.
> They're just so sensitive to reputation for IPv6 sends, though. Don't
> even try without SPF and DKIM, and even then, get ready for some
> possible pain.

For well managed mail servers, supporting well managed mailing lists I see no 
practical difference between address families. I have visibility over a few 
boxes sending a few hundred thousand messages per day. They are all dual stack 
and provisioned on a cloud provider (gasp!). The two deliverability issues 
they've had in the last two years have been related to sending to Microsoft, 
over IPv4.

I also see similar boxes, used mostly for one-to-one and small scale mailing 
lists in the same scenario, with the same results.

Of course, this is a small number of samples and perhaps even anecdotal, but 
these kinds of absolute pieces of advice are perhaps not for everyone.

Someone once said that IPv6 was an opportunity to introduce a good set of 
requirements into the email ecosystem (forgot who/where, and I'm paraphrasing). 
With the potential to send each individual email message over the lifetime of a 
mailing list from a unique IPv6 address, I think this is a good justification 
for this.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best mailbox provider for personal domain?

[Luis E . Muñoz via mailop]

On 8 Apr 2022, at 12:24, Michael Peddemors via mailop wrote:

> FYI, I would NOT be recommending Digital Ocean for email servers.. given 
> their current reputation. However, you can find many good hosting companies 
> that offer a server for $5/month.

The reputation of the neighborhood changes over time. Not having mechanisms to 
identify the good sources from the bad ones is already a diminishing returns 
game. However I think this has been discussed sufficiently here, and I don't 
mean to hijack the thread.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best mailbox provider for personal domain?

[Luis E . Muñoz via mailop]

On 8 Apr 2022, at 9:40, Tara Natanson via mailop wrote:

> Where would you recommend hosting your domain so that you can pop/imap, use
> "+" addressing, isn't spammer friendly, and basically works similar to
> gmail? I no longer have a website setup, so mail is the only thing I care
> about. I'm fine with a solution that has me setting up a new gmail account
> and just popping the mail to there, but what are folks using these days?
> (assuming I have no desire to run my own server)

I run my own VM for this. Relatively small incremental costs beside a few boxes 
I need to run for ~unrelated things. This also keeps me sharp and allows me to 
try hackish experiments on live email streams. If you were willing to go this 
route, $6-$12 would provide a DigitalOcean "droplet" with up to 50Gb of good 
storage. They have static IPv4 and IPv6 addresses although the latter are 
actively discouraged from being usable for email.

I also run a few mailservers in AWS with great results, although slightly more 
expensive.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Traffic patterns related to Russian-Ukranian conflict

[Luis E . Muñoz via mailop]

On 31 Mar 2022, at 10:57, Suresh Ramasubramanian wrote:

> How would you correlate it to Russia?

Time frames and a limited sampling of messages that mentioned topics related to 
the incident.

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Traffic patterns related to Russian-Ukranian conflict

[Luis E . Muñoz via mailop]

On 30 Mar 2022, at 11:03, Marcel Becker via mailop wrote:

> On Wed, Mar 30, 2022 at 7:29 AM Luis E. Muñoz via mailop 
> wrote:
>
>>
>> I am looking at some data showing substantial email traffic increase (2x
>> baseline) along with a visible change in the spam filtering statistics,
>> centered at or near 2022-02-28. Are you guys aware of any publicly
>> available source that would be discussing a similar observation?
>>
>
> Why do you think both of these (increase and spam filter changes) happened
> at all?

I meant, the results of the spam filters not the filters themselves, just in 
case I miscommunicated before.

I know about the increase because this was directly measured. We saw an 
unexpected increase in traffic, accompanied with a change in the otherwise 
uniform score results from the anti-spam filters.

However it would seem not everyone was seeing the same, so perhaps this is a 
different phenomenon?

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Traffic patterns related to Russian-Ukranian conflict

[Luis E . Muñoz via mailop]

Dear colleagues,

I am looking at some data showing substantial email traffic increase (2x 
baseline) along with a visible change in the spam filtering statistics, 
centered at or near 2022-02-28. Are you guys aware of any publicly available 
source that would be discussing a similar observation?

Thanks in advance.

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] sorbs DNS problems

[Luis E . Muñoz via mailop]

On 11 Mar 2022, at 19:09, Noel Butler via mailop wrote:

> Firslty yes, seen too many issues with SORBS, we removed them about 3 weeks 
> ago, the problems have been ongoing for months.

Just wrapping up a trial with them for a traffic sample. We saw no issues in 
processing north of 300 million messages. Care to share what issues did you see?

We configured a private secondary for this and experienced exactly zero issues.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Paging SaskTel

[Luis E . Muñoz via mailop]

Hi there,

Could someone provide a pointer to SaskTel postmasters or network security 
folks?

Thanks!

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] Info on deluxe.com

[Luis E . Muñoz via mailop]

On 28 Feb 2022, at 10:06, Laura Atkins via mailop wrote:

>> That is a very good guess, but not in this case.
>
> It strikes me this is really a question you should be asking the bank. It’s 
> very likely that the bank did pass the address along, for whatever reason, 
> but they are the only group that’s going to be able to answer “why did this 
> check processing firm have access to PII that was only given to you.”
>
> I’d be amazed if the answer from Deluxe was anything other than “your bank 
> gave it to us.”

Yes, the inquiry with the bank is ongoing. At this point and given the process 
that we follow for our accounts, we know that all preferences for data sharing 
were the functional equivalent of "do not spam", so there should not be a 
reason for the email in the first place, other than whatever process imported 
the address to Deluxe ignored that preference.

Not sure this warrants more time from this list, although I will report back 
the results given the interest expressed in private by a few of you.

Thanks!

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] Info on deluxe.com

[Luis E . Muñoz via mailop]

On 27 Feb 2022, at 21:43, Kevin A. McGrail via mailop wrote:

>> I just received my first ever spam from |info.deluxe.com|, sent to a tagged 
>> address used exclusively for online banking. Does anyone have a contact at 
>> deluxe so that inquiries can be sent?
>
> Lem: Any chance you use that account with an accounting software that has ToS 
> that allow for the solicitation?

That is a very good guess, but not in this case.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Info on deluxe.com

[Luis E . Muñoz via mailop]

On 25 Feb 2022, at 16:05, John Levine via mailop wrote:

> That's not to say I would want them to send me spam, but it doesn't
> seem very mysterious.

Indeed. My first quick glance of their website missed that fact. However we are 
meticulous in ensuring that all preferences for data sharing are set so as to 
minimize spam.

Thanks!

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Info on deluxe.com

[Luis E . Muñoz via mailop]

Hi there,

I just received my first ever spam from `info.deluxe.com`, sent to a 
tagged address used exclusively for online banking. Does anyone have a 
contact at deluxe so that inquiries can be sent?


Thanks!

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Can someone from Vade get in touch?

[Luis E . Muñoz via mailop]

On 8 Dec 2021, at 4:03, Stephane Decamps via mailop wrote:

> The review of our tools verdicts can be requested by the "owner" of the 
> concerned IPs via SenderTool: https://sendertool.vadesecure.com
>
> But I see that we received a request there from one of your colleagues 
> yesterday, who seems to have found the right way.

Yes, thank you. There was also some (internal) confusion about addresses listed 
by someone else, but this has already been resolved. It was caused by confusion 
on our end.

Thanks for the response!

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Can someone from Vade get in touch?

[Luis E . Muñoz via mailop]

I would like to review some listings and revise some registrations that look 
bogus.

Thanks!

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Postfix / DNSblog Query Problems with various RBLs running in timeouts

[Luis E . Muñoz via mailop]

The only part of your setup that looks strange (to me) is the use of 
systemd-resolve.

On 3 Dec 2021, at 6:55, Glowfish Domainadministrator via mailop wrote:

> netstat -tulpn |grep 53
>
> tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 586/systemd-resolve
> udp 0 0 127.0.0.53:53 0.0.0.0:* 586/systemd-resolve

Perhaps someone more familiar with systemd-resolve could give you advice 
specific to it. I would test this using a resolver such as Bind or Knot.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Tucows / OpenSRS Hosted Email outbound IP addresses

[Luis E . Muñoz via mailop]

On 23 Nov 2021, at 19:17, Michael Peddemors via mailop wrote:


Oh, and forgot to mention..

Might consider SWIP or 'rwhois' entries to show these networks are for 
Tucows email servers, and not part of the other networks that may have 
different use cases..


eg.

NetRange:   64.98.0.0 - 64.99.255.255
CIDR:   64.98.0.0/15
NetName:TUCOWS-BLK2
NetHandle:  NET-64-98-0-0-1
Parent: NET64 (NET-64-0-0-0-0)
NetType:Direct Allocation
OriginAS:   AS15348, AS32491, AS394308
Organization:   Tucows.com Co. (TUCOW)
RegDate:2000-05-18
Updated:2015-08-06
Ref:https://rdap.arin.net/registry/ip/64.98.0.0

A clear SWIP for the new ranges will save you grief.. shows that they 
started being used for the new purpose on a specific date..


Those are great pointers, thank you Michael. I'll make sure to them on.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] New Tucows / OpenSRS Hosted Email outbound IP addresses

[Luis E . Muñoz via mailop]

Tucows / OpenSRS is executing an upgrade that will result in new SMTP 
outbound IP addresses being used within the next couple weeks.


* All outbound email for regular and "filter-only" delivery:

  64.98.42.0/24
  64.99.140.1/24
  216.40.44.0/24

* All outbound forward and autoresponder traffic:

  64.98.36.17/32  forward.b.hostedemail.com
  64.99.140.10/32 fo-relay.a.hostedemail.com
  216.40.42.17/32 forward.a.hostedemail.com

I hope this information is helpful for anybody doing any special 
processing for these mail flows.


Best regards

-lem


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Does someone have a postmaster contact for smtp.wi.gov / wisconsin.gov

[Luis E . Muñoz via mailop]

I'm trying to troubleshoot what appears like a packet filtering issue. 
Pointers appreciated.


-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Someone from Suddenlink / Synchronoss / Altice

[Luis E . Muñoz via mailop]

Hi there,

Can someone provide a pointer to the folks in charge of Suddenlink 
email? I would like to troubleshoot a delivery issue with them and have 
ran out of ideas on how to contact. Someone mentioned earlier 
Synchronoss and Altice as potential operators of their mail 
infrastructure, but no luck there either.


Thanks!

-lem


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Why TLS is better without STARTTLS

[Luis E . Muñoz via mailop]

On 10 Aug 2021, at 11:21, Alessandro Vesely via mailop wrote:


SASL methods allow secure authentication over unencrypted channels.

(Well, I use CRAM-MD5 even over TLS.  When heartbleed came around I 
thought it wasn't that silly after all.)


FSVO secure, IIRC. Having to keep the unencrypted password at hand on 
the server side opens the door to other types of attack.


Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] HIPAA compliant email (was Re: So uh... Zoom/Sendgrid... How's that webinar spam investigation coming?)

[Luis E . Muñoz via mailop]

On 5 Aug 2021, at 10:26, yuv via mailop wrote:


If anyone can suggest an email relay system that is compliant with US
HIPAA , I would love to connect
my internal email system to it and outsource email deliverability
problems.


Out of curiosity, and recognizing that this would be a separate thread, 
what makes email non-compliant, considering that fax seems to be 
compliant? Just in case, this is a serious question of mine.


Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Anybody around from chegg.com / Adobe

[Luis E . Muñoz via mailop]

Hi there,

Would like to try and troubleshoot greylisting issue related to email 
sent on behalf of chegg.com. Please ping me offlist.


Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] MTA-STS issues

[Luis E . Muñoz via mailop]

On 14 May 2021, at 21:53, Eric Germann via mailop wrote:


For the STARTTLS cert I’m using LetsEncrypt.  DANE is also in place.


The TLS certificate checker at https://esmtp.email/tools/tls/ returns a 
Sectigo certificate which otherwise matches mail.semperen.com and 
www.mail.semperen.com on port 25. This is what a compliant MTA-STS 
implementation would do (and is part of what 
https://esmtp.email/tools/mta-sts/ does.



My question is what could be the cause of the failure?

1.  Certificate validation error in the certificate chain


The certificate chain I am seeing is unusual (to me) because it is 
presenting two separate signature paths, likely due to the rebranding of 
Comodo/Sectigo.


```
$ ccheck chain --starttls smtp.semperen.com:25
* spec smtp.semperen.com:25
  TLS version: TLS-1.2
  Cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  [chain 0]
[cert 0.0]
  Subject: CN=smtp.semperen.com
  Issuer: CN=Sectigo RSA Domain Validation Secure Server 
CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB

  Serial: 22691099081371953397362798816794149806
  Dates: 2020-10-23 00:00:00 + UTC to 2021-10-23 23:59:59 + 
UTC

  Signature Algorithm: SHA256-RSA
  CA: false
DNS: smtp.semperen.com
DNS: www.smtp.semperen.com
[cert 0.1]
  Subject: CN=Sectigo RSA Domain Validation Secure Server 
CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
  Issuer: CN=USERTrust RSA Certification Authority,O=The USERTRUST 
Network,L=Jersey City,ST=New Jersey,C=US

  Serial: 166627644428940058458651716034439089575
  Dates: 2018-11-02 00:00:00 + UTC to 2030-12-31 23:59:59 + 
UTC

  Signature Algorithm: SHA384-RSA
  CA: true
[cert 0.2]
  Subject: CN=USERTrust RSA Certification Authority,O=The USERTRUST 
Network,L=Jersey City,ST=New Jersey,C=US
  Issuer: CN=USERTrust RSA Certification Authority,O=The USERTRUST 
Network,L=Jersey City,ST=New Jersey,C=US

  Serial: 2645093764781058787591871645665788717
  Dates: 2010-02-01 00:00:00 + UTC to 2038-01-18 23:59:59 + 
UTC

  Signature Algorithm: SHA384-RSA
  CA: true
  [chain 1]
[cert 1.0]
  Subject: CN=smtp.semperen.com
  Issuer: CN=Sectigo RSA Domain Validation Secure Server 
CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB

  Serial: 22691099081371953397362798816794149806
  Dates: 2020-10-23 00:00:00 + UTC to 2021-10-23 23:59:59 + 
UTC

  Signature Algorithm: SHA256-RSA
  CA: false
DNS: smtp.semperen.com
DNS: www.smtp.semperen.com
[cert 1.1]
  Subject: CN=Sectigo RSA Domain Validation Secure Server 
CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
  Issuer: CN=USERTrust RSA Certification Authority,O=The USERTRUST 
Network,L=Jersey City,ST=New Jersey,C=US

  Serial: 166627644428940058458651716034439089575
  Dates: 2018-11-02 00:00:00 + UTC to 2030-12-31 23:59:59 + 
UTC

  Signature Algorithm: SHA384-RSA
  CA: true
[cert 1.2]
  Subject: CN=USERTrust RSA Certification Authority,O=The USERTRUST 
Network,L=Jersey City,ST=New Jersey,C=US
  Issuer: CN=AAA Certificate Services,O=Comodo CA 
Limited,L=Salford,ST=Greater Manchester,C=GB

  Serial: 76359301477803385872276235234032301461
  Dates: 2019-03-12 00:00:00 + UTC to 2028-12-31 23:59:59 + 
UTC

  Signature Algorithm: SHA384-RSA
  CA: true
[cert 1.3]
  Subject: CN=AAA Certificate Services,O=Comodo CA 
Limited,L=Salford,ST=Greater Manchester,C=GB
  Issuer: CN=AAA Certificate Services,O=Comodo CA 
Limited,L=Salford,ST=Greater Manchester,C=GB

  Serial: 1
  Dates: 2004-01-01 00:00:00 + UTC to 2028-12-31 23:59:59 + 
UTC

  Signature Algorithm: SHA1-RSA
  CA: true
```

I would give this a try with an LE certificate. I use that myself to 
send email to Gmail with no issues. Note that you will need to add a new 
TLSA record.



2.  No reverse DNS for the IPv6 address

The host is in AWS and has a PTR for IPv4 setup correctly.  Not sure 
if you can do a PTR for IPv6 in AWS


I have been able to do it with no issues in the past via the same form 
you use for IPv4 rDNS/SMTP unblocking. That said, I wouldn't think this 
is a factor when in the scenario you describe, Gmail will be _sending_ 
to semperen.com.


Mail is delivered successfully to and from gmail.  DMARC and DKIM and 
SPF and ARC all pass.


I think you will find that without rDNS for your IPv6, your MTA is 
either trying first with IPv4 or retrying over IPv4 after failing with 
IPv6 due to no rDNS. This is easy to check in the corresponding 
`Received` header.


Hope this helps

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Some Days I think that Gmail isn't even trying to stop outbound spam..

[Luis E . Muñoz via mailop]

On 5 Feb 2021, at 7:25, Michael Orlitzky via mailop wrote:

> Pay more and more people to do it, until the number of unhandled abuse
> reports at the end of the day is zero. It scales linearly.

Here's where I stopped reading. It does not scale linearly.

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone using clustered DoveCot?

[Luis E . Muñoz via mailop]

On 28 Jan 2021, at 2:40, Dr. Christopher Kunz via mailop wrote:


Maybe someone has some additional pointers what to look at?


You mention that the issues happen infrequently, so pinpointing the 
actual cause might be tricky. I am assuming an NTP synchronized server 
pool with multiple Dovecot front and backends. Accurate timing is 
critical in any synchronized system, and in my experience is an often 
overlooked source of entertainment.


NFSv4 pushes more "state" into the protocol, which leads to client side 
caching and other assumptions. Keep in mind that managing a mail spool 
is almost never the target use case for this type of optimizations.


I can see how two different Dovecot backend processes on different 
machines might be reading different versions of the files whenever 
transactions are routed to them. As files get written and renamed 
around, and changes are applied in potentially non-deterministic order, 
you could end up with these errors.


I would try two things, most likely in this same order.

* Downgrade to NFSv3. With less caching involved, there would be fewer 
things that could go wrong. Given the general numbers you mention, I 
would not expect a performance penalty on this experiment. Most I/O 
would go to mailbox metadata (indexes and such) rather than the 
individual message files themselves.


* Route all traffic to a single Dovecot backend server if feasible.

Do one and wait a prudential time to see if the issues happen again. 
Else, add the second and watch again.


I remember that NetApp's NFSv2 and v3 implementations were textbook 
correct. I think I never played with NFSv4 on an email environment 
though, other than limited experiments to validate configurations that 
did not get to see even light loads.


I'll be very curious about your results, so report back if you can.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone using clustered DoveCot?

[Luis E . Muñoz via mailop]

On 24 Jan 2021, at 12:07, Michael Peddemors via mailop wrote:


+1 Customers using NFS is perfectly fine, and scales well.

But do yourself a favour.. not all storage appliances are the same.
Go NetApp (amazing how reasonable cost you can get them now) if you 
can. Seen it too many times where people 'experiment' with this and 
get themselves in trouble.


Also, for email storage, we still like NFS 3, had some early issues 
with NFS 4, might be time for us to experiment with it again, but for 
email..


As someone that did such an experiment and sustained growth from 10Ks to 
millions of subscribers. We tested a few NFS solutions (then EMC², 
Hitachi + Sun, NetApp, BlueArc).


* Do stay with NetApp. Back in the day we settled with redundant heads 
(960s if memory serves well) with FC drives. Dollar for dollar, this 
outperformed their competition. Their pre-, post-sales engineering and 
support was truly knowledgeable as well.
* Maildir+ — I actually wrote a specialized MDA that encoded the 
length and relevant dates in the filename, which allowed us to avoid 
using the stat() NFS call. Our setup ran lock-free with no issues, while 
allowing a noticeable throughput increase due to the very large number 
of files involved.
* Local delivery happened directly from the SMTP servers, which mounted 
the remote filesystems RW.
* Most email access happened via POP on dedicated servers, with a 
dedicated load-balancing switch at the front. We also provided IMAP, 
which was used for webmail exclusively. Dovecot would likely change this 
substantially, as it can do its own service routing.
* Separate your users in a few filesystems. Try to keep them below a few 
TBs. We used MD5 to spread out users through the possible filesystems 
automatically. This strategy tended to spread the load surprisingly 
evenly.
* At the time, we worked with NFSv3. v4 wasn't a widely usable option 
for some reason I cannot recall. This might no longer hold true for your 
scenario.
* Switches are very important. Make sure they can sustain a continuous 
stream of jumbo frames back to back. The NetApps were actually capable 
of saturating their 1000BaseT interfaces routinely, and at some point 
our switches would just not be able to keep up. Nowadays, you would get 
10G or the largest interfaces you could buy, but switching needs to be 
well thought.


With the above, we received visits from prospective NetApp customers 
twice during my tenure. They were very keen to show their customers how 
our boxes actually performed ~20% more IOPS than the spec sheet claimed.


Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Current OSS anti-spam software best practice?

[Luis E . Muñoz via mailop]

On 16 Dec 2020, at 3:03, André Peters via mailop wrote:


Indeed, Rspamd changes everything.


Just another +1 from me. Definitely enable DCC as well. Huge game 
changer for some of our flows.


We're also using it for DKIM (signing and validating).

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Week+ delays within btinternet,com / synchronoss.net

[Luis E . Muñoz via mailop]

On 20 Oct 2020, at 23:55, Andy Smith via mailop wrote:

> Their mail server is at 85.119.83.252 (and 2001:ba8:1f1:f073::2, but
> none of the eventual deliveries happen over IPv6).

Are they getting any email over IPv6 at all?

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] What's Microsoft's S3150 block list and where do I go to request removal?

[Luis E. Muñoz via mailop]

On 9 Sep 2020, at 11:29, Atro Tossavainen via mailop wrote:

> (Some time ago I might have added "and isn't even based on x86" to the
> bit about running windows apps. Maybe I'll go back to that and run Mutt
> on ARM instead. Wonder how much it would cost to host an army of Pi at
> a commercial datacenter. My SPARC Solaris 10 box is still doing fine :-D)

AWS rents cheap ARM-based servers now.

Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] MTA Server IP "Warm Up" Reputation Recommended Best Practices

[Luis E. Muñoz via mailop]

On 4 Sep 2020, at 7:00, Laura Atkins via mailop wrote:

You’re trying to send mail from an Amazon compute server sitting in 
the middle of a range of IPs that have the generic aws rDNS.You’re 
being blocked because you’re sending from a place many, many people 
don’t want mail from.


You need to get your mailserver hosted somewhere that is not a cloud 
provider. Get a VPS or better.


While this has been the common mantra for quite some time, I have direct 
experience with a few email senders in AWS space that are getting great 
open rates.


You do need to pay attention to all details. All outbound email from 
those operations is DKIM-signed and the sending domains had a history of 
sending prior to assigning those IPs though.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] MTA Server IP "Warm Up" Reputation Recommended Best Practices

[Luis E. Muñoz via mailop]

On 3 Sep 2020, at 12:02, L. Mark Stone via mailop wrote:

If anyone has a better process for warming up sending MTA IPs, I would 
be grateful.


This has been in use for a few years with great success. Numbers will 
need adjustment to your specific case.


https://esmtp.email/blog/warming-up-your-managed-email-tunnel/

Best of luck.

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google and Spam detection

[Luis E. Muñoz via mailop]

On 24 Jul 2020, at 19:07, John Levine via mailop wrote:

Gmail has repeatedly said that they do not accept unauthenticated mail 
on IPv6.


And with very good reason. Consider that you can very easily have a 
dedicated IP address for every email message you will ever send :-)


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google and Spam detection

[Luis E. Muñoz via mailop]

I would push DANE a bit up in the list. DNSSEC can be a drag to some, 
but it is really the way to go in terms of decentralization of 
encryption. It is also a good practice.


On 24 Jul 2020, at 12:40, Phil Pennock via mailop wrote:


 * MTA-STS webserver with HTTPS from the same CA, and the relevant
   MTA-STS txt file in place; add the DNS record when it's up and 
happy.


You may find this helpful

https://esmtp.email/tools/mta-sts/

Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google and Spam detection

[Luis E. Muñoz via mailop]

On 24 Jul 2020, at 7:48, Jaroslaw Rafa via mailop wrote:

Not true, I was (and am) always delivering mail via IPv4 and had 
mentioned
problems (and also other people whose complaints I have read don't use 
IPv6

as well).


I see no difference in IPv4 vs IPv6. You do need to have rDNS properly 
setup and we use SPF and DKIM, no DMARC. IPs from a cloud provider to 
boot. Good deliverability.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] host mx.tiscali.co.uk[62.24.139.42] said: 453 4.1.1 wJGljsu8zj2dp Recipient Lookup Failed (TT513)

[Luis E. Muñoz via mailop]

On 18 Jul 2020, at 7:12, Stefan Bauer via mailop wrote:


No. Recipient is valid. Unknown recipients should be a perament error.


I am seeing what seems to be user lookup issues on their end from a few 
servers. Specifically


Server Too Busy (TT101)
Recipient Lookup Failed (TT513)

I have a couple samples that were delivered ~24 hours ago, and are 
failing with the errors above now.



I also tried postmaster@ and get same TT513 error.


The examples I picked at random are for domains served by tiscali.co.uk.

Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Is there a contact for ono.com

[Luis E. Muñoz via mailop]

On 15 Jul 2020, at 14:07, Atro Tossavainen via mailop wrote:

> 2) Deliberate DROP-style firewalling of your ranges and mine too
>
> Since https://www.ono.com/ is equally unaccessible from my domestic
> Internet connection (also in Finland), I'd say #1 sounds more likely
> to me.

Add my nodes in New York, Amsterdam, Oregon and London to the blacklist.

Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Rolling DKIM Key Disclosure

[Luis E. Muñoz via mailop]

On 10 Jul 2020, at 16:54, Matt Corallo via mailop wrote:


Replies inline.

On 7/10/20 7:50 PM, Brian Toresdahl wrote:

Your approach and goals don't seem to make sense to me.


TL;DR: The customer is always right, and the customer sees DKIM being 
used regularly to authenticate leaked emails - if
old not-in-use keys are public, anyone can sign anything they want, 
and suddenly you can't authenticate mail with them,

at least after-delivery, that is.


Not sure I understand your customer's use case completely, but DKIM is 
meant to verify the signature upon delivery. You can certainly try and 
verify again at a later time.


You do not need to have a _small_ number of public keys published. You 
can have a very large pool of them, and theoretically use them to sign a 
single message when sending. A while after delivering the message, you 
can remove and destroy the key material – DNS public key and private 
key – to prevent its reuse.


This could be an interesting project – which would be stretching the 
intended use case for DKIM IMO :-)


DKIM works (I'm summarizing a lot) by signing mail, and the 
public key to check that signature is placed in a "selector"
record in DNS (selector1._domainkeys.example.com 
). If you want to rotate DKIM keys, 
you
can immediately start signing new mail with with another selector 
(selector2._...), keeping the selector1 around long
enough for the old mail to be delivered and checked. Are you asking 
how long selector1 needs to stay around? For some

sort of 95th percentile, probably less that an hour.


Yes, that was my question, thanks :). Sadly, I don't think and hour 
would work - plenty of time to timestamp the emails
in question and suddenly the email is non-reputably signed again. Back 
to the drawing board, I suppose.


I was lost by the end of this paragraph.

The goal is to actually publish the private key, no need to wait for 
someone to brute-force it :)


Are you sure you're not better using S/MIME or GPG to produce _signed_ 
email payloads?


-lem
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Intermittent slow email delivery

[Luis E. Muñoz via mailop]

On 10 Jul 2020, at 14:36, Job Cacka via mailop wrote:


There is PAT firewall that load balances multiple networks.


Hopefully not a descendant of a PIX. I've never have had happy stories 
involving [NP]AT and SMTP servers.


I tend to go with what others have said: The fw might be trying to 
round-robing to destinations that are not prepared for it / not running 
an MTA.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Intermittent slow email delivery

[Luis E. Muñoz via mailop]

On 10 Jul 2020, at 9:47, Adam D. Barratt via mailop wrote:


On Fri, 2020-07-10 at 09:22 -0700, Job Cacka via mailop wrote:

slowmailtest...@ccbox.com
slowmailtest...@ccbox.com

slowmailtest...@p-r-c.com
slowmailtest...@p-r-c.com


From a quick test, at least half of connections get immediately
rejected, which probably isn't helping:


Seeing the same results from Amsterdam, New York, California, Oregon and 
London.


A trace gets up to

```
 static-76-14-192-30.or.wavecable.com (76.14.192.30)  77.015 ms  76.805 
ms  77.570 ms

```

Are there load balancers or NAT devices in front of those MXen? I can 
see that MXen and IPs remain unchanged since at least October 2019 
– was this happening back then?


Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Post-processing Journal-Mails coming from O365, forwardedMail

[Luis E. Muñoz via mailop]

On 8 Jul 2020, at 22:36, Stefan Bauer via mailop wrote:

there is a feature in O365 that forwards mails (in/out/both..) to an 
archive-mailbox for long-term archiving.


We grab this mails via pop. However our available mail-readers 
(Thunderbird, Kopano) show the original mail as attachment.


This is the „envelope wrapper“ format. It contains the _final_ 
recipient(s) of the email (eg after aliasing, distribution list 
expansion etc), and contains the original email - headers and body - 
unchanged. The advantage is that the archiving process does not need 
to do any of the logic Exchange does (no further LDAP lookups etc).


Can someone donate a test message through pastebin? I would like to take 
a look at one directly.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Microsoft Block list (S3150)

[Luis E. Muñoz via mailop]

On 29 Jun 2020, at 14:11, Scott Mutter via mailop wrote:

Microsoft has not provided any evidence that anything bad has ever 
come
from this IP address.  (Which the pros/cons of disclosing this have 
already

been discussed)


I don't think that in the current state of affairs, they *have* to 
provide you with such *evidence*. I would certainly tell anyone affected 
by the firewall rules I deploy to pound sand if they come demanding 
evidence. "My system, my rules".


It should be clear to us that the current system works well for 
Microsoft clients: The advertisers probably prefer other advertisement 
to not make it to the inbox. And most end users can't be bothered 
– or would not even know how – to request MS to get involved with 
this. I posit that for those that this gets inconvenient, they will 
simply ask the corresponding sender to use their gmail account, or 
subscribe again. Wash. Rinse. Repeat.


Not trying to defend them – and I'm 100& pro venting – but having 
been on the other end as well as many others here, they have their 
reasons for being so non-transparent. Some commercial, others not so 
much.


Now is the IP blocked because of a larger class-C, class-B, or some 
subnet
block?  That'd be nice to know.  But even if it is, if you're not 
seeing
any activity from the specific IP address I'm referring to, why can't 
you

just whitelist that IP from the subnet block?


When my $dayjob involved doing this in exchange for money, fame and 
celebrity I went the transparent route. Each and every IP address we 
blocked included a reason and links to evidence emails that invariably 
were sent by our own users. From time to time we discovered poor reports 
that lead to unwarranted blocks – those were resolved quickly. Would 
this scale? Not in that shape, for sure. For a few million email 
accounts we held it quite well with a couple people. I can't even 
imagine how much people would it take to scale that to MS gargantuan 
size.


But then many years have passed, and better tools exist today.

Rather than the rant I had before, I'll just say that current MS 
technology in email receiving is not at the forefront – and hasn't 
been for a long time. The situation we're all living through is a 
consequence of the economics at play.


It's impossible to get a hold of anyone using Microsoft website 
contact
form links that knows a lick about how their own mail servers work.  
If you
tell them that you're IP is blocked they try to figure out why you 
can't

access http://outlook.com


In their defense, I'm sure their numbers back them. 99.99% of the people 
opening tickets are likely unable to access http://outlook.com :-)


The thing is, we should not have to resort to interacting with their 
support channels so frequently. This unfortunately won't change as long 
as the layer of suspense and mystery is not lifted from the art of 
emailing Microsoft.


All the while, our users see us as being the bad guys.  They don't 
believe
that Microsoft/Hotmail/Outlook can be a bad guy because they're too 
big.  I
would be half a good mind to tell our users to sign up for this 
Mailops
mailing list, just so they can read all of the horror stories that 
happen

with Microsoft/Hotmail/Outlook mail server blocks.


The stories would be impossible to find because of all the questions 
about how to access http://outlook.com.


Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] t-online.de outage?

[Luis E. Muñoz via mailop]

On 9 Jun 2020, at 9:13, Michael Peddemors via mailop wrote:


Hehehe.. testing from a Digital Ocean IP might NOT be the best ..


You would be surprised.


Maybe they using GEO IP blocking UNLESS on an internal whitelist?
Usually only see that on IPv6 ports, but maybe that is what we are 
looking at?


Need more tests from european IP(s)..


AWS machines provisioned in UK do get past the HELO.

Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] t-online.de outage?

[Luis E. Muñoz via mailop]

On 9 Jun 2020, at 8:40, Jon Morby (Fido) via mailop wrote:

The forward and reverse on our mail servers matches  one of my 
test boxes (on my home network) was new and didn’t have matching 
reverse, but that the other machines I’ve tried from all have 
matching forward/reverse and they’re still being rejected before 
EHLO / etc

 
For example (and the actual IP that’s experiencing issues)
 
[root@ns1 ~]# host 80.252.116.10
10.116.252.80.in-addr.arpa domain name pointer mail-1-116-10.fido.net.
[root@ns1 ~]# host  mail-1-116-10.fido.net.
mail-1-116-10.fido.net has address 80.252.116.10
 
Status: 5.0.0Remote-MTA: dns; mx01.t-online.deDiagnostic-Code: smtp; 
554 IP=80.252.116.10 - A problem occurred. (Ask your postmaster for 
help or to contact t...@rx.t-online.de to clarify.) (BL) 


Same here on an IPv4 allocated from Digital Ocean NY1 location. I don't 
think this host has sent a single piece of email to those servers in at 
least a couple months.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Force double opt in for marketing list companies per email address

[Luis E. Muñoz via mailop]

On 2 Jun 2020, at 14:25, Michael Peddemors via mailop wrote:

Yeah, and IMHO (don't hit me) that VERP should go the way of the 
Dodo..


This assertion doesn't follow the rest of your message. Even if useless 
for the use case being discussed – for which it was never meant as a 
solution – there are plenty of other valuable use cases for VERP.


Any use case involving a downstream or 1-removed error benefits from 
VERP, because the sending organization can unambiguously know which 
destination address was at fault and can mitigate.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] contact at google

[Luis E. Muñoz via mailop]

On 17 Apr 2020, at 15:20, Al Iverson via mailop wrote:


If you're going to copy what he does just block 0/0, it's faster. :\


And cheaper! :-)

Not my intention at all. But the collection of network ranges would be 
useful to me in trying to understand how a large collection of 
distributed receivers are querying DNS-based sources.


The subtext of the bounce I quoted though makes me question whether the 
data will be worthwhile.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] contact at google

[Luis E. Muñoz via mailop]

Wow,

tried twice to email you directly w no luck

   - The following addresses had permanent fatal errors -

(reason: 550 5.7.1 : Client 
host rejected: Get a real domain, spammy)


Oh well, thank you anyway.

-lem


On 17 Apr 2020, at 12:31, Bill Cole via mailop wrote:


On 17 Apr 2020, at 10:42, Steven Champeon via mailop wrote:

I sent this to John offlist but here is a list of the IPs that are 
doing
stupid and useless queries against one of our mirrors (couple of days 
stale

but still potentially useful to someone):

   count IP
 122 172.253.12.1
 119 172.253.14.3
 117 172.253.12.2
 117 172.253.11.3
 116 172.253.14.2
 115 172.253.14.1
 114 172.253.11.1
 112 172.253.12.4
 110 172.253.14.5
 110 172.253.12.3
 109 172.253.12.5
 105 172.253.11.5
 104 172.253.11.4
 101 172.253.14.4
  98 172.253.11.2

There are more, but those are the high-count Google IPs. Apparently, 
there
are idiots at Linode, too. But the vast majority of these things are 
coming

from Google netspace.


Bogus DNSBL queries come from all over Google, Level3, Linode, Amazon, 
Cloudflare and other large DNS provider space. I have automation that 
blackholes DNS traffic from /24s around any such miscreants until 
they've stopped for 30 days, and the current consolidated ranges just 
from that /16 are:


172.253.0.0/23
172.253.2.0/24
172.253.4.0/22
172.253.8.0/22
172.253.12.0/24
172.253.14.0/24
172.253.192.0/24
172.253.194.0/23
172.253.196.0/22
172.253.201.0/24
172.253.210.0/23
172.253.212.0/24
172.253.214.0/23
172.253.217.0/24
172.253.220.0/24
172.253.230.0/24
172.253.233.0/24
172.253.234.0/24
172.253.246.0/24

My total list has 312 automatically added /24s and along with a few 
manual larger and smaller ranges those consolidate into 257 blocks 
with ranges as large as /20s where every /24 has made a query in the 
last 30 days against a never-public DNSBL that has never given useful 
answers to the world at large.


Please, make it stop already. You do not understand what you're 
doing.


They don't just not understand. They don't know, don't want to know, 
don't care, and won't make it stop.


For 15+ years I've tried every form of complaint and DNS trickery I 
can think up to make bogus DNSBL queries stop. The only success I've 
ever had has been with a couple of dumb cargo-culting "check all the 
blacklists" sites that had working contacts I could berate. When I've 
managed to get any response from people operating DNS resolver 
services, that has basically boiled down to "I guess it sucks to be 
you."


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo/AOL slower than normal delivery

[Luis E. Muñoz via mailop]

Hi Michael,

On 11 Apr 2020, at 6:36, Michael E. Weisel via mailop wrote:

We’ve noticed over the last 36 hours or so slower than normal 
delivery to Yahoo and AOL.


Our numbers for the last 48 hours look normal.

Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Luis E. Muñoz via mailop]

On 21 Mar 2020, at 21:11, Ted Cooper via mailop wrote:


Has anyone run into "Abusix" /potentially/ compromised account
notification emails before?


I got three in the last 48 hours at different sites. All referenced real 
user accounts – no clue about the password. The warning seemed legit 
so I passed the info to the potentially affected users, with the 
recommendation to change their passwords at any sites where they used 
said email accounts.


My reading is that bad actors will find valid email addresses as part of 
successful exploits and then feed those into their automated attacks.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] AT&T Block - abuse_...@abuse-att.net still valid?

[Luis E. Muñoz via mailop]

On 26 Feb 2020, at 14:18, Scott Mutter via mailop wrote:


[⋯] Do any DNS resolvers actually cache
data for the period stated in the TTL these days?


Many do. If you're operating a recursive for any sizable user 
population, you want to minimize the response time. Having the response 
in your local cache is actually as fast as you can get. Then again, with 
long TTLs comes the longevity of errors. This is why public resolvers 
have heuristics / buttons to forget data ahead of time or trigger a 
refresh.


I've seen some studies that compare large recursive resolver 
performance, that left me with the impression that at some sites, the 
resolvers are resource-starved. I wouldn't think this is a deliberate 
stance, as it degrades the quality perception of customers.


If you look at gmail.com it's TTL is 300 seconds - now... granted that 
IP
address is not used to actually connect to mail server to send out 
mail,

it's just the IP address for the front facing gmail.com.


Likely, they need to be able to point to a wholly different anycast node 
on a whim, or don't want you to carry a cached response when roaming 
between networks. I would not consider any large sender as a good 
example of the discussion on this context, because with that scale, come 
very specific challenges.


Many of the infrastructure elements I manage have sub-1d TTLs in their 
DNS records except for things like TLSA records and such. In our case, 
this is to ensure that changes can be deployed quickly. This of course 
comes with the price that we will disappear much faster from the DNS if 
we manage to screw up our geo-diverse name servers.


I definitely would subscribe to the notion that TTL should not matter 
for

this.  But should and does are two different things.


+1

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] AT&T Block - abuse_...@abuse-att.net still valid?

[Luis E. Muñoz via mailop]

On 26 Feb 2020, at 13:53, Lyle Giese via mailop wrote:

Don't know if ATT looks at this but I know they used to.  The TTL for 
the A record for server.divebums.com is 900 seconds.  If checking 
this parameter, it was recommended that this be at least 12 hrs or 
43,200 seconds.  The theory was that 900 seconds indicated it was on 
a dynamic ip address.


I've seen that criteria used in the past in a DNS blacklist. TBH, I 
haven't seen this mentioned anywhere else in relation to deciding 
whether an IP address is static or not. In particular, there are many 
reasons you might want to have a short TTL – geo load balancing is 
just one of them.


I would tend to think that an organization doing that is trying very 
hard to be "static", as in "being there to receive your email" :-)


-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Luis E. Muñoz via mailop]

On 25 Feb 2020, at 3:12, Simon Lyall via mailop wrote:

Thank you for all the suggestions. I've put together a couple of 
pages:


https://www.mailop.org/faq/
https://www.mailop.org/best-practices/

as a start. What do people think needs to be added or changed?


This is a TLS Checker that is POP/IMAP/SMTP: aware 
https://esmtp.email/tools/tls


There's also a sibling MTA-STS validator: 
https://esmtp.email/tools/mta-sts


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Luis E. Muñoz via mailop]

On 17 Feb 2020, at 11:20, Hans-Martin Mosner via mailop wrote:

My personal experience with SPF is that it is less helpful than 
harmful, at least when mail server operators use it for
rejection instead of tagging. It can help reject some mails with fake 
sender information, but at the same time it

prevents some legitimate forwarded mails from getting through.


And this is a decision of the sending mail system. Editorializing on 
this does not help. Many of us have personal experience that shape our 
own decision making process. Those experiences don't necessarily map 
well to others'.


Unfortunately, we are operating in a world where legitimate forwarding 
is far outweighed by spoofed email and SPF is a response to that. If 
forwarding is expected, cooperating mail systems can make arrangements 
– i.e., ARC is an attempt to do this at a larger scale – but this 
is part of the consensual aspect of email transmission.


As for SPF-breaking mailing lists, this is likely a self-correcting 
problem. ARC would also help with this use case.


One could state facts – i.e., pointing out that SPF will break 
straight forwarding and mailing lists that do not rewrite – without 
introducing judgement.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Remarkable longevity of AWS-hosted spamming operation

[Luis E. Muñoz via mailop]

On 10 Feb 2020, at 20:27, Michael Rathbun via mailop wrote:


The data:


FWIW, I'm seeing these IPs among the 40th percentile in terms of global 
SMTP activity / session attempts.


3.18.213.86
54.186.253.233
54.212.82.49

The rest is not registering.

Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How long to retry?

[Luis E. Muñoz via mailop]

On 4 Feb 2020, at 11:43, Brandon Long via mailop wrote:

The problem is, user's get used to the performance they get.  It's not 
a

question of user education
or worse users.  If you typically deliver messages in seconds, 
eventually

that's what they expect.


Great summary!

And, there are different use cases. Some of the mail flows I manage, 
include messages that are ideally delivered within a couple hour window. 
Outside that window, the usefulness of said email greatly diminishes.


Some others involve more relaxed restrictions.

The challenges of both pale by many shades of white vs what I can only 
imagine are Google-scale constraints.


I think there isn't a single solution for all. It's our job as email 
(postmasters|architects|janitors) to identify which parameters work best 
for our specific use cases. Some are bound to be harder than others. And 
hopefully we won't forget that at times, things will break and it will 
be us fighting the clock to recover the damn mail server.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How long to retry?

[Luis E. Muñoz via mailop]

On 3 Feb 2020, at 14:20, Michael Orlitzky via mailop wrote:

You have problems with 100% of messages 0.0001% of the time -- it's 
not
a steady 99. success rate, even though that's what the numbers 
look

like if your window is five-years long.


Since recently – heh, let's call it 5-6 years – I've observed more 
and more that senders are unable to connect the first NDR ("your mail is 
stuck, we're still trying") with their original message. There's some 
cognitive dissonance at play here. If the bounce is not instantaneous, 
that NDR is a waste of resources for them. More or less the same happens 
with the final NDR ("sorry, I give up"), where they seem to be unable to 
grasp that the message was not delivered.


Setting the first NDR too soon tend to cause confusion – and often, a 
resent of the same message – which does not improve the situation for 
that specific communication.


This issue is, IMO, testament that the email landscape today is far more 
resilient than 30 years ago. But we still need to accommodate the 
occasional flooded rack. User expectations are very heavily driven by 
what happens with 99.% of their email. Can't say I blame them.


Personally, I've seen more bounces in the last 3 months due to receivers 
wanting to do TLSv1.0 than the rest of possible causes, all together. 
The NDR has helped notice this and make special arrangements. But still, 
the senders were not entirely aware of what happened to their email 
during the few hours they remained in our outbound queues.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How long to retry?

[Luis E. Muñoz via mailop]

On 3 Feb 2020, at 14:04, Brandon Long via mailop wrote:

One of the main reasons I don't think we should use such long retries 
is

that it violates user expectations.  Users often treat email as nearly
instantaneous, because it normally is... so taking hours or days of
actually failing without any quick indication to the user violates 
that

expectation.


This. Expectations have changes *a lot* over the years.

For some pairs of correspondents, it's ok to wait a couple days for an 
email. For others, a message delayed more than a few hours is pointless.


For bulk outbound email, we tend to see a queue that doesn't drain fast 
enough as a sign of trouble.


Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

[Luis E. Muñoz via mailop]

On 26 Jan 2020, at 16:23, Ángel via mailop wrote:


I like them as 2FA solution, too. Simple, standard, offline, vendor
neutral, not vulnerable to MITM...


Ahem. If the attacker manages to position themself in between your 
session, they get a chance at your TOTP. Same attack scenario as with 
the old RSA SecureID tokens.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Messages from small personal SMTP server being marked as junk by Google

[Luis E. Muñoz via mailop]

On 24 Jan 2020, at 3:33, Laura Atkins via mailop wrote:

Using +all is actually a giant, negative reputation hit according to 
various folks I’ve talked to about filters. Using +all says “every 
IP is valid” and this was (dunno about still is but definitely was) 
used by spammers so they could have SPF validate bot spam.


I thought it interesting to scan for the relative frequency of each one 
in the SPF records I've observed over the last 6 months...


 expression |  count
|--
 +all   |   142150
  all   |   159293
 ?all   |  5816058
 -all   | 18227533
 ~all   | 28709709

This data comes from an ongoing analysis of ~190 million unique domain 
name observations across legacy, new gTLDs and ccTLDs in that same 
period.


Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BT Internet postmaster contact

[Luis E. Muñoz via mailop]

On 3 Jan 2020, at 20:46, Philip Paeps via mailop wrote:

I've found BT's postmaster team to be very responsive in the past.  I 
invariably get replies from actual humans.


I suppose YMMV. I've interacted twice with them in the last 24 months on 
behalf of clients. The interaction has been... lacking in substance.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] G-Suite removing LSA functionality

[Luis E. Muñoz via mailop]

On 16 Dec 2019, at 13:30, Jaroslaw Rafa via mailop wrote:

Do any Windows/Linux/MacOS email clients currently support OAuth "out 
of the

box"?


I can report that MailMate on MacOS works perfectly with OAuth. And it's 
also much better for email geeks. Not free, but well worth the license.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] G-Suite removing LSA functionality

[Luis E. Muñoz via mailop]

On 16 Dec 2019, at 11:20, Al Iverson via mailop wrote:

Question for the group -- [⋯] Are there other folks out there that 
will

have to make code changes to comply with these changes?


I will have to make code changes to more or less the same classes of 
tools you mentioned.


Best regards

-lem

___
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?

[Luis E. Muñoz via mailop]

On 9 Dec 2019, at 7:58, Al Iverson via mailop wrote:


Whenever these threads come up, a dozen or so people say "I still read
email on my stone tablet and so do all my friends." But count how many
friends do you have, and then divide that by the 1.5 billion active 
Gmail
users (as of October 2018), the resulting percentage is how much it 
matters

if random sender X creates a text version or not in 2019. It really
doesn't. Nobody except those 12 guys see the email in plain text. 
Those 12
people may be unhappy, but they probably aren't subscribed to a 
company's

marketing messages anyway.


I suspect that not all cheap and easy to replace accessibility 
devices[1] are able to cope with the HTML content that some senders pump 
out. So sure, there might be 12 old timers who don't care anyway. But by 
dismissing text/plain entirely, people restricted by those devices are 
also left behind.


I'm all in for pragmatic approaches, but I suspect that as proposed, 
this is over-generalizing.


[1] bad attempt of a joke. In many cases, those devices are neither 
cheap nor easy to replace.


Best regards

-lem

___
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?

[Luis E. Muñoz via mailop]

On 9 Dec 2019, at 6:23, Ned Freed via mailop wrote:


Generate the plain text alternative if you can.


Absolutely. But please, try hard.


But if you can't, or aren't
sure you can, just send the HTML and don't generate the 
multipart/alternative

structure.


+1

Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Can someone write me a prescription for a sane MTA? I'm allergic to Postfix.

[Luis E. Muñoz via mailop]

On 6 Dec 2019, at 9:17, John Levine via mailop wrote:

> I'd be interested in why he's still using uucp.

+1


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Suggestions for VPS providers in Europe?

[Luis E. Muñoz via mailop]

On 2 Dec 2019, at 15:59, John Levine via mailop wrote:

I warned a guy away from Hetzner and OVH if he wants to send mail so 
he
reasonably asked what VPS provider in Europe is better for sending 
mail.


Any suggestions?


I'm AWS (IPv4 and IPv6) with good results. I would go with AWS for 
Europe services. Months ago did some tests from DigitalOcean ams2 VMs, 
but for other reasons ended up ditching it.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Best strategy to prune address list

[Luis E. Muñoz via mailop]

On 23 Nov 2019, at 11:05, Tom Ivar Helbekkmo via mailop wrote:

> Today, I suspect that most MTAs
> will refuse to service a VRFY request.
>
> Anyone know if that assumption is good?

I would be very surprised if you were wrong.

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mailop made Hacker News

[Luis E. Muñoz via mailop]

Looking forward to the n-gate.com summary :-)

And the comments on Brandon about him being helpful and respectful are 
well deserved.


-lem


On 25 Oct 2019, at 12:40, Simon Lyall via mailop wrote:

Remember that "Gmail marking email from me as spam" thread a couple of 
weeks ago? Somebody posted it to Hacker News:


https://news.ycombinator.com/item?id=21352161

"Brandon Long, is as ever, a helpful and respectful voice of reason on 
the sometimes fractious Mailop list"


" Sometimes fractious? Ha. There's so many cranks there that 95% of 
the messages are not worth reading, even if most are well-intentioned. 
 "


" It’s posted elsewhere in this comment thread but that’s after 
the point where it becomes clear that he wrapped a moral argument in a 
technical envelope and people spent a lot of time trying to help him 
out with the technical argument. "


--
Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
"To stay awake all night adds a day to your life" - 
Stilgar___

mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Do we need Spam folders?

[Luis E. Muñoz via mailop]

On 14 Oct 2019, at 23:39, Thomas Walter via mailop wrote:


On 15.10.19 00:34, Chris Wedgwood via mailop wrote:

Doesn't "550 Requested action not taken: We don't like you." apply
after DATA?


it does

most severs honor this but not all

(i experience this sometimes, my domain somtimes gets a lot of
backscatter)


What MTAs do not honor this? How does 550 after DATA result in 
backscatter?


The problem isn't lack of honoring the bounce. The problem is what to 
make out of it when multiple recipients are present. Also, assuming that 
a reject after DATA is strictly content-related is, well, an assumption.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Do we need Spam folders?

[Luis E. Muñoz via mailop]

On 14 Oct 2019, at 15:18, Thomas Walter via mailop wrote:


On 14.10.19 23:59, Luis E. Muñoz via mailop wrote:
This is not a pure performance issue. It's more a matter of not 
having
the data at hand to decide whether the message is ham or spam. To do 
so,

filters need user feedback.


You can still have feedback if you don't move emails to a spam folder
and rely on a user checking that regularly.

Recipients can still mark email as spam or explicitely allow mails 
from

specific senders.


This requires accepting the message and putting it on recipients' 
mailboxes. This would not be possible if you rejected the message. In 
order to get feedback, you need to accept a sample.



Protocol-wise, what is a sender supposed to do with a post-DATA
rejection? Is that rejection associated to one of the RFC-5321 RCPT 
TOs?

All of them? None, because it's actually a content issue? What if the
policies for each recipient differ?


He is supposed to handle it like any other rejection too?

Doesn't "550 Requested action not taken: We don't like you." apply 
after

DATA?


It does apply. Understanding what it means is perhaps another 
discussion. Why did the 550 happen? Was it the content? Some of the 
recipients? All the recipients?



MTAs should be able to handle rejections at all stages. Which doesn't?


Most of them do. Most of them will cause a multi-recipient message with 
a 550 post-DATA rejection to drop out of the queue. Now, suppose you're 
the person sending that email: What would you do with such a rejection? 
Again, was it the content? Was it the policy of one of the receivers?


I am also not a fan of "unread mails can still be taken out of the 
users

mailbox". I wouldn't want my postman to fish mail out of my letterbox
just because he thinks my neighbour didn't like it, so I won't either.


Why? At least where I live, the letterbox is owned by the post office. 
As long as I haven't picked up the message, they could remove it from my 
box and I would not know about it. There's no material difference for me 
between the postman refusing delivery or the letter being fished out of 
my box before I see it.


Keep in mind that mailbox providers are trying to ease the burden on 
users of their services.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Do we need Spam folders?

[Luis E. Muñoz via mailop]

On 14 Oct 2019, at 14:20, Thomas Walter via mailop wrote:

Of course I don't have the experience in the last category, but I'd 
like

to learn. Why can't you reject emails post-DATA?

Is it a performance issue? Google or Bing find 935.000.000 search
results in 0,60 seconds for the word "spam", but they can't do a spam
check in that amount of time?


This is not a pure performance issue. It's more a matter of not having 
the data at hand to decide whether the message is ham or spam. To do so, 
filters need user feedback.


In order to have the data, a trickle of those suspicious messages are 
allowed to get in. What the recipients do with them is used to decide 
what to do with future messages.


Protocol-wise, what is a sender supposed to do with a post-DATA 
rejection? Is that rejection associated to one of the RFC-5321 RCPT TOs? 
All of them? None, because it's actually a content issue? What if the 
policies for each recipient differ?


SMTP does not allow for this level of granularity in the signaling.

MTAs know how to deal with a post-RCPT rejection. A post-DATA is an 
entirely different thing.


There's also the option of sending a NDR after accepting the message, 
which is undesirable for a plethora of other reasons.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop