Re: [mailop] Cannot send messages to Google Mail users

[Florian Effenberger via mailop]

Hi,

Marco Moock via mailop wrote on 24.04.24 at 10:41:

That is fine, the host has 2 addresses attached.
Both have a PTR.

I don't see a DNS issue.


I just had a look at one of my friend's MX and can confirm that the PTR 
was correct there as well - but disabling IPv6 interestingly helped to 
avoid the rejection...


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

Re: [mailop] Cannot send messages to Google Mail users

[Florian Effenberger via mailop]

Hello,

Simon Branch via mailop wrote on 24.04.24 at 09:28:
/550 5.7.350 Remote server returned message detected as spam -> 550 
5.7.1 [2a01:111:f403:261b::700 19] Gmail has detected that this 
message;is likely suspicious due to the very low reputation of the 
sending;domain. /


/To best protect our users from spam, the message has been;blocked. For 
more information, go to; https://support.google.com/mail/answer/188131 
 
im8-20020a056214246800b00696b2e6b32asi14453219qvb.337 - gsmtp/


a friend of mine had a similar problem lately. DKIM, SPF, DMARC, PTR 
were all set up correctly, no blocklist entry.


He disabled IPv6 delivery to Google and could send his e-mails with 
IPv4, so "domain reputation" suggest something that might not be 
applicable, as the sending domain per se seemed fine.


I don't know how flexible you are in your configuration with MS365, but 
the error message suggests you connect to GMail via IPv6, so maybe the 
above helps.


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

Re: [mailop] Microsoft heads-up - Outlook Deliverability Support not working

[Florian Effenberger via mailop]

Hello,

Allen Kevorkov via mailop wrote on 12.03.24 at 16:41:
I don't know if it's just us, but I've been getting "we're experiencing 
technical difficulties" response for a number of tickets submitted to 
Outlook.com deliverability support. We're unable to get any issues 
resolved. If someone could /please /help, it would be greatly 
appreciated. This has been going on for a week now (since about 3/6).


I've filed a ticket just last Friday that was acted on over the weekend, 
so it doesn't seem a general issue at least.


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

Re: [mailop] Microsoft/Lindo - junked,not blocked

[Florian Effenberger via mailop]

Hello,

Raman Gupta via mailop wrote on 07.12.22 at 15:40:
Closest I've found is 
https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75  but I'm pretty sure I've submitted a request to that form before to no effect.


the one I've bookmarked is 
https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0=capsub=edfsmsbl3


After some time, you get an SRX ticket number, followed by an automated 
reply. If that says your IP has not been mitigated, reply with some 
details (e.g. I usually explain what the server is about and what my 
contact data is), and a human will look into it, and normally mitigate 
the IP address.


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

Re: [mailop] Microsoft/Lindo - junked,not blocked

[Florian Effenberger via mailop]

Hi,

Raman Gupta via mailop wrote on 07.12.22 at 14:45:

SNDS reports exactly the same for my mail server's outbound IP address 
74.207.245.70/32 , however weirdly every test 
I've done to actual Office365 addresses works fine. It bothers me that 
SNDS still reports this information though and I'd love to find out a 
way to get SNDS to report the correct status.


SNDS seems for Outlook/Live/Hotmail, not for Office 365 destinations.

I had the same effect on one of my IPs recently, but by filling in the 
Outlook unblocking form, had the status reset within 2-3 days.


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

Re: [mailop] [Marketing Email] t-online.de

[Florian Effenberger via mailop]

Hi,

John Devine via mailop wrote on 27.11.22 at 12:27:

Well….they whitelisted me this morning with no website imprint etc, just an 
explanation from me as to how long I had run an MTA etc…….


thanks for sharing - so seems they do some "sanity checks", probably 
also depending on the IP range, not sure. In general, their 
responsiveness is really good, usually goes quite fast, even during 
weekends.


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

Re: [mailop] t-online.de

[Florian Effenberger via mailop]

Hello,

seems I forgot to reply to the list, so let me re-send my answer here. :)

I was just this week able to unblock two IPs. Requirement was the same 
as before, a website with an imprint. No proof of commercial use required.


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Florian Effenberger via mailop]

Hi,

Kai 'wusel' Siering via mailop wrote on 21.10.22 at 18:28:

To stay ontopic here, the question is: _why_ were you getting "blocks 
left and right"? And what were they?


Was it a "fresh & clean" IPv4 address or one that had been abused in the 
past? What did the RBL checking tools tell you about that IP?


as I am just a small operator, my chance of getting a fresh and clean 
IPv4 address is rather low. Of course, I checked against known 
blocklists, asked for removal there, and that worked quite well. 
However, some operators are a bit more complicated, sometimes it's also 
hard to discover that you are blocked - e.g. with Telekom there is no 
RBL to query, you need to do this manually, but I made a similar 
experience with other operators.


Did the IP belong to an ISP that people that have to deal with remote 
abuse do wrinkle their nose at?


That's something hard for me to judge - I am quite happy with my 
provider, I don't know how the interaction with them is for others. But 
then, several providers have mixed reviews, from excellent to really 
bad, so probably that choice isn't so easy either.


And, most importantly: did you have to contact any postmaster to get 
that IPv4 address, with matching PTR and A records, proper SPF and DKIM 
entries, whitelisted to access their MXes at all?


Sometimes I did have to get even further to get unblocked, yes. And I 
know I'm not the only one with that problem when it comes to certain 
operators.


Postmasters are people, too. They as well don't want such a shit show. 
_They_ didn't do anything wrong to deserve that treatment.


I agree with that, but I'm still not convinced a default block will 
change anything on that. Having different points of view is fine, in the 
end it's not me deciding upstream changes anyways. ;-)


There is one known public mail service that blocks universally, not just 
arbitrarily. Given that, default MTA configuration should be "don't talk 
to them as the won't let you talk back". Saves peoples time and nerves, 
therefore a very pragmatic, and very practical solution.


If your customers *request* to talk to t-online.de users, you still can 
negotiate with tosa@rx and then reflect that in your MTA configuration.


If you are a mail operator here in Germany, the likelihood of someone 
writing to a t-online.de account is rather high. So it's just a matter 
of time, and then when it's an important message, this might add even 
further delay. Again, I'm not defending any policy here, I just try to 
be pragmatic for my users.


Well, mostly no-one using a @t-online.de mailbox knows about their 
provider's block-by-default policy. And no customer ever notices, as 


I guess they would just not care. They "want it to work". The politics 
behind that doesn't matter to them, they rather go for a different mail 
operator, I guess. And I fear such blocks will just draw people even 
further into the hands of the big operators, where there are "no problems".


I doubt that it would take GMX more that one single mail to tosa@rx if 
they change IPs in their sending pool. Question is if they even would 
notify t-online.de upfront anyway. Would Google, Microsoft? "T what?"
I actually expect that t-online.de proactively monitors known webpages 
or DNS records of the big players — what they do not want, are major 
tabloids doing headlines like "T-Online messes up it's mail service".


I guess that indeed amongst the big operators there are quite some 
specifics, that are much more of a challenge to the small operator.


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

Re: [mailop] Update: it's not. Re: T-Online is now really blocking messages from non-commercial and simliar senders

[Florian Effenberger via mailop]

Hello,

Bernardo Reino via mailop wrote on 21.10.22 at 16:32:

Well Germans are not what they used to be , so maybe that one 
considered your insistence enough to whitelist you.. or perhaps the 
decision of when a server is commercial or not is not /that/ 
well-defined for them.


maybe the term "commercial" here stems from the German imprint 
requirements. Websites that are not purely private (and that definition 
is very narrow, more narrow than the term might suggest) need an 
imprint. If they consider "commercial" the opposite of "private", that 
could explain it.


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Florian Effenberger via mailop]

Hi,

Grant Taylor via mailop wrote on 21.10.22 at 07:09:

I believe there have been multiple others beside myself that think that 
T-Online should NOT be shunned in MTA /default/ configurations.


I am neither a package maintainer nor a mail server developer, so my 
voice likely is just a very small one - but last year I've been gone 
through a lot of the pain with setting up a new mail server on a new IP 
address and getting blocks left and right - I learned things the hard 
way, and yes, I was quite upset. I do this as a volunteer project, it 
cost me lots of time, pain and headache, and was a frustrating experience.


Let me agree that blocking a provider by default does not seem wise.

Your end-users don't care, for them it just "does not work". They are 
not interested in "politics", and if their e-mail doesn't work, they 
just go with a different service. People are lazy and people want 
practical solutions.


Second, where to start and where to end? There seem to be quite a few 
mail operators who block, let's say, a bit arbitrary. Blocking all of 
them makes things worse, and then the fear of e-mail getting into the 
hand of a few single big players becomes a self-fulfilling prophecy. 
Nobody wants to be on a mail server that can only connect to very few 
selected sites, whatever the reason, and how good the motivations might be.


Third, I guess the deployment cycles are rather long - so what you add 
to a package right now will very likely not end up on a majority of 
machines for months, years, whatever. And who knows if distributions 
will incorporate anything of that, so it seems a lot of work with very 
little predictable result.


Some perceive the behaviour as aggressive maybe, but reacting the same 
way rarely yields to good results - well, at least I try to be an 
optimist in life. ;-)


I don't have much insight into all those working groups and how the mail 
operators talk to each other, I am just a small operator for a rather 
specific use case here, so I can only assume the amount of pain and 
frustration bigger operators must go through.


However, in general, I think the first step to actually help people is 
to document things. Learning all these things can become quite tedious 
and exhausting, with multiple sources - explaining best practice can 
help many people a lot. Of course, not everyone is skilled to run a mail 
server, but then we all started small I guess, so helping those who get 
onto such role with proper and good documentation to avoid the most 
obvious pitfalls is a first step. If there is documentation available, 
at least the problems don't come as a surprise, whether one likes the 
policy or not.


Long-term, I do get quite worried about all the growing obstacles and 
enforced rules by mail operators that make it harder to deliver your 
mail and make self-hosting more and more problematic. That is 
frustrating nad makes me sad. However, and that is purely my personal 
experience, Telekom is amongst the nicest and easiest one to deal with...


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Florian Effenberger via mailop]

Hello,

Grant Taylor via mailop wrote on 20.10.22 at 16:06:
Please forgive ~> humor my ignorance, but what does the imprint / 
impressum (?) /need/ to have in it?


not sure what Telekom actually asks for - but (as you can imagine, it's 
Germany :) things are quite regulated in the law. Depending on the kind 
of business, you have to provide various information, that could include 
VAT number, your chamber or supervisory authority etc.


There are actually websites offering "imprint generators" so you don't 
miss anything. It _is_ quite obscure and an everlasting legal discussion.


What I would assume, without knowing, is that Telekom would be happy 
with a name, street address (PO boxes are likely not accepted), phone 
number and e-mail address.


Not defending any policies or laws here, just trying to shed some light.

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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Florian Effenberger via mailop]

Hello,

Kai 'wusel' Siering via mailop wrote on 20.10.22 at 15:51:


As a German, you have to have an imprint on anything that is considered a
"service", yes, even on your personal, non-monetized blog. It the law ;) 
And

also off-topic here.


I agree, this part of the discussion will likely lead to no conclusion. 
The regulations here in Germany are a bit weird, but it's something we 
can hardly ignore. Experience tells me that other jurisdictions have 
other "strange" regulations too.


Obviously the intersection with the imprint mandate on one hand, and the 
GDPR rules (and how public data can be misused) on the other hand is an 
interesting one, but that's more of a legal, less of a technical problem.


I totally understand for non-Germans this imprint stuff is just super 
irritating, for us it's sadly somehow "normal", which doesn't mean we 
don't find it stupid... :-)



Well, it's a kind of non-written contractual agreement: you want your
mailserver to be able to sent to t-online.de, they want to know who you 
are.

You're free not to agree to the terms, so where's law involved anyway?


In the end, the acceptance or non-acceptance of mail operators is 
something many of the small providers suffer from, as outlined just 
recently here on the list. However...



And, to point this out again: the subject of this thread already has been
disproven — t-online.de/Deutsche Telekom/t...@rx.t-online.de is still 
white-

listing personal mailservers, as long as the criteria on their postmaster
page are met.


...that is my understanding. And from all interactions I had with mail 
operators, Telekom was amongst the fastest and most uncomplicated ones, 
so at least the practical handling was quite relaxed.


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Florian Effenberger via mailop]

Hello,

Bernardo Reino via mailop wrote on 20.10.22 at 09:01:


I wasn't aware of the timing aspect, so thank you for this!


that's at least what I understood back in the days. :-) Whether there's 
a more fine-grained approach, differentiation by ISP reputation and 
other factors, I don't know. I have my machines at Hetzner, too, and I 
think I had to unblock all new IPs in the same way. The IP I used before 
was working without explicit unblocking, but I had it in use for some 
years already.


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Florian Effenberger via mailop]

Hello,

I actually ran into a similar problem last year after a mail server 
migration. Here's what I documented back then in my blog:


"Deutsche Telekom, respectively T-Online, by default blocks IP addresses 
that haven’t been used for sending e-mails to their servers for a 
certain amount of time. You can test if you are blocked by connecting to 
their mail server on port 25 – if the blocking is active, the connection 
will get immediately dropped with an 5xx error message, that lists a 
contact address to request unblocking from. To test, run the following 
command from your mail server:


telnet [-b floating IPv4] mx00.t-online.de 25

When I ran into the problem, they were quite fast in reacting and 
removed the blocking in about an hour. However, as per their use policy, 
they require the mail server’s main domain to have a proper imprint. In 
other words, if your mail server’s hostname is mail.mydomain.tld, you 
must place a proper imprint at mydomain.tld."


I just checked on a machine I operate, and they still can deliver to the 
Telekom MX'es. So right now I would guess that only the error message 
has changed, without a change in the policy.


The imprint thing is probably something very specific German, nearly 
everyone needs an imprint here.


I don't comment on whether all this is sensible or not, but I hope the 
above helps a bit those of you who run into problems.


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

Re: [mailop] Moving email server to new IP

[Florian Effenberger via mailop]

Hi,

Nate Burke via mailop wrote on 07.07.22 at 19:41:
I've had a small multi-domain business mail server running on the same 
IP for the last 20 years, I need to change the IP from an address in a 
reassigned IP block, to my own ARIN block.  Is IP reputation still a big 
deal, or are anti-spam measures now content/quantity based and the IP 
address isn't as important anymore.  Can I just flip the IP and update 
my DNS/SPFs and be good.


I went through something similar about a year ago and blogged about my 
experiences and shared my "cheatsheet". Not sure if a link to own 
publications (CC-BY-SA) are fine on this list - I'm mostly a passive 
reader here. ;-) But I'll follow-up directly with you.


In general, checking several blocklists and some manual checks did the 
trick for me. Note, however, that my experience is based indeed on low 
mail volume.


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

Re: [mailop] Microsoft banned sender (Linode hosted IPs)

[Florian Effenberger via mailop]

Hello,

Andy Smith via mailop wrote on 01.03.22 at 21:12:

So again, if anyone is able to push that along I'd be most grateful.
Also if it's totally pointless for the intended recipient to do
anything I'd appreciate knowing so I can stop pushing them about it.


I made indeed good experiences with an Office 365 tenant filing a 
ticket, asking for the IP to be delisted. Whether that works always I 
can't say, but from my POV it's worth a try.


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

Re: [mailop] Manitu blocking Microsoft relay servers

[Florian Effenberger via mailop]

Hi,

Raymond Dijkxhoorn wrote on 26.11.21 at 10:57:

I saw that. I resolved it locally and posted just here to give both 
Microsoft and Manitu/NixSpam a heads up.


The list might not be used insain widely, i dont know, but decided to 
post so they can resolve it. I am not going to request seperate ip's its 
a big very big list that i have seen so likely its a large range thats 
impacted here.


But thanks for the pointer, appreciated!


you're welcome! Let me know if you're successful. :-)

If you don't get a reply by next week (usually they are very fast in 
answering), I can try to forward your mail to someone there I know, who 
might be able to put you in touch with the right person.


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

Re: [mailop] Manitu blocking Microsoft relay servers

[Florian Effenberger via mailop]

Hello,

Raymond Dijkxhoorn via mailop wrote on 26.11.21 at 09:53:


(Also sended to them directly but hopeing someone can ping them)

rejected because 40.107.8.138 is listed at ix.dnsbl.manitu.net


never tried myself, but on https://www.nixspam.net there's a form to ask 
for unblocking. Not sure however if confirmation from postmaster@ is 
required.


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

Re: [mailop] Low Volume Senders

[Florian Effenberger via mailop]

Hi,

Brielle via mailop wrote on 20.09.21 at 16:33:


You could increase that volume by sending DMARC aggregate reports.


Is there any (preferably free / open source) tools to make generating 
these aggregate reports easy enough?


seems rspamd supports this: https://rspamd.com/doc/modules/dmarc.html 
(see "Reporting" section). Didn't try it myself though, I don't send 
reports yet.


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

Re: [mailop] Cyren status regularly flapping back to Suspicious

[Florian Effenberger via mailop]

Hello,

Alessandro Vesely via mailop wrote on 07.07.21 at 13:27:

So it's IPv4.  Talos[*] reports low email activity on it.  Do you send 
out DMARC reports and similar stuff?  I found that doing so increases my 
footprint and hence stabilizes reputation, albeit some point out that 
reports can be classified as spam...


indeed, the activity on the various IPs of mine is not that high. It's a 
bit higher on some, but in any case I'm not one of the big players with 
a large mail volume. :-)


I don't send out DMARC reports (yet), but the quality of the traffic 
should be good, i.e. the bounce ratio rather low. All are individual 
mailboxes from the educational sector, no newsletters or the like.


Luckily, thanks to this list, a kind person from Cyren poked me directly 
(thanks so much!) and in parallel, the recipient was excluding these IPs 
from their Cyren checking, so my current case at hand seems solved for 
the moment.


I'm trying to understand if the Cyren behaviour is expected and the 
recipient is just wrongly blocking the yellow IPs, or if actually the 
flapping back is due to "spammy neighbours" and can be mitigated. I'll 
report back if I have more insight.


That being said - thanks indeed, I appreciate how helpful and 
cooperative this list has been to me so far, although I'm fairly new here!


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

Re: [mailop] Cyren status regularly flapping back to Suspicious

[Florian Effenberger via mailop]

Hello,

thanks for the replies!

John Levine via mailop wrote on 05.07.21 at 18:59:


I believe the recipient's mail system is misconfigured.  If Cyren tags an IP
as yellow, they should soft fail with 450 so it can retry later.


That could be indeed helpful. I was reaching out to their postmaster 
already (recipient is a larger German city) to see if they can do 
something - a greylisting would be "fine", but the hard reject is an issue.


Alessandro Vesely via mailop wrote on 06.07.21 at 18:38:


I tried https://www.cyren.com/security-center/cyren-ip-reputation-check-gate and it says "No 
Risk" for 188.34.176.133 and "Please enter a valid IP" for 2a01:4f8:c010:587c::1.  
Is it the latter the one that gives you problems?


The IPv4 is one of the several IPs affected, indeed. I unblocked it 
again last week, but it likely will switch back after a while. Not sure 
if CYREN supports IPv6 - but the recipient's MX doesn't in any case, so 
it's not a workaround to deliver the mails either.


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

[mailop] Cyren status regularly flapping back to Suspicious

[Florian Effenberger via mailop]

Hello,

I have some issues with the Cyren blocklist - one recipient's server is 
bouncing mails back with


550-5.7.1 This email was rejected because it violates our security policy
550 5.7.1 CYREN IP reputation determined a medium risk associated with
the sender address X.X.X.X. (in reply to DATA command)

Their website lists the IP as yellow ("Suspicious"), with an explanation 
of "The IP has only recently started sending mails, and therefore still 
has an Unknown reputation".


Unblocking on their website works like a charm and is effective within 
minutes. The status turns green ("No Risk"), with an explanation of 
"This IP address has not been used for sending Spam".


Some time ago, usually 2-3 weeks later, the status however flaps back to 
"Unknown", effectively blocking mails again. I then unblock again, just 
to get blocked again 2-3 weeks later.


I'd say the mail server is configured properly - PTR, A, , SPF, 
DKIM, DMARC all in place. Active DNSWL (!) listing, and no other 
listings anywhere. postmaster@ and abuse@ are reachable.


I have this effect on a few machines (mine and also colleagues under a 
different domain, but same hoster), including some without any outgoing 
mails, and one box where I'm the only user currently. Given the IP is 
from a big provider's netblock, I tend to assume that actually too few 
mail samples are with Cyren, and they therefore block again. Chicken and 
egg problem in the end, if I can't send mails, they can't get good 
samples...


Anyone has experiences with this, any way to contact them?

Thanks a lot,
Florian
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail's MTA is broken

[Florian Effenberger via mailop]

Hello,

Thomas Walter via mailop wrote on 07.06.21 at 21:08:


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.

It's been a while since I tracked systems like that, but it happened.


t-online.de mail servers do that when they block IPs. Actually helpful, 
because it allows getting things sorted out before the mail gets bounced 
back as undeliverable.


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

Re: [mailop] [EXTERNAL] Re: protection.outlook.com refusing to accept mail with misleading temp error message

[Florian Effenberger via mailop]

Hi,

Jay Hennigan via mailop wrote on 02.06.21 at 23:39:

Allowing such queries would be giving quite a bit of information to 
potential bad guys.


honestly don't know what is better. The majority of DNBLs can be queried 
publicly, and I could imagine for those who really aim hard, simply 
spamming some known accounts on the destination MX helps to find out if 
they're blocked or not. But on that I don't have enough insight to make 
an educated guess.


Michael Wise via mailop wrote on 03.06.21 at 01:16:


But I was primarily suggesting a test against the infra to see if the mail was 
bounced or accepted.
If accepted, it WOULD be delivered either to the INBOX or Junk.
And if bounced, that should also highlight why.


With a proper test account it's quick to find out if you're blocked or 
not, indeed.


The issue in my case was the radio silence after the initial ticket. I 
would assume the previous IP owner really did bad, or some spammy 
neighbours massively rate down the netblock, so probably people were not 
eager to follow-up - but not the nicest experience. But, not your fault 
personally. ;-) And it's finally fixed in the meantime.


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

Re: [mailop] [EXTERNAL] Re: protection.outlook.com refusing to accept mail with misleading temp error message

[Florian Effenberger via mailop]

Hi Michael,

Am 2021-06-02 21:09, schrieb Michael Wise via mailop:

Sending from that IP is ... how one usually tests that it's working.


what IMHO would be much better to check newly assigned IPs is, if 
there's a way to query via DNS, or a web form. That way the issue can be 
solved and clarified in advance, and not only when problems occur. Not 
everyone has an account at hand to test it upfront.


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

Re: [mailop] protection.outlook.com refusing to accept mail with misleading temp error message

[Florian Effenberger via mailop]

Hello,

I'm rather new to this list, so I hope it's okay to jump in directly in 
this discussion and share some thoughts. :-)


I just recently faced a very similar problem with one of the new IPs I 
got assigned. Likely, the IP was in use by someone else previously or 
there are spammy neighbours (not surprising when it's a big provider 
with some customer turnaround). I got all deblocking done in the various 
blocklists, the status was clean everywhere, including SNDS, but still, 
Microsoft 365 mailboxes (*.protection.outlook.com) blocked it.


It seems there are various independent blocklists - one set is covering 
consumer Outlook/Live/Hotmail, the other set is covering Microsoft 365. 
SNDS seems to only query the former one, and the Outlook.com web form 
only unblocks on these domains, so neither of that helps for Microsoft 
365 mailboxes.


For Microsoft 365, there seem to be various levels of blocking. 
Sometimes, you can unblock yourself at sender.office.com, but I hit the 
infamous "Write to delist@" message. I managed to create a ticket there, 
they asked for some details, but then radio silence, all follow-up mails 
ignored, for over a month now. Various ways of contacting them went 
without any outcome, and I sense that on their end there is also some 
confusion as to the existing blocklists - I got repeatedly told the IP 
is not listed (which is what sender.office.com told me too), or to use 
the Outlook.com form, that obviously didn't help for my problem at hand.


In the end, via way one of the communication channels I tried, I somehow 
managed to get a supporter who was really engaged and managed to helped 
me out, but I must admit that the whole process was not straightforward 
and took me a month in the end. At least when people provide full 
contact data/imprint and proof that the IP was freshly assigned, some 
feedback would be good to not be left in the dark.


Problematic is also that there is no actual way to test if your new IP 
is blocked before using it, apart from sending to an actual e-mail 
address hosted there.


Hope to help,
Florian
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop