Re: [mailop] [ADDENDUM] Update from .. personal pet peeve

[Dave Warren via mailop]

On 2022-06-15 14:08, Michael Peddemors via mailop wrote:

On 2022-06-15 12:50, Michael Peddemors via mailop wrote:
Haven't been keeping up on these, figured it is time to put one out, 
even though it isn't the end of the week...




(see attach)

This one really bugs me Gmail, why should we have to filter these to 
protect out customers, as one of the world's largest email emitter, it 
behooves you to take on a great role to protect the internet.


Its' obvious over here, so why isn't it obvious on egress at your side?

This type of extortion email has no business leaving Gmail, and I am 
sure volumetric analysis, sending behavior, content, fake reply, or 
email account activity at your end should enable you to target these 
readily.


Or are you letting this stuff out on purpose for some business reason 
beyond me? Inquiring minds would like to know.


The especially frustrating part is that even letting a few of these slip 
through mailboxes forwarded to Gmail will cause me issues delivering to 
Gmail for a while, so Gmail is seemingly capable of identifying them.



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

Re: [mailop] Leaseweb

[Dave Warren via mailop]

On 2022-06-07 11:11, Hans-Martin Mosner via mailop wrote:
it's probably no surprise to anybody, but Leaseweb is a confirmed 
spammer haven.


Sadly, this is where my mail server is hosted. Due to their acquisitions 
rather than by my choice, but it hasn't been enough of a problem to make 
any efforts to move. I'll wind down completely soon enough.


I don't believe they've ever forwarded a spam complaint to me (not that 
I can recall, anyway) and I'm sure the must have gotten something the 
few times a compromised account managed to send some outbound junk. They 
were fine to work with when I was a DDoS target briefly.


I've definitely had stuff hit my own abuse@, but per-acquisition I did 
periodically get something from my host (happily, never before I already 
identified and mitigated it, to the best of my recollection).


They also don't give me any rwhois to make myself easier to reach. I'll 
be winding it down soon enough, so this is not a request to exempt my IP 
space as it will no doubt be promptly reassigned.


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

Re: [mailop] State Of The Sendgrid

[Dave Warren via mailop]

On 2022-03-02 09:56, Brie via mailop wrote:
So, are we all still under the conclusion that it's a waste of time to 
hope that something might be done about abuse from their network?


If nothing was fixed last year, why would anything be fixed this year?

Maybe next year!

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

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

[Dave Warren via mailop]

On 2022-01-11 03:29, Jaroslaw Rafa via mailop wrote:

Dnia 10.01.2022 o godz. 19:30:02 Dave Warren via mailop pisze:

How would it know the difference if it was Thunderbird, or the user?

You can guess by timing.

If the message is moved to spam folder immediately after being fetched by
client, then it is an automated filter action. If there is at least a few
seconds delay, then it is probably the user manually moving the message into
spam folder (the user needs some time to look at least at the subject of
the message and click the appropriate button).


It's a start. But I don't think it can be particularly reliable since 
IMAP allows multiple connections to a mailbox and can't link a 
particular connection to a particular client.


For example, it is quite reasonable to make connections that check a 
folder and use IDLE in that folder while other connections service 
explicit user actions (regardless of folder).


And I suspect most users use more than one client at the same time 
(mobile clients don't magically disconnect when you start your 
desktop/laptop client). Plus all the server-based "assists" that so many 
mobile clients use.


I suspect one could study enough mail clients to figure it out, and I 
don't really even know how many behave poorly out of the box or can be 
configured to perform automated actions.




___
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?

[Dave Warren via mailop]

On 2022-01-11 09:11, Lukas Tribus via mailop wrote:

in my opinion Office 365 does it right (in the browser).

When marking an email as Junk, it will ask the user whether the
message should*ALSO*  be reported. This hints at the possibility that
this will land at a human person (can be true for abuse reports),
which makes this a good UI choice, in my opinion.


I very much like this implementation, and it seems to be reasonably 
clear to the user that "something" is happening. In a simple 
sender-to-recipient or spammer-to-recipient situation it's great!


But once you get mailboxes that are forwarded, mailing lists, and all 
the other things people do to/with email... I'm not even sure I could 
make any sort of decision tree for what is the right place, let alone 
start to implement such a thing in code.



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

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

[Dave Warren via mailop]

On 2022-01-11 03:29, Jaroslaw Rafa via mailop wrote:

Dnia 10.01.2022 o godz. 19:30:02 Dave Warren via mailop pisze:


How would it know the difference if it was Thunderbird, or the user?


You can guess by timing.

If the message is moved to spam folder immediately after being fetched by
client, then it is an automated filter action. If there is at least a few
seconds delay, then it is probably the user manually moving the message into
spam folder (the user needs some time to look at least at the subject of
the message and click the appropriate button).


Or conversely, what steps should an IMAP user take to report spam
properly?


Maybe set up an address like spamrep...@your-provider.com where users should
forward all messages they consider to be spam?


Over the last 1-2 decades I implemented just this! A spam/non-spam 
address that users could forward mail to, plus dedicated shared 
#ReportAsSpam #ReportAsNotSpam folders that users could use.


I don't think I managed to get a single person to forward an EML file to 
the spam/non-spam addresses even once in over a decade.


Teaching users to forward spam is just bad for a whole number of reasons 
and I wouldn't do it today. Even though the intent is only an internal 
"send your spam to spam@localdomain or spam@provider-name", good luck 
getting users to understand that forwarding spam is otherwise bad. The 
"we hacked your email and watched you do private things" are especially 
bad because users legitimately get worried and forward these to their 
partners or others to get advice.


Forwarded non-spam without the EML was useful if their client bothered 
to forward enough of the original From header that I could toss the 
address on a "User wants this mail" list, although that wasn't 
particularly scalable, and didn't actually give me anything that webmail 
address books and whitelisting outbound mail didn't also give me.


User's "Archive" folders seem to be a good proxy for not-spam, if a user 
had a lot of messages over a reasonable period of time in their Archive 
folder I'd point SA's bayesian learning at it.


A few used the #ReportAs shared folders. This was safer because it 
didn't use their mailbox's own Junk folder so it required explicit 
action. These got used by the webmail interface too so it is hard to 
judge if users explicitly used the folders. If we were to redesign 
protocols from scratch, having an explicit "The user marked this as junk 
and wants to unsubscribe, or have it blocked, or file a report" would 
all be excellent things, but outside of webmail providers who control 
their servers and interface, this won't be a thing.


(EML, meaning anything that attached the original message with headers 
and at least some body).


___
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?

[Dave Warren via mailop]

On 2022-01-10 15:32, Mark Fletcher via mailop wrote:
On Mon, Jan 10, 2022 at 11:24 AM Douglas Vought via mailop 
mailto:mailop@mailop.org>> wrote:



Does anyone have any tips on handling abuse complaints on legit email?

When we (Groups.io) receives an FBL report, we automatically unsubscribe 
that person from all email groups they're subscribed to. We then send 
them one final email with a link to re-subscribe if it was a mistake. 
This has been a controversial feature and a source of angst. "How dare 
you remove me from my groups", "Hey, you've got a bug, all my groups are 
gone", "I never clicked the spam button".


When I was first starting out, my operating assumption was that if we 
did not act on the FBL reports in this way, that we'd eventually get 
blocked. I still don't know if that's true or not, but I'm inclined to 
keep the behavior; it does nobody any good if their group messages are 
going into spam, and I don't know of another way to get someone's attention.


First of all, this is awesome, thank you!

I love the idea of alerting the user and blocking all mail (not just the 
one list) as a way to get their attention.


I would also like to see a one-click "Unsubscribe from this group, 
unblock the rest" along with a "Unsubscribe all" and "Resubscribe all if 
I promise to not do it again"


If possible, I think it would be genuinely useful to give them the 
details of the message that they reported as spam, at a minimum the list 
name and subject of the message. Already this year I've had a "I've 
never reported anything from you as spam", conversation which turned 
into "Oh, right, but that is spam!" once we identified the message. It 
wasn't untrue, it was just a info@ address that went through a mailing 
list of one, to a mailbox which itself was forwarded to a third party.


Only by the grace of Mr Goldberg himself does all the stupid things 
users do manage to get their email delivered at all, and one cannot 
reasonably be expected to know where the spam report goes when they hit 
"Spam" on one of these messages.


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

Re: [mailop] What a drag it is sending DMARC reports

[Dave Warren via mailop]

On 2021-12-26 18:44, Ángel via mailop wrote:

On 2021-12-23 at 21:02 -0700, Dave Warren via mailop wrote:

Even just verifying a phone number adds a real world cost to
switching identities which makes blocking far more effective.


There is certainly a cost for casual users wishing to switch
identities. Both for wannabe trolls & spammers and people that would
have preferred  (or for which it would have been wiser) not to use
their main identity for $community.¹ Having them provide their "real"
phone number means they are easier to block, as well as easier to track
and by whatever corporation is going to mint it to... ehm "provide a
more customized experience to you" (even though that might be
undesirable for the user privacy).

I wonder however if that's still the case for "professional" spammers,
as I expect they would be able to buy phone numbers more easily and
cheap than common users. Is it really a hurdle for them or just a minor
annoyance?


When compared to an open system like email, where one can create 
"identities" trivially, forcing a spammer to acquire a new phone number 
per unique identity is definitely a useful and limiting factor.


While the cost is not all that significant to obtain a new number for an 
individual, doing so in bulk will absolutely require a change in 
behaviour on the part of spammers.




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

Re: [mailop] What a drag it is sending DMARC reports

[Dave Warren via mailop]

On 2021-12-26 19:23, Michael Rathbun via mailop wrote:

On Mon, 27 Dec 2021 02:44:35 +0100, Ángel via mailop 
wrote:


I wonder however if that's still the case for "professional" spammers,
as I expect they would be able to buy phone numbers more easily and
cheap than common users.


What is this 'buy' of which you speak?   Phone numbers are composed of digits,
all of which have been freely available for use since they were propounded by
Indians, Arabs, Romans...   Unless you mean "phone numbers that are actually
routable from caller to called party" which is unnecessary in this context.


Many/most centralized communication systems require phone number 
verification/validation (SMS or voice, typically) to activate a new 
account. Even when multiple accounts can be activated using a single 
phone number they can be linked and deactivated as a group.



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

Re: [mailop] What a drag it is sending DMARC reports

[Dave Warren via mailop]

On 2021-12-18 08:39, yuv via mailop wrote:

On Sat, 2021-12-18 at 15:13 +0100, Alexey Shpakovsky via mailop wrote:

On Sat, December 18, 2021 13:50, yuv via mailop wrote:

What makes the difference between [the smoothly running messaging
systems] and internet email?


I believe answer is centralization and to some extent lack of
backwards compatibility requirement.


what is it that centralization brings to those systems?  after all,
they also consists of numerous independent parties communicating with
one another over electronic devices, exactly like internet email.


Among other things, the barrier to entry is higher with many/most 
services verifying at least a phone number (and sometimes the hardware 
itself).


As an example, you can only create a certain number of @iCloud.com email 
addresses from a single device over a fixed period of time, and 
resetting the device doesn't reset your limit. There are probably 
thresholds to how quickly you can register and change iMessage addresses 
too although I haven't encountered or explored them.


Even just verifying a phone number adds a real world cost to switching 
identities which makes blocking far more effective.


This is beyond the obvious "single party in control", running the 
servers and clients all at once and having a vested interest in the user 
experience all have their benefits.


As much as I am a fan of open and decentralized, there are advantages 
and disadvantages.


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

Re: [mailop] Experience with SMTP2GO?

[Dave Warren via mailop]

On 2021-12-19 08:01, Daniele Nicolodi via mailop wrote:

Hello,

does anyone have experience in using SMTP2GO Free tier service for 
sending tiny volume of emails from personal domains?


Being grumpy about the failure of SMTP as a federated protocol does not 
help have email delivered, thus I am looking for options that do not 
entail going around begging every free email provider to pretty please 
accept email from my little server.


I use SMTP2Go, I've been back and forth between the free tier and the 
lower 3 paid plans.


In particular, when moving a small server (a few hundred users) to a new 
set of IP space I started delivering small volumes directly with 
everything else (including anything that failed for any reason) going 
through SMTP2Go. They had no problem with the spike of traffic from an 
account that was previously just used for testing.


I still have them as a backup that I can activate with a configuration 
change, plus I use them directly from Thunderbird to route mail 
externally explicitly.


They have contacted me with regards to some outgoing spam from a webform 
and were great to work with.


I'm unclear if there are any further limitations on the free plan, but I 
didn't encounter any when I used it. I have stayed on the lowest paid 
plan despite not really using it just to have it handy.


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

Re: [mailop] HIPAA compliant email (was Re: So uh... Zoom/Sendgrid... How's that webinar spam investigation coming?)

[Dave Warren via mailop]

On 2021-08-05 09:47, John Levine via mailop wrote:

It appears that Luis E. Muñoz via mailop  said:

Out of curiosity, and recognizing that this would be a separate thread,
what makes email non-compliant, considering that fax seems to be
compliant? Just in case, this is a serious question of mine.


It's supposed to be end-to-end encrypted, for some version of end-to-end.

Since vanishingly few patients are au courant with S/MIME and PGP, in practice
it means that they take the Paypal approach, and the mail only says you have a
message, log into our web site to see what it is.  If the patient wants to send
a message to the doctor, log into the web site and hit the New Message button.

I do know a few physicians who correspond directly with some patients under the
theory that the patient has knowingly waived the encryption but I don't think 
it's
ever had a legal test.


Even more annoying is a secure request to "please send the requested 
private medical data to some.doctor6...@gmail.com", which could be 
knowingly waiving the encryption requirement if I did, but wouldn't be 
knowingly waiving the encryption requirement if my grandmother did.


I have not yet found a doctor's office able to S/MIME or PGP, not that I 
have either configured, but I would immediately and happily set it up if 
I could get away from phone calls and long talky voicemail messages 
(which just end up transcribed in my email anyway).


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

Re: [mailop] m-365 still works like a spammer !

[Dave Warren via mailop]

On Sat, Jul 24, 2021, at 09:14, Xavier Beaudouin via mailop wrote:
> Hello,
> 
> >> But it seems they never trys the best preference first.
> >> 
> > 
> > Are you greylisting or running pregreet tests on your MXes?
> > 
> > Here's what I think is happening.  MS first tries the priority 10 MX,
> > and postscreen (or such) issues some tests that delay the transaction,
> > so then MS tries the next (next, next...) priority MX and eventually
> > ends up on your highest priority MX.
> 
> I use greylisting... BUT... there is not log trace from microsoft servers on 
> the 10 MX... so they didn't bother about greylisting...
> Maybe they had some issue... I changed the priority to 50... let's see
> if there is something different...

One consideration is that Microsoft seems to cache connection failures, 
possibly quite aggressively, so you shouldn't expect to see much further 
traffic once your primary MX gets on the list.

I do similar on my own server, although not as aggressively, and I've had a few 
cases where someone was yelling at my postmaster@ for hitting their lower 
priority MX when their primary MX was "working perfectly" and it turned out the 
primary MX was definitely not.

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

Re: [mailop] Huh?

[Dave Warren via mailop]

On 2021-04-30 08:50, Chris Kolbenschlag via mailop wrote:
I got an email from a small receiver that they are blocking one of our 
/24s because of spam.  I looked up the email address they referenced and 
found the contact signed up on their website 2 years ago, has a 41% open 
rate, a 17% click rate and has made thousands of dollars in purchases 
and now they block the /24.

Any idea the thought process here?
Chris K


Did they sign up to website to transact and receive transactional 
messages, or to marketing email?


Are you sending only transactional messages or also marketing email?

Have they ever requested you stop sending marketing email?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Dave Warren via mailop]

On 2021-04-21 13:34, John Levine via mailop wrote:

It appears that Peter Nicolai Mathias Hansteen via mailop  
said:

Greylisting implementations tend to expect retries to come from the same IP 
address as the original one. Some of us are still quite cross that
the writers-of-RFCs did not care to make that a MUST requirement (see [1] for 
my grumble on that from a while back).

SMTP was defined in the late 1970s and we didn't invent greylisting
until about 2003. I don't think you can blame them for not being
clairvoyant.

I find that fuzzing the IP addresses to anything in the same ipv4 /24
or ipv6 /64 handles most of the different IP retries without letting
any more spam through.


I also just ignore the IP completely for mail marked as SPF:PASS. A 
quick and easy way to let the sender define what IPs they use and I 
don't need to worry about the outbound IP changing.



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

Re: [mailop] Greylisting never passing on retry

[Dave Warren via mailop]

On 2021-04-20 03:24, Hans-Martin Mosner via mailop wrote:

Another possibility, which would for example apply to the mail systems for 
which I'm responsible, is that temp rejection
is used to defer mail from questionable sources until a manual check shows that 
they're likely genuine (or in some
cases, until a rbl hit indicates that others received the mail and categorized 
it as spam). In this case, we wouldnt
talk about greylisting in the error message, though, as that is misleading.


Never hurts to remember that some of us are jerks when it comes to 
providing clues to spammers too.


Back when I was running a small hosting company I would try to report 
the least significant DNSBL hit in the rejection message when in reality 
there was a more complex scoring system at play, and resolving that 
listing would do nothing more than give you a new (but also valid) DNSBL 
hit on your next attempt.


It wasn't misleading, technically, but by the time an IP tripped the 
scoring system to an outright reject before even seeing the message body 
it was pretty certain they were living in a sewer anyway, so why not let 
senders work their way up?


There was also a link to generate a whitelisting request for the odd bit 
of legitimate mail.

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

Re: [mailop] [E] Re: Some Days I think that Gmail isn't even trying to stop outbound spam..

[Dave Warren via mailop]

On 2021-02-09 14:47, Chris via mailop wrote:

On 2021-02-08 21:09, Dave Warren via mailop wrote:
\

You could always turn on + addressing on M365...

https://docs.microsoft.com/en-us/exchange/recipients-in-exchange-online/plus-addressing-in-exchange-online 



Admittedly it is fairly new, and opt-in for reasons described on the 
link above, but it should be straightforward for a client moving in 
from another that supported plus addressing.


The convention has existed almost as long as there's been sendmail, and 
is available in postfix too.  This is handy to direct incoming email 
into different boxes, and makes it possible to narrow down who leaked 
your email address.


Absolutely. but in the context of the Microsoft 365 platform, it is less 
than 6 months since it was implemented as a checkbox administrators 
could enable. Before that it took custom aliasing or other hackery.




Indeed: I use it for my subscription to mailop as you can see.


I'm not sure how many years I have used plus addressing, but I first 
blogged about my experience with a product-specific implementation in 
mid-2008.



UNFORTUNATELY, many web sites outright refuse to accept "+" as a valid 
character in an email LHS, despite the fact that the RFC's permit it.


In fact, I've run into occasions where the "new user" function permits 
it, but logging in and/or password change *don't*.  Worse was one that 
entirely disabled it long after I've been using it successfully, routinely.


I've run into both of these a couple times. Sometimes in my favour, in 
one case it was the "update your profile" page that wouldn't work, I 
couldn't even change my e-mail address as the existing one was 
non-editable and invalid. Customer service shrugged and suggested I 
create a new account, so I did by referring myself, and got both sides 
of the referral bonuses and their slew of new-user bonuses.


When I was running my own hosting service, I supported - as an alternate 
character (user-subaddress@domain = user+subaddress@domain) and for 
users that wanted, subaddress@user.domain too, although I only deployed 
the DNS records upon request.


When I exited the market professionally and was looking for somewhere to 
refer customers, my discovery that FastMail supported the subdomain 
addressing by default brought them a decent number of mailboxes, 
eventually including my own personal address(es).




It's useful, but be aware that some sites screw it up.  Some relatively 
major ones.


I haven't yet found anywhere that can't cope with at least one of my 
address format alternates.


Another issue is that more and more companies are restricting addresses 
that contain their name. Uber doesn't (or at least didn't) allow uber@, 
dave+user@ or dave-uber@, but they were fine with u-morons-ber@ so that 
was good enough for me.


I've seen this a bit in the health world, our local blood laboratory 
accepts my email address and sends account related information, but not 
appointment confirmations. I was able to discuss it with their technical 
staff and the addresses was blacklisted in their ESP's database, but 
they couldn't see why. I experimented with other addresses at the same 
domain, and the same username at another domain, it was definitely the 
username portion.


Tossing a -morons- in the middle does the trick, but it means I have 
even more address formats to potentially use when trying to recall 
credentials or account details. Thank dog for password managers and 
searchable indefinite email retention being things.

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

Re: [mailop] How important is an ipv6 ptr record?

[Dave Warren via mailop]

On 2021-02-10 12:08, Andrew C Aitchison via mailop wrote:

On Wed, 10 Feb 2021, Dave Crocker via mailop wrote:

The much larger address space makes it too easy for a bad actor to 
jump around and, therefore, not develop a bad reputation associated 
with the address.  So non-history features are made more strict.


My recollection is that when IPv6 mail services started being available
the received wisdom here was that any IPv6 blocks (this was before
talk of reputation was common) should be at the /64 level (cf /32 in
IPv4) on the assumption that ISPs would give each end user a /64.

Is that still reasonable advice, if you *are* blocking or scoring
IPv6 addresses (presumably as well as domain/host names) ?



Unfortunately it is complicated by the fact that you can't count on IP 
allocations to happen at any particular subnet point, especially when 
you consider VPS environments, and similarly, providers will typically 
give out a new and larger range when you ask.


Given this, it makes it a lot harder to track any sort of negative 
history as you can assume a malicious sender will just jump to new IPs.

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

Re: [mailop] [E] Re: Some Days I think that Gmail isn't even trying to stop outbound spam..

[Dave Warren via mailop]

On 2021-02-08 16:14, Bill Cole via mailop wrote:

On 8 Feb 2021, at 17:03, Richard Bewley via mailop wrote:


The critical feature in '+' tagging (and equivalents using other 
characters or patterns) is the ability to create aliases on-the-fly in a 
namespace that the user controls such that the mail system handling 
delivery only needs to know the tagging pattern rather than every new tag.


In a previous life I had an email system that would sort tagged messages 
into a subfolder, but only for folders that existed. If a folder didn't 
exist the message would get rejected at SMTP time.


Not many users used it or grasped the concept of giving out a different 
address to each company, but the idea you could actually revoke a 
sender's ability to send to you just by deleting a folder was well received.


Since some companies didn't accept tags, we allowed a - instead, and 
t...@mailbox.example.com would get aliased to mailbox+...@example.com. 
But of course now users have even more possible addresses they might 
have given out, which increases confusion significantly for those who 
didn't really get how tagged addresses worked but tried anyway.



The "de-tagging" tactic that Al noted has existed, although I don't see 
much evidence of it in recent years. I think it may be that enough 
people who use tagged addresses give tagged addresses less scrutiny that 
senders who paid attention noticed that de-tagging hurts deliverability.


There is also the possibility to give anything missing a tag extreme 
scrutiny (or outright reject it) if a user is careful to never give out 
untagged addresses.


By definition there is no consent given to a sender who just makes up 
their own addresses (by stripping or changing tags), which is 
significant to any sender trying to operate on an opt-in basis.


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

Re: [mailop] [E] Re: Some Days I think that Gmail isn't even trying to stop outbound spam..

[Dave Warren via mailop]

On 2021-02-08 15:03, Richard Bewley via mailop wrote:

Only this weekend I was trying to help an old colleague with a migration from 
Gsuite to M365. The #1 complaint... was some of his minions were seemingly 
crippled by the lack of this function.. and I was thinking err aliases? 
Aliases?


You could always turn on + addressing on M365...

https://docs.microsoft.com/en-us/exchange/recipients-in-exchange-online/plus-addressing-in-exchange-online

Admittedly it is fairly new, and opt-in for reasons described on the 
link above, but it should be straightforward for a client moving in from 
another that supported plus addressing.

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

Re: [mailop] open RBL and RHSBL lists these days?

[Dave Warren via mailop]

On Mon, Dec 14, 2020, at 11:32, Mark E. Jeftovic via mailop wrote:
> Hey all, we're looking to deploy some user-configurable options in our mail 
> filtering such as being able to select which RBLs and RHSBLs they want to 
> apply to their inbound messages.

> We already subscribe to some on a system wide level (Abusix) but I'm 
> wondering which ones over and above are still a thing, ie. spamcop? etc?

> which ones are open or offer rsync or zone transfer ability if they want to 
> reduce load, and which ones are effective on general spam and malware 
> blocking with the fewer false positives.


I'm running a few... The ones I believe are defaulted enabled:

bl.spamcop.net, ix.dnsbl.manitu.net, bl.mailspike.net, z.mailspike.net, 
bl.spameatingmonkey.net, and noserver.dnsbl.sorbs.net.

However, none of these are outright blocking, all are feeding input into a 
scoring system which can result in the message being accepted, greylisted 
(mostly to wait and see if there are more DNSBL hits by the next attempt), or 
treated as spam.

In some cases a hit (spameatingmonkey.com's "Fresh" 0-15 lists) virtually 
guarantees a greylist while 15-30 puts them on a hair-trigger for greylisting.

I have a handful of others, some of the other sorbs.net, and a few smaller ones 
have a small impact. Make sure these are active before using them, and measure 
the results. My scoring is not necessarily well tuned at this point as I have 
been fairly hands-off, and I have a couple things that will turn a list off for 
me (like if they list a couple test addresses, including myself). 



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

Re: [mailop] [E] Google bounce after accept

[Dave Warren via mailop]

On 2020-10-30 08:25, Marcel Becker via mailop wrote:
On Fri, Oct 30, 2020 at 1:11 AM Atro Tossavainen via mailop 
mailto:mailop@mailop.org>> wrote:


Why does Google bounce after accepting a message? At Google's scale,
the potential to become the world's biggest spammer simply through
backscatter is enormous.


What do you prefer they do with that email if they determined it's 
malicious only after they accepted it?


A: Dropping it: Folks will complain about them "behaving like Microsoft"

B: Send it to the user (even spam folder): Users are not necessarily 
smart, they interact with phish mail in the spam folder; compromised 
accounts or worse


C: Bounce it back: It's legally the right thing to do, it's the right 
thing to do to protect consumers. Senders get annoyed.


I know what I'd do.


The problem isn't annoying actual senders, the problem is annoying me 
when I am not a sender or recipient, and instead am completely 
uninvolved in the transaction. There are other options.



D: Process and return real-time accept/fail after DATA when possible. 
When inadequate resources have been provisioned to keep up with load, 
note the hash of the item (attachment, message, whatever) and temp-fail 
it. If the hash is already on the list, send a temp-fail to the sender 
but queue it for scanning. Eventually the decision will be made and 
stored so that when the sender retries the message can be properly 
accepted/rejected at SMTP time.



E: Provision adequate resources to serve your customer base.


F: Stop accepting new customers until adequate resources have been 
provisioned.



G: Refuse to accept messages where the decision cannot be made 
immediately if there isn't valid SPF/DKIM validation of the bounce 
address. The rejection message can indicate that SPF/DKIM validation is 
required for this type of message. Combine this with D (only temp-fail 
if the sender cannot be validated, otherwise accept and queue).



There are still edge-cases, especially when there are multiple RCPT-TO 
addresses with different configuration but the information needed to 
make the decision isn't available until after the DATA command, or when 
the messages are queued for delivery to a customer's server... But 
things could be better.

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

Re: [mailop] This is..Concerning: DatabaseUSA Wins Case Against The Spamhaus Project

[Dave Warren via mailop]

On 2020-08-03 17:39, Jerry Cloe via mailop wrote:

It could also be argued as case law against other blacklist providers.


As I understand US law, defaults do not provide any form of precedent or 
other form of useful case law.


There might well be exceptions, of course.

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

Re: [mailop] Microsoft Outlook "Modern Authentication"?

[Dave Warren via mailop]

A bit late, sorry. 

On Tue, Jun 2, 2020, at 04:55, Ken O'Driscoll via mailop wrote:
> On Thu, 2020-05-28 at 13:35 -0600, Daniele Nicolodi via mailop wrote:
>> Does anyone know if there is any alternative to Outlook to access
>> 
>> Exchange Online mailboxes that require modern authentication?
> 
> Take a look at Davmail, it's basically a proxy that sits in-between your 
> existing "legacy" MUA and O365. It handles all of the MFA and talks EWA then 
> presents standards based IMAP, SMTP, CalDAV and CardDAV protocol interfaces 
> for your MTA to use.
> 
> I don't know if it will work for your specific environment but it works for 
> most people that what to continue to use Thunderbird etc. with Exchange.
> 

Thunderbird beta (78.0b2) supports M365’s OAuth2 support natively, no external 
shim required.

The setup is a little weird, you need to set up the account, go to the advanced 
settings (so that it creates the account despite not working), switch the 
authentication to OAuth2 for both IMAP and SMTP, it just works. ___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail Vacation responder replying to spam?

[Dave Warren via mailop]

Looks good from what I can see from here, thanks!

On 2019-05-07 12:31, Brandon Long via mailop wrote:

This should be fixed now.

Brandon

*From: *Dave Warren mailto:d...@thedave.ca>>
*Date: *Fri, Mar 29, 2019 at 4:40 PM
*To: * mailto:mailop@mailop.org>>

__
Thanks, sent off-list!

On Fri, Mar 29, 2019, at 17:09, Brandon Long via mailop wrote:

If you send me the header of a message we responded to, I can file
a bug.

Brandon

On Fri, Mar 29, 2019 at 3:53 PM Dave Warren mailto:d...@thedave.ca>> wrote:

I've had a couple users complaining about receiving a bunch of
unexpected bounce messages recently, since we filter bounce
messages pretty carefully I dug into it and the messages are
being pulled from Gmail accounts via our POP retrieval system
which bypasses bounce filtering. We don't get the original
spam by POP3, but we get the autoresponder and matching bounce.

I checked one of my own accounts and I'm seeing the same, I
have messages in Spam that generated a vacation responder.
Looking in my Sent folder (thank you Google for including
these in the Sent folder) I see about a dozen responses to
spam today, a few more yesterday (Mar 28), and then nothing
before that. The previous autoresponder was Mar 15, to a
legitimate message, while my spam folder has an average of 30
messages daily).

I suppose I could probably filter these out for users, but it
seems odd that Google has started sending vacation responders
to spam. I don't have any personal contacts at Google anymore,
any chance someone has a contact at Google that you could
forward this to?


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

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


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


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




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

Re: [mailop] The utility of spam folders

[Dave Warren]

On 2019-04-22 08:11, Michael Rathbun wrote:

Neither you nor your customer are customers of the freemail provider.


Agreed.


The provider has close to zero economic incentive to pay attention to your needs
and desires.  



I strongly disagree here, the freemail providers have a product (your 
eyeballs) to sell to their customers (the advertisers). Their customers 
aren't particularly interested in advertising on a service without users.


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

Re: [mailop] Gmail Vacation responder replying to spam?

[Dave Warren]

Thanks, sent off-list!

On Fri, Mar 29, 2019, at 17:09, Brandon Long via mailop wrote:
> If you send me the header of a message we responded to, I can file a bug.
> 
> Brandon
> 
> On Fri, Mar 29, 2019 at 3:53 PM Dave Warren  wrote:
>> I've had a couple users complaining about receiving a bunch of unexpected 
>> bounce messages recently, since we filter bounce messages pretty carefully I 
>> dug into it and the messages are being pulled from Gmail accounts via our 
>> POP retrieval system which bypasses bounce filtering. We don't get the 
>> original spam by POP3, but we get the autoresponder and matching bounce.
>> 
>>  I checked one of my own accounts and I'm seeing the same, I have messages 
>> in Spam that generated a vacation responder. Looking in my Sent folder 
>> (thank you Google for including these in the Sent folder) I see about a 
>> dozen responses to spam today, a few more yesterday (Mar 28), and then 
>> nothing before that. The previous autoresponder was Mar 15, to a legitimate 
>> message, while my spam folder has an average of 30 messages daily). 
>> 
>>  I suppose I could probably filter these out for users, but it seems odd 
>> that Google has started sending vacation responders to spam. I don't have 
>> any personal contacts at Google anymore, any chance someone has a contact at 
>> Google that you could forward this to?
>> 
>> 
>>  ___
>>  mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> ___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Gmail Vacation responder replying to spam?

[Dave Warren]

I've had a couple users complaining about receiving a bunch of unexpected 
bounce messages recently, since we filter bounce messages pretty carefully I 
dug into it and the messages are being pulled from Gmail accounts via our POP 
retrieval system which bypasses bounce filtering. We don't get the original 
spam by POP3, but we get the autoresponder and matching bounce.

I checked one of my own accounts and I'm seeing the same, I have messages in 
Spam that generated a vacation responder. Looking in my Sent folder (thank you 
Google for including these in the Sent folder) I see about a dozen responses to 
spam today, a few more yesterday (Mar 28), and then nothing before that. The 
previous autoresponder was Mar 15, to a legitimate message, while my spam 
folder has an average of 30 messages daily). 

I suppose I could probably filter these out for users, but it seems odd that 
Google has started sending vacation responders to spam. I don't have any 
personal contacts at Google anymore, any chance someone has a contact at Google 
that you could forward this to?


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

Re: [mailop] Office365 Eating E-mail

[Dave Warren]

On Sun, Mar 17, 2019, at 19:40, Mike Hammett wrote:
> Oh, I love focused. It works exactly as intended. I'll dig around in the 
> Office 365 I admin and then relay to the one with the problem where to look.
> 

You might, but to less technical users it is just another spam folder that they 
don't check. With that being said, I have started recommending to users that 
they enable it on mobile, but not on desktop so that the filtered stuff gets 
seen eventually.

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

Re: [mailop] Quick question on SPF...

[Dave Warren]

On 2019-01-26 16:24, Paul Ebersman wrote:

ebersman> And if the server doesn't give the same complete answer every
ebersman> time (regardless of order), it's technically violating the DNS
ebersman> RFCs.

dw> I'm not sure that this is really true from a client's standpoint.

dw> Just because you get a different answer from my authoritative server
dw> every time you query doesn't actually mean I am giving you
dw> incomplete answers, maybe I'm just changing the zone very very
dw> frequently?

Yes, if the zone changes. But assuming the same SOA for the zone, giving
a different answer for the same query is breaking the "rules".


Assume I incremented the SOA so many times it wrapped around and is back 
to the original number (because you can't prove it didn't, therefore 
your code can't make assumptions about the SOA even if you happen to 
have it available).


Besides which, the SOA serial shouldn't be used by anything other than 
primary/secondary implementations which rely on classic zone transfers.




Doesn't
mean it doesn't happen (there are all sorts of places we now do "stupid
DNS tricks") but it does violate the RFCs. And assuming you're not also
doing DNSSEC tricks, it breaks DNSSEC.

But getting back to the original topic, the point is that using things
like DNS round robin or trying to load balance by giving different
responses to the same question will tend to bite you in the ass because
you might not want to follow the rules but someone else in the DNS chain
might be strict.


Outside of DNSSEC, everyone else can be as strict as they want, they can 
either cache the result (within the TTL) or not (it doesn't matter).


(My understanding of DNSSEC is that you could make this work by signing 
the responses on the fly, but I could be wrong about this, I freely 
admit I am not up to speed on DNSSEC beyond signing basic zonefile based 
zones.)




In general, it's far more reliable for the app that is generating the
query to have any logic or load balancing or whatever built into the app
and not assume that the DNS won't ever surprise you.


Agreed. But in practice, it works well enough on the small scale.

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

Re: [mailop] Quick question on SPF...

[Dave Warren]

On 2019-01-24 09:29, Paul Ebersman wrote:

And if the
server doesn't give the same complete answer every time (regardless of
order), it's technically violating the DNS RFCs.


I'm not sure that this is really true from a client's standpoint.

Just because you get a different answer from my authoritative server 
every time you query doesn't actually mean I am giving you incomplete 
answers, maybe I'm just changing the zone very very frequently?


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

Re: [mailop] Expires SSL cert for mailop

[Dave Warren]

On Fri, Oct 26, 2018, at 19:29, Noel Butler wrote:
> Problem with letsencrypt is their preferred and insisted " certbot "
> - does not run (easily at least) on all flavours..> I gave up with it on 
> slackware which is what my servers run, tried
> using Crypt::LE and voila instant success, it was painless to use even
> for (tested at least) renews, although it requires a working webserver
> so come time to replace my comodo's on my MX's, will give me another
> challenge :)
https://letsencrypt.org/docs/client-options/ does recommend starting with 
Certbot, but it certainly makes it clear that there are alternative options: 
"If certbot does not meet your needs, or you’d simply like to try something 
else, there are many more clients to choose from below"
You also don't need to generate your certificate on the same machine
that hosts the services using the certificates. It can either increase
or reduce complexity depending on the particulars of your environment,
but I generate most of my certificates centrally using DNS based
authorization and either push or pull the certificates based on what is
appropriate.
It is an imperfect world, and this definitely applies to Let's Encrypt's
documentation, but I've had good success building on top of what is
already out there to get a custom solution when I don't see a perfect
cookiecutter fix.

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

Re: [mailop] GMail Delisting

[Dave Warren]

On 2018-09-11 11:00, Mike Hammett wrote:
Most platforms have a password per account. Not a password per 
account-service combination.


Yes, and?

This isn't an overnight switch or even possible on all platforms, but it 
is a viable way to move forward. Most of the major consumer platforms 
(Google, Outlook.com, Yahoo!, AOL, Apple/iCloud) and some of the larger 
hosted solutions (Office 365, G Suite, FastMail) are now either offering 
or requiring this approach.



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

Re: [mailop] GMail Delisting

[Dave Warren]

On 2018-09-07 15:09, Jay Hennigan wrote:

On 9/7/18 12:32 PM, Michael Peddemors wrote:


* Do you enforce 'tough' passwords?


Most formula-based "tough" passwords are only "tough" for the legitimate 
user, not an attacker.


Consider that with email protocols, this doesn't necessarily apply. 
While users may need to see/use/remember their webmail password, for 
IMAP/SMTP you can assign strong passwords instead of allowing users to 
set their own. Users may grumble a little at first, but the pain is 
short-lived and you are suddenly immune to password reuse, weak 
passwords and other types of attacks.


In my experience attacks against webmail are quite uncommon, and also 
can be mitigated with more flexible techniques than the SMTP protocol 
offers.



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

Re: [mailop] Bitcoin password ransom email from user at outlook.com

[Dave Warren]

On 2018-07-13 08:53, Mihai Costea wrote:

At the other side of the spectrum there are one off mails that go ignored due 
to the signal to noise ratio of the long tail.  There’s tons of folks with 
weird complains (from “I think Xbox live is too expensive” to suggestions on 
what billGates should do with his money, conspiracy theories, etc)


I realize it would be impossible, but were this feed published I would 
spend far too much of my life reading through it.


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

Re: [mailop] Bitcoin password ransom email from user at outlook.com

[Dave Warren]

Keep in mind that "no human will likely ever read..." does not mean that 
the mailbox is ignored. At this scale abuse handling is automated in one 
fashion or another.


I have no knowledge of what specifically Microsoft is doing.


On 2018-07-12 14:28, Eric Tykwinski wrote:

I really hope your wrong, since it's in their FAQs.
https://support.office.com/en-us/article/Deal-with-abuse-phishing-or-spoofing-in-Outlook-com-0d882ea5-eedc-4bed-aebc-079ffa1105a3

Reporting abuse

 If you're being threatened, call your local law enforcement.

 To report harassment, impersonation, child exploitation, child 
pornography, or other illegal activities received via an Outlook.com account, 
forward the offending email as an attachment to ab...@outlook.com. Include any 
relevant info, such as the number of times you've received messages from the 
account and the relationship, if any, between you and the sender.

I never rely on just emailing standards since I've noticed more and more form 
submittals, so I usually search first.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300


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

Re: [mailop] HELO *.*

[Dave Warren]

On Mon, Jun 11, 2018, at 13:27, Brielle Bruns wrote:
> Been seeing an awful lot of these lately on one of my email servers 
> (exim based):
> 
> 
> 2018-06-11 14:15:44 no host name found for IP address 157.25.104.90
> 2018-06-11 14:15:47 rejected HELO from [157.25.104.90]: syntactically 
> invalid argument(s): *.*
> 2018-06-11 14:21:42 no host name found for IP address 185.221.172.140
> 2018-06-11 14:21:43 rejected HELO from [185.221.172.140]: syntactically 
> invalid argument(s): *.*

How would you blacklist *.* in a system that uses DOS-similar glob wildcard 
blacklisting? Unless there is an escape character (unlikely), this is likely 
very difficult to handle for an unskilled admin, and certain platforms will 
make this more difficult.

The answer is  ?.? as most such systems do allow for "? matches exactly one 
character", but this is not particularly intuitive to a lot of less skilled 
admin types in the SMB/SOHO worlds.


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

Re: [mailop] Received header address information

[Dave Warren]

On 2018-04-18 17:49, Al Iverson wrote:

In the past I've had to deal with DNSBL listings based on faked
received headers-- IMHO, it's not safe to parse IPs beyond connections
that you yourself have verified.


I've always considered this a feature, not a bug. Spammer forges their 
way into getting caught by a DNSBL? Good.


Legitimate mail forges received headers and hits a DNSBL? They just lost 
their legitimate status by forging Received headers, so my sympathy is 
probably busy that day.


Am I missing a case where there is a negative outcome to a legitimate, 
by-the-book sender?


(Obviously this needs to be applied to very selective DNSBLs, carefully 
excluding lists of end-user gear and other "Does not send mail" lists 
since these senders did the correct thing and used a smarthost).



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

Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

[Dave Warren]

On 2018-03-01 16:26, David Carriger wrote:

Yes, I'm still seeing this. So, an open question:

As an ESP, how am I supposed to tell my users to practice good list 
hygiene and remove unengaged recipients from their lists when my data is 
being tainted by Google/Microsoft/etc triggering all of my engagement 
mechanisms (open tracking pixel, tracked links, etc)? These show up as 
their /most/ engaged recipients.


Obviously there are things that can be done on my end (look for all URIs 
in the email being triggered with a short time frame from IP ranges that 
we know do this behavior and don't count those as engagement), so I'll 
tread down that path with our developers. Still, I find it frustrating, 
and wonder how other people are dealing with this issue.


I don't know if this has already been discussed, but what's the 
User-Agent? Any clues there?


___
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?

[Dave Warren]

On 2018-02-27 21:17, Philip Paeps wrote:
You're posting as an alias in a domain from a server that's not 
authorized to send mail for that domain and isn't dkim signing for 
that domain, and posting to a public group in that domain.  It's kind 
of a spammy set of circumstances, but really it's the not great ipv6 
address with no auth that does it.


When this particular domain moved to GSuites, we talked (at length) 
about making sure those of us who run our own mailservers could still 
use it.  Turns out spf and dkim were never actually set up though.


I will chase that down.

Thanks again for helping debug this.


Don't forget to make sure that the G Suite side is also DKIM signing and 
that you've published these records properly.


(You probably know this, but I've seen so many clients screw it up that 
it is worth repeating... And re-checking that some eager-beaver DNS 
admin doesn't remove your older DKIM records when they add a new one).



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

Re: [mailop] VERP in 2018 (Was: RoadRunner Help?)

[Dave Warren]

On 2018-02-17 03:48, Stefano Bagnara wrote:

Unfortunately there are still some server accepting everything and
sending bounces without headers or malformed bounces.


This is not a small group. Every few months I get massive floods of 
bounces from some spambot that decided forging my domain is a good idea.


I didn't even realize this was still a thing when I was running my own 
mail server as I've used something similar to BATV for years. But after 
switching my personal to a host that doesn't use this technique I have 
begun to realize just how much garbage goes flying by out there.



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

Re: [mailop] [OT] Re: contact at telkomsa.net

[Dave Warren]

On 2018-02-13 03:33, G. Miliotis wrote:

Hi,

For a moment there I thought that there was a banner ad in your 
signature. May I suggest you make it animated, it'll be a lot more catchy.


That and I wonder what MimeCast pays for a sponsored email footer?


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

Re: [mailop] Anyone on this list from SpamCop?

[Dave Warren via mailop]

On 2018-02-06 16:34, Laura Atkins wrote:

Putting a URL in a List-Unsubscribe header is an entirely reasonable
thing to do, and lots of ESPs do it. 


Lots of non-ESPs do it, too.


Heck, I do it for virtually all automated messages, even on some 
internal stuff, basically anything that is automated results in the 
header being added at the MTA level.


Sometimes someone wanted notifications at one point and now they don't 
care, why not make it easy? If it's a true list, it'll get unsubscribed 
automatically but if it's not (e.g. "WordPress was just updated", you 
received a fax, etc), I'll see the unsubscribe request and talk to the 
user to figure out what they actually wanted to change and assist.



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

Re: [mailop] Mail Transfer Agent Alternatives

[Dave Warren via mailop]

On 2018-02-05 10:27, Marc Goldman via mailop wrote:
I received an email telling me I would need to pay RETROACTIVELY for the 
years I did NOT receive support in order to upgrade.


Has anyone ever heard of a policy like that?


What is cheaper, paying retroactively or buying a new license?

At $DAYJOB we charge about 30% (of a new license) to renew if you renew 
on time, or about 70% to buy an upgrade if you let your support lapse. 
We want customers to always get a better deal than jumping ship but it 
encourages ongoing revenue which is what allows us to have a new version 
to buy at all.


(This is an example/anecdote and not an offer, we're in the SMB email 
space, but not an MTA vendor).



On 2018-02-05 11:03, Steve Atkins wrote:

Yes, it's pretty much normal. It dissuades people from only paying for support 
every few years when they need support or want an updated version, while not 
paying the ongoing fees that pay for development of that updated version.


While this is true, the vendor is also not paying for staff to support 
the customer while the license is expired. I'd argue that some 
percentage other than 100% retroactive costs would be appropriate since 
the customer is only benefiting from the development but not from having 
support staff available.


At the end of the day though, as long as the cost doesn't exceed that of 
simply buying a new license, I can't get super excited about the details.



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

Re: [mailop] Heads Up

[Dave Warren via mailop]

On 2018-02-02 15:18, Michelle Sullivan wrote:

Charles McKean wrote:

On Sat, Jan 20, 2018 at 9:41 AM, Ken O'Driscoll via mailop
 wrote:

On Sat, 2018-01-20 at 11:14 +1100, Michelle Sullivan wrote:

One can only conclude, they either have a leak in their API, or they
altered the permissions to give out emails when specifically denied, or
they got hacked and didn't disclose it.

They had bug for over a year between ~2012-2013 where contact details
(including email) were unintentionally exposed.

Can't your friends see your email address on Facebook? Wouldn't that
mean that literally anybody could be responsible for leaking this
address?



No certain details (like email address) are 'Only Me' permission on my 
Facebook - because it (the email) is only used for Facebook login.


It also occurs to me that your Facebook login can be accessed by nearly 
anything that has permission to access your account, regardless of 
permissions on the email address itself, and in the past friends' apps 
might have been able to access your data.


While I don't recall the specifics, some years ago I had at least one 
app I used was able to show me some contact details of my contacts that 
weren't visible in Facebook's web interface. Who knows where that data 
has ended up.



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

Re: [mailop] Invalid address ratio?

[Dave Warren via mailop]

On 2018-02-02 10:47, Chris wrote:

On Fri, 02 Feb 2018 16:52:16 +
Ken O'Driscoll via mailop wrote:


On Fri, 2018-02-02 at 17:26 +0100, Chris wrote:

I'm a bit surprised, that on a small mail server, 77 % of the
rejected mails are rejected because of invalid recipient adresses.
22 % because of DNSBL.

Is this ratio normal?


Assuming you're talking about inbound emails and wondering why more
mails aren't being caught by RBLs.


Yes, inbound. I'm wondering why there are so many mails to
not-existing recipients.


Are they real messages or bounces? I'm currently seeing a few domains 
receiving massive floods of bounces, some spammer seems to be using 
$firstname$randomnumber@$variousdomain forged addresses to send tons and 
tons of spam. Nothing of the outbound message touches anything I 
control, it seems to be bot originated.


I own a couple domains that are being hit, one I can guarantee that I've 
never used addresses in that format and the other was used by various 
throwaway email addresses generated by multiple people. Both are domains 
I have owned for 10-15+ years, and I'm moderately comfortable saying 
that I am the first registrant in both cases.


It's been on and off for a few months but it seems to hit the same 
domains when it happens.


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

Re: [mailop] Anyone on this list from SpamCop?

[Dave Warren via mailop]

On 2018-02-06 10:12, Anne P. Mitchell Esq. wrote:


  


Also URLs in mail headers, which is perhaps reasonable, except that


...many ESPs now put unsub URLs in the headers.


Are the results any more harmful than the same unsub URL in the foot (or 
otherwise in the visible body of the message)?




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

Re: [mailop] Heads Up

[Dave Warren]

On 2018-01-21 09:40, Charles McKean wrote:

On Sat, Jan 20, 2018 at 9:41 AM, Ken O'Driscoll via mailop
 wrote:

On Sat, 2018-01-20 at 11:14 +1100, Michelle Sullivan wrote:

One can only conclude, they either have a leak in their API, or they
altered the permissions to give out emails when specifically denied, or
they got hacked and didn't disclose it.


They had bug for over a year between ~2012-2013 where contact details
(including email) were unintentionally exposed.


Can't your friends see your email address on Facebook? Wouldn't that
mean that literally anybody could be responsible for leaking this
address?


This is configurable at the user level.




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

Re: [mailop] Gmail forwarding blowback

[Dave Warren]

On 2017-11-08 12:20, Warren Volz wrote:

All,

One of my users has their account setup to forward mail to Gmail. 
Recently I've started to see lots of rejects that look like the following:


 (expanded from ): host
gmail-smtp-in.l.google.com[2607:f8b0:400e:c04::1a] said: 550-5.7.1
[ipv6 address 18] Our system has detected that
550-5.7.1 this message is likely suspicious due to the very low reputation
of 550-5.7.1 the sending IP address. To best protect our users from spam,
the 550-5.7.1 message has been blocked. Please visit 550 5.7.1
https://support.google.com/mail/answer/188131 for more information.
p26si2014836pli.781 - gsmtp (in reply to end of DATA command)

I've looked over the forwarding best practices provided by google and we 
are not modifying the envelope sender. I'd rather not start throwing 
away what our filter marks as spam since I leave that up to the user, 
but is that the only way to stop the bounces? Also, is the "18]" an 
artifact or some kind of error?


How good are your spam filters? One thing you can try is to only forward 
non-spam and dump the spam in the user's mailbox.


Next, have the user configure Gmail's POP3 account retrieval feature so 
that Google will retrieve the spam and add it to the mailbox. There will 
be some degree of latency for the spam to come through, but nothing gets 
lost.


It mostly doesn't matter if you deliver the non-spam into your local 
mailbox (and forward it) or just forward it as Gmail skips duplicate 
messages.




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

Re: [mailop] unique/shared public DKIM keys per domain?

[Dave Warren]

On 2017-10-10 08:20, John R Levine wrote:

On Tue, 10 Oct 2017, David Hofstee wrote:
Didn't Google mention they wanted the age of the keys to count in the 
spam

score?


I'll check but I would be surprised if it made much difference.

I rotate my keys every month, which seems to be more often than anyone 
else in the world. and they like my mail just fine.


(Anecdote, not data.)

I was rotating very frequently at one point, daily or better, primarily 
for testing. Once it was working, it was scheduled daily for while, then 
monthly.


There was no notable impact when I started, nor when I stopped either.


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

Re: [mailop] Gmail labeled as Spam based on content

[Dave Warren]

On Tue, Aug 1, 2017, at 13:48, Paul Witting wrote:
> Anyone from Gmail here? Hopefully I’m not off topic.


>  


> CEO was complaining about mail not getting to clients (not mail campaigns, 
> just day to day business). He sent a simple Subject: Test w/ Body Test (+ 
> signature) to his personal Gmail account and Gmail flagged it as spam based 
> on “content”. I duplicated it sending from my own account to my own account 
> (even included his signature) and it came through to my inbox, no issues. . 
> SPF and DMARC both passed on the original message. How is the message he 
> sends getting flagged as spam while the identical message I send gets right 
> through.
Gmail is far from the only provider to take knowledge learned from individual 
user activity into account when spam filtering. Perhaps your CEO has a habit of 
using Gmail's spam handling features to deal with legitimate mail, or has 
otherwise flagged a lot of similar messages as spam in the past?
While Google doesn't talk about the details, it seems that open and click rates 
are likely a factor too, perhaps the CEO sends a lot of stuff to himself that 
is deleted unread, Google may have decided this mail is less valuable for this 
recipient.
You can override using filters if needed.


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

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

[Dave Warren]

On Thu, Jul 27, 2017, at 09:05, Vittorio Bertola wrote:
> 


>> Il 26 luglio 2017 alle 19.10 Brandon Long  ha scritto:>> 
>> 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.> There is a standard 
>> explanation (literally) in RFC 7672, section 1.3, and especially 1.3.4.:> 
>> "Even if it were generally possible to determine a secure server name, the 
>> SMTP client would still need to verify that the server's certificate chain 
>> is issued by a trusted CA (a trust anchor).  
I've never understood why this is a special challenge in the SMTP world, it's 
generally a solved problem for HTTPS, XMPP, and various other protocols.
User-configured SMTP clients obtain a hostname from the user, using an 
incorrect hostname doesn't magically work, so adding one more validation test 
(certificate name matches hostname) doesn't seem onerous. Similarly, MX records 
with an incorrect hostname already don't work, so why would requiring a 
consistent mx.our-email-host.example. be used in MX records be a big deal?
The STARTTLS command could be extended to allow "STARTTLS hostname" (like HTTPS 
SNI), where hostname would indicate the requested certificate, allowing 
multiple certificates to be used without a single certificate listing every 
possible alternate name. This would accommodate large virtual hosters who want 
to offer every client their own mail.client-company.example without dedicating 
IPs to every client.
There would definitely be a transition period, and it would make suddenly 
renaming your SMTP server more of a challenge (at least in so far as 
maintaining secondary certificates), but these would have been more solvable 
problems had it been handled as STARTTLS was starting to take off rather than 
the current state of ignoring mismatching common names and assuming self-signed 
certificates are good enough (which implicitly means MITM attacks are not 
defended against).

> 
> MTAs are not interactive applications where a human operator can make a 
> decision (wisely or otherwise) to selectively disable TLS security policy 
> when certificate chain verification fails.  With no user to "click OK", the 
> MTA's list of public CA trust anchors would need to be comprehensive in order 
> to avoid bouncing mail addressed to sites that employ unknown CAs.> On the 
> other hand, each trusted CA can issue certificates for any domain.  If even 
> one of the configured CAs is compromised or operated by an adversary, it can 
> subvert TLS security for all destinations. Any set of CAs is simultaneously 
> both overly inclusive and not inclusive enough."
... So we therefore assume that every attacker has the resources to compromise 
or become a CA and just don't bother trying.
The CA system has it's flaws, but it's still better than "Trust every 
certificate implicitly". This just seems like a case of "We can't be 100% 
perfect, so we won't try".

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

Re: [mailop] btinternet.com blacklist

[Dave Warren]

That hetzner.de (or whatever host owns the equipment) is leasing 
hardware+connectivity in one bundle, and possibly the OS, leaving their 
customer is fully in control of the machine and the host has no day to day 
administrative duties or responsibilities. 

On Tue, Jul 18, 2017, at 16:52, Tim Starr wrote:
> Then what does "unmanaged" mean in this context?
> 
> -Tim
> 
> On Tue, Jul 18, 2017 at 1:28 AM, Dave Warren <da...@hireahit.com> wrote:>> __
>> As far as #2, because users of said servers often want to send email.>> 
>> 
>> On Mon, Jul 17, 2017, at 12:05, Tim Starr wrote:
>>> An overall admirable response, keep up the good work. Just 2 questions:>>> 
>>> 1) Why not put TLDR at top?
>>> 2) Why allow email to be sent at all from "unmanaged servers"?
>>> 
>>> -Tim
>>> 
>>> On Mon, Jul 17, 2017 at 7:44 AM, Hetzner Blacklist <blackl...@hetzner.de> 
>>> wrote:>>>> I just got back from a 2 week holiday and have been reading this 
>>> thread>>>> with a lot of interest. I thought I would respond and try to 
>>> explain the>>>> situation from our perspective. I could write an entire 
>>> essay on this,>>>> but I have tried to be as concise as possible, though it 
>>> is still a wall>>>> of text.
>>>> 
>>>> Am 11.07.2017 um 13:00 schrieb Felix Schwarz:
>>>> > If I'm not mistaken also Hetzner's mail admins are reading this list>>>> 
>>>> > so maybe
>>>> > they can convice their management to do something about the bad
>>>> reputation.
>>>> 
>>>> Management was convinced over a year ago. Our internal abuse 
>>>> processing>>>> and handling was reviewed, and made stricter. I will admit 
>>>> that we used>>>> to be too lenient in that regard, but that is no longer 
>>>> the case (at>>>> least not intentionally).
>>>> 
>>>> The results have been very encouraging. The leading blacklist and
>>>> reputation providers that have easy network/ASN lookups show a 
>>>> decrease>>>> of at least 60% in “bad” IPs within our network within the 
>>>> last year.>>>> This applies to Spamhaus, SpamCop, SORBS, UCEPROTECT, 
>>>> Senderbase (now>>>> Talos Intelligence) and the Microsoft SNDS. The amount 
>>>> of abuse
>>>> complaints we get has also decreased substantially. All of this, even>>>> 
>>>> though we are continually growing.
>>>> 
>>>> I’ve been in contact with a number of people this past year and many 
>>>> of>>>> them have acknowledged that our network no longer deserves a bad
>>>> reputation. However, I can fully understand that not everybody will>>>> 
>>>> agree, and I believe there are 3 main reasons for that.
>>>> 
>>>> 1) Historical. I wil be the first to admit that in the past we were 
>>>> too>>>> lenient with spam-handling, and there was more spam leaving our 
>>>> network>>>> than there should have been. This can mean that if somebody 
>>>> gets spam>>>> from our network today, they think "great, Hetzner hosting 
>>>> another>>>> spammer", even though the message was due to a compromised 
>>>> account (see>>>> point 2), and the overall amount of spam is much lower 
>>>> than it was>>>> historically.
>>>> 
>>>> 2) Constant spam. Due to the nature of our business (IAAS provider), 
>>>> the>>>> fact is that there will always be a certain level of spam leaving 
>>>> our>>>> network. Brandon actually mentioned exactly this.
>>>> 
>>>> Am 10.07.2017 um 21:37 schrieb Brandon Long:
>>>> > They may not even be renting directly to spammers, but their users 
>>>> > are>>>> > getting compromised and sending spam and other crap from their
>>>> servers.  We
>>>> > see clickbot and other fraud farming from those IP ranges as well.>>>> >
>>>> > It is an unfortunate situation, and challenging, no doubt.
>>>> 
>>>> We have over a million IP addresses, and the vast majority of those 
>>>> are>>>> allocated to unmanaged servers. Short of blocking all email
>>>> communication from our network, there are always going to be customers&

Re: [mailop] btinternet.com blacklist

[Dave Warren]

As far as #2, because users of said servers often want to send email.


On Mon, Jul 17, 2017, at 12:05, Tim Starr wrote:
> An overall admirable response, keep up the good work. Just 2 questions:> 
> 1) Why not put TLDR at top?
> 2) Why allow email to be sent at all from "unmanaged servers"?
> 
> -Tim
> 
> On Mon, Jul 17, 2017 at 7:44 AM, Hetzner Blacklist  
> wrote:>> I just got back from a 2 week holiday and have been reading this 
> thread>>  with a lot of interest. I thought I would respond and try to 
> explain the>>  situation from our perspective. I could write an entire essay 
> on this,>>  but I have tried to be as concise as possible, though it is still 
> a wall>>  of text.
>> 
>>  Am 11.07.2017 um 13:00 schrieb Felix Schwarz:
>>  > If I'm not mistaken also Hetzner's mail admins are reading this list>>  
>> so maybe
>>  > they can convice their management to do something about the bad
>>  reputation.
>> 
>>  Management was convinced over a year ago. Our internal abuse processing>>  
>> and handling was reviewed, and made stricter. I will admit that we used>>  
>> to be too lenient in that regard, but that is no longer the case (at>>  
>> least not intentionally).
>> 
>>  The results have been very encouraging. The leading blacklist and
>>  reputation providers that have easy network/ASN lookups show a decrease>>  
>> of at least 60% in “bad” IPs within our network within the last year.>>  
>> This applies to Spamhaus, SpamCop, SORBS, UCEPROTECT, Senderbase (now>>  
>> Talos Intelligence) and the Microsoft SNDS. The amount of abuse
>>  complaints we get has also decreased substantially. All of this, even>>  
>> though we are continually growing.
>> 
>>  I’ve been in contact with a number of people this past year and many of>>  
>> them have acknowledged that our network no longer deserves a bad
>>  reputation. However, I can fully understand that not everybody will>>  
>> agree, and I believe there are 3 main reasons for that.
>> 
>>  1) Historical. I wil be the first to admit that in the past we were too>>  
>> lenient with spam-handling, and there was more spam leaving our network>>  
>> than there should have been. This can mean that if somebody gets spam>>  
>> from our network today, they think "great, Hetzner hosting another
>>  spammer", even though the message was due to a compromised account (see>>  
>> point 2), and the overall amount of spam is much lower than it was
>>  historically.
>> 
>>  2) Constant spam. Due to the nature of our business (IAAS provider), the>>  
>> fact is that there will always be a certain level of spam leaving our>>  
>> network. Brandon actually mentioned exactly this.
>> 
>>  Am 10.07.2017 um 21:37 schrieb Brandon Long:
>>  > They may not even be renting directly to spammers, but their users are>>  
>> > getting compromised and sending spam and other crap from their
>>  servers.  We
>>  > see clickbot and other fraud farming from those IP ranges as well.>>  >
>>  > It is an unfortunate situation, and challenging, no doubt.
>> 
>>  We have over a million IP addresses, and the vast majority of those are>>  
>> allocated to unmanaged servers. Short of blocking all email
>>  communication from our network, there are always going to be customers>>  
>> sending emails, and thus there will always be some who send spam. Our>>  job 
>> is to minimize that as much as possible. Anybody who has worked an>>  abuse 
>> desk will know how hard that is, especially at an IAAS provider>>  like 
>> ourselves.
>> 
>>  We don’t intentionally harbor any spammers, and any that manage to get>>  
>> through our checks (we block dozens of new orders a day) and start
>>  sending spam, are soon terminated. We have a few email marketers, but>>  
>> the vast majority of the spam leaving our network is from compromised>>  
>> accounts, for which we can do very little.
>> 
>>  3) Perspective. As with so many things in life, what you think of
>>  something depends greatly on your point of view, and the assumptions and>>  
>> expections you (sometimes subconsciously) bring along. If somebody
>>  assumes that there should be zero spam leaving our network, they will>>  
>> always be disappointed.
>> 
>>  I believe a perfect example of these different perspectives is found>>  
>> within this thread.
>> 
>>  Am 11.07.2017 um 09:11 schrieb John Levine:
>>  > Hetzner gushes spam, and I've had most of their
>>  > IP ranges totally blocked for years.
>> 
>>  Am 13.07.2017 um 20:15 schrieb John Levine:
>>  > Look for yourself:
>>  >
>>  > http://www.taugh.com/sp.php?c==78.47.0.0=78.47.255.255=puavppaxru>> 
>>  First of all, thank you for that link John, I appreciate you sharing>>  
>> that information. It’s always good to have additional information about>>  
>> our network, and I will be checking that link regularly.
>> 
>>  I have no idea what assumptions John has, but the comment about
>>  “gushing” spam made me believe that the evidence would show a list of>>  
>> hundreds, 

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

[Dave Warren]

On Mon, May 22, 2017, at 18:59, frnk...@iname.com wrote:
> Just starting last week we started seeing our outbound queues fill up
> with undeliverable client messages generated because of this one-click
> unsubscribe feature.  Since this Apple feature has been in place for
> over six months, I’m surprised we haven’t seen this until now.
Is the problem iOS 10 doing something wrong, or is it just some
bulk mail sender has started sending mail with invalid
Unsubscribe information and users that try to unsubscribe are
generating queue noise?
I don't use the feature much myself on a day to day basis, but I did
monkey with it a bit when it first came out and it seems to work as
described.

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

[Dave Warren]

On Mon, Apr 10, 2017, at 09:15, Laura Atkins wrote:

> 

>> On Apr 9, 2017, at 11:00 AM, Jim Popovitch  wrote:
>> 

>> On Apr 9, 2017 13:07, "Anne P. Mitchell, Esq."
>>  wrote:
>>> This brings up a good point...back in 'the day' folks would report
>>> spam on NANAE;  is there a managed, moderated mailing list to report
>>> spam, that has the main ESPs and such on it?
>> 

>> SDLU ?

> 

> Reporting spam in public just makes it harder for the abuse desks to
> handle thing. If there is a working abuse desk, then abuse@ is fine.
> If there’s not, reporting in public is performance art at best.


As a counterpoint, transparency also makes it harder to dodge a failure
to address ongoing problems. I'm not suggesting this list is the place,
but it would be nice if there was some formal way to deliver public spam
reports and include the ESP's response.


Not that Twitter is appropriate as a replacement, but an example: when
I interact with a company's support team on Twitter I check to see if
they respond, and if their responses are useful. I'm left with a very
different feeling when they respond publicly and address issues vs
when 100% of their responses is "Contact us privately, don't air our
dirty laundry in public". I feel like abuse handling could benefit
from similar.


I understand issues of scale, I really do, but maybe senders shouldn't
be sending more mail than they're able to handle with their existing
staff, or they should staff up before making their abuse problem into my
abuse problem.

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

Re: [mailop] LOUDMOUTHS WANTED!! ICANN WHOIS Replacement Work URGENT IMPORTANT ACTION NEEDED

[Dave Warren]

On Sun, Mar 26, 2017, at 13:58, John Levine wrote:
> In article <20170326220333.3c517c48@quill> you write:
> >If I want to be able to give people information for being able to
> >contact me via the Internet, so that I can have a reasonable expectation
> >of being able to make sure that this will still work in 20 years
> >(provided I am then still alive and healthy enough to be able to use
> >computers), how would I do that without a second level domain of my own?
> 
> I know a certain number of people with e-mail addresses that haven't
> changed in 20 years, not at domains they own.  It's probably more
> than the number I know with 20 year old vanity domains, and I know
> a lot of vain old nerds.

20 is relatively extreme at this stage of the internet, largely due to
the fact that 20 years ago internet access wasn't as ubiquitous and the
situation has changed considerably. I lost my email address(es) of that
day because the provider(s) no longer exist (or in one case, ceased
selling email addresses outside of other services, so the price went
from $19/year to several hundred a year), after which point I bought a
domain and kept it since 2000. It's not my primary address, but I can
still be reached there just the same and this is important to me.

Not being a target of criminals is also important to me, and insisting I
publish a valid street address, phone number and email address increases
my exposure to criminals.


> But I can't help noticing that people keep trying to change the topic.
> Once again, nobody* has a problem with privacy protection for the
> small minority of domains registered by natural persons.  The problem
> is that the pro-crime crowd keep demanding that all the rest be
> anonymous or effectively anonymous, too.

Suggesting people who are interested in privacy are pro-crime is a bit
silly, and I would request that you do not attach derogatory labels just
because someone else happens to have a different opinion than you,
unless I am welcome to make up labels for you?


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

Re: [mailop] LOUDMOUTHS WANTED!! ICANN WHOIS Replacement Work URGENT IMPORTANT ACTION NEEDED

[Dave Warren]

On Fri, Mar 24, 2017, at 13:34, Neil Schwartzman wrote:

> *PLEASE JOIN THE ICANN GROUP* and help us fight back against people
> who are fighting *in favour* of crime.


Please also take the time to understand that your needs are not my
needs. I would be in favour of a WHOIS system that doesn't expose my me
(and my mom) to criminals calling, emailing, and occasionally mailing
the owner with fraudulent claims that something will be lost if I/she
doesn't take some action, or that she needs to sign up to a search
engine provider, or similar.


Decent spam filters can eat a lot of it, but far from all.



She's clever enough to sort out most of it, but it shouldn't be a
necessary part of being on the internet just to have her own single page
website and email address for her consulting business.


I understand the utility of the data, I do, but it's disingenuous to
suggest that only criminals would benefit from some changes here.

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

Re: [mailop] LOUDMOUTHS WANTED!! ICANN WHOIS Replacement Work URGENT IMPORTANT ACTION NEEDED

[Dave Warren]

On Sun, Mar 26, 2017, at 13:03, Norbert Bollow wrote:
> On 26 Mar 2017 00:20:17 -
> "John Levine"  wrote:
> 
> > Of course.  But the fraction of domains registered by natural people
> > is quite low.  And, of course, the claim that you need your own second
> > level domain to communicate on the Internet is ridiculous.
> 
> Depends on the time horizon.
> 
> If I want to be able to give people information for being able to
> contact me via the Internet, so that I can have a reasonable expectation
> of being able to make sure that this will still work in 20 years
> (provided I am then still alive and healthy enough to be able to use
> computers), how would I do that without a second level domain of my own?

Not only that, but if you don't want to put up with whatever any
particular provider feels like offering on any particular day.

Yahoo! may have been a reasonable choice at one point, but given their
complete inability to secure their service over the last few years, and
their reaction to the exodus was simply to disable mail forwarding.

Or maybe you went with a smaller provider like Fastmail.fm's free plans?
Oops, those are going away, you've gotta pay. Now maybe their prices are
reasonable (I think so, I'm writing this from my own domain hosted on
Fastmail), but if their prices go up tomorrow by 10x, and I still want
to maintain my contacts from the last 10 years, I can do so because my
name comes with me.

Personally, I think it's rather silly to not have a domain that you
control, as it puts you in control instead of relying on what one
particular vendor chooses to offer on any particular day; the risks are
the same whether you are using a free product or a paid product.


___
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

[Dave Warren]

On Thu, Mar 16, 2017, at 17:38, John Levine wrote:
> In article
> <1489684655.3176120.913642288.0d732...@webmail.messagingengine.com> you
> write:
> >You can make a rule against sending credit cards by email, but if
> >customer service reps know it works they might still encourage a
> >customer to do it as it's faster and easier than other options (fax,
> >mail) and when Something Bad Happens, the customer will rightly blame
> >the company.
> 
> So just out of nosiness, when's the last time Something Bad Happened
> in real life due to sending credit card info by e-mail?

I've seen companies get their merchant account shut down for storing
credit cards in email based ticket systems, this made for a Really Bad
Day at said company and for their customers.

With that being said, I personally have no problem sending my credit
card via TLS secured email. Yes, I will take the time to check that
their server supports STARTTLS, no I don't check to see whether it's a
secure set of protocols and ciphers. 

As was mentioned, the real risks are the database, POS systems and other
places where bulk collection can happen. I also lock my doors despite
the fact that one could simply smash the glass, reach through and unlock
the door.


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

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

[Dave Warren]

On Thu, Mar 16, 2017, at 07:37, Paul Smith wrote:

> On 16/03/2017 14:18, Kevin Huxham wrote:

>> they probably sell fax machines. 

> 

> Their response is a bit like someone sending them credit card details
> on a postcard, and them tearing it up (because you shouldn't send
> confidential information on postcards) and asking the sender to send
> the details again, but put them in an envelope next time.
> 

>  It's totally ignoring the fact that it's too late by then... (and the
>  fact that the envelope will be opened by the mail boy (Google in this
>  case) so the confidential information will still be visible by
>  unspecified eyes after arrival).
> 



While all of that may be true, it's still worth doing because it will
encourage better behaviour in the future.


You can make a rule against sending credit cards by email, but if
customer service reps know it works they might still encourage a
customer to do it as it's faster and easier than other options (fax,
mail) and when Something Bad Happens, the customer will rightly blame
the company.


By enforcing rules at a technical level you won't stop someone creative
from sending a credit card number, even if they have to go Craigslist
Style ("this 4000 is  my  credit  card"), but it will slow
people down and make doing it properly suddenly seem more attractive.


It's an imperfect world. 
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Spammers mining SPF records (of all things)

[Dave Warren]

On Sat, Mar 11, 2017, at 16:19, Rich Kulawiec wrote:
> On Sat, Mar 11, 2017 at 10:52:21AM +0800, ComKal Networks wrote:
> > I have noticed the scrapping of whois and dns records
> > appears to have increased dramatically over the past
> > 2 years.
> 
> Both of those are poor sources of email addresses, though: the
> duplication
> across many domains and the frequent use of role accounts means that even
> someone with WHOIS data for 100M domains may only have 30M valid
> addresses
> and half of those may be role accounts.  (Real data point pulled from
> some info I have on hand: 790876 domains, 309907 unique email addresses,
> about 125K of those using obfuscated registration, 3K "hostmaster" or
> "postmaster", 4K "admin", so roughly 200K or 25% viable spam targets.)
> 
> I'm not saying they're not doing it: of course they are.  I've done
> some manipulation of WHOIS and DNS records in order to track it, so
> I've got proof in hand.  I'm sure others do as well.  I'm just saying
> that it's not one of the more productive approaches.

In my very limited experiments there is far more WHOIS scraping than DNS
SOA scraping.

I get very little spam to an address that only exists as a SOA record,
far more to the WHOIS contacts, especially after registering a new
domain. I suspect ICANN's current process of requiring an address that
doesn't bounce makes WHOIS a richer source than it otherwise would be,
while SOA records are unlikely to be maintained by less technical users
(and are more likely to point to a provider who will simply disregard
the crap). 



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

Re: [mailop] Mails to microsoft

[Dave Warren]

On 2017-02-09 01:16, Paul Smith wrote:

I never understand why users won't just collect mail from the 'proper'
mail server rather than having to forward it all to gmail/hotmail. A
large portion of our support issues are to do with this forwarding.


In my experience, it's because Gmail/Hotmail/whatever offers a much 
better user experience. Whether it's the webmail interface or app 
experience, or just the consistent experience (vs their personal mail) 
varies depending on the user.


I agree that I find this quite annoying, but just the same, from an 
end-user's perspective, I can understand it, especially when said 
interfaces have the ability to send "From" foreign addresses (including 
using valid SMTP credentials, thereby avoiding SPF/DKIM failures).


Just the same, when someone chooses to treat an external service as a 
client, they should set it up like a client (pull via IMAP or POP, send 
via SMTP).




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

Re: [mailop] Forwarding issues, was Mails to microsoft

[Dave Warren]

On 2017-02-09 12:25, John Levine wrote:

I never understand why users won't just collect mail from the 'proper'
mail server rather than having to forward it all to gmail/hotmail. A
large portion of our support issues are to do with this forwarding.


Bad reason: setting up POP collection takes two minutes, while adding a
forward only takes 15 seconds.

Better reason: POP polling can add noticable delays to your mail, and
most places don't let you set the polling schedule.


While this is true, this is really on the Gmail/Hotmail of the world for 
not implementing IMAP with IDLE support to monitor for new messages.


Gmail is interesting here, while you can't set the POP3 polling 
frequency it does seem to take user activity into account and poll more 
often when you're active.


The hybrid "SMTP forward what you can, let POP3 pick up the rest" model 
works well with Gmail, but I haven't really tried other providers to 
know how or if it scales.





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

Re: [mailop] Odd spamcop glitch

[Dave Warren]

On Mon, Jan 23, 2017, at 17:57, valdis.kletni...@vt.edu wrote:
> 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?

It could just as easily be poor bounce-handling or an inability to take
no for an answer; politicians love to sell or otherwise distribute
addresses, even ones that have been explicitly unsubscribed and also
bounced for a substantial period of time.

My uninformed guess would be that someone got cute, imported a years-old
list from a past campaign as valid confirmed subscribers and got what
they deserved.

But maybe that's just my personal experience.


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

Re: [mailop] SORBS help

[Dave Warren]

On Sun, Jan 8, 2017, at 17:53, Jay Hennigan wrote:
> Having a bad credit score is 100% of your problem if you can't get a 
> loan, and 99% of the time your bad credit score isn't the fault of the 
> credit bureau. You earned that bad credit score (or RBL listing).

This is a good analogy though, as you can and should hold a credit
bureau responsible for errors if they're not promptly corrected upon
notification. 



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

Re: [mailop] Cloudflare not taking actions agains spamers?

[Dave Warren]

On Mon, Sep 5, 2016, at 23:41, Benoit Panizzon wrote:
> At least they could forward all spam complaints they receive to the
> hoster of the origin on the content. But in my observation, they don't
> do that.

Truthfully, forwarding complaints is a bit of a messy business as this
could easily forward to the abuser themselves. But, this should at least
be an option when filing a complaint, as should actually terminating the
abusive customer.




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

Re: [mailop] Spamcop Contact

[Dave Warren]

On Thu, Sep 1, 2016, at 02:16, Benoit Panizzon wrote:
> I used to discuss issues on their NNTP Server:
> 
> news://news.spamcop.net/
> 
> But it is down at the moment (or has it been put out of service? I
> haven't connected for a long time)

http://forum.spamcop.net/topic/14438-spamcop-groups-on-giganews/#comment-90960
suggests that it died some time ago. I've tried since then a couple of
times, without success, so I assumed that it was put out of it's misery
and removed it from my local config.



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

Re: [mailop] How many more RBL's do we really need?

[Dave Warren]

On Tue, Aug 30, 2016, at 15:22, Michael Peddemors wrote:
> On 16-08-30 12:43 PM, Michael Wise via mailop wrote:
> > We could use one to call out the location of colo servers that should never 
> > be connecting on port 443, for instance.
> 
> Um, I can think of a reason why that might not be perfect.. For instance 
> cloud services which monitor your email box for you..

Or web servers that shouldn't ever be calling out on 443, at least,
until we install a new gizmo that does and it doesn't work. Or my mail
server, which should never call out on 443, except that now we use
Cyren's spam/AV stuff, which does.

Still, it would be nice if there was a way to identify what type of
traffic/behaviour is expected of an IP, when a commercially run web
server starts attacking, it would be nice to know I can safely block 443
whereas I can't do that if it's a carrier grade NAT outbound IP.

Unfortunately I suspect maintaining such a list would be resource
prohibitive, and/or the data would be too low quality to be useful.


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

Re: [mailop] How many more RBL's do we really need?

[Dave Warren]

Worse still is the silent discards... It makes you beg for a "possible
spam detected". 

The BOFH in me has always wanted to adjust my rejection messages to show
the lowest scored DNSBL in the rejection message, then add a bunch of
useless, high-false-negative DNSBLs with trivially low scores just to
confuse senders, but I've never had the time or energy to implement it.
Plus, I'm not usually that much of a jerk.

On Tue, Aug 30, 2016, at 00:18, David Hofstee wrote:
> I for one welcome the explicit blocks of email. They tell me simply what
> is wrong so I can (let people) fix things. What I really hate is the
> "possible spam detected"-like messages. I don't have time to check all 40
> domains in the email and all IPs involved for those domains (and then
> usually not finding badness). I like to nitpick and find bad stuff, but
> that stretches it. Explicit blocks make my life easier.
> 
> So even if you weigh RBLs it would be nice to see the most important
> reason stated in the smtp reply. You could even change that behaviour
> given the reputation of the sender. 
> 
> Met vriendelijke groet,
> 
> 
> David Hofstee
> 
> Deliverability Management
> MailPlus B.V. Netherlands (ESP)
> 
> - Oorspronkelijk bericht -
> Van: "Anne P. Mitchell" 
> Aan: "Michael Wise via mailop" 
> Verzonden: Maandag 29 augustus 2016 19:08:58
> Onderwerp: Re: [mailop] How many more RBL's do we really need?
> 
> > using Barracuda's RBL for high scoring, and not for outright blocking.
> 
> I think that in this day and age, this is true for *any* list - black-,
> white-, reputation- (yes, even ours).  Whitelists can also have false
> positives - even pay for play ones, because while full-on spammers may
> not pay to be on a whitelist, or for reputation certification, etc, 
> organizations that are whitehat can experience personnel changes in their
> email and marketing departments, and an organization can go from
> blindingly white to a shade of grey overnight. 
> 
> Plus, even more now than ever, what one receiving system may think of as
> 'spam' another may think of as 'legitimate email our users just didn't
> know they wanted'.  In fact, that's why we take pains to make a point
> that our lists are *not* whitelists - they are lists where receivers can
> get information about the specific practices of the senders - so, like
> Rob said - use them for scoring, not for outright blocking (well,
> accepting, in our case).
> 
> Anne
> 
> Anne P. Mitchell, 
> Attorney at Law
> Legislative Consultant
> CEO/President, 
> SuretyMail Email Reputation Certification and Inbox Delivery Assistance
> http://www.SuretyMail.com/
> http://www.SuretyMail.eu/
> 
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
> Member, California Bar Cyberspace Law Committee
> Member, Colorado Cybersecurity Consortium
> Member, Asilomar Microcomputer Workshop Committee
> Ret. Professor of Law, Lincoln Law School of San Jose
> Ret. Chair, Asilomar Microcomputer Workshop
> amitch...@isipp.com | @AnnePMitchell
> Facebook/AnnePMitchell  | LinkedIn/in/annemitchell
> 
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


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

Re: [mailop] Null MX & Preference

[Dave Warren]

On 2016-07-18 04:45, Kurt Andersen (b) wrote:

We have certainly encountered some that do not support a '.' value.


DNS Made Easy's web UI is like this. I've used their secondary services 
for years, but recently I've been looking at their primary services and 
it's a sloppy mess of things that are valid but their UI won't permit.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



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

Re: [mailop] I trust my candor is appreciated...?

[Dave Warren]

On 2016-06-09 15:44, Michael Wise via mailop wrote:


These are hard issues to discuss, and I hope the view I present of how 
certain issues are viewed from behind the trenches of a large scale 
mail service are useful.


Sometimes, what scales and what doesn't are not obvious. But the 
comment on German law in particular is interesting, and ... Will not 
go un-noticed.


I am not a fan of Silent Drop, and continue to push for some other 
infrastructure and user friendly solution, but so far... It's a hard 
sell for many reasons.


It's a hard sell because your users blame me when they don't get a 
receipt, they don't blame you. If you could publish some sort of a "Yes, 
we drop your mail and won't tell the sender or recipient why" article, 
it would give senders a chance to point receivers toward it so that 
receivers could understand that the fault really is on their side of the 
line.


Either way, yes, your candor is greatly appreciated!

--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

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

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Dave Warren]

On 2016-06-09 12:23, David Hofstee wrote:
Same here, auto-unsubscribe presumed. The https is a nice addition 
that I will pass along. I hope that all implementations can handle 
https. Did people verify?


I treat it nearly as strict as a feedbackloop. All streams (of my 
customer X) to the recipient will cease permanently. I cannot expect 
Gmail (or others) to differentiate between specific permissions that 
my customer uses and filter accordingly.


As a user, I like the idea of a HTTPS page that shows all lists to which 
I was subscribed, clearly indicates that I have been removed from all, 
but also has a one-more-click to resubscribe to specific lists if I desire.


A bit more complex, and I think the user expectation is that you'll be 
completely unsubscribed from all marketing drivel with one click, but in 
cases where there are clearly differentiated lists, it's nice to expose 
that to the user and give them a chance to reconsider.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



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

Re: [mailop] signup form abuse

[Dave Warren]

On 2016-05-29 12:29, Rich Kulawiec wrote:

On Fri, May 27, 2016 at 11:07:44AM -0700, Jay Hennigan wrote:

>CAPTCHA could potentially fix it, but that is sure to raise
>objections as being too inconvenient for list operators playing the
>numbers game.

Captchas are also not a valid anti-abuse mechanism: they have been quite
thoroughly beaten and are only used today by those who have failed to
pay attention to adversarial progress over the last 10-15 years.

Resources are either targets for abuse or they're not; adversaries are
either competent and well-resourced or they're not.  In the case where
resources*are*  targets and adversaries*are*  competent/well-resourced,
they will defeat captcha mechanisms at will using either automated,
manual, or hyrid techniques.  In the other three cases, captchas aren't
necessary, either because the resource isn't being targeted, or adversaries
aren't capable, or both.


This is downright silly, it's akin to saying that one shouldn't bother 
locking their front door because a trained locksmith can pick the lock.


Yes, a captcha can be beaten, as can literally every other security 
mechanism if one imagines a sufficiently competent and well-resourced 
adversary. Most adversaries are not both competent and well-resourced, 
why not raise the bar against the low-level dull roar of attacks that 
happen all the time?


Security is a system of layers, never a single perfect mechanism and 
we're talking about mailing list subscriptions here, not missile launch 
codes; unless one's company depends on mailing lists, the overall 
resources available to combat a generally-minor problem will be equally 
minimal and a captcha will defeat the entirety of the types of 
adversaries which one can expect to encounter.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

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

Re: [mailop] signup form abuse

[Dave Warren]

On 2016-05-24 15:30, Michael Wise via mailop wrote:

If someone has a better idea how to keep mailinglist software like MailMan from 
being co-opted into such an attack, I would LOVE to hear it.


I think the obvious approach would be to move back to 
listname-subscr...@example.com requests, but require subscription 
requests to either have valid SPF, DKIM, or some matching of 
MX/rDNS/something to indicate it might be legitimate.


But of course this would require users to actually want to join lists 
enough to take action, and we can't have friction.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



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

Re: [mailop] signup form abuse

[Dave Warren]

On 2016-05-24 15:17, Jay Hennigan wrote:

On 5/24/16 12:26 PM, Michael Wise wrote:


We're still seeing cases where a malicious actor, typically in 
Eastern Europe, will try and sign up a target email address for 
thousands of lists all at once, flooding their mailbox with 
confirmation traffic , perhaps to hide some other nefarious issues.


I wonder what the point is. How does the bad guy monetize it, or is it 
a coordinated attack against a specific victim? What other nefarious 
issues? Making the address useless or burying some other mail in the 
midst of the junk would seem to be a possibility.


If an attack against a specific victim, it would seem that unconfirmed 
marketing lists would be a more effective weapon than a bunch of 
random confirmation messages. 


I could see this type of attack being useful when the bad actor desires 
to suppress a legitimate message. For example, if I were to spoof a 
message from the finance director to a subordinate to send corporate 
financial information out to a third party, I might want to disrupt the 
finance director's email temporarily to ensure that the subordinate's 
attempt to confirm the request is not seen.


I might do so again after compromising the corporate bank account so 
that wire transfer confirmations are not seen and acted upon in a timely 
fashion.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



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

Re: [mailop] Cisco PIX Mailguard Oddity

[Dave Warren]

On 2016-05-05 17:08, Todd Herr wrote:

Forgive me if this is off topic, but I don't know where else to turn.

I've got a customer who's having trouble sending mail to two domains 
with nothing obvious (to me) in common save for one thing; both 
domain's primary MXen look to be sitting behind Cisco PIX devices with 
Mailguard turned on. I know this because of the greeting I get from both:


220 ***

Now, everything I can find about these devices says that they only 
allow seven SMTP commands:​


​ HELO, ​
MAIL
​, ​
RCPT
​, ​
DATA
​, ​
RSET
​, ​
NOOP
​, ​
QUIT
​


And they're supposed to respond with OK to everything else. These two 
domains, again not obviously related, mail servers in different /8s, 
don't even do that, though; both of them are responding in

​ unsuspected ways even to commands from the above list, to wit:

RSET
500 Syntax error, command unrecognized
QUIT
500 Syntax error, command unrecognized
​

​ I've never wrangled one of these beasts (haven't even *seen* 
evidence of one in many years) so I'd like to ask you fine folks if 
you've ever seen anything like this​ from one of these, and what it 
means for their configuration? I mean, is this a common 
bug/misconfiguration, or have I just hit the lottery?




They're broken by design and not fit for purpose. Among their many 
flaws, they don't even make it to RFC821 3.1, the MAIL command, which is 
described as the following:


MAIL  FROM: 

Instead, when they receive a "M" in a packet alone, they interpret it as 
an invalid command and don't bother to parse the rest of the command. 
However, if you deliver the whole command in one TCP packet, they will 
accept it; This is patently stupid.


Although TCP won't generally break up such a short string into multiple 
packets there's actually nothing wrong with doing so and there's no 
requirement in RFC 821 to send each command in a single packet. It also 
makes troubleshooting difficult since telnet and similar tools often 
send each byte as you type it rather than waiting for the . If you 
can configure your tool to send whole lines, you'll run into other 
stupidity, but it will at least attempt to recognize commands.


Given that RFC 821 is from August of 1982, I would wholeheartedly 
recommend unplugging them until they catch up to at least 1984, or if 
that's not possible, at least disable the SMTP-breaking "feature". Even 
Microsoft published a how-to article on the topic: 
https://support.microsoft.com/en-us/kb/320027


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

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

Re: [mailop] Gmail rate limit

[Dave Warren]

I have the old one with 50 accounts. And "hobbled" might be a bit of an 
exaggeration, but I do run my own servers and I am used to having all 
sorts of flexibility :)


However, hobbled feels right since the features already exist, they're 
just... well...


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

On 2016-04-05 13:21, Brandon Long wrote:
Well, free edition should be limited to 5 accounts, but yeah, 
$300/year is pricey for consumers, no doubt about that.


And I wouldn't call Gmail hobbled, it's just more similar to the 
consumer version, doesn't add the bells & whistles of the paid 
version.  Though, when you're used to running your own server, not 
being able to do simple routing things feels really irritating.


Brandon

On Tue, Apr 5, 2016 at 12:51 PM, Dave Warren <da...@hireahit.com 
<mailto:da...@hireahit.com>> wrote:


I would, if I could pay for just the actual users. Sadly, I have
too many other things that need mailboxes and/or accounts for
other purposes and I just can't justify paying for each of them.

Instead, I just keep Gmail disabled and only use the features that
aren't hobbled.

On 2016-04-05 11:44, Brandon Long via mailop wrote:

I know I'm paying for full Google apps for my personal domain
after missing too many of these features.





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




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

Re: [mailop] Microsoft/GMail MX Priority Issues - mailop Digest, Vol 100, Issue 32

[Dave Warren]

On 2016-02-25 15:53, Mike Reed wrote:

Hi Brandon,

Does GMail publish a list of its outbound hosts/ranges some place to 
enable us to whitelist?




_spf.google.com.300 IN  TXT "v=spf1 
include:_netblocks.google.com include:_netblocks2.google.com 
include:_netblocks3.google.com ~all"


It's a lot of ranges, and I'm not sure if Google uses them all for mail 
today, but they well might tomorrow -- I don't see much point in 
greylisting mail from Google, other than perhaps to allow for URIBLs to 
learn of new hosts.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



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

Re: [mailop] Migration of mail client profiles from one system to another

[Dave Warren]

On 2016-02-23 05:52, Rolf E. Sonneveld wrote:

this may be slightly off-topic, but I wonder whether there's anyone on this 
list who has some suggestion re. the following 'problem'.

One of my customers is using a mail client (Outlook) with a number of profiles 
to access a number of IMAP (test) accounts. He has to 'clone' these profiles 
with all settings to other laptops on a regular basis, but has no Admin rights 
so he can't fiddle with the registry settings.


Why can't he fiddle with registry settings?

Admin rights are not needed to edit the registry, this is the whole 
point of HKEY_CURRENT_USER (and obviously if the user doesn't have 
access to the right parts of the registry, neither will Outlook have the 
ability to create or modify anything)



--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

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

Re: [mailop] ping DNSBLs

[Dave Warren]

On 2016-01-23 07:35, John Levine wrote:

RFC 5782 says that a live DNSxL does list 127.0.0.2 to show that it's
alive, and does not list 127.0.0.1 to show that it's not wildcarded.
We published that in 2010 but it was in draft form for quite a while
before that.  For IPv6 BLs, you list :::127.0.0.2 and don't list
:::127.0.0.1.  For name BLs, you list TEST and don't list INVALID.
You can't make everyone follow the rules, but I have to say that it's 
been a while since I've seen a BL that I care about that doesn't.


And conversely, if a DNSBL can't be bothered to follow simple standards 
or doesn't have the technical competence to avoid listing 127.0.0.1, is 
it worth caring about?


If a DNSBL lists an IP in a forest and nobody ever queries it, does 
anyone but NANAE care?


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



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

Re: [mailop] New method of blocking spam

[Dave Warren]

On 2016-01-22 19:24, John R Levine wrote:

What get's spammers caught is that eventually they
have to sell you something


Gee, did we drop through a wormhole into 1998 or something?


He's missing a few somethings.
Spammers might not be trying to sell you something.


No kidding.  The classic example is pump and dump, where they're 
trying to get you to call your own stockbroker to buy the stock 
they're touting, with no direct contact at all with the spammer.


Even with stuff like drug spam, the number of throwaway domains and 
redirections between the spam and the payload site is likely to be 
somewhat higher than someone might expect.  A *lot* higher.


While all of that is true, IF his claims were true (an idea could 
magically detect any spam trying to sell you something) would you walk 
away from a magic pill that completely and perfectly identified one 
particular type of spam and didn't hit any ham?


I don't think that this solution is that, but spam filtering has always 
been about multiple layers and approaches, some of which will excel for 
different types of spam, and combining the results of multiple filters 
and rulesets has, in my experience, always worked better than any one 
single approach.


Bayes is good at categorizing mail, but I don't think "Trying to sell 
something" is necessarily even a spam-sign, lots of legitimate and 
desired mail is trying to sell me something too. At the same time, 
everything I've read about this new method seems to be a slightly 
modified bayes approach (with the twist of taking word pairs or triplets 
into account) and I doubt it will be a real game changer, although it 
may result in some new ways to tune bayes to increase effectiveness.



--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



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

Re: [mailop] Delivery to gmail via IPv6

[Dave Warren]

And unfortunately the friendlier they are, the less useful they usually are.

The ugly ones are the only ones that are useful, but for whatever 
reason, it's beyond MTA developers to start with friendly messages with 
a "Troubleshooting information below" that contains a useful transcript.


As a techie, I appreciate the info, but the reality is that unless you 
expect the sender to take some action, transient error messages aren't 
usually useful. We've scaled back the transient failures that we send, 
at most you get a single transient and single permanent error, and even 
still, I question the value of the transient error since the user can't 
actually do anything (and nor does forwarding it to support@ help). Of 
course, we also allow users to view the SMTP queue for all messages 
involving their account for those who care, so that might skew my viewpoint.


I'm not a fan of the current trend of using permanent error codes in 
SMTP for what might well be transient errors (DNS problems, for 
example), but at the same time, as a sender, I don't see any value in 
retrying more than 24 hours.


It's tough to balance user expectations though.

--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

On 2015-12-10 10:43, Franck Martin wrote:
It also has to do with people not understanding DSN. Seriously they 
are ugly and hard to find the relevant information in them...






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

[mailop] List-Id

[Dave Warren]

Is it my imagination or did the List-Id header change? Is this 
intentional/permanent and/or should I update filtering rules?


Previously:
List-Id: For mail operators 

Now:
List-Id: For mail operators 



--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



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

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Dave Warren]

On 2015-09-10 04:45, Robert Mueller wrote:
Is there any evidence it's been useful in any way to help stop or 
identify spam?


No. But it's moderately good at helping identify when a message is from 
the sender it claims, and this is useful information.


I love that I can give users a one click "Allow everything from this 
address/domain" without giving a free pass to forged messages. And 
without having to guess at every outbound MX a sender uses today, and 
without having to maintain that list tomorrow.


SPF:PASS, valid DKIM, mail coming from the MX or a rDNS match all help 
identify whether a message is likely coming from an authorized sender, 
and if so, that can be useful information.


Similarly, if I get spam from @cotapmail.com (again), and it has 
SPF:PASS or valid DKIM, I known I can safely block the whole domain 
(whether future mail validates or not) and not have to care about losing 
legitimate mail, whereas it's not fair to block a sender because a 
spammer is forging their domain.


SPF's neutral, none, softfail and fail responses are mostly just noise. 
So is it useful? Yes. But does it stop spam? No.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Dave Warren]

  
  
On 2015-09-10 06:58, John Levine wrote:


  SRS was mostly useful as an exercise to confirm that the world is not
going to completely change how it works just because the FUSSP du jour
can't describe the way it's been sending mail for 30 years.


Personally, I'd rather have the bounces hit me rather than some
random sender who won't recognize the destination address that
actually failed. When a bounce hits one of my rewritten addresses,
my systems know to flag it and (eventually) disable the forwarding.

I don't actually use SRS, but rather, the BATV-like implementation
which rewrites the MAIL FROM field to something trackable.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren


  



___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Apple, iPhone setup, attempts SSL on port 587

[Dave Warren]

On 2015-07-30 18:33, Robert Mueller wrote:

A client with a new iPhone (not sure what model), attempts to setup
imap/smtp using starttls. As part of the setup, the iPhone apparently
probes the smtp server on port 587 with an SSL handshake:

Jul 29 21:31:34 ns1 sendmail[20641]: t6U4VYQL020641: rejecting commands
from 97-93-80-251.static.rvsd.ca.charter.com [97.93.80.251] due to pre-
greeting traffic after 0 seconds

Having dealt with lots of iOS users for many years, I find this really
surprising. I've never seen an iOS device do this before. It does appear
to be SSL/TLS traffic, but I'm really surprised it was sent to port 587.

Are you absolutely sure this is happening on port 587? Is there anything
else logged before or after this from the same IP (maybe get a tcpdump)?
Does it actually attempt plaintext + STARTTLS upgrade after the direct
TLS/SSL connection fails?


What domain? It's possible that there was some autodiscovery DNS records 
(or hard-coded server names in Apple's database) that is misconfigured.


(Although truthfully I'm not sure Apple tries much for IMAP/POP and SMTP 
configuration, it might only actually try to auto-detect specific known 
providers and Exchange/ActiveSync accounts as autodiscovery tends to be 
more common on these platforms)


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop