Opened 8 months ago

Closed 8 months ago

Last modified 8 months ago

#6164 closed defect (fixed)

trac.ffmpeg.org email verification is very spotty

Reported by: JohnHawkinson Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: trac
Cc: jhawk@mit.edu, john.hawkinson.fwd@gmail.com Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

I created a Trac account with my preferred email (jhawk@mit.edu), and never an email acknowledgement, so could not create a ticket. Switched to a gmail address, that works. Switched to another non-gmail address (jhawk@netbsd.org), also did not receive the ack.

It seems like the trac server is very picky in terms of where it sends email? I'm not sure how best to debug this (or even really who to concat, or if opening a ticket is the right thing).

I'd much rather not ever use my gmail account... thanks.

Change History (13)

comment:1 Changed 8 months ago by JohnHawkinson

  • Cc john.hawkinson.fwd@gmail.com added

comment:2 Changed 8 months ago by llogan

Your mail systems refused to talk to ours:

Feb 19 05:32:08 host dmz-mailsec-scanner-5.mit.edu[18.7.68.34] refused to talk to me: 554 5.7.1 You are not allowed to connect.
Feb 19 05:32:11 to=<jhawm@mit.edu>, relay=dmz-mailsec-scanner-7.mit.edu[18.7.68.36]:25, delay=4.6, delays=0.02/0.01/4.6/0, dsn=4.7.1, status=deferred (host dmz-mailsec-scanner-7.mit.edu[18.7.68.36] refused to talk to me: 554 5.7.1 You are not allowed to connect.)

Probably due to yet another blocklist which is not an unknown occurrence for mailing lists. I will attempt to request removal.

As for netbsd:

Feb 19 07:46:54 to=<jhawk@netbsd.org>, relay=mail.netbsd.org[199.233.217.200]:25, delay=2.1, delays=0.01/0/1/1.1, dsn=4.7.1, status=deferred (host mail.netbsd.org[199.233.217.200] said: 450 4.7.1 <jhawk@netbsd.org>: Recipient address rejected: Greylisting in action, please try later (in reply to RCPT TO command)

The server appeared to try to resend several times but was rejected each at attempt.

comment:3 follow-up: Changed 8 months ago by JohnHawkinson

Thanks for the analysis. I'll followup with my side of the world. Am I correct in thinking that these came from fftrac-bg.ffmpeg.org [79.124.17.101]?

comment:4 Changed 8 months ago by JohnHawkinson

Oh, and in re netbsd.org, it ultimately went through, a little over an hour later.
"I guess that's how greylisting is supposed to work," but that's clearly not your issue, it's mail.netbsd.org's internal choice.

comment:5 in reply to: ↑ 3 Changed 8 months ago by llogan

Replying to JohnHawkinson:

Thanks for the analysis. I'll followup with my side of the world. Am I correct in thinking that these came from fftrac-bg.ffmpeg.org [79.124.17.101]?

That is the correct IP address from where the mail originates. Earlier today I submitted a request to http://ipremoval.sms.symantec.com/lookup/ which a lazy search indicated *may* be the responsible blocklist, but please do proceed if I am incorrect.

Replying to JohnHawkinson:

Oh, and in re netbsd.org, it ultimately went through, a little over an hour later.
"I guess that's how greylisting is supposed to work," but that's clearly not your issue, it's mail.netbsd.org's internal choice.

I didn't search the extensive log files to view every instance, but good to hear it worked eventually.

comment:6 Changed 8 months ago by JohnHawkinson

I think that worked. Or it might have been my IT folks taking action (although I've not heard back from them yet...

At 20 Feb 2017 16:46:57 -0500 (Mon Feb 20 21:46:57 UTC 2017), dmz-mailsec-scanner-7.mit.edu received a message from fftrac-bg that had been hanging out since Sun Feb 19 05:58:59 UTC 2017. Although I'm not sure if all the mit.edu MXs necessarily have their blacklists in perfect sync...

mit.edu.		120	IN	MX	100 dmz-mailsec-scanner-7.mit.edu.
mit.edu.		120	IN	MX	100 dmz-mailsec-scanner-3.mit.edu.
mit.edu.		120	IN	MX	100 dmz-mailsec-scanner-2.mit.edu.
mit.edu.		120	IN	MX	100 dmz-mailsec-scanner-4.mit.edu.
mit.edu.		120	IN	MX	100 dmz-mailsec-scanner-1.mit.edu.
mit.edu.		120	IN	MX	100 dmz-mailsec-scanner-6.mit.edu.
mit.edu.		120	IN	MX	100 dmz-mailsec-scanner-8.mit.edu.
mit.edu.		120	IN	MX	100 dmz-mailsec-scanner-5.mit.edu.

Thanks again!

comment:7 Changed 8 months ago by llogan

  • Resolution set to fixed
  • Status changed from new to closed

comment:8 follow-up: Changed 8 months ago by JohnHawkinson

Problem is back. Unfortunately when I put details in this box I get blisted.

comment:9 in reply to: ↑ 8 Changed 8 months ago by llogan

Replying to JohnHawkinson:

Unfortunately when I put details in this box I get blisted.

Sorry. It appears one of the regex spam blocks is causing a false positive. I'll find out which it is and delete it.

Which address is now problematic again? Both?

comment:10 Changed 8 months ago by JohnHawkinson

fftrac-bg.ffmpeg.org [79.124.17.101] is back on Symanetec's blacklist.

comment:11 follow-up: Changed 8 months ago by JohnHawkinson

My original post attempt:

For what it's worth, this appeared back on Symantec's blacklist with "negative reputation" a few days ago. I'm not sure what's going on, but I assume whatever automated scanning they are applying is re-detecting this. Not sure if that means there's an attack vector that spammers are using to send email through fftrac-bg.ffmpeg.org, or if it's something else.

(At first I was hopeful there was just some latency between removal and their web reporting system, but it's pretty clear that's not the issue here.)

(I'm also not sure if I'm supposed to be clicking Symantec's "Investigate" button [probably not, I assume].)

I did hear back from my IT people Tuesday referencing the Symantec Global Bad Senders List with the same URL you cited, but they have been silent since then...

comment:12 in reply to: ↑ 11 Changed 8 months ago by llogan

Replying to JohnHawkinson:

Not sure if that means there's an attack vector that spammers are using to send email through fftrac-bg.ffmpeg.org

I have seen no evidence of such behavior, and a third-party service monitors all of the FFmpeg IP addresses for malicious behavior (none has ever been detected).

I'm not sure why it was relisted, and I don't know how Symantec determines what they think is spam or not. They probably don't like mailing lists, maybe they don't like servers located in Bulgaria, maybe it's part of a larger service and instead of unsubscribing from the mailing lists some lazy users just report the mailing list messages as spam? Who knows. I am not a mail systems expert, but there are some things I can look into that may help; I just need the time and motivation to do it.

(I'm also not sure if I'm supposed to be clicking Symantec's "Investigate" button [probably not, I assume].)

If you want to request the IP be re-removed, then yes, you can click it and fill out a form, but unless they tell us why it has been relisted then it will likely just reappear.

comment:13 Changed 8 months ago by Cigaes

I do not know if that applies to this one in particular, but AFAIK, a lot of self-styled “spam blacklists” are not much more than a protection racket.

Note: See TracTickets for help on using tickets.