Re: [mailop] Strange Behavior from Microsoft IP Address

[Mark Milhollan via mailop]

On Tue, 7 May 2024, Vitali Quiering wrote:

We've identified an IP address, notably tied to Microsoft 
(20.203.218.75), executing thousands of hits on our URLs almost 
immediately after dispatching a newsletter. However, the peculiar part 
is the variation in the hash segments they're accessing. The URL 
queries we've seen look something like 
https://sub.customerdomain.tld/info/Mjl2Y3N6ej, which, upon decoding, 
starts off with a familiar segment 29vcsz% but diverges significantly 
right after.


Microsoft performs link scanning.  This seems like they are attempting 
to check for mutated patterns as well, something like John the Ripper.



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

Re: [mailop] Gmail + Spamhaus "technical values and unusual sending behaviors"

[Mark Milhollan via mailop]

On Mon, 6 May 2024, K. M. Peterson wrote:


I'm going to have to put together some sort of automated reporting of when
I get blacklisted,


I can recommend .


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

[mailop] Google Postmaster Tools

[Mark Milhollan via mailop]

On Sun, 31 Mar 2024, Odhiambo Washington wrote:


Might someone know what I must do to get data showing on
https://postmaster.google.com/managedomains ?
I have two verified domains in there, but nothing on the (expected)
dashboard.


You must reach a certain volume of messages before anything will appear.


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

Re: [mailop] Outgoing Spam from Microsoft IPs

[Mark Milhollan via mailop]

[Piggybacking as I didn't see Matt's message directly]

On Mon, 19 Feb 2024, Gellner, Oliver wrote:

On 16.02.2024 at 03:38 Matt Palmer via mailop wrote:



Although I must say that



without reverse DNS



would seem to be the easier blocking option -- when was the last time you saw 
legitimate mail from an IP without rDNS?


It isn't like DNS (data), the servers involved, and network paths never 
fail.



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

Re: [mailop] Is forwarding to Gmail basically dead?

[Mark Milhollan via mailop]

On Mon, 12 Feb 2024, Dave Crocker wrote:

On 2/12/2024 4:37 PM, Mark Milhollan via mailop wrote:

On Mon, 12 Feb 2024, Dave Crocker wrote:



 1. S/MIME has been around for 25 years. While it has gained
    respectable amounts of implementation in MUAs, it has achieved use
    only in specialized environments.


Google could greatly accelerate its uptake by automatically providing every 
freemail account with a certificate (DV cert style, i.e., without a 
fullname) and adding it and a signature to every message, and an indicator 
on messages received. 


Certificates are not magic symbols of safety.


I never said they were.  I said, paraphrasing though I see I should have 
been explicit, that Google could increase the number of people using 
S/MIME though not any additional MUAs since theirs already has S/MIME 
support though different.  If only Gmail did it for their freemail that 
could be called just 1 more specialized environment but it might drive 
others to implement it breaking a barrier.  Haven't they done similar 
for TLS transport since otherwise messages get a "bad" indicator, or did 
their effort really do nothing to help increase transport security?


Of all of email's problem's, the most intractable is the widespread and 
continuing insistence that its problems can be solved simply.


I only said it might simply increase the level of use, perhaps 
dramatically, not that it solved anything.



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

Re: [mailop] Is forwarding to Gmail basically dead?

[Mark Milhollan via mailop]

On Mon, 12 Feb 2024, Dave Crocker wrote:


1. S/MIME has been around for 25 years.  While it has gained
   respectable amounts of implementation in MUAs, it has achieved use
   only in specialized environments. 


Google could greatly accelerate its uptake by automatically providing 
every freemail account with a certificate (DV cert style, i.e., without 
a fullname) and adding it and a signature to every message, and an 
indicator on messages received.  Automatic, no muss, no fuss.  If they 
did that a goodly fraction of global email could be signed within a 
year.  They could go further, collecting certificates and encrypting 
when writing to those contacts so that user-to-user encrypted email 
could become globally significant -- yes there are tedious details 
involved.  Most likely Apple, Microsoft, and Yahoo could as well 
accelerating things further.  Sadly I doubt any of them will, and for 
smaller operators it is too cost prohibitive to consider as yet.


Or for that matter Google might do similar with OpenPGP, as well or 
instead of S/MIME.  Smaller providers could do this, but alas I doubt 
enough would.


Of course not everyone wants signed or encrypted email, so probably it 
would need to be opt-in.  And many mailing lists would still have issues 
since they want to alter the message body.



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

Re: [mailop] zen.spamhaus.org

[Mark Milhollan via mailop]

On Tue, 6 Feb 2024, Odhiambo Washington wrote:

On Wed, Feb 7, 2024 at 12:53 AM Mark Milhollan  
wrote:

On Tue, 6 Feb 2024, Odhiambo Washington wrote:



Today morning I woke up to all emails being rejected as I was using
zen.spamhaus.org in my dnslists.



Are you using your own resolver (like BIND, Knot Resolver, or Unbound)
rather than a public resolver (like Cloudflare, Google, or Quad9)?



I have my local instance of unbound resolver.


I should have mentioned that it must not use a forwarder, it must query 
Spamhaus directly.  What results do you obtain if you query for 
127.0.0.1, e.g., ''dig 1.0.0.127.zen.spamhaus.org''?  If the result is 
that there are no records (NXDOMAIN) then the problem isn't use of an 
open resolver.  But if the result is 127.255.255.254 then you are using 
an open resolver and you must find a way to stop doing so -- if you must 
use a forwarder then be sure to specify that for zen.spamhaus.org it 
should not.  Otherwise you need to stop using Spamhaus -- even if you 
sign-up, perhaps because of the query volume, you still must query them 
directly not via a public resolver.



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

Re: [mailop] zen.spamhaus.org

[Mark Milhollan via mailop]

On Tue, 6 Feb 2024, Odhiambo Washington wrote:


Today morning I woke up to all emails being rejected as I was using
zen.spamhaus.org in my dnslists.
Almost all incoming emails - even from gmail.com - were being rejected.
Did I maybe miss something?


Are you using your own resolver (like BIND, Knot Resolver, or Unbound) 
rather than a public resolver (like Cloudflare, Google, or Quad9)?  You 
must else Spamhaus will return 127.255.255.254.  If your software 
blindly treats an A/TXT result as indicating the host is listed then the 
policy refusal result, 127.255.255.254/"Error: open resolver; ...", will 
make it seem like the host is listed.



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

Re: [mailop] Contact Google Postmaster

[Mark Milhollan via mailop]

On Fri, 26 Jan 2024, Scott Mutter wrote:


The 173.225.104.91 server has sent 68 emails to gmail.com email addresses
thus far in January 2024.


GPT will not present data for that volume.  From their FAQ: "Most of the 
Postmaster Tools dashboards will only display data when there’s a 
sizable daily volume of email traffic (up to the order of hundreds) 
coming from your Authentication Domains and/or certain other conditions, 
in place to prevent abuse."



How am I supposed to remedy a low reputation?


Supposedly the only way is for the receivers to signal Google's system 
that your messages are wanted.  So far as I know that means they must 
remove the spam label (click not spam), actually open the message not 
merely look at the subject/preview before deleting it, and do so pretty 
consistently.  But it might not be reputation that is your issue, or at 
least not only reputation, it might be the content itself so you might 
have to remove or change URLs (don't use any shorteners), graphics, 
and/or words in the messages, especially in boilerplate.



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

Re: [mailop] Gmail blocking of good customer

[Mark Milhollan via mailop]

On Fri, 24 Feb 2023, Rob McEwen wrote:

Quite frankly, I'm constantly amazed at how often I see assumptions from so 
many - that assume Google is always right and the other entity is wrong - even 
when all the facts point to the opposite.


I never said Google was "right", but if you want to deliver to them you 
have to jump through their hoops.  If you don't have enough volume to 
qualify for them to provide data -- Google's vague metric -- it turns 
into a guessing game, so you have to look for other indicators such as 
having any RBL hits which the IP address quoted does (SORBS listings 
within the last 28 days).



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

Re: [mailop] Gmail blocking of good customer

[Mark Milhollan via mailop]

On Fri, 24 Feb 2023, Christine Borgia wrote:


I have a customer whose email campaign was heavily
blocked yesterday by Gmail with the error:

421 4.7.0 [149.72.90.158 15] Our system has detected that this message is
suspicious due to the very low reputation of the sending domain. To best
protect our users from spam, the message has been blocked. Please visit
https://support.google.com/mail/answer/188131 for more information.
v14-20020a05620a440e00b0073ba7884843si8095361qkp.8 - gsmtp


Did you read the link?  Does your ESP have a postmaster account?  If 
they don't send enough messages ("a large volume") to Gmail they won't 
provide any information about reputation, except that that itself 
indicates that you haven't (and can't) collect enough reputation to be 
other than low aka poor.  SORBS certainly doesn't like that IP address.



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

Re: [mailop] Microsoft Sending DMARC Reports From IP In SBL

[Mark Milhollan via mailop]

On Tue, 19 Jul 2022, Matt Corallo wrote:

Relevant headers below, but note that its actually the very first Received 
header that matches SBL-CSS.


You are via Spamassassin doing what Google does and I guess at least 
some other Spamassassin users do -- presuming to know how earlier hops 
should have authenticated/judged their peers because of how you would 
have.  Yes Microsoft should get their internal system off the Spamhaus 
list since it uses a GUA, but it is risky to decide how others should 
have made their decisions.  Since it is your MTA your rules, it is also 
fine that you lose mail for that rule.



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

Re: [mailop] forwarding to gmail - problem

[Mark Milhollan via mailop]

On Thu, 28 Apr 2022, Scott Mutter wrote:


configure your Gmail account to POP mail from that POP3 mailbox.  This
side steps the issues of SPF failing,


It does not.  As recently discussed, Gmail plays a game of trying to 
guess whether SPF should have failed on a previous hop, rather than just 
the connected peer.  If they see a hop that accepted from a source that 
SPF does not authorize and if not an RFC1918 address or an IPv6 LLA the 
result is failure -- they don't accept the common indication of SMTP 
AUTH, e.g., ESMTPSA, likely to catch when leaked credentials are 
(ab)used, but it also "catches" roaming users.


Authentication-Results: mx.google.com; ... spf=fail ...
Received: from passes-spf ... by mx.google.com ...
Received: from not-within-spf-its-a-forking-cafe ... by passes-spf with 
ESMTPSA ...


This is also done for messages fetched via POP with the result that some 
are given the spam label while some are skipped.


  spam labeled (details in Gmail web MUA indicate SPF failure):

Delivered-To: m...@some.corp
Received: from not-within-spf-its-a-forking-cafe ... by mail.some.corp with 
ESMTPSA ...
From: 
To: 

  not saved, which seems the POP fetch equivalent of an SMTP reject:

Delivered-To: m...@some.corp
Received: from their-mta-wthin-spf ... by mail.some.corp with ESMTPS ...
Received: from not-within-spf-its-a-forking-cafe ... by 
their-mta-within-spf with ESMTPSA ...
From: 
To: 

  spam labeled -- more verbose:

   Original to be fetched:

Received: from BY5PR22MB1826.namprd22.prod.outlook.com 
(2603:10b6:a03:239::8) by BY5PR22MB2034.namprd22.prod.outlook.com with HTTPS; 
Wed, 20 Apr 2022 16:49:43 +
Authentication-Results: dkim=none (message not signed) 
header.d=none;dmarc=none action=none header.from=some.corp;
Received: from BY5PR22MB2034.namprd22.prod.outlook.com 
(2603:10b6:a03:230::13) by BY5PR22MB1826.namprd22.prod.outlook.com 
(2603:10b6:a03:239::8) with Microsoft SMTP Server (version=TLS1_2, 
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Wed, 20 Apr 
2022 16:49:41 +
Received: from BY5PR22MB2034.namprd22.prod.outlook.com 
([fe80::149a:1ce0:44a0:a16%6]) by BY5PR22MB2034.namprd22.prod.outlook.com 
([fe80::149a:1ce0:44a0:a16%6]) with mapi id 15.20.5186.014; Wed, 20 Apr 2022 
16:49:41 +
From: 
To: 

   As seen in Gmail web MUA (which indicates SPF failure):

Delivered-To: m...@gmail.com
Received: by 2002:a5d:860f:0:0:0:0:0 with SMTP id f15csp3628616iol; Wed, 20 
Apr 2022 10:26:27 -0700 (PDT)
X-Google-Smtp-Source: [elided]
X-Received: by 2002:a05:620a:404e:b0:69e:a5db:22cb with SMTP id 
i14-20020a05620a404e00b0069ea5db22cbmr8513102qko.735.1650475587274; Wed, 20 Apr 
2022 10:26:27 -0700 (PDT)
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of 
transitioning m...@some.corp does not designate 2603:10b6:a03:239::8 as 
permitted sender) smtp.mailfrom=m...@some.corp
Received-SPF: softfail (google.com: domain of transitioning m...@some.corp 
does not designate 2603:10b6:a03:239::8 as permitted sender) 
client-ip=2603:10b6:a03:239::8;
Received: by 2002:ac8:56fa:0:b0:2eb:a8b9:b77 with POP3 id 
26-20020ac856fa00b002eba8b90b77mf678417qtu.2; Wed, 20 Apr 2022 10:26:27 
-0700 (PDT)
X-Gmail-Fetch-Info: m...@some.corp 3 outlook.office365.com 995 
m...@some.corp
Received: from BY5PR22MB1826.namprd22.prod.outlook.com 
(2603:10b6:a03:239::8) by BY5PR22MB2034.namprd22.prod.outlook.com with HTTPS; 
Wed, 20 Apr 2022 16:49:43 +
Authentication-Results: dkim=none (message not signed) 
header.d=none;dmarc=none action=none header.from=some.corp;
Received: from BY5PR22MB2034.namprd22.prod.outlook.com 
(2603:10b6:a03:230::13) by BY5PR22MB1826.namprd22.prod.outlook.com 
(2603:10b6:a03:239::8) with Microsoft SMTP Server (version=TLS1_2, 
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Wed, 20 Apr 
2022 16:49:41 +
Received: from BY5PR22MB2034.namprd22.prod.outlook.com 
([fe80::149a:1ce0:44a0:a16]) by BY5PR22MB2034.namprd22.prod.outlook.com 
([fe80::149a:1ce0:44a0:a16%6]) with mapi id 15.20.5186.014; Wed, 20 Apr 2022 
16:49:41 +
From: 
To: 


Good thing I don't do the same silliness else a daily email I get from 
them would be rejected at end of DATA or dumped in my spam folder since 
"domain of u...@gmail.com does not designate 24.199.x.x as permitted 
sender" ...


Received: from mail...google.com by me with ESMTPS ...
Received: by mail...google.com with SMTP ...
Received: from smtpclient ([24.199.x.x]) by smtp.gmail.com with ESMTPSA ...


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

Re: [mailop] gmail - pop3 retrieval checking SPF ? ( gmail, wth ? Take 2 )

[Mark Milhollan via mailop]

On Wed, 13 Apr 2022, Paulo Pinto wrote:


Why on earth is gmail checking the IP address of the message sender (ISP
assigned home address, for instance) against the sender's domain SPF


I've mentioned it before to which got a "I don't think we do that" when 
it was plain they did (their own SPF results claimed that's what they 
checked).


Google appears to be trying to decide if it was submitted from a "bad" 
place thus is likely a bad message by checking SPF as if they were the 
initial receiver, with the same checks applying to messages they fetch 
from elsewhere.  On the surface it seems a reasonable way to catch 
submissions using stolen credentials but it also penalizes submissions 
aren't made entirely "inside" -- their checking ignores RFC1918 
addresses.  To avoid Google's non-compliant behavior you must put the 
encoded information in a non-standard header, or toss it and rely on 
your logs.



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

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

[Mark Milhollan via mailop]

On Sun, 10 Apr 2022, Byron Lunz wrote:


I don't recall seeing any discussion in this thread about how to migrate
old email messages from a Google Workspace account to a different host.
Anyone have advice or suggestions on how to do that?


If you use a desktop MUA likely you just add the other service and drag 
the folder tree (that might move the messages+structure instead of 
copying it).  I don't know of a general service, nor if I'd trust it, 
but it isn't too difficult to do yourself using an IMAP tool (e.g., 
using a little throw-away VM somewhere) -- sometimes where you go has 
such a tool integrated into their control panel.



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

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

[Mark Milhollan via mailop]

On Sat, 9 Apr 2022, John Levine wrote:


PS: Gmail allows general plus addresses, Yahoo allows a limited
number, can't think of any other significant commercial mail system
that allows either.


Apart from whether they are significant I've found many others provide 
plus addressing / subaddresses, though if they are Qmail based generally 
they use a dash rather than a plus.


Microsoft's Exchange Online, Office365, and Microsoft365 can allow it 
generally as well.  Whether a + means plus addressing or is just another 
character is a per tenant setting with plus addressing as the default 
for new tenants but for existing tenants it depends on their existing 
addresses (if none have a + then plus is enabled else disabled).  I 
don't know if this applies to Hotmail/Live/Outlook. 



Fastmail was mentioned earlier, and they go beyond it using subdomains, 
i.e., mail...@example.com is the same as mailbox+anyth...@example.com as 
well as anyth...@mailbox.example.com provided you've got the DNS setup. 



Gmail also goes beyond it, in that they also ignore periods such that 
mailbox@, mail.box@, mailbo.x@, mailbox.@, etc., are all the same 
mailbox.  


Yahoo has "disposable" addresses that use a dash (quite expectable since 
they use qmail-ish), which are not automatic, you have to create them -- 
500 are allowed -- and they are limited generally to Plus subscribers. 



Verizon (nee Yahoo) Small Business does not appear to though at one time 
they were all hosted on the same platform as the Yahoo! (et al) brand 
(and might still be) so they might provide either plus or disposable.



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

Re: [mailop] What am I supposed to do with abuse complaints on legit mail?

[Mark Milhollan via mailop]

It is too bad if you or your user feels the message was legit but 
reported as junk, spam or unwanted, whether directly or indirectly, 
whether mistaken or not -- even messages that "need" to be delivered 
might get you blocked.


PSA: You should authenticate bounces, feedback reports and even SMTP 
rejects as inauthentic ones should be handled differently (often as an 
attack that needs mitigation).


Can it be a challenge to get into a feedback loop, yes.  For an ESP it 
is usually easy or relatively so as long as the WHOIS, RWHOIS and RDAP 
data for the IP address(es) name your service -- if the data isn't 
correct get it fixed.  If you can't get in a loop you'll usually want to 
be far more aggressive about reject and bounce handling.


Whether you take action is up to you, of course, though an ESP almost 
certainly will want to avoid delivery problems so that the majority of 
their users can continue to enjoy their service.


Deciding whether to continue, delay, or desist means deciding what is 
going on, things like whether the receiving ORG or MX seems to be having 
a problem, vs the ORG/MX spurning your service or sender, vs a specific 
recipient accidentally/mistakenly spurning a specific sender vs 
intentionally, which is not trivial especially for an ESP due to scale 
(they'll need software and databases and people to accomplish it).


As the MTA operator you most certainly should be able to prevent 
messages from address A to address Z -- after all you are operating the 
thing that says MAIL FROM and RCPT TO.  As an ESP if your MTA doesn't 
make that easy it is time to augment or switch, and if the one you use 
can but isn't configured for such, well, reconfigure.


How an ESP handles all this is part of what differentiates each.


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

Re: [mailop] How to detect fraud login in POP IMAP or SMTP?

[Mark Milhollan via mailop]

On Tue, 21 Sep 2021, Michael Peddemors wrote:


Use RATS-AUTH to block auth attacks, from known dedicated IP(s) ;)


I've tried this, so far it has blocked 7 of 4933 AUTH attempts since I 
began using it.



Block AUTH from Amazon/Gcloud/Azure by default


Would you include other clouds, like Alibaba, Oracle, OVH, Rackspace, 
etc., perhaps especially those that are "too easy" for spammers and 
miscreants to get a machine going on?  I can understand this sentiment 
but be aware it might block your more advanced users, e.g., those 
hosting a VPN or mail archive there or a service that does.



but the MOST IMPORTANT THING!!

Stop allowing unencrypted AUTH.. eg port 110, 143, 25.

#didyouknow that by turning off unencrypted AUTH you can reduce compromised 
accounts by as much as 90%?


I've seen attempts try clear even though authentication isn't offered 
w/o TLS, but also explicit-TLS and implicit-TLS so yes some of them 
would be blocked and that's good, just don't anybody expect a silver 
bullet.  Lately I've closed all but 25 which cannot AUTH -- they still, 
blindly, try -- and only open the other ports upon port knocking and 
locally which a VPN can reach.



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

Re: [mailop] Gmail putting messages to spam

[Mark Milhollan via mailop]

On Mon, 20 Sep 2021, Ken O'Driscoll wrote:


2. Your sending domain (rafa.eu.org) is a sub-domain of a pseudo-TLD which a) gives 
sub-domains away for free, and b) has an overly permissive SPF policy ("v=spf1 
+all"). The reputation of your sub-domain is going to be influenced by the 
reputations of the base domain and all of the other sub-domains.


One would hope Gmail consults the PSL which would disclose that 
rafa.eu.org is not merely/only a subdomain of (name under) eu.org but 
rather it is its own apex domain, just as names under com and co.uk are, 
i.e., milhollan.com is a zone/parent delegated from com not merely a 
name under com.  And I certainly hope I don't inherit the reputation of 
com and all the names under it.


$ psl --print-reg-domain com milhollan.com co.uk eu.org rafa.eu.org
com: (null)
milhollan.com: milhollan.com
co.uk: (null)
eu.org: (null)
rafa.eu.org: rafa.eu.org

I'll agree that if obtaining eu.org domains is too easy that might be 
too strong a negative signal to easily overcome, or put another way it 
might be easy to include other things that make a decision of spam for 
only some of a series of messages.



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

Re: [mailop] SNDS At Work

[Mark Milhollan via mailop]

On Tue, 7 Sep 2021, Mike Hammett wrote:


I now manage another ISP with another set of e-mail servers



I went to sign up for SNDS with my work e-mail.



I don't want to use my existing account because I want some amount of 
separation of duties.


What are the rest of you doing in these kinds of scenarios? My only 
thought at the moment is to sign up with an e-mail address on the 
server that I'm wanting to watch (and is currently blocked).


Generally I use subaddressing (plus or ext style, so mailbox+additional 
or mailbox-additional respectively) for the purpose, i.e., 
$roleaccount+$client-$subpurpose@$workdomain or similar which for this 
might be $you+$client-snds@$yourdomain or if that's too long perhaps 
just $you+snds$n@$yourdomain.



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

Re: [mailop] I disabled Spamhaus checking due to false-positives

[Mark Milhollan via mailop]

On Thu, 15 Jul 2021, Bastian Blank wrote:


Did you check the result of those RBL requests?  Spamhaus also provides
specific codes for errors, so you _must_ explicitely list what codes you
want to accept.  See
https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 what those mean.


I've been consuming SBL-XBL for years.  But I don't have Postfix 
checking for specific results -- I'm not sure I care whether those 
addresses were temporarily listed (127.0.0.0/16), nor my 200 queries a 
day managed to trip some policy limit (127.255.255.255), nor were the 
queries via a public/open resolver (127.255.255.254), nor were they DBL 
queries that might have been malformed (127.255.255.252), it has become 
problematic for me to continue using.  Perhaps it was due to a bug -- 
we'll see what Matthew finds -- in which case I might risk using it 
again provided a fix is also described as having been made.



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

Re: [mailop] I disabled Spamhaus checking due to false-positives

[Mark Milhollan via mailop]

On Fri, 16 Jul 2021, Al Iverson wrote:


is it bad vibes to query Spamhaus directly against
a.gns.spamhaus.org - e.gns.spamhaus.org?


Those are the servers that would normally be queried, in that they are 
the listed NS for the DBL, PBL, SBL, XBL, SBL-XBL and ZEN zones.



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

[mailop] I disabled Spamhaus checking due to false-positives

[Mark Milhollan via mailop]

Spamhaus has been working fine for me and has been a wonderful resource 
for many years, but I recently decided I had to disable using them on my 
personal, low volume mail server because of a few recent surprises 
(that's right, I don't look at Spamhaus rejects, timestamps are UTC):


  Jul 10 22:20:34 mm-new smtpd[28996]: NOQUEUE: reject: RCPT from 
s0.eburgsquare.com[104.223.145.19]: 554 5.7.1 Service unavailable; Unverified Client host 
[s0.eburgsquare.com] blocked using dbl.spamhaus.org; 
https://www.spamhaus.org/query/domain/eburgsquare.com; from= 
to=<[elided]@milhollan.com> proto=ESMTP helo=
  Jul 13 21:59:33 mm-new smtpd[20435]: NOQUEUE: reject: RCPT from 
liaoningosaurus.mktdns.com[192.28.148.54]: 554 5.7.1 Service unavailable; Client host 
[192.28.148.54] blocked using sbl-xbl.spamhaus.org; 
from=<733-ksk-625.0.175526.0.0.16914.9.10824...@email1.digium.com> 
to=<[elided]@milhollan.com> proto=ESMTP helo=
  Jul 14 00:13:04 mm-new smtpd[22318]: NOQUEUE: reject: RCPT from 
mail-ej1-f68.google.com[209.85.218.68]: 554 5.7.1 Service unavailable; Client host 
[209.85.218.68] blocked using sbl-xbl.spamhaus.org; 
from= to=<[elided]@milhollan.com> proto=ESMTP 
helo=
  Jul 14 15:25:30 mm-new smtpd[3627]: NOQUEUE: reject: RCPT from 
gk-w94-email.usps.gov[56.0.84.94]: 554 5.7.1 Service unavailable; Client host [56.0.84.94] 
blocked using sbl-xbl.spamhaus.org; from= 
to=<[elided]@milhollan.com> proto=ESMTP helo=
  Jul 14 22:37:33 mm-new smtpd[10015]: NOQUEUE: reject: RCPT from 
my-mail.splashtop.com[34.208.80.28]: 554 5.7.1 Service unavailable; Client host [34.208.80.28] 
blocked using sbl-xbl.spamhaus.org; from= 
to=<[elided]@milhollan.com> proto=ESMTP helo=
  Jul 15 06:17:18 mm-new smtpd[14530]: NOQUEUE: reject: RCPT from 
mta0.tedlarbagsale.com[134.73.145.18]: 554 5.7.1 Service unavailable; Unverified Client host 
[mta0.tedlarbagsale.com] blocked using dbl.spamhaus.org; 
https://www.spamhaus.org/query/domain/tedlarbagsale.com; 
from= to=<[elided]@milhollan.com> proto=ESMTP 
helo=
  Jul 15 10:00:11 mm-new smtpd[3294]: NOQUEUE: reject: RCPT from mx.mailop.org[91.132.147.157]: 
554 5.7.1 Service unavailable; Client host [91.132.147.157] blocked using sbl-xbl.spamhaus.org; 
from= to=<[elided]@milhollan.com> proto=ESMTP 
helo=

Both DBL rejections look to be spam.  But all but 1 of these SBL-XBL 
rejections were non-spam (I know those senders and want their messages) 
so for me are false-positives -- the Gmail rejection looks like spam (I 
don't know that sender).  16 rejections (9 good rejections not shown) 
between Jul 10 00:00Z and Jul 15 10:20Z, 4 of which were not appropriate 
makes for a not good ratio.


Manually checking the SBL-XBL rejections on the mail server shortly 
after the last rejection yielded null/NXDOMAIN responses via DNS using 
getent/dig and showed "no issues" via the Spamhaus web site reputation 
center.  I use my own local resolver (unbound 1.13.1) with no forwarders 
configured.



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

Re: [mailop] Gmail's MTA is broken

[Mark Milhollan via mailop]

On Sun, 6 Jun 2021, Larry M. Smith wrote:


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,



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]


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.  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.


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



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

Re: [mailop] Ooo.. That's an ugly email header..

[Mark Milhollan via mailop]

On Fri, 26 Feb 2021, Michael Peddemors wrote:


can any one guess why they need THAT much data in the email header?


It seems that those that add giant or lots of headers are doing so for 
future analysis purposes where logs are not kept or may have expired by 
the time an investigation might begin.




Seems everyone wants to add a verification code in the TXT records,


Most can be removed after the verification passes.


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

Re: [mailop] Hotmail and block on OVH: possible solutions alternatives?

[Mark Milhollan via mailop]

On Thu, 25 Feb 2021, Michael Peddemors wrote:

Also, speaking of whois, pet peeve that some of the whois databases never seem 
to be updated/cleaned up.


And some of the biggest don't publish anything.



whois 51.79.55.200

Still thinks RIPE is responsible..


Your whois program thinks that -- not entirely wrongly, the /8 once was 
entirely managed by RIPE NCC but islands have been carved out for other 
regions -- time to update its configuration or replace it ...


$ jwhois 51.79.55.200
[Querying whois.arin.net]
[...]
OVH Hosting, Inc. HO-2 (NET-51-79-0-0-1) 51.79.0.0 - 51.79.255.255
OVH Hosting, Inc. VPS-BHS6 (NET-51-79-48-0-1) 51.79.48.0 - 51.79.55.255

Granted OVH didn't document (via SWIP/rwhois/RDAP) that 55.200 was 
reassigned to a customer.  Do they even have a way for a customer 
receiving to request pubication -- I do not know, but it isn't 
surprising that they don't absent their customer requesting they do so.



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

Re: [mailop] RFCs on quoted pairs in From:?

[Mark Milhollan via mailop]

On Thu, 28 Jan 2021, Paul Smith wrote:


From: "Joe " 
Subject: test

and Thunderbird tries to reply to b...@example.com. That is totally wrong! It's 
a bug and needs reporting.


At a guess, it is a mistaken attempt to work around a rewritten From 
header (e.g., for SPF reasons) but no Reply-To header.



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

Re: [mailop] t-online.de refuses to remove an ip from their blacklist

[Mark Milhollan via mailop]

On Thu, 18 Jun 2020, Benoît Panizzon wrote:


AFAIK only one PTR per RR is allowed,


Incorrect.  Whether others will process them in a way you want might be 
the larger concern.



/mark

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

Re: [mailop] Anyone have any luck delisting from Microsoft's Advanced Threat Protection (ATP)?

[Mark Milhollan via mailop]

On Wed, 13 May 2020, Alex Burch wrote:


we tried going this
route - we went through paid support in our Office/Microsoft365 account
(Business Premium) and these tickets have not been resolved.


Is there no way to ask for or demand escalation?  Or by "not resolved" 
do you mean "as we wished/needed" instead of them still being open?



/mark

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

Re: [mailop] Sendgrid strikes again; zendesk, actually

[Mark Milhollan via mailop]

On Wed, 26 Feb 2020, Paul Smith wrote:


## In replies all text above this line is added to the ticket ##


Your Twilio Ticket ID # 3806345 Encoded ID # [Q54RWY-VROX] Your Ticketing 
System's ID # (if we have recorded one): -


 This email is a service from SendGrid.

below the quoted text. The middle of the message is the ticket history. That 
is quite normal for ticket acknowlegements that I see. It all looks normal to 
me. They can't put anything else at the top of the message because "all text 
above this line is added to the ticket"


I.e., Standard crappy Outlook style quoting of the original message (and 
likely the whole chain of messages) hence the "respond above part", 
combined with templating including a footer.  I'm surprised Jaroslaw is 
unfamiliar with it.



/mark

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

Re: [mailop] sendgrid sending spam claiming to be chase.com

[Mark Milhollan via mailop]

On Mon, 23 Dec 2019, Carl Byington wrote:


The spam was sent with a From: header of @email.chase.com.
_dmarc.email.chase.com. has a txt record with p=reject, so it was
rejected here. Sendgrid - you should be able to check that at your end,
and just not send anything that violates the dmarc restriction published
by the ostensible sender.


The problem there is that what was once okay might turn to crud or DNS 
responces might be different for you than for them.  The former should 
be detectable if they were to do it as they forward/relay but the odds 
of that are low so Sendgrid might think all is well -- of course your 
report might trigger a re-check but reports via this ML don't really 
scale.  The latter, if true, should almost certainly be fixed at least 
with respect to e-mail related items but again might have once been fine 
then suffered rot.  Relativity at human scale, as it were.


RUA and RUF are present in the DMARC record, which theorhetically scales 
-- did you send one or both to the related e-mail addresses?  One would 
hope those would similarly trigger research, perhaps especially given 
they were the peer reported to have submitted the message.



Your Chase Banking has been disabled. Your online access  has been
disabled due to multiple use of incorrect passwords. For your security
reason, we have disabled your online banking

Contains a link to https://resize.yandex.net/mailservice?url=.


And I'd think at forwarding/relay time there'd be basic malware and 
phishing checks though perhaps use of that URL was too new to be 
classified.



/mark

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

Re: [mailop] Gmail doesn't like my IPv6 address, why?

[Mark Milhollan via mailop]

On Wednesday 2019-12-18 12:18, Brian wrote:


For what I can see
on my logs, Gmail seem to prefer v6 when delivering emails to my
server, but for some reason when my server uses v6 to deliver emails
their milters mark them as spam (except of course when I send test
emails to my 15 years old personal gmail account... *sigh*)

My question is: why Gmail is OK with my old v4 but at the same time
doesn't trust my new v6 when they have all the information available to
verify that both sources are in fact from the same origin?


IPv6 is normally preferred so if you have published an  for the 
highest priority MX then IPv6 would be tried first, and since you accept 
the messages you no longer see much IPv4 from them.  As to why they 
don't like you via IPv6 -- they are (more) "strict" about IPv6 
connections so you need a PTR along with SPF and/or DKIM, plus you 
should be sure to signal "Not Spam" on any messages that make it in but 
have the Spam label.  G Suite has additional controls you should look 
into.



/mark

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

Re: [mailop] BIMI

[Mark Milhollan via mailop]

On Tuesday 2019-12-10 17:32, John R Levine wrote:


I sadly realize that I am the last person in the world using Alpine.


Not quite, but indeed not a large crowd.


/mark

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

Re: [mailop] Issue with Mailop 'From' header

[Mark Milhollan via mailop]

On Wed, 14 Aug 2019, Andy Smith wrote:

On Wed, Aug 14, 2019 at 12:09:10PM -0600, Anne P. Mitchell, Esq. via mailop 
wrote:



Something has changed in the past several weeks so that email from Mailop now 
comes:

From: 



..making triage, etc., of reading Mailop mail more onerous now,



I don't really get how it's harder to see the mail's source


When I read "triage" i thought filtering.  Rules that used to be "if 
From ..." must now all be augmented with or changed to "if Reply-To ..." 
if the MUA can even filter on that header.  Lists used to use Reply-To 
to direct responses to the list and some MUAs expect(ed) that, which is 
now reversed making it more likely to direct responses off-list.


Visually I expect it is similar for cases where addresses are known 
better than friendly names, making the habit to look at From having to 
be revised to look at Reply-To, which may not normally be displayed and 
even difficult to pick out especially with some providers prepending a 
huge number of headers to every message.


Don't expect better Anne -- perhaps a way can be found for your MUA to 
help you, e.g., display Repl-To if not already shown (it really should 
be) perhaps even color it differently.



/mark

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

Re: [mailop] Outlook/Hotmail reporting to us that a mail has been declared as SPAM by a recpient, but... ?

[Mark Milhollan via mailop]

On Fri, 28 Jun 2019, Sébastien Riccio wrote:

We've seen this a few times. We've come to the conclusion that it's 
either anti-spam software on the local computer that is automatically 
moving the email into the user's spam folder (and thus marking it as 
spam),


For example Thunderbird defaults to having its Junk system enabled.

or the users are accidentally doing it themselves without 
realising it.


Yes, that's an interresting possibility. I''ll be sure our customer ask 
his recipient if he's using the webmail or a client for his outlook 
account.


Also explore if your user might have deleted the message without reading 
it.



/mark

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

Re: [mailop] Are there any de facto standards around no-reply@ addresses?

[Mark Milhollan]

On Wed, 10 Apr 2019, Grant Taylor wrote:


Are there any standards around no-reply type addresses?



The back story in this case involved two such systems that were naively
replying to each others no-reply address.


Automation trying to be "helpful"?  Damned if you do and damned if you 
don't, and in this case damned all around.  It sounds like the messages 
were auto-generated and should have had headers indicating such, which 
still leaves whether there's enough clue in the receiver to check for 
them and if found avoid generating a response.



Another part of the question was if it's okay to omit such no-reply addresses
when generating recipients for auto-replies or other programmatically
generated emails.


Almost certainly.  A related question is whether the presence of one 
should supress any kind of response especially from automation.  The 
trick is that you can't be sure if  is from 
automation or merely someone at example.com being funny/peevish.  When a 
message is received from a sender that doesn't want a reply (even if 
human) the mere presence of those headers begins to provide convincing, 
well not proof but at least an assertion that automation should not 
respond even "helpfully".



/mark

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

Re: [mailop] Google to the WCP?

[Mark Milhollan]

Google inspects Received headers and checks SPF for each ignoring those 
showing an RFC-1918 address, any of which failing means a pretty good 
chance the message will be given the SPAM tag, i.e., SPF is checked not 
just for the connected peer.  So a message originated at 192.168.1.101 
and relayed via 192.0.0.x with SPF saying that only 192.0.0.0/24 is an 
authorized sender then all is well, but if it had originated at 1.2.3.4 
Google would judge that it fails SPF and very likely be given a SPAM 
tag.  (Repeated more RFC-ishly at bottom)


More specifically if the message originated at internal.apple.com at 
17.x.x.x then was relayed via the ESP at 192.0.2.x with SPF saying that 
only 192.0.2.0/24 is an authorized sender of the FROM FQDN Google would 
likely tag it SPAM because of the first Received header.



Given an SPF of "v=spf1 ip4:192.0.0.25 ~all".

  Okay:
Received: from ([192.0.0.25]) by Google
Received: from ([192.168.1.101]) by myserver

  Fail:
Received: from ([192.0.0.25]) by Google
Received: from ([1.2.3.4]) by myserver


/mark

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

Re: [mailop] Any t-online.de admins here?

[Mark Milhollan]

On Fri, 25 Jan 2019, Eike Armbrust wrote:

>I'm not sure what you mean. Of course my users do have IMAP.

I.e., have them configure their T-Online account to pickup messages from 
you via IMAP.  That doesn't always help/work though.  If they forwarded 
SPAM to other than themselves (e.g., a friend) that's an education issue 
which is usually "don't forward", sadly.


/mark

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

Re: [mailop] Expires SSL cert for mailop

[Mark Milhollan]

On Thu, 25 Oct 2018, Doug Barton wrote:

>In the age of Let's Encrypt expired TLS certs are a really bad look.

Let's Encrypt changes little, processes can break whether they are 
yearly, bi-yearly or monthly.  Granted you'd think there would be 
monitoring and then reasonably quick restoration.


/mark

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

Re: [mailop] Anyone else seeing EOP/O365 unable to connect when delivering?

[Mark Milhollan]

[mildly rearranged]

On Wed, 3 Oct 2018, Ryan Krueger wrote:

>The behavior is that EOP/O365 servers get a connection refused error 
>when connecting to our servers.  The error is "450 4.4.316 Connection 
>refused [Message=Socket error code 10061]...".

>One of our customer's business partner has opened a ticket at Microsoft 
>but experienced difficult and slow support.  The support tech simple 
>says the other side is refusing the connection, the end.  Not helpful.

And yet that is exactly the issue Microsoft is having in contacting your 
system, error code 10061 is WSACONNREFUSED (connection refused), as you 
have noted.  What more should they report when there's nothing but an 
RST returned to them?

>Our software doesn't have the capability to refuse a connection 

Your software may not but does that include your load balancers?  That 
they haven't been overloaded might not be the only reason they would 
return an RST.  I've seen people try to block the prefixes of countries 
with which they had no business connections in an attempt to lessen 
their SPAM and phishing load only to find out that sometimes SMTP 
connections from their customers indeed originated from those countries 
-- I'm not suggesting that you've done exactly this, only that something 
might be involved in the hosts of the software or the load balancers 
where they've been instructed to refuse certain kinds of connections.

Is there any chance your prefix is being hijacked or poorly sniffed?  
Cases where systems other than your MTAs are (also) receiving the SYN 
but return an RST because they aren't listening on port 25.

>Is there anyone at Microsoft that is able to look into this?

This is indeed what you need, that perhaps nobody else can usefully look 
into but you might want to check connections from various places 
yourself to see if you do encounter connection problems, e.g., RIPE 
ATLAS traceroute, a few hours of VM time from different continents 
and/or use of 3rd party monitoring services.


/mark

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

Re: [mailop] How to find 'low flying' spamers?

[Mark Milhollan]

On Mon, 1 Oct 2018, Rob McEwen wrote:
>On 10/1/2018 5:23 AM, Benoit Panizzon wrote:

>> * Require SMTP Authentication.

So much is now via stolen credentials (which your other checks try to 
handle) that this does nothing to prevent, of course, but it is indeed 
reasonable and responsible of you to deny relaying except with some kind 
of authorization and accountability/traceablity.  (Primarily noted as a 
lead-in to the following ...)

Have you looked at providing multiple credentials, e.g., OAUTH2 or 
merely additional auth-for-email-only alias credentials within your 
systems?  It doesn't prevent them being stolen but it limits the 
colateral damage that invalidation/limiting/blocking causes.

>> * Keep cache history from which IP an SMTP Authentication occurred.
>> * If count(IP) in delta time > IPlimit block account and require
>>password change.
>> * If count(geoIP) in delta time > Geolimit block account and require
>>password change.

It must be terrible to roam with your phone but leave your PC on at 
home, each checking e-mail.  Multiple credentials can help with this too 
though it does add complexity.

>> * If count(recipients) in delta time > RecipientLimit - tempfail and
>>notify postmaster to check manually.

In addition hopefully you run much of the same SPAM checking on the 
messages they're sending as you use for messages you receive from 
non-customers, instead of bypassing all checking, e.g., skip "PBL" 
checks (which I don't think much of anyway) but perform content scanning 
and check all other BL's you use -- if a customer is on the CBL or a 
droneBL, etc., they should only be able to write to your admin and 
support addresses even if the message appears squeaky clean until the 
matter is cleared-up (thence into an RPZ temporarily to remove them from 
your local view of those lists and/or tweaking of the content rules 
perhaps just for them).

>Start limiting the ability of your end users to set up forwarders for 
>email accounts forwarding to freemail addresses. 

Alas people do that not only because they are sheep, but because they 
like the interface (perhaps sheepishly) or at least more than they like 
what you provide, and for other reasons so about all this will do is 
nudge/force them to go elsewhere, which is great if they're spammers or 
shady.  Good mailbox providers have the ability to pickup mail, which 
includes all the majors, and that should be encouraged instead of 
forwarding but you'll get push-back on that because there's more to 
configure and it doesn't absolve you of being deligent, i.e., a forward 
is usually a single change (odds are it isn't even verified first -- it 
should be), but to enable picking up means configuring an(other) email 
client which most mailbox providers try to make easy but it's still more 
to check even if all the automation / guesses are perfectly correct.

>The problem in general is that they [hotmail/outlook, generally ms]
>often view any spam that slipped past your filter and made it to that 
>mailbox's forwarding - as being a spam that YOUR mail server sent. 

Because your server did indeed send SPAM -- it just wasn't the origin -- 
and it might send more so it should be(gin to be) limited.  Alas your 
notions of SPAM may not agree with theirs, but you must try.  Even if 
the mailbox provider fetches messages it isn't sufficient to skip checks 
as that often earns your server/domain/service black marks just as if it 
tried to forward the same message, indeed it might be good to require 
that less than squeaky clean messsages go into a folder other than the 
(usually one) folder that the mailbox provider fetches or that you'll 
forward -- alas the customer usually doesn't like this.

>it doesn't help that many end users are click-happy on the "this is 
>spam" button when going through their hotmail/outlook mail, often using 
>it in place of the "delete" button! 

Not only that but if the subject is too clear they might delete the 
message "unread" which amounts to calling it junk/SPAM yet if it isn't 
clear enough they might discard it out-of-hand which amounts to the same 
thing.


/mark

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

Re: [mailop] Weird Gmail deliverability issue - mail message not there

[Mark Milhollan]

On Fri, 21 Sep 2018, Vytis Mar?iulionis wrote:

> relay=aspmx.l.google.com[64.233.163.27]:25, delay=1.2,
> delays=0.13/0/0.51/0.6, dsn=2.0.0, status=sent (250 2.0.0 OK 
> 1537051207 z2-v6si12644415ljb.127 - gsmtp)
>
>The only probable idea I come up with is that we have gotten rid of 7
>domains used throughout our infrastructure and since volume increased from
>one particular domain that we are using we could have gotten ourselves
>volume limited.

If you were limited there would normally be a defer response, or if 
blatant SPAM a reject.  An accepted message should appear somewhere, 
perhaps tagged as SPAM but in any case visible.  But the story does 
sound like some change was made at Google.  That "searching" reveals 
what isn't obvious might merely mean the user's settings are to place 
messages from contacts first which happen to be plentiful or perhaps 
tagged as SPAM with that "folder" specifically hidden.  It would be sad 
if it turns out messages were accepted then silently discarded or lost.


/mark

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

Re: [mailop] Orange.fr and Wanadoo.fr Hardbounces

[Mark Milhollan]

On Thu, 5 Jul 2018, David Hofstee wrote:

>- You send to e.g. a 1000 recipients one week. These recipients download
>images and click on links (e.g. 40% open rate and 5% click rate).
>Conclusion: Recipients are real and active.
>- The next week *all* these recipients suddenly bounce 

Unless Orange is performing object and link scanning / safety checks 
making the recipients seem alive (to euromsg at least), but later the 
accounts are disabled or closed for whatever reasons.  (Even exclusive 
of aliveness, just not rejected last time but some rejected now.)  Or 
not all but enough that after some number of unknown recipient rejects 
Orange's MTA shifts to bouncing everything (for a while).


/mark

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

Re: [mailop] question regarding support for international characters

[Mark Milhollan]

And yet Google (and Microsoft and many others) do seem to assume that if 
the headers are badly formatted (in various ways) it needs rejection or 
adds to the score tending towards classification as SPAM.  The body is a 
different mess, indeed, and one where a more relaxed scanner seems to be 
used.


/mark

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

Re: [mailop] question regarding support for international characters

[Mark Milhollan]

But that's the From: comment and Subject: text where they're expected 
and already have a way to provide for encoded UTF-8 (or whatever), where 
SMTPUTF8 means we will likely begin seeing raw UTF-8 in the From: 
mailbox name, and anywhere in Received: and other headers.

This will make MUAs and thus SPAMmers jobs easier by not having to 
encode where allowed and removes an easy rejection / scoring rule, but 
other than US(ish) have had a rotten time of it using their own scripts 
so something needed to be done.  I hesitate to guess how many web site 
e-mail address validators will suddenly be wrong(er) and thus the users 
are likely going to need US-ASCII only mailbox names (aliases?) anyway.


/mark

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

Re: [mailop] Reg. Instant delivery within sec. for OTP based mailer

[Mark Milhollan]

On Sat, 10 Mar 2018, Vaibhav wrote:

>At Gmail we are able to deliver 70% emails less than 2sec where we expect
>all emails to get deliver within 1 OR 2 sec. Does TLS encryption slow down
>the delivery ?

E-mail isn't instant messaging -- don't expect instant delivery.  Yes of 
course TLS slows things down, though not by too much as long as it is 
working.


/mark

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

Re: [mailop] GSuites looking too closely at first-hop Received: headers?

[Mark Milhollan]

On Tue, 27 Feb 2018, Philip Paeps wrote:

>I have no way of knowing if GSuites is actually looking too closely at my
>first-hop Received: headers but that's the only theory I can come up with for
>my emails not arriving on that GSuites list.

Probably.  I postulate that since they hide the sender's connection so 
would everyone else and thus treat the first real* received as having to 
pass SPF rather than just the peer delivering the message.

* Meaning they will skip over received headers that use loopback or 
  RFC1918 addresses.


/mark

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

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

[Mark Milhollan]

On Fri, 24 Nov 2017, Shane Clay wrote:

>I can't figure this one out so looking for some help from people in the 
>know. One of our clients has a postfix mail relay server used for 
>relaying emails from photocopiers/internal software systems out to the 
>world.

>Any ideas?

I don't know, but can't an admin put the fixed IP address(es) in some 
sort of "known relay / good(ish)" list.  Of course if they have dynamic 
addresses that shoots that idea in the other foot.

For other receivers the SPF+DKIM should do the trick but those sorts of 
messages are faked by malware a lot.  Maybe be sure they aren't using a 
generic FROM.


/mark

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

Re: [mailop] Timeouts on "." sending to nic.ru

[Mark Milhollan]

On Tue, 14 Nov 2017, Brandon Long wrote:
>On Tue, Nov 14, 2017 at 10:58 AM Renaud Allard via mailop  
>wrote:

>>Actually, it's way more than that:
>> Initial 220 Message: 5 Minutes
>> MAIL Command: 5 Minutes
>> RCPT Command: 5 Minutes
>> DATA Initiation: 2 Minutes
>> Data Block: 3 Minutes. This is while awaiting the completion of each TCP 
>> SEND call transmitting a chunk of data.
>> DATA Termination: 10 Minutes

>Ugh, those timeouts are insane, from a different era.

They might have been shortened by RFC 5321 (only 10 years ago), but 
weren't -- satellite can be terrible and links into disaster areas can 
be worse, not even counting personal or overloaded servers (as was 
suggested, taking a while to scan content).  General aviation crusing at 
100kts continues even while others fly or ride 5 times faster -- I see 
similar in SMTP/networking/servers; hell a hundred-fold difference 
probably exists between my home and your employer's datacenter yet 
either of us can source or sink SMTP sessions -- I'd not need 10 minutes 
to scan but it is nice that I am (they are) not required to run races 
just because others can/do/must.  That being aside from what we actually 
practice despite the rules (guidelines it sometimes seems).


/mark

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

Re: [mailop] Concurrent Messages and Proper Time to Keep a Connection Open

[Mark Milhollan]

On Mon, 31 Jul 2017, Ryan Harris wrote:

>Naturally we don't want to cause unrest within the ecosphere by keeping
>connections open for too long.

Have you looked at the related RFCs?  (2821 and 1123 primarily but et 
seq)


>>It would seem kind of pointless to keep a connection open for 10 
>>minutes to save 2s of connection time, for example.
>
>
>Agreed, but when you are sending high volumes of email, optimizing the
>opening of a connection and reuse of a connection is worth us investigating.

Everyone varies, be prepared to adapt.


/mark

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

Re: [mailop] New gmail warning about spoofing

[Mark Milhollan]

On Wed, 14 Jun 2017, Stefano Bagnara wrote:

>PS: maybe this list is used to "complaints" and "how to get a contact at a
>given provider", so I don't know if this generic discussion about Google
>approach to user spam/spoofing warnings is an interesting/appropriate topic.

Your thread seems to me to fit the list's mandate.

I don't have a strong opinion as to the alert Gmail provides when a 
message has the From header matching the To header, though it seems to 
me most of the time it would result in an SPF failure (whether soft or 
hard) and so be problematic.  I've done this a few times but always 
between machines that would pass SPF checks.

I've no certain idea as to why Google wouldn't provide an alert when the 
From header names some other Gmail address yet didn't originate from a 
Google server, apart from guessing that they have some bugs or as yet 
unresolved edge cases they're considering.


/mark

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

[mailop] Come on protection.outlook.com, don't send me messages even you think are SPAM

[Mark Milhollan]

We periodically receive SPAM from outbound.protection.outlook.com hosts.  
No worry, they can slip through anyone's filters.  But some have an 
X-Forefront-Antispam-Report header with SFV:SPM which has been said is 
their indicator of a message they consider to be SPAM.  How MS handles 
them is up to them, of course, but delivering them seems inappropriate.  
Or is SFV insufficient indication (e.g., weak indicator rather than 
final judgment)?  An additional tag seems to indicate SPAM as well 
though nothing has been said publicly about it, it merely has "spm" in 
the pair (MLV:spm).


/mark

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

Re: [mailop] Confused by bounce

[Mark Milhollan]

On Tue, 15 Nov 2016, Terry Barnum wrote:

>If we send email to a specific gmail user we receive a bounce from Hotmail 
>saying it can't deliver due to our DMARC policy. Postfix logs show the email 
>being delivered and accepted by gmail. Email to other gmail users goes through 
>fine.

If you get a bounce from Hotmail for a message you delivered to Gmail I 
would bet the Gmail user has forwarding enabled but Gmail didn't do any 
header rewrites.  Maybe they should (always is safer than only when SPF 
and/or DMARC results make it a certainty) or like others they could do 
away with forwarding in favor of having the destination fetch from them.


/mark

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

Re: [mailop] Your subscription is not allowed because the email address you gave is insecure?

[Mark Milhollan]

On Sat, 27 Aug 2016, Jay R. Ashworth wrote:
>- Original Message -
>> From: "Steve Atkins" 
>>> On Aug 27, 2016, at 2:11 PM, John Levine  wrote:

>>> Valdis Kletnieks, an old nerd at Virginia Tech, tells me he just tried
>>> to subscribe to mailop and it said "the email address you gave is
>>> insecure."  Huh?
>>> 
>>> He's at vt.edu, which has the usual MX and SPF records.  They even
>>> have their own CA for their web sites, chained from Globalsign.

Hmm, that phrasing does sound like it might be SPF, DKIM and/or DMARC 
related.

>> What's the email address? /me bets on something non-ascii, or a malformed LHS
>> ("," vs "." for instance) or a + tag or ...
>
>If an email operations mailing list bounces a plus-hack email address as
>malformed

And a plus-sign in the local-part is explicitly valid -- I wish more web 
grunts knew this.

It would be misleading to call a malformed address "insecure", so I 
certainly hope that's not the case.

Alas it's almost certainly the web form making the determination using a 
web-ish notion of secure, for which we'd have to hope the off-the-shelf 
software being used can be reconfigured or fixed.

Or maybe an annoying web server security module that the form can do 
nothing about, that disallows anything ever before used for any kind of 
badness.  If it's this we can hope the list admins can influence the 
module configuration.


/mark

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

Re: [mailop] Microsoft Junk Mail Reporting Program

[Mark Milhollan]

On Wed, 27 Jul 2016, Craig Marchant wrote:

>That's an issue we have also, where customers set up forwarders on the
>cPanel "account / service" and then forward it off to hotmail as an example.

I'd love a way to disable that ability whenever the destination is a 
service known to have the ability to pickup.

>Maybe we need to adopt the policy of removing forwarders as a last resort
>when all else has failed as you have.


Or do so immediately.



/mark

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

Re: [mailop] Microsoft Junk Mail Reporting Program

[Mark Milhollan]

On Wed, 27 Jul 2016, Craig Marchant wrote:

>I've got no issue with people reporting spam - it just seems like that
>"this is spam" button makes it a little too easy for end users to take
>absolutely zero responsibility for legitimate mailing list subscriptions
>and in the process getting other legitimate senders / mail servers in
>trouble because of it. It's a hard line to walk either way I realise.

And worse, the button isn't labelled "this is spam" nor even "report as 
spam", merely "Junk" which doesn't seem quite the same in the mind of 
the general public -- they received a message they don't feel they 
needed or are now done reading.  Still even where it says SPAM!!! people 
seem to use it because often it makes the message go away quickly with 
no confirmation unlike the delete button or from having just used it to 
nuke the 3 previous messages which were (friendly fire, so to speak).


/mark

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

Re: [mailop] Mail accepted by outlook.com/hotmail.com disappears.

[Mark Milhollan]

On Fri, 18 Mar 2016, Michael Wise wrote:

>And yes, under certain circumstances, Hotmail/Outlook will [...] delete 
>[...] with no NDR. The issue will be highlighted in the SNDS report, 
>however.

Any idea what that looks like?  Are those the ones to be found in the 
blocked table on the ipStatus.aspx page, when present?  If you mean it 
is indicated on the data.aspx or dataIP.aspx pages then I don't think 
I've ever seen it or if I have it has not managed to stand out in my 
memory.  Pointers, pictures, etc., appreciated.


>Join the Smart Network Data Services program (SNDS)

>The SNDS program provides data about traffic seen originating from your 
>registered IP, such as mail volume and complaint rates.

The amount of info can be variable, but on the plus side it is very easy 
to handle after you setup automated access.

Usually samples of HELO/EHLO and MAIL FROM are provided, but sometimes 
they are omitted, e.g., 33 report periods across as many days for an IP 
address but only 31 have samples.  Not a terrible ratio, but the lack is 
like running across a pothole, yet they seldom relate to problems, at 
least not that we've found.

Much less often a message sample is provided, e.g., of those same 33 
report periods only 1 sample message link is present though there were 
22 yellow and only 11 green periods and in particular the link is for 
one of the green.  Alas the link provided no content, which is not 
unusual either (older links often don't provide content, newest usually 
do, sure caching ... but another pothole).  Way too often samples for 
red periods aren't provided but there'll be one for a non-red period, 
which isn't useless but isn't generally as useful.


/mark

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