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

[Larry M. Smith via mailop]

On 8/31/2022, Bill Cole via mailop wrote:
(snip)
Who/what/where their clients are, and for what purpose of course, is 
not likely something we will find out unless they like to share more, 
but we can continue discussing this in terms of all the operators out 
there, and what constitutes the good vs the ugly.


Their intended service is the problem.



Also at the same address physical address;

https://woodpecker.co/

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

Re: [mailop] State of the Union - Update due to activity..

[Larry M. Smith via mailop]

On 8/30/2022, Michael Peddemors via mailop wrote:
Normally, we could simply post this on a blog, but the traffic is 
significant enough that other mail operators might be interested..


Last couple of days a LOT of new IP Address abuse from the same actors 
using throwaway domains, on the typical suspect hosting providers, but 
the sheer volume should be noticible.


Of course, this actor is pretty spammy in nature, and decent filtering 
should be catching it anyways, but it is worth noting his methods given 
the sheer volume.


Sampling of Activity (Sorry for the long scroll)



I've only glanced at this, but it smells like PredictLabs to me.


SgtChains

___
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

[Larry M. Smith via mailop]

On 7/29/2022, 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:

“It shall be unlawful for an operator of an email service to use a filtering 
algorithm to apply a label to an email sent to an email account from a 
political campaign unless the owner or user of the account took action to apply 
such a label.”

It is getting relatively very little press, and of course the chances of it 
passing are greater if nobody knows to oppose it.

We've written an article about it, which includes what to do, whom to contact 
and how, etc., and which includes all relevant links, here:

https://www.isipp.com/blog/do-you-want-political-email-to-bypass-spam-filters-and-go-directly-to-your-inbox-congress-does-heres-what-to-do/

Feel free to share - in fact please do, if this thing passes it's the camel's 
nose under the tent.


IIRC, this all started because a research paper somewhere noted that a 
specific political party seemed to have more deliverability issues than 
the other prominent party did.  Fast forward a bit and  there 
exists a vast conspiracy in anti-spam against that specific political 
party .


I can't speak to all anti-spam systems, but the vast majority of them 
work on behavioral models and not some list of word that someone has 
entered into a list somewhere.


I have noted that a large number that political party's members seem to 
be quick to label those that disagree with some its policies and 
positions as either the enemy or disloyal.  Perhaps it is an attitude "I 
will do what I want, and if you disagree with me, then you are some sort 
of commie scum," that has resulted in them not following advise offered 
to them, so that they don't look like a bunch of spammers taking a bump 
all over everyone's inboxes.


.. I really don't know, but I tend to discount the belief that this is a 
conspiracy against them.



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

Re: [mailop] Did Google become stricter about RFC 5322?

[Larry M. Smith via mailop]

On 7/13/2022, Philip Paeps via mailop wrote:
In the past couple of days, I'm seeing an uptick in rejects from Gmail 
as follows:


<[elided]@gmail.com>: host
     gmail-smtp-in.l.google.com[2607:f8b0:4004:c17::1a] said: 550-5.7.1
     [2610:1c1:1:606c::19:2] Our system has detected that this message is
     550-5.7.1 not RFC 5322 compliant. To reduce the amount of spam sent to
     Gmail, 550-5.7.1 this message has been blocked. Please review 550 
5.7.1

     RFC 5322 specifications for more information.
     bp41-20020a05620a45a900b006a64dbdb75asi7765031qkb.308 - gsmtp (in 
reply to

     end of DATA command)



Heh, Isn't that neat.  Gmail re-queues and re-sends messages if your 5xx 
response isn't to their liking.  And being worried about their users 
_getting_ spam while they seemingly ignore notifications about the spam 
their users are _sending_.


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

Re: [mailop] Talking DOXING of spammers on this mailing list..

[Larry M. Smith via mailop]

On 6/1/2022, Michael Peddemors via mailop wrote:
(snip)
In leiu of my bi-weekly state of the union (spam threats) email, I think 
we should consider working together to do a little 'doxing' of the bad 
guys.. Now, I know it is done in other places, SpamHaus used to post 
regularly about ROCKSO spammers, etc.. but since it appears to be 
affecting everyone on the list, why not co-operatively take on one bad 
guy every couple of weeks..


Off the top of my head, I feel that it would be unlikely to have good 
participation on this subject in such a public forum.  I have been 
thinking about what a vetted community might look like for a while now.


.. it is encouraging to know that others feel the same way as I, and 
that it might be possible to boot-strap such a community.



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

Re: [mailop] Spamhaus "open resolver" errors

[Larry M. Smith via mailop]

On 5/13/2022, John Levine via mailop wrote:

It appears that Chris via mailop  said:

On 2022-05-13 12:57, Grant Taylor via mailop wrote:


I suspect that their $BLOCKING method has progressed to false positives
as a way to get email administrator's attention.


It's progressed to false positives because some people run mail servers
who aren't parsing DNSBL return codes right.


What he said. My mail server isn't very good at telling one return
code from another so once a week I run a dedicated script on each
DNSBL I use to make sure it does return a reasonable result for
127.0.0.2 and no result for 127.0.0.1. If it doesn't, I stop using it.


In the past I had advocated for DNSBL clients to validate response 
codes.  Back then my recommendation was to ensure a response within 
127.0.0.0/8 and not within 127.0.0.0/31.  Now, over a decade later, I'm 
going to suggest that 127.255.255.255 also be flagged as an error, 
logged, and the query not be used as a source of reputation.


Additionally, I just want to remind people that there are many ways that 
a DNSBL operator could attempt to inform users of policy issues;


* CNAMEs as flags to listed objects
* Flagging in response codes to listed objects
* List nothing
* Return error (SERVFAIL or REFUSED)
* Drop the request
* Return NS records to things that fail or are really slow.
* List everything

.. But because there is no actual user sitting behind the DNSBL client, 
and many DNSBL clients don't validate response codes, only a couple of 
those might actually be understood by someone reviewing logs (both on 
the mail server and the local resolver)



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

Re: [mailop] [E] $GOOG

[Larry M. Smith via mailop]

On 4/19/2022, Hans-Martin Mosner via mailop wrote:
(snip)>
When I detect those in the logs I add the MAIL FROM address to the 
known-spammer list, which causes the mail to be rejected earlier in the 
SMTP dialogue and seems to stop the retries. Most times I don't care 
whether they're retrying repeatedly, though, it costs more of their 
resources than mine.




There is a group of spammers that have been on Gmail for months and 
using something that shows in the header records as gmailapi.google.com. 
 Given that it appears that the spammers have a near endless supply of 
gmail addresses to send from, I don't know how effective that strategy 
might be.


API documentation for defining aliases on the fly;
https://developers.google.com/gmail/api/guides/alias_and_signature_settings

.. I'd suggest anything that shows gmailapi.google.com in the header be 
rejected -- at least until Google can get a handle on the abuse.


E.g.;
Received: from .* named unknown by gmailapi.google.com with HTTPREST;
 Mon, 18 Apr 2022 16:53:54 -0700


--
SgtChains

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

Re: [mailop] [E] $GOOG

[Larry M. Smith via mailop]

On 4/18/2022, Bill Cole via mailop wrote:
(snip)

Did you mean "GMail?"



Yes, you are correct -- Gmail.  Sorry about that.  Finger memory, or 
something.


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

Re: [mailop] [E] $GOOG

[Larry M. Smith via mailop]

Sorry, late to the game...

On 4/17/2022, John Levine via mailop wrote:

It appears that Tobias Fiebig via mailop  said:

If your friends somehow believe that Gmail is the only mail provider in the 
world I suppose I am sorry for them but I don't understand why that is anyone 
else's problem.


The idea is that you give away something for free, gain significant market 
share (=network effect), and then get into a position where you can first push 
standards (hello
MTA-STS), and later can migrate to a walled garden, ...


Uh, what? Google follows public mail standards at least as well as
their large competitors like YahAOL and Microsoft. You do not have to
like MTA-STS, but it's an open IETF standard and there's a lot more
providers than Google that use it.



I'm going to disagree.  To the best of my knowledge Yahoo, Vz, AOL, or 
Microsoft do NOT re-queue messages after receiving a 5xx response -- 
Qmail does.


I don't know if this is because their system expects a specific text 
response, if they expect enhanced status codes (even when the remote 
doesn't respond to EHLO with ENHANCEDSTATUSCODES), of if Google simply 
believes that sender's policy trumps receivers policy.


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

Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)

[Larry M. Smith via mailop]

On 12/18/2021, yuv via mailop wrote:
(snip)

Their FAQ is up at  and it all
looks like a lawyers-approved shield to try to justify what they have
done.  They know they have pushed too far.  The question is whether
they will learn from this and whether the learning will flow into a
fairer IRB.  I will follow up with Jonathan.


There has been another update, and appears to be well worth a read.  The 
part that is of interest to me is;



Second, our team is prioritizing a possible one-time follow-up email to 
recipients, identifying the academic study and recommending that they 
disregard the prior email. If that is feasible, and if experts in the 
email operator community agree with the proposal, we will send the 
follow-up emails as expeditiously as possible.



While I'm not really a fan of more spam; I do not have the experience to 
comment on what damage may have been done, nor what their best path 
forward should be -- as such this plan seems acceptable to me.


--
SgtChains

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

Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)

[Larry M. Smith via mailop]

On 12/18/2021, Larry M. Smith via mailop wrote:

On 12/18/2021, yuv via mailop wrote:
(snip)

Their FAQ is up at <https://privacystudy.cs.princeton.edu/> and it all
looks like a lawyers-approved shield to try to justify what they have
done.  They know they have pushed too far.  The question is whether
they will learn from this and whether the learning will flow into a
fairer IRB.  I will follow up with Jonathan.


I find this bit interesting;



Heh, I also note the following addition to the HTML;


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

Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)

[Larry M. Smith via mailop]

On 12/18/2021, yuv via mailop wrote:
(snip)

Their FAQ is up at  and it all
looks like a lawyers-approved shield to try to justify what they have
done.  They know they have pushed too far.  The question is whether
they will learn from this and whether the learning will flow into a
fairer IRB.  I will follow up with Jonathan.


I find this bit interesting;


* When are you contacting websites for this study?

We sent emails to websites through December 15, 2021. We are not 
currently sending additional emails for this study.



Originally this was scheduled to run though "spring of 2022," so my 
question is; Did Princeton stop it, or did AmazonSES cut them off?


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

Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)

[Larry M. Smith via mailop]

On 12/16/2021, Al Iverson via mailop wrote:

On Thu, Dec 16, 2021 at 9:48 AM Larry M. Smith via mailop
 wrote:


On 12/15/2021, Anne P. Mitchell, Esq. via mailop wrote:

FYI, I have sent my own letter, with my full signature (same one as below), to 
Princeton, including cc:ing the dept. chair, the abuse department, and the 
legal department.  I do hope you send yours, and soon, as it would be a good 
1-2 punch.



It would appear that other punches are being thrown elsewhere;

https://www.spamhaus.org/sbl/query/SBL538721


Well, I'm sure this'll be a popular opinion, but I'm giving it anyway.
Maybe let's try not to do something that'll screw up that college
kid's life forever over their bit of stupidity. It's wrong, they
shouldn't be doing it, but it's not for commercial gain, and the
amount of bad mail being sent here in comparison to the amount of bad
mail being sent by others is .1%. If I had a top ten list of
spam problems I cared about, this would be #14, barely.

Not every annoying gnat needs a nuclear missile response. (Quite
possibly, few-to-none of them do.)

I'm getting a deja vu feeling from when somebody tried to get my
friend thrown out of college 25 years ago for doing open relay testing
after being told to stop. In both cases, what the person was doing was
stupid, but the response was way over the top. That was dumb then and
this is dumb now.



I feel that its a bit different, as a quick google search shows 
discussion on this spam eight months ago, and then it dies down.  I 
would suggest that they were put on notice back around April that this 
was questionable behavior, and yet they decided to start it back up.


I also don't believe that anyone here is going after the student, but 
instead pointing out to Princeton (and its staff) that this is 
unacceptable behavior.


--
SgtChains


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

Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)

[Larry M. Smith via mailop]

On 12/15/2021, Anne P. Mitchell, Esq. via mailop wrote:

FYI, I have sent my own letter, with my full signature (same one as below), to 
Princeton, including cc:ing the dept. chair, the abuse department, and the 
legal department.  I do hope you send yours, and soon, as it would be a good 
1-2 punch.



It would appear that other punches are being thrown elsewhere;

https://www.spamhaus.org/sbl/query/SBL538721


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

Re: [mailop] Privacy research spam apparently from a grad student at Princeton

[Larry M. Smith via mailop]

On 12/15/2021, Al Iverson via mailop wrote:

I wonder if this guy would teach me his secret to get AWS to unblock
port 25 for him. They turned me down, as I'm sort of a security risk,
being an elite hax0r with xnnd.com and all that, haxing port 25s all
over town.
(And maybe I don't WANT to use SES, yuck.)


I'm not yet sure on the SMTP sources.  It could very well be that the 
IPs that the domains are hosted on are not the actual sending IPs.


--
SgtChains



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

Re: [mailop] Privacy research spam apparently from a grad student at Princeton

[Larry M. Smith via mailop]

On 12/15/2021, Raymond Dijkxhoorn via mailop wrote:
(snip)
If people received ones not originating from the below list (and the new 
reported org version) please let me know.


yosemitemail[.]com
potomacmail[.]com
envoiemail[.]fr
novatormail[.]ru



The list of domains being used appears to be here;
https://measurement.cs.princeton.edu/privacystudy/

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

Re: [mailop] Idea for new internet standard: DKIM-QR

[Larry M. Smith via mailop]

On 12/11/2021, Sebastian Nielsen via mailop wrote:

Hi.


(snip)
Note here, that if full body is signed, the content of the QR code 
signature, and the DKIM-Signature: field, will differ by the bh=, as the 
email without QR-code embedded will be signed in the QR-signature, and 
the header DKIM-Signature will have the email WITH the QR-signature. 
This should be completely valid, otherwise a chicken&egg problem would 
appear if the signature must be a signature of itself.




On principal I do not like anything that modifies a message body or most 
of the MUA (mail user agent) provided headers in flight.  The sender or 
the receiver can modify these to suit their needs, but not any other 
systems.  Sender or receiver can be a business entity or an individual 
user; to my mind the test I would use is who "owns" the mailbox. 
Employees of a business entity do not own the mailbox, the business does.


(snip)
This allows a user, to be able to DKIM validate an email EVEN if the 
receiving system has no support for DKIM validation at all, neither the 
client or receiving mail server. This would increase trust for email, as 
users that suspect an email with an embedded link is phishing, could 
easily scan the QR code with his mobile phone, and instantly know the 
email is legit.


It sounds like you want sweeping changes to MUAs to support this, and I 
feel that it would be easier to get MUAs to support the already existing 
DKIM and DMARC standards, even easier would be to find a mailbox 
provider that will do this for you.  Attempting to get phone MUAs to 
support something like this DKIM-QR, when I have yet to find one that 
supports IMAP subscriptions, is umm... Going to be hard.


Having said that, I do not know how much unwanted mail is stopped by 
DMARC mis-alignment...  I simply do not have stats.  I do suspect that 
most of the traffic such systems would catch would be bot-generated 
email, and not much else.  Most of the phishing that I do see is from 
dedicated spammers willing to pay for both domains and IP addresses; 
stolen user accounts; and free-mail providers with poor outbound abuse 
handling -- I'm looking at you Gmail.  DKIM/DMARC isn't going to solve that.




Security considerations:

If a phisher steals the QR code, he would not be able to use it, because 
the Date: will be different. It would be immediately clear to the 
receiver that its an old signature that have been wrongly reused.


Since the To: is included in the validation popup, it would also be 
evident to the original user that the To: address doesn’t match.


And misusing a QR for one email, to send a phishing email with another 
content, would also be evident either by the subject tag not matching 
the content of the email, or the subject tag not matching whats shown in 
validation popup.


There is a risk that someone might include a malicious link instead of 
dkim:// in QR-code, but since all the QR scanner apps today ask the user 
if they want to open the link, the danger decreases.


Also another thing is that mobile phones are today inherently more 
secure, as they, unless configured, will refuse to install binaries from 
unknown sources and isolate apps from each other, meaning that even if a 
dangerous link would be mistakenly opened, nothing would install without 
clicking through multiple consent windows.


This would bring DKIM more to the masses, by senders being able to put 
in a “Scan-To-Verify” DKIM-QR in emails, also prompting users to verify 
their emails.


Would love to hear the toughts about the idea.


The last issue that I have here is the use case for users, and just how 
many of them you would expect to find the feature useful.  It seems to 
me that the vast majority of email's user base just doesn't care, 
doesn't want to go though extra effort, and/or believes that this is 
something that mailbox provider should be doing for them for them.



--
SgtChains

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

Re: [mailop] myshopify.com

[Larry M. Smith via mailop]

On 12/7/2021, John Levine via mailop wrote:

It appears that Chris via mailop  said:

Mailops, is the listing of myshopify.com on AbuseIPDB a cause for concern?

Many small firms use links to x.myshopify.com &
asking if the AbuseIPDB listing impacts on email delivery.

https://www.abuseipdb.com/check/myshopify.com


I've never heard of them, so probably not.


IIRC, AbuseIPDB is one of a few reporting collectors for things like 
fail2ban, but I have no idea how much anyone should be concerned about a 
domain based listing via them.

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

Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?

[Larry M. Smith via mailop]

On 11/24/2021, Michael Peddemors via mailop wrote:
CONN: 40.107.96.87 -> 25 GeoIP = [US] PTR = 
mail-sn1anam02on2087.outbound.protection.outlook.com OS = Windows NT kernel


Returning 250 ok [qp 3539411] for data
QUIT command received, args:

And then it terminates the connection, SSL collapses, without waiting 
for the remote mail server to acknowledge the QUIT.


I get it that they 'might' think that closing when 'they are done' and 
we gave a 250ok on the DATA, and they sent the QUIT.. I don't know, 
thinking to shave a few milliseconds off of the connection, but the RFC 
is pretty clear that a QUIT .. AND .. and acknowlegement is part of RFC.


Comments? (And no, there is zero lag before they terminate)


If I understand you correctly;

When sending mail, *.outbound.protection.outlook.com appears to send 
DATA, terminate via ., wait for a response, then issue QUIT 
immediately followed by a TCP FIN packet.


Operationally, I don't think it makes a difference.  RFC pedantics? 
Maybe.  Does the receiving system advertise the Pipelining SMTP Service 
Extension?.. Does setting/un-setting that response to EHLO make a 
difference to outlook.com's behavior?  If so, does and/or should RFC2920 
allow for QUIT->TCP FIN?




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

Re: [mailop] Bro, do you even VERP?

[Larry M. Smith via mailop]

On 11/6/2021, Dan Mahoney (Gushi) via mailop wrote:

All,

I have email for my whole domain.  I'm typically known to sign up for 
services with vendor@mydomain, so that when an email gets retired or 
leaked, I route it to /dev/null, or in the event of a leak, retire it 
from the original place (say, ad...@mydomain.com) and auto-route it to 
spam reporting and bayes learning.


One of my older ones: d...@mydomain.org was a general purpose one, and 
thus for that one, rather than just routing it straight to sa-learn, I 
put in an autoresponder saying "the spammers won this address, if you 
really want to contact me, use this".


Here's the thing though.

Spam is coming to me with VERP'ed addresses.  It's getting autoresponded 
to.   Those autoresponses are then bouncing back to me as undeliverable.


So...you're a spammer.  You're going to the trouble to do VERP.  You're 
throwing the responses on the ground, or even blocking their receipt.  
Or your VPS got suspended (which I'm sure you saw coming).


What's the bloody point here?  I mean, I know there doesn't have to be 
one, buy I'f love to hear ideas as to what the possible use case is.


I mean, logically, one thing I could do is have my autoresponder detect 
the verp'ed format to this address specifically, and not attempt to 
respond to it (and in fact, I could report on/train on it).


The autoresponder is for legitimate humans trying to contact me directly 
(i.e. nobody who will use verp).  In the few years since I realized this 
address was a lost cause, nobody's tried.  (Although I have started 
getting spam at gushi2015@domain, so that's some intelligence).


You might find a better operational experience by just rejecting the 
messages in SMTP post DATA with a URL for a whitelisting web page.  E.g.;


550 Rejected for spam. Please see 
https://www.example.com/wl?e=&d=&i=


At least then you'll have a chance for the humans to see it w/out all of 
the possible back-scatter and queues possibly filling up do to MX 
records being forged and/or offline.


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

Re: [mailop] Feasibility of a private DNSBL

[Larry M. Smith via mailop]

On 11/3/2021, Nicolas JEAN via mailop wrote:

On 15/10/2021 23:22, Paul Gregg via mailop wrote:

(snip)

Sorry for the late reply.

The trick to this is not to limit by IP address - but to implement
service (API) keys.

e.g. each authorised user is given a key e.g. sj3Fa3Gomd937Z12

Then they make queries for 44.33.22.11.sj3Fa3Gomd937Z12.myserver.example.com.

That way you don't care what IP it comes from, but you know who it is.


Nice trick. :)

Unfortunately, it seems that it would require modifications to e.g. 
postfix, or other software, in order to add that identifying string to 
the DNS query.
Still an idea to keep in mind. Because of how DNS works, the source IP 
address isn't available anyway in a usual, unmodified postfix DNS query.


Isn't this how Spamhaus runs their DQS service?

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

Re: [mailop] WhatCounts/Costco silliness

[Larry M. Smith via mailop]

On 10/27/2021 12:25 PM, Mickey Chandler via mailop wrote:
If you want to get THAT pedantic about it, so is sending an email. After 
all, I can usually get info on the person's anti-spam solution, what MUA 
(other than the web interface) they used, and often the IP address they 
used to send the message via headers.


.. Or just the initial signup, the COI confirmation pass, or any other 
time that the user clicked on one of the URLs.

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

Re: [mailop] WhatCounts/Costco silliness

[Larry M. Smith via mailop]

On 10/27/2021 11:45 AM, Michael Peddemors via mailop wrote:
Not to be a 'nitpicker', but isn't visiting a URL providing a lot more 
information that just the email address opt-out preferences ;)




If done by the MUA passing the request to the user's browser, most 
likely...  Or at least it _could_ do such things.  If done by a webmail 
provider as an API call from the user clicking a button.  No, not 
really, as long as it doesn't redirect the user to the page.  But then 
again, I have no idea how these things are done in practice.


Course, even worse are those companies that have an opt-out link that 
then asks for your email address ;) Doh!


Yes, and such things years ago were a great place to feed spamtraps. 
Everybody leaks, and having a list of unsubs lying around will often 
eventually be imported into the recipients list -- sometimes inadvertently.

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

Re: [mailop] Sendgrid spam of the day

[Larry M. Smith via mailop]

On 10/20/2021 6:56 AM, Michael Orlitzky via mailop wrote:

On 2021-10-19 16:41:40, John R Levine via mailop wrote:

Fake USPS spam, sent to my father who I am pretty sure has not ordered anything
lately since he is dead.


Tragically, we lose most of these because they still haven't figured
out how to retry a 4xx.


I guess this is better than when I saw them sending the same message 
over and over again after 5xx.


Or, even when I saw them trying to issue StartTLS after 'HELO' (not 'EHLO')

.. There are days when I'm left scratching my head after watching 
Sendgrid's SMTP conversations.




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

[mailop] WhatCounts/Costco silliness

[Larry M. Smith via mailop]

Ya know, I'm not a deliverability guy; So there's a good chance that I 
don't understand how these 'List-Unsubscribe' headers work.  However, I 
would believe that pointing it to LITERALLY 'www.example.com' doesn't 
produce the functionally desired.


List-Unsubscribe: 
List-Unsubscribe-Post: List-Unsubscribe=One-Click

I don't know which fools to blame; The client Costco, or their ESP 
WhatCounts.  Perhaps both.

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

Re: [mailop] Gmail's MTA is broken

[Larry M. Smith via mailop]

On 6/7/2021 1:13 PM, Mark Milhollan via mailop wrote:
(snip)
> In general Google's MTA handles SMTP just fine.  But an MTA isn't always
> run in a way that blindly follows the RFCs.
> 
> Some have learned that a 5xx code isn't always a permanent problem
> though the extended code (5.x.x) and/or the words that follow tend to
> influence that determination, potentially on an MX (domain) basis -- too
> bad you redacted the remainder of the server response.  

These extended codes RFC3463 are for better descriptions when forming
bounce messages and other DSNs back to the user, and *not* a method to
override the RFC5321 error.


Abstract

   This document defines a set of extended status codes for use within
   the mail system for delivery status reports, tracking, and improved
   diagnostics.  In combination with other information provided in the
   Delivery Status Notification (DSN) delivery report, these codes
   facilitate media and language independent rendering of message
   delivery status.

[...]

2. Status Code Structure

   This document defines a new set of status codes to report mail system
   conditions.  These status codes are used for media and language
   independent status reporting.  They are not intended for system
   specific diagnostics.


There is only one case where that a sending MTA is allowed to interpret
a 5xx code as a 4xx code, and it is outlined in RFC5321.


4.5.3.1.10.  Too Many Recipients Code

   RFC 821 [1] incorrectly listed the error where an SMTP server
   exhausts its implementation limit on the number of RCPT commands
   ("too many recipients") as having reply code 552.  The correct reply
   code for this condition is 452.  Clients SHOULD treat a 552 code in
   this case as a temporary, rather than permanent, failure so the logic
   below works.


>  For example some
> MTAs respond 554 to a mailbox being full because to them that is a
> policy issue even if the user might add space, remove messages, or
> complain about settings such that a subsequent retry could succeed,
> making some senders treat that 5xx response as a "soft" failure and so
> retried.  I'm not saying Google is doing this for sure, merely that what
> you've shown supports this as a possibility.

This statement suggests that you place greater emphasis on the policies
of the sending system than the receiving system.  Attempting to
enumerate textual response beyond '554 ' for the purpose of determining
error is a fool's errand.

> 
> For that matter some 4xx responses turn out to be effectively permanent
> so instead are treated as you'd expect a 5xx, not retried.

How a sending MTA manages its queues, and its re-sending of messages, is
a matter for the sending system's policies.  I am unaware of any
requirements for the sending MTA to always reattempt sending messages
for a specific number of days or attempts.  In fact RFC5321 suggests
otherwise.


4.5.4.1.  Sending Strategy

[...]

   Retries continue until the message is transmitted or the sender gives
   up; the give-up time generally needs to be at least 4-5 days.  It MAY
   be appropriate to set a shorter maximum number of retries for non-
   delivery notifications and equivalent error messages than for
   standard messages.  The parameters to the retry algorithm MUST be
   configurable.

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

Re: [mailop] Gmail's MTA is broken

[Larry M. Smith via mailop]

On 6/7/2021 2:08 PM, Thomas Walter via mailop wrote:
(snip)
> And there's also systems that send a 5xx and immediately disconnect
> without waiting for the "quit" from the initiating party to properly
> terminate the SMTP session.
> 
> In those cases MTAs following the RFCs see this as a failed connection
> and try again, no matter if the return code specified a permanent or
> temporary issue.

This is behavior specifically allowed in RFC5321, and your sending MTA
need to accommodate it.


7.8.  Resistance to Attacks

   In recent years, there has been an increase of attacks on SMTP
   servers, either in conjunction with attempts to discover addresses
   for sending unsolicited messages or simply to make the servers
   inaccessible to others (i.e., as an application-level denial of
   service attack).  While the means of doing so are beyond the scope of
   this Standard, rational operational behavior requires that servers be
   permitted to detect such attacks and take action to defend
   themselves.  For example, if a server determines that a large number
   of RCPT TO commands are being sent, most or all with invalid
   addresses, as part of such an attack, it would be reasonable for the
   server to close the connection after generating an appropriate number
   of 5yz (normally 550) replies.

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

Re: [mailop] Gmail's MTA is broken

[Larry M. Smith via mailop]

On 6/6/2021 2:01 PM, Gene Hightower wrote:
> On 06/06/2021 07:34, Larry M. Smith via mailop wrote:
> 
>> Seems that gmail.com's MTA can't properly speak SMTP.  [...]
> 
> $ telnet imp.fahq2.com smtp
> Trying 47.12.77.216...
> Connected to imp.fahq2.com.
> Escape character is '^]'.
> 220 "helob0gus.fahq2.com ESMTP"
> 
> The syntax of the initial greeting offered by your MX includes double
> quote characters which don't look to be complaint with the syntax of an
> SMTP reply as specified by RFC 5321 section 4.2. SMTP Replies.
> 
> Perhaps your MTA might be the problem?
> 
> 

I was unaware that my Postfix install was doing that.  Trust me, I'll
fix it.

As for my original message; My personal vanity domain has nothing to do
with what I am seeing, nor does it share any of my infrastructure.  Is
it your normal response to probe unrelated systems when you read posts
on mailop?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Gmail's MTA is broken

[Larry M. Smith via mailop]

Seems that gmail.com's MTA can't properly speak SMTP.  I've been seeing
re-queuing and re-sending of permanent failures for some time now, but
now I'm seeing its user simply hitting forward and sending the bounce to
the original failed recipient.

.. I do get pretty worked up by not being able to follow the RFCs and
normally just shake my head, but this is some pretty basic stuff;  I
give you a 5xx response -- that's a permanent failure, not a temporary one!


From: Mail Delivery Subsystem 
Date: June 5, 2021 at 9:55:58 AM EDT
To: [redacted]@gmail.com
Subject: Delivery Status Notification (Delay)

[redacted]

Delivery incomplete
There was a temporary problem delivering your message to [redacted].
Gmail will retry for 47 more hours. You'll be notified if the delivery
fails permanently.
The response from the remote server was:
554 [redacted]


-- 
SgtChains

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

Re: [mailop] HaveIBeenPwned Was: Abusix Potentially Compromised Account Report

[Larry M. Smith via mailop]

Not trying to rehash things, but while catching up on reading;

On 3/24/20 11:52 AM, Michael Peddemors via mailop wrote:
> On 2020-03-24 9:35 a.m., micah anderson via mailop wrote:
>> Steve Freegard via mailop  writes:
>>
>>> I included the partial SHA-1 to be compatible with automation and
>>> tooling around the HaveIBeenPwned API - see
>>> https://haveibeenpwned.com/API/v3#PwnedPasswords
>>
>> I understand that desire, but I wish the HaveIBeenPwned things were
>> better. As a provider, even with their API, its basically useless for us
>> to actually consume in a way that makes sense.
>>
> 
> While 'haveIbeenpwned' is an interesting piece of data for researchers,
> having an email address password combination in there does NOT
> necessarily mean the account has been compromised either, or more to the
> point, still compromised.
> 

I still haven't decided if I want to classify HaveIBeenPwned as
shameless FUD, an all-out shill for 1password.com, or security
performance art.

Some time ago I downloaded their data, at the time over 555M hashes, and
while there is good reason to avoid passwords that have been used over
and over again.  E.g.;

7C4A8D09CA3762AF61E59520943DC26494F8941B:23547453
F7C3BC1D808E04732ADF679965CCC34CA7AE3441:7799814
B1B3773A05C0ED0176787A4F1574FF0075F7521E:3912816
5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8:3730471
3D4F2BF07DC1BE38B20CD6E46949A1071F9D0E3D:3120735
7C222FB2927D828AF22F592134E8932480637C0D:2938594
6367C48DD193D56EA7B0BAAD25B19455E529F5EE:2855057
20EABE5D64B0E216796E834F52D61FD0B70332FC:2512537
E38AD214943DAAD1D64C102FAEC29DE4AFE9DA3D:2413945
8CB2237D0679CA88DB6464EAC60DA96345513964:2380800

.. I see _no_ value in the millions of hashes (over 196M) that appear to
have only ever been exposed once.  No one is going to load up and
attempt a dictionary attack of those used-only-once hashes.  It sure as
heck doesn't mean a thing about if a specific user has been compromised
without any context to go with the password.

-- 
SgtChains

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

Re: [mailop] btinternet.com blacklist

[Larry M. Smith]

Dom Latter wrote:
(snip)
> But it shouldn't matter.  We are not spammers.  [...]

.. And btinternet.com is supposed to automatically know this?  How?

-- 
SgtChains

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

Re: [mailop] Spamhaus CSS listings of normal mail servers?

[Larry M. Smith]

Robert L Mathews wrote:
> Sadly, I'm still having a problem where my hosting company's mail
> servers keep being listed in Spamhaus CSS, despite working for days to
> identify the cause. (208.80.4.163 is an example listed now.)
> 
> I've written to sbl-remov...@spamhaus.org, but have received no response
> after several days.
> 
> If anyone from Spamhaus sees this and could contact me, it would be
> tremendously appreciated.
> 

So...

https://www.spamhaus.org/query/ip/192.0.2.10 -> "SBLCSS" ->
https://www.spamhaus.org/css/

[...]
"If you are authoritative for an IP address and you believe the issues
that caused the listing have been solved, you can [request a delisting]."

Doesn't work for you?

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