Re: [mailop] Hotmail/Outlook feedback loop processing delay?

2018-01-10 Thread valdis . kletnieks 
On Tue, 09 Jan 2018 20:59:04 +0200, Sotiris Tsimbonis said:
> Hi all,
>
> I received today (9 Jan 2018) a message from outlook's feedback loop
> with a message that was originally sent to a hotmail address on 30 Jan 2017.

Just as a gentle reminder - sometimes the Date: is incorrect because
the system clock on the box is horribly broken.  It's amazing how long
stuff runs on autopilot - as of last year, there were still some 800 systems
that were pointing  NTP at one certain IP address that used to be in my office
running a stratum-2 NTP server.

The weird part?  That box was removed from the public 'clocks.txt' document
in 1998 and decommissioned in 1999, the IP never re-used.

Think about that for a bit.


pgpG44g9l4Lvp.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google groups dropping mail?

2017-11-22 Thread valdis . kletnieks 
On Wed, 22 Nov 2017 11:28:08 +0100, Leo Gaspard said:

> hours (between 10.200.48.129 and 10.55.109.198 if someone knows what
> those IPs mean), and then for exactly 8 hours (between
> mail-vk0-f56.google.com and and... itself?) before reaching my server.

Sounds almost like two different processes on the same server, but
running with different timezones in their environment.


pgpOUjBcoDqun.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hotmail and 4.5.1 4.7.500 Server Busy with some

2017-11-09 Thread valdis . kletnieks 
On Thu, 09 Nov 2017 13:46:05 -0800, "Luis E. Muñoz via mailop" said:

> On 9 Nov 2017, at 13:33, Charles McKean wrote:
>
> > Legal? Was that a threat? Do you have prior experience attacking a
> > lunatic asylum with a banana? Best of luck.
>
> I suspect^Whope this is a language thing.

Almost positive.

> >> When will a legal explanation come from Hotmail (or Microsoft)?

I think the word Emre was looking for was "legitimate"


pgplACpYW8DQp.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail forwarding blowback

2017-11-08 Thread valdis . kletnieks 
On Wed, 08 Nov 2017 11:42:41 -0800, Michael Peddemors said:

> Besides, you want to keep the customer, not make him a gmail customer ;)

If the mail service is bundled with something else that's a profit center, 
unbundling
the cost center part and handing that to Google will improve your bottom line.. 
;)


pgp8awhZxd04o.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SENDERSCORE

2017-10-25 Thread valdis . kletnieks 
On Wed, 25 Oct 2017 12:50:16 -0600, "Anne P. Mitchell Esq." said:
> Weirdly, every single email in this particular thread ended up in Gmail's
> spam folder.  Any good guesses as to why?

My email is also hosted at GMail, but none of the thread ended up in my
spam folder.  So whatever it was, it must be something subtle...



pgp8U67IA6C4Q.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] AOL Postmasters - Syntax replacement for http://postmaster.aol.com/faq/mailerfaq.html#syntax

2017-10-24 Thread valdis . kletnieks 
On Tue, 24 Oct 2017 07:56:19 -0400, "Kevin A. McGrail" said:

> Recently we were alerted to a valid address that did not meet the syntax.

Are you able to tell us in what way it didn't meet the syntax, and how you
confirmed it's valid anyhow?


pgp8_pvw2dwEM.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Slow botnet IMAP scans?

2017-10-08 Thread valdis . kletnieks 
On Sat, 07 Oct 2017 01:30:27 +0200, Philip Paeps said:
> On 2017-10-06 15:18:45 (-0700), Brandon Long via mailop wrote:
> >It can also aid in using say geohop stats.  Ie, one easy way to try to
> >detect hijacking is to geoloc the accessing IP, and see how close it
> >was to the last access, or keep track of where the user is accessing
> >from.  This has obvious issues if your users travel. If a user with a
> >phone that supports it goes somewhere else, chances are they'll access
> >from the phone first, even if their desktop client doesn't support
> >client-token, so you have a strong signal that they traveled somewhere
> >else.
>
> This paragraph sounds incredibly creepy...  I'm glad I'm not one of your
> users!

I read it as "even if they travel, we have a way to identify it's them and not
an impostor".

Can be really handy sometimes.  I notified my bank that I was going to
the Philippines once - and had my card declined in the Beijing airport
because it wasn't the Philippines.  Now that they have given out new
cards that have chips on them, my bank can be more sure that it's
really my card in the Beijing airport next time



pgpwLPdZ_FFiQ.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [RFC 2822] RFC Header Line Length..

2017-08-10 Thread valdis . kletnieks 
On Thu, 10 Aug 2017 07:57:14 -0700, Michael Peddemors said:

> Seeing more and more cases of this not being honoured..
> Surprised that there is not more breakage, but noticed that Yahoo's DKIM is
> now one long line, in addition to Microsoft's VERY long header lines..

I wonder if this is the source of some "never did figure it out" DKIM breakage?


pgpu_qnIOj957.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread valdis . kletnieks 
On Wed, 26 Jul 2017 10:10:53 -0700, Brandon Long via mailop said:
> Why can't smtp software being expected to maintain a list of trusted CAs?
> Or at least run on an OS that is expected to do so.

Quick: What two CAs did Google just remove from Chrome's list?

Has your OS vendor followed suit?  And what percent of your OS vendor's installs
are prompt in applying patches?


pgpwnCPJNDv7D.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] User question about getting off blocklists

2017-07-12 Thread valdis . kletnieks 
On Wed, 12 Jul 2017 12:10:21 -0500, "Scott Bonacker CPA" said:

> The IP for abanet.org is (currently) listed on CASA and SORBS as a bad sender

> What authority is required to make a request for removal from a block
> list? Certainly not a user, but what level in the sending
> organization?

As a user, you can vote with your feet/wallet and find hosting
someplace that doesn't have that happen to them often.



pgpkjCc_3bts_.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] btinternet.com blacklist

2017-07-12 Thread valdis . kletnieks 
On Wed, 12 Jul 2017 00:46:28 -, Michael Wise via mailop said:
> You’d be surprised how many people think that their sincerity is flagged in
> the protocol somehow….

RFC3514 was written explicitly to add support for that.


pgpzmD8obTwjW.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] So, about this iOS10 unsubscribe feature...

2017-05-23 Thread valdis . kletnieks 
On Tue, 23 May 2017 09:29:34 -0400, Joey Rutledge said:
> Do you guys have any samples of the invalid Unsubscribe headers?  There is a
> newish spec (RFC8058; https://tools.ietf.org/html/rfc8058) that I’ve seen
> floating around and wondering if those are the headers screwing things up.

That probably isn't it - 8058 adds a new "one-click' option to the very old
List-Unsubscribe: (how old? RFC2369 is from last century).  Or more properly,
it's a method to tag the URI as being a one-click auto-ambush link, and that
gratuitously following it in the MTA may piss the user off.

For it to add to your queues, somebody would need to be using the one-click
unsub with a mailto: URI, *and* your local e-mail purgatory software needs
to (a) chase the URI as part of anti-spam/malware protection and (b) do so
even if it's a mailto: rather than http: or ftp: or gopher: or so on.

Having said that, I've seen lots more questionable design decisions



pgpvrkeAxU5L5.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SPF record

2017-05-22 Thread valdis . kletnieks 
On Mon, 22 May 2017 14:42:20 -0700, W Kern said:

> I am talking about the scenario where a third party sender WITH an -all 
> SPF record sends to my customer and then MY customer forwards it 
> elsewhere (gmail, hotmail).

So you accept spam if it has a valid SPF?


pgp1vLecxuz_9.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SPF record

2017-05-22 Thread valdis . kletnieks 
On Mon, 22 May 2017 13:21:08 -0700, W Kern said:

> On 5/22/2017 11:22 AM, valdis.kletni...@vt.edu wrote:
> > not an SPF problem.
> > Forwarding has worked just fine for 30 or so years, if not longer. The
> > "problem" only happens if you insist on attaching SPF to it.

> Except when it is a shared server and that server forwards enough
> spam/virii (despite anti-spam efforts) to a common email host (gmail,
> outlook, etc) to get EVERYONE on that server blocked.

Then it's your fault for *accepting* the spam/virus that ended up getting
forwarded.

> failure or when their customers Website is delivering transactional
> email but the customer didn't alter their SPF record to include the
> webserver.

That isn't even related to the point under discussion - SPF and forwarding.


pgpGokSVJjYbq.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SPF record

2017-05-22 Thread valdis . kletnieks 
On Mon, 22 May 2017 10:59:21 -0700, Michael Peddemors said:
> Some have pointed out on the list the problem with 'forwarding', however
> that is a forwarding problem, and not an SPF problem.

Forwarding has worked just fine for 30 or so years, if not longer. The
"problem" only happens if you insist on attaching SPF to it.

If a car manufacturer had been making perfectly usable vehicles with perfectly
functional windshield wipers for decades, and you discovered that the windshield
wipers tend to malfunction when you attach other devices to the windshield,
is that the fault of the windshield wipers, or the other devices?

> Since every email client out there can check multiple mailboxes, if you
> want to properly take advantage of SPF as a recipient, don't do email
> forwarding ;)

No, what you meant was:

If you want to properly take advantage of SPF as a recipient, ensure that
no users at other sites set a forward to your mail system if their sysadmin
has set an SPF record that will cause problems.

Which is, in general, obviously not achievable.


pgplKjkIt9ptZ.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Speaking of too many SPF, Many SPF failures lately

2017-05-18 Thread valdis . kletnieks 
On Thu, 18 May 2017 08:53:37 -0700, "Luis E. Muñoz" said:
 
> large ranges in the SPF validation. I suppose it would be plagued with 
> false positives, but if enough people did it, it would give some 
> priority to actually think about your SMTP flows when setting up your 
> SPF records.

That sort of thinking may have worked 3 decades ago, when Sendmail 5.67
was the latest and greatest way to move e-mail around, and pretty much all
the sysadmins on the network knew each other by reputation, and posting "Hey
guys, I can't seem to get this working, what am I missing?" was guaranteed to
get you useful help.

However, I haven't seen much evidence that it's been a workable strategy
anytime this century.  In particular, it would require a number of 800 pound
gorillas who are mostly centered around increasing the success percentage to
voluntarily choose a course of action that would lower the percentage - and
they'd be relying on the set of sysadmins who did the *least* thinking about
their configuration to fix their stuff.

Phrased differently - did anybody in school *ever* voluntarily choose to work
on a project with the least clued and engaged student in the class, in hopes of
improving their own grade on the project?



pgpKpSNoaca12.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] does Google use SAME outbound IPs for "G suite" as they do for gmail?

2017-05-05 Thread valdis . kletnieks 
On Fri, 05 May 2017 14:50:54 -0700, Brandon Long via mailop said:

> In reality, ESPs exist along a spectrum, both in their ability to keep
> spammers out and their desire to.  And "spammers" also exist along a
> spectrum, from folks clearly knowing they are doing it to folks who don't
> to entities who have controls in place but occasionally fail.  And entities
> can also be compromised and used by spammers.

The word "egregious" was used.  That pretty much rules out entities that
have controls in place, and most cases of compromised entities.

"Egregious" does cover folks who clearly know they are doing it.

And in 2017, if you're somebody who doesn't know if they're spamming, there's
only two options: (a) You are a spammer in denial or (b) You need to get a
lot more clue *now* or get out of the business.


pgp7YqWohSXaa.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] does Google use SAME outbound IPs for "G suite" as they do for gmail?

2017-05-05 Thread valdis . kletnieks 
On Fri, 05 May 2017 10:48:46 -0400, Rob McEwen said:
> Does Google use the SAME?... or DIFFERENT?... outbound IPs for "G suite"
> (or any other customers who are using their own domain names) ...as they
> do for @gmail.com addresses?

Don't your own logs have enough info in them for that?  See what addresses
you receive @gmail.com mail from, and @google-hosted-stuff.com


pgptsysZZlkNw.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Do we need a new list for reporting spam? (Was Re: Admin: This is not a place to report Spam. )

2017-04-10 Thread valdis . kletnieks 
On Mon, 10 Apr 2017 12:21:45 -0600, Ryan Harris via mailop said:

> It might be helpful to understand why people want to post on email forums
> rather than an abuse desk. Is it to gain public attention on the matter? Is
> there a bit of shaming going on and the reporter wants the community to
> know they are fed up with the ESP? Are people reporting on public forums
> b/c they want to know if others are experiencing the same problem?

Posting the spam itself on forums is pretty much pointless.

On the other hand, having a forum where you can ask "Are the guys who
are supposed to be dealing with ab...@robot-penguins.xyz merely clueless
or actively rogue?" or "Does anybody have a contact at helium-filled-cows.com?"
does have value

Cue somebody saying "in 2017, being clueless *IS* actively rogue" in 5..4..3 :)


pgp1pfV05N4c5.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] conventional wisdom, was Google rejects a TLS connection

2017-03-17 Thread valdis . kletnieks 
On 17 Mar 2017 15:47:50 +0100, "John R Levine" said:

> I used to have my own credit card account and my card processor demanded
> PCI compliance.  About 1/4 of it was reasonable, 3/4 was cargo cult stuff
> that mostly involved stuff like setting packet filters so they couldn't
> probe ports that weren't going to answer anyway.

I gave up on thinking that PCI was something other than an extortion racket a
number of years ago, when somebody reported on the major breaches of the year
and noted that 100% of them were in full PCI compliance at the time of the 
breach.


pgpFr_Mad6Rf1.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Enforcement of RFCs [was: GoDaddy Email admins' in the house?]

2017-02-15 Thread valdis . kletnieks 
On Wed, 15 Feb 2017 05:59:36 +, Phil Pennock said:

> I believe Brandon's point is that this is a probe _of_ Gmail, not _by_
> Gmail, and the service purporting to be testing RFC conformance is
> instead doing a very old-style message with no headers at all.

Right.  The test sends something that's not 5322 compatible, so gmail
saying it's not 5322 is correct behavior.  So unless it's a test to ensure
that particular flavor of broken is correctly rejected, I'm not sure
what the point being made was...

> As of ye olde RFC2822, there are mandatory headers, "From:" and "Date:",
> so Gmail is insisting upon having the RFC-mandated headers, so rejects
> the mail, so the RFC conformance testing tool is issuing a
> false-positive.

I believe the phrase "violently in agreement" applies here. :)


pgpagTr5OXmV9.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] blocking mails/networks (was: Mails to microsoft)

2017-02-13 Thread valdis . kletnieks 
On Mon, 13 Feb 2017 09:16:42 -0800, ml+mai...@esmtp.org said:

> How would a user know that (s)he missed a mail?
>
> I sometimes send patches to various open source projects and if a
> mail to the maintainer bounces due to some "anti-spam" measures,
> then I take that as an indication that they don't care -- so why
> should I try to reach the maintainer in some other way?

Turn that around.  How would the *maintainer* know he missed a mail due
to their provider's anti-spam magic incantations?  If nobody tries to
reach them in some other way, they may be sitting there wondering why
they get so few patches to merge


