Re: [mailop] Trouble sending/receiving @dm.duke.edu

2024-09-19 Thread Seth Mattinen via mailop

On 9/19/24 11:29, Seth Mattinen via mailop wrote:



dm.duke.edu. 21600 IN NS nameserver1.mc.duke.edu.
dm.duke.edu. 21600 IN NS nameserver2.mc.duke.edu.
;; Received 135 bytes from 152.3.105.232#53(dns-auth-02.oit.duke.edu) in 
76 ms


nameserver1.mc.duke.edu has address 152.16.1.4
nameserver1.mc.duke.edu has IPv6 address 2620:0:691:dc50::4

nameserver2.mc.duke.edu has address 152.16.1.12
nameserver2.mc.duke.edu has IPv6 address 2620:0:691:dc57::12




The broken IPv6 addresses have been silently removed.

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


Re: [mailop] Trouble sending/receiving @dm.duke.edu

2024-09-19 Thread Seth Mattinen via mailop

On 9/19/24 11:47, Viktor Dukhovni via mailop wrote:

On Thu, Sep 19, 2024 at 11:29:23AM -0700, Seth Mattinen via mailop wrote:


Looking for someone who handles mail in duke.edu for a sub-delegation. I am
having problems with mail delays on @dm.duke.edu due to DNS lookup failures
causing domain does not exist errors.


The are of course (soft-fail) deferred, because the DNS lookup failures
are not definitive, SERVFAIL is not NXDOMAIN.


2024-09-18T10:22:33.457792-07:00 mail postfix/smtpd[4184837]: NOQUEUE:
reject: RCPT from unknown[2600:1806:511:210:1eaf::11]: 450 4.1.8
: Sender address rejected: Domain not
found; from= to=
proto=ESMTP helo=



Looking at DNS shows me the following (and DNSViz):

dm.duke.edu. 21600 IN NS nameserver1.mc.duke.edu.
dm.duke.edu. 21600 IN NS nameserver2.mc.duke.edu.
;; Received 135 bytes from 152.3.105.232#53(dns-auth-02.oit.duke.edu) in 76
ms

nameserver1.mc.duke.edu has address 152.16.1.4
nameserver1.mc.duke.edu has IPv6 address 2620:0:691:dc50::4

nameserver2.mc.duke.edu has address 152.16.1.12
nameserver2.mc.duke.edu has IPv6 address 2620:0:691:dc57::12


But do you really only have IPv6 connectivity?  Sadly, you really should
have at least one IPv4-capable MX host whose iterative nameservers can
reach the IPv4 Internet.  Many mail systems are still only V4-capable,
or their DNS is only available via IPv4 (no IPv6 NS IPs to even attempt
to query).



I have been dual stacked since December 2008 so I have a decent amount 
of experience, but it's a problem in this situation for reasons that at 
the moment I can't find.


I use PowerDNS Recursor with DNSSEC validation enabled with dnsdist in 
front of the Recursor pools.


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


Re: [mailop] Trouble sending/receiving @dm.duke.edu

2024-09-19 Thread Seth Mattinen via mailop

On 9/19/24 11:53, Marco Moock wrote:

Am 19.09.2024 um 11:29:23 Uhr schrieb Seth Mattinen via mailop:


Looking for someone who handles mail in duke.edu for a
sub-delegation. I am having problems with mail delays on @dm.duke.edu
due to DNS lookup failures causing domain does not exist errors.


Do they reply on hostmas...@dhe.duke.edu.?




No, that doesn't appear to exist in DNS.

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


[mailop] Trouble sending/receiving @dm.duke.edu

2024-09-19 Thread Seth Mattinen via mailop
Looking for someone who handles mail in duke.edu for a sub-delegation. I 
am having problems with mail delays on @dm.duke.edu due to DNS lookup 
failures causing domain does not exist errors.



2024-09-18T10:22:33.457792-07:00 mail postfix/smtpd[4184837]: NOQUEUE: 
reject: RCPT from unknown[2600:1806:511:210:1eaf::11]: 450 4.1.8 
: Sender address rejected: Domain not 
found; from= to= 
proto=ESMTP helo=
2024-09-18T10:22:34.095199-07:00 mail2 postfix/smtpd[2623717]: NOQUEUE: 
reject: RCPT from unknown[2600:1806:511:210:1eaf::11]: 450 4.1.8 
: Sender address rejected: Domain not 
found; from= to= 
proto=ESMTP helo=
2024-09-18T10:22:35.175737-07:00 mail2 postfix/smtpd[2623717]: NOQUEUE: 
reject: RCPT from unknown[2600:1806:511:210:1eaf::11]: 450 4.1.8 
: Sender address rejected: Domain not 
found; from= to= 
proto=ESMTP helo=



Looking at DNS shows me the following (and DNSViz):


dm.duke.edu. 21600 IN NS nameserver1.mc.duke.edu.
dm.duke.edu. 21600 IN NS nameserver2.mc.duke.edu.
;; Received 135 bytes from 152.3.105.232#53(dns-auth-02.oit.duke.edu) in 
76 ms


nameserver1.mc.duke.edu has address 152.16.1.4
nameserver1.mc.duke.edu has IPv6 address 2620:0:691:dc50::4

nameserver2.mc.duke.edu has address 152.16.1.12
nameserver2.mc.duke.edu has IPv6 address 2620:0:691:dc57::12


Works on IPv4:

; <<>> DiG 9.10.3-P4-Debian <<>> MX dm.duke.edu @152.16.1.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4622
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 12 ("..")
;; QUESTION SECTION:
;dm.duke.edu. IN MX

;; ANSWER SECTION:
dm.duke.edu. 3600 IN MX 10 mx.oit.duke.edu.

;; AUTHORITY SECTION:
dm.duke.edu. 86400 IN NS nameserver1.mc.duke.edu.
dm.duke.edu. 86400 IN NS nameserver2.mc.duke.edu.

;; Query time: 77 msec
;; SERVER: 152.16.1.4#53(152.16.1.4)
;; WHEN: Thu Sep 19 06:37:13 PDT 2024
;; MSG SIZE rcvd: 140


; <<>> DiG 9.10.3-P4-Debian <<>> MX dm.duke.edu @152.16.1.12
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7136
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 12 ("..")
;; QUESTION SECTION:
;dm.duke.edu.INMX

;; ANSWER SECTION:
dm.duke.edu.3600INMX10 mx.oit.duke.edu.

;; AUTHORITY SECTION:
dm.duke.edu.86400INNSnameserver2.mc.duke.edu.
dm.duke.edu.86400INNSnameserver1.mc.duke.edu.

;; Query time: 76 msec
;; SERVER: 152.16.1.12#53(152.16.1.12)
;; WHEN: Thu Sep 19 09:57:48 PDT 2024
;; MSG SIZE  rcvd: 140


Fails on IPv6:

; <<>> DiG 9.10.3-P4-Debian <<>> MX dm.duke.edu @2620:0:691:dc50::4
;; global options: +cmd
;; connection timed out; no servers could be reached

; <<>> DiG 9.10.3-P4-Debian <<>> MX dm.duke.edu @2620:0:691:dc57::12
;; global options: +cmd
;; connection timed out; no servers could be reached



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


[mailop] AT&T blocking 208.79.240.5 and 208.79.240.7

2024-08-01 Thread Seth Mattinen via mailop
AT&T is blocking our outbound server at 208.79.240.5 and alternate 
208.79.240.7.


Remote-MTA: dns; ff-ip4-mx-vip2.prodigy.net
Diagnostic-Code: smtp; 553 5.3.0 flpd576 DNSBL:RBL 521< 208.79.240.7
>_is_blocked.For assistance forward this error to 
abuse_...@abuse-att.net


I already emailed abuse_...@abuse-att.net but I don't want to wait a 
week to see if I actually get a response or not since a bunch of recent 
threads say they never get a response. Also I'm emailing from behind 
that same IP and don't know if they are blocking my request for help.


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


Re: [mailop] DKIM signing with ed25519 keys - leap of faith

2021-10-14 Thread Seth Mattinen via mailop

On 10/12/21 2:02 AM, Sidsel Jensen via mailop wrote:
*My question to you: What are your thoughts on starting to sign with 
ed25519 keys and what is currently holdning you back?*



As soon as Mail::DKIM supports it I'll probably do it (dual sign).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] [EXTERNAL] Blocked from hotmail/live/outlook but ticket response says not blocked

2021-01-06 Thread Seth Mattinen via mailop

On 1/6/21 16:38, Michael Wise via mailop wrote:


Can you please share at the very least, the IP in question and the full error 
message?



Well, now I just got an email that says "Not qualified for mitigation
208.79.240.5
Our investigation has determined that the above IP(s) do not qualify for 
mitigation."


And then a bunch of crap about joining JMRP and SNDS, of which I have 
been registered on for at least a decade. JMRP sent me a grand total of 
5 reports on this issue: only 2 on the 28th, the rest after I'd already 
shut the customer off. First goddam time I've ever been blocked and "not 
qualified for mitigation".


I've suggested that my customers start opening tickets and telling their 
recipients to also open tickets from the customer side. Maybe if the 
recipients complain they can't get mail someone will listen more than 
being pigeonholed as "not qualified".

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


Re: [mailop] [EXTERNAL] Blocked from hotmail/live/outlook but ticket response says not blocked

2021-01-06 Thread Seth Mattinen via mailop

On 1/6/21 16:38, Michael Wise via mailop wrote:

Can you please share at the very least, the IP in question and the full error 
message?



2021-01-06T16:34:09.179927-08:00 smtpauth postfix/smtp[17311]: 
202C32800046: to=, 
relay=hotmail-com.olc.protection.outlook.com[104.47.10.33]:25, delay=2, 
delays=1.5/0/0.4/0.14, dsn=5.7.1, status=bounced (host 
hotmail-com.olc.protection.outlook.com[104.47.10.33] said: 550 5.7.1 
Unfortunately, messages from [208.79.240.5] weren't sent. Please contact 
your Internet service provider since part of their network is on our 
block list (S3150). You can also refer your provider to 
http://mail.live.com/mail/troubleshooting.aspx#errors. 
[DB5EUR03FT040.eop-EUR03.prod.protection.outlook.com] (in reply to MAIL 
FROM command))


2021-01-06T16:30:16.291292-08:00 smtpauth postfix/smtp[17322]: 
799A22800049: to=, 
relay=outlook-com.olc.protection.outlook.com[104.47.59.161]:25, 
delay=0.79, delays=0.21/0/0.52/0.06, dsn=5.7.1, status=bounced (host 
outlook-com.olc.protection.outlook.com[104.47.59.161] said: 550 5.7.1 
Unfortunately, messages from [208.79.240.5] weren't sent. Please contact 
your Internet service provider since part of their network is on our 
block list (S3150). You can also refer your provider to 
http://mail.live.com/mail/troubleshooting.aspx#errors. 
[DM6NAM12FT003.eop-nam12.prod.protection.outlook.com] (in reply to MAIL 
FROM command))


2021-01-06T14:16:26.329892-08:00 smtpauth postfix/smtp[12993]: 
8FD75280085E: to=, 
relay=live-com.olc.protection.outlook.com[104.47.18.161]:25, delay=2.7, 
delays=2.1/0/0.45/0.15, dsn=5.7.1, status=bounced (host 
live-com.olc.protection.outlook.com[104.47.18.161] said: 550 5.7.1 
Unfortunately, messages from [208.79.240.5] weren't sent. Please contact 
your Internet service provider since part of their network is on our 
block list (S3150). You can also refer your provider to 
http://mail.live.com/mail/troubleshooting.aspx#errors. 
[AM7EUR06FT042.eop-eur06.prod.protection.outlook.com] (in reply to MAIL 
FROM command))

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


[mailop] Blocked from hotmail/live/outlook but ticket response says not blocked

2021-01-06 Thread Seth Mattinen via mailop
Being blocked (apparently delayed after a customer compromise back on 
the 28th) from Microsoft properties. Submitted ticket, got response 
saying IP is not blocked. Checked logs, nope still seeing 550's. SNDS 
says "All of the specified IPs have normal status." Submitted ticket again.


Now what? Why am I being told not blocked when I'm clearly getting an 
SMTP 550 response when sending to hotmail/live/outlook?


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


Re: [mailop] [E] Re: IP based reporting for Yahoo feedback loop gone?

2020-12-31 Thread Seth Mattinen via mailop

On 12/28/20 1:22 PM, Marcel Becker via mailop wrote:


Your example is in fact addressing part of the “sense” question: Why 
should you be getting all abuse reports for an IP when it’s shared and 
all you really should be getting is the stuff for your own domain you 
are responsible for.





I don't think so. I'm primarily a datacenter operator and 
commercial-only ISP and my AUP says no spamming. As the proactive type 
that prefers to prevent spamming instead of ignoring it for profit, I do 
like to know if anyone is emitting spam from any of our IP space. 
Feedback loops based on our IP ranges help with that goal, and provide 
effective evidence of AUP violations.


I can't do that with DKIM. Feedback loops are also faster than waiting 
for someone to email abuse@ after looking in whois, if anyone bothers to 
go that far. If my abuse@ is already in whois, then why should I not be 
allowed to request automated reporting of the same?



BTW: Some ESPs solve the “not practical” problem by double signing their mail with their own DKIM domain. 


I can't double sign emails that are coming from IP space reassigned to 
customers. (And before someone says filter port 25 this is not 
residential or dynamic IP.)


But I also understand that other mail operators don't want to maintain a 
system that can work with IP-based reporting. My only point is that it's 
helpful to those of us that want to help prevent spam.

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


Re: [mailop] IP based reporting for Yahoo feedback loop gone?

2020-12-28 Thread Seth Mattinen via mailop

On 12/28/20 9:28 AM, Marco Guillen Barrionuevo wrote:

There you go
Yahoo! Help - Submit a Form 





It asks for DKIM stuff; I need IP based.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


[mailop] IP based reporting for Yahoo feedback loop gone?

2020-12-28 Thread Seth Mattinen via mailop

What happened to the Yahoo feedback loop?

I had a customer with a compromised account today and I notice that we 
didn't get any feedback loop emails from Yahoo like we used to in times 
past from .


After looking for the login page it looks like it's gone 
(http://feedbackloop.yahoo.net/request.php).


I can google all kinds of things but every search result I click on just 
gives me an "You have been redirected to this page because the page you 
requested was not found" error on help.yahoo.com.


Can anyone point me in the right direction to re-sign up for IP based 
feedback loop reporting for Yahoo mail?

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


Re: [mailop] btinternet.com blacklist

2017-07-11 Thread Seth Mattinen

On 7/11/17 02:19, Philip Paeps wrote:


Unfortunately, spammers have made the internet worse for everyone.  In 
the world of email today, "we are not spammers" is not a good enough 
argument to get your email accepted by anyone.



"We're not spammers" is up there with "double confirmed opt-in" or 
"can-spam compliant" as things a spammer would say to try and get 
unblocked so they can fire off a spam run.


~Seth

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


Re: [mailop] btinternet.com blacklist

2017-07-10 Thread Seth Mattinen

On 7/10/17 04:53, Dom Latter wrote:


[1] We have relatively unusual requirements - we need *lots* of disk
space (we upload 2TB / year, and it's nice to have a few years worth)
but other than that a fairly modest server will suffice.  It would be
nice to find a UK provider with, say, 4 x 4TB disk, for < 100USD / yr.



Spammers and abusers like low costs, too. One could even argue it 
attracts them, especially if the hoster doesn't really care. Even if 
they do get turned off they're not out that much money (if any) to fire 
and forget.


~Seth

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


Re: [mailop] Sender IP reverse lookup rejected

2017-06-23 Thread Seth Mattinen

On 6/23/17 11:56, Nick Schafer wrote:

Hi all,

Anyone have any ideas what would cause the below error?

Sender IP reverse lookup rejected

rDNS is configured for the IP where we are seeing this so its not an 
issue with the record not resolving.





Well, the recipient could be having problems resolving.

~Seth

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


[mailop] Google rejects a TLS connection saying it needs TLS...

2017-03-15 Thread Seth Mattinen
Here's one I'm hoping someone can tell me I'm missing something obvious: 
Google is rejecting a TLS connection with an error saying to use TLS, 
but the connection is indeed using TLS.



2017-03-15T21:03:15.960985-07:00 smtpauth postfix/smtp[14716]: Trusted 
TLS connection established to 
aspmx.l.google.com[2607:f8b0:400e:c06::1a]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)


2017-03-15T21:03:17.241821-07:00 smtpauth postfix/smtp[14716]: 
E6AB62800049: to=, 
relay=aspmx.l.google.com[2607:f8b0:400e:c06::1a]:25, delay=5.3, 
delays=3.1/0/0.93/1.2, dsn=5.7.1, status=bounced (host 
aspmx.l.google.com[2607:f8b0:400e:c06::1a] said: 550-5.7.1 Your email 
has been rejected because it violates X X 550-5.7.1 security policy. 
Potential sensitive data was found in the email 550-5.7.1 and/or 
attachment and your email server does not support TLS 550-5.7.1 
encryption. Please use and alternate method of delivery such as fax 550 
5.7.1 or a different email provider that supports TLS. - gcdp X.124 - 
gsmtp (in reply to end of DATA command))



What am I missing other than the suggested fax?

~Seth

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


Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

2016-08-12 Thread Seth Mattinen

On 8/12/16 03:28, Robert Mueller wrote:



It's also easy for the spammer to test. Signup trial account, send to
gmail. No DKIM signature or wrong domain? Use a credit card to pay.
Still not working? Buy a stolen account on some black market. Still not
working due to message content? just tweak their message content and
keep trying until they get the DKIM signature they want.




True, but each of the steps raises the bar for effort a little bit more. 
Right now you have a situation where FM signed an email and said yep we 
vouch for this, even though the bar to get that signature was a ground 
level free trial account.


~Seth

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


Re: [mailop] Lack of TLS 1.1/1.2 support on Apple email products

2016-06-24 Thread Seth Mattinen

On 6/24/16 10:31 AM, Frank Bulk wrote:

Due to PCI requirements to disable TLS 1.0, and recognizing an overall
push towards to TLS 1.1 and TLS 1.2, we tried turning off TLS 1.0 on our
email servers.  That generally worked out fine for webmail, but Apple
users couldn’t use SMTP, POP3, or IMAP, resulting in a lot of helpdesk
calls.  We ended turning TLS 1.0 back on.




Unless you're sending card numbers or track data by email why would you 
need to disable TLSv1.0 on a mail server for PCI?


~Seth

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