pgpkL7u7wEyFM.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Enforcement of RFCs [was: GoDaddy Email admins' in the house?]

2017-02-13 Thread valdis . kletnieks 
On Sun, 12 Feb 2017 07:52:25 -0500, Rich Kulawiec said:
> On Wed, Jan 11, 2017 at 12:33:47PM -0800, Michael Peddemors wrote:
> > More and more, if you want to deliver email in today's environments, you
> > have to ensure your email servers are correctly configured.
>
> I think there's considerable value in slowly enforcing this in stepwise,
> announced fashion.

And where do you announce it where all the mail system administrators who
don't read the *current* BCPs will see it and act on it?




pgp1mxrhriC_L.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Odd spamcop glitch

2017-01-23 Thread Valdis . Kletnieks 
On 23 Jan 2017 21:30:20 +, "John Levine" said:

> That led to great merriment, since that's Blue State Digital and mail
> from mainstream political groups went into spamtraps that tested the
> URLs, some of which were "Click here to donate now with your preregistered
> credit card!"  Oops.

OK, I'll bite.  How did the mail end up at a spamtrap address in the first
place?  Somebody maliciously signed the address up for a mailing list?  Or some
other failure mode?


pgppvCDnIC97w.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mysterious DKIM failure.

2016-12-13 Thread Valdis . Kletnieks 
On Mon, 12 Dec 2016 13:26:04 -0700, Luke Martinez via mailop said:

> Whether or not you should ignore changes to whitespace and capitalization
> seems like a fairly trivial thing.

Not when you're talking about a cryptographic signature, where a single
changed bit should change the signature drastically.


pgpvlrqjHabwc.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection

2016-11-19 Thread Valdis . Kletnieks 
On Sat, 19 Nov 2016 08:33:27 -0800, Carl Byington said:

> Of the 220 sites identified above, 218 of them manage to see the icmpv6
> packet and respond by resending with a packet that makes it thru the
> tunnel. I suspect that packets from at least one of those 218 sites goes
> thru many of the same systems as the packets from login.yahoo.com.

> https://www.mega.nz and https://www.1fichier.com seem to have the same
> icmpv6 filtering issue.

OK, you're *almost* done.  Now take the sites that failed, and traceroute -6
to them, and then to several sites that work (just as a control).

What router(s) do the 3 failing sites (yahoo, mega, and lfichier) have in
common, which are *not* in the path to a site that works?

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

Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection

2016-11-18 Thread Valdis . Kletnieks 
On Fri, 18 Nov 2016 13:01:50 -0800, Carl Byington said:

> response to that will be a bunch of full size packets from Yahoo with
> the certificate, etc. The *far* end of my tunnel will be sending the
> icmpv6 "packet too big" back to Yahoo.

And you identified that the problem was at Yahoo, and not one or more of the
hops between the far end of your tunnel and Yahoo, how, exactly?


pgptbYp3YHmou.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection

2016-11-18 Thread Valdis . Kletnieks 
On Fri, 18 Nov 2016 11:58:58 -0800, Carl Byington said:

> If you have IPv6 connectivity thru a tunnel, with a smaller MTU, that
> will fail. With a 1500 byte MTU, it works. The TCP handshake works - it
> then hangs during the TLS handshake which sends full size packets.

Did you do anything to specifically identify Yahoo's routers as the offenders?

Hint: If there's a tunnel in the path, it will be *your* end of the tunnel
that sends back the "can't frag" ICMP.  So the filtering is happening somewhere
between your end of the tunnel and you.


pgpBSyxc1Fhnl.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft Blacklisting IPs

2016-11-17 Thread Valdis . Kletnieks 
On Thu, 17 Nov 2016 16:58:35 +0100, Hetzner Blacklist Support said:

> our customers who use them on their own dedicated servers. They're the
> ones having issues, since Microsoft has blacklisted large parts of our
> network.

That should be your big hint that you have a customer problem. (The other
possibility is that Microsoft actually screwed up, but when you're talking
huge chunks of address space, it's more likely quite intentional on their
part and done for good reason)

> In this case, I'm talking about hundreds of thousands of IPs from our
> network being blacklisted by Microsoft.

At some point, people get fed up with blacklisting individual IP addresses
and start blocking /24s and working up to /16s.  Especially if the number of
*legitimate* e-mails from the /24 or /16 is far less than the number of spam
e-mails. Hopefully, at some point the collateral damage makes the owner of
the address space finally take action (remember - it's causing Microsoft a
lot less pain than it is causing your legitimate customers)

If in fact you have hundreds of thousands of blocked IPs, that means you've
managed to get multiple /16s (or larger) blocked.  That takes some doing. And
at that point, you should probably be checking where *else* you've been
blacklisted - I highly doubt that Microsoft has been the only one your
customers have been spamming.

Step 0 is going to be figuring out what's *really* going on with your customers.



pgpk03ICq3KMs.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] connection issues from .*?.bullet.mail.(skk|kks).yahoo.co.jp

2016-10-28 Thread Valdis . Kletnieks 
On Fri, 28 Oct 2016 11:09:27 +0200, Benoit Panizzon said:
> > PS: Maybe I am not supposed to send multiline prompts if a server
> > greets with HELO instead of EHLO?
>
> Note to self, next time read RFC before sending email...
>
> Old RFC 821 does not state, that a reply to HELO can be multiline.
> After changing my spamtrap to only send one line in reply to HELO, it
> is getting a lot of spam from all over yahoo.co.jp.

What RFC 821 actually says in section 4.2:

  An SMTP reply consists of a three digit number (transmitted as
  three alphanumeric characters) followed by some text.  The number
  is intended for use by automata to determine what state to enter
  next; the text is meant for the human user.  It is intended that
  the three digits contain enough encoded information that the
  sender-SMTP need not examine the text and may either discard it or
  pass it on to the user, as appropriate.  In particular, the text
  may be receiver-dependent and context dependent, so there are
  likely to be varying texts for each reply code.  A discussion of
  the theory of reply codes is given in Appendix E.  Formally, a
  reply is defined to be the sequence:  a three-digit code, ,
  one line of text, and , or a multiline reply (as defined in
  Appendix E).  Only the EXPN and HELP commands are expected to
  result in multiline replies in normal circumstances, however
  multiline replies are allowed for any command.

Note the last sentence.


pgpT84Y6uOeHL.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] 21cn.com connection reset before QUIT

2016-10-21 Thread Valdis . Kletnieks 
On Thu, 20 Oct 2016 17:59:46 -0400, Mitchell Kuch said:

> Filtering by either
> the List-Id header contains ""
> or
> a Received header contains "for mailop@mailop.org"

"D'Oh!" -- H. Simpson.

Apparently, the last time I looked at this and gave up in disgust,
List-Id: wasn't as common out in the wild.  And Recieved: headers
are so often a morass of non-standard formats I never considered
filtering on them


pgpm82msrL6rZ.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] 21cn.com connection reset before QUIT

2016-10-20 Thread Valdis . Kletnieks 
On Thu, 20 Oct 2016 15:57:24 -0400, Mitchell Kuch said:

> inbox. Gmail discards what it considers to be duplicate messages. I
> find this to be a frustrating behavior.

And most of the time, that's not too bad - if somebody cross-posts to two
lists that you're on, you'll get only one copy.  And that's OK, because almost
nobody does mail filtering of such things into separate folders (or more
correctly, there's usually no sane way to do so, because whatever rule you
set in .procmailrc or whatever, *both* copies will end up going the same path).

The *annoying* part is that if you post via Google, it records the Message-ID:
that it assigns to you *outbound* post, and then filters out *all* inbound
copies with that ID.  This means that you don't get to see your own post.

The best workaround I've found so far is to have your MUA do message
submission to a non-Google mail server.  Whether you can find one that
will accept mail with your From: is a different matter (for me, $DAYJOB
runs a suitable service locally).


pgpHp1SFZKSGl.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Spamhaus and Spamcop Blacklisting

2016-09-13 Thread Valdis . Kletnieks 
On Tue, 13 Sep 2016 14:23:20 +0100, Rupesh Gohil said:

> Yes email marketer having those IPs. Is it really hard to come out from
> Drop? - Email Marketer has 20 to 25 Spamtraps and these spamtraps has been
> removed now.

Removing the spamtraps won't fix the problem.

Your Email Marketer needs to fix the very deep issues in their business
process that allowed those spamtraps to get *onto* their lists in the
first place.


pgpCKNl_Q5yIi.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google: Increase in false positives?

2016-09-02 Thread Valdis . Kletnieks 
On Fri, 02 Sep 2016 14:27:39 -0400, Jim Popovitch said:
> On Fri, Sep 2, 2016 at 4:28 AM, Brandon Long via mailop
>  wrote:
> > The spam team would love to send all unauthed mail to the spam label or even
> > reject it (they call it no auth no entry).

> I'd love to see "no auth no entry", but I'd prefer to see native PGP.   ;-)

Only if you agree to handle all the support calls regarding web-of-trust. :)

(This is a major problem for deploying e-mail crypto at scale -
http://pgp.cs.uu.nl/plot/ says the strongly connected set in the web-of-trust
is right around 60,000 keys - which amounts to about 0.001% of the world
population. You want PGP to take off, you need to find a sane way for the
*other* 99.999% of the population to do keys correctly)



pgpfFCPKJ5xY8.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop