Re: [mailop] Mailserver accepts ssl/tls only

[Paul Smith* via mailop]

On 18/07/2024 13:36, Jeff Pang via mailop wrote:
Can I setup mailserver to accept messages via sdl/tls only from other 
MTA? How to disable peer MTA send me plaintext mail?


You can certainly do that. But don't be surprised if some other mail 
servers can't send mail to you.


Why would you want to do this?

Note that you cannot control what happens before the mail gets to you.

So, even if you only accept mail using TLS, then the message may have 
gone: User -> MSA (no TLS), MSA -> ISP (no TLS), ISP -> content filter 
service (no TLS), content filter service -> you (TLS). It *probably* 
won't, but you have no control, so it's perfectly possible for it to 
have done so.


Also, note that even if TLS is used for all transmission paths, the 
unencrypted messages are theoretically available to anyone or any 
software with access to any of the mail servers that the message has 
passed through.


If you're concerned about message privacy, you need to use end-to-end 
encryption (eg PGP or S/MIME).


Paul


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

Re: [mailop] Why an SPF hard bounce on ~all ?

[Paul Smith via mailop]

That would be an SPF fail, but the sender
domains are ~all

Why the hard bounce?


It's entirely up to the receiver what they do with a message.

If they've decided to hard fail messages with soft SPF fails, that's their 
choice...



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

Re: [mailop] DKIM / slippery slope gmx.de

[Paul Smith* via mailop]

On 18/12/2023 10:18, ml+mailop--- via mailop wrote:

And it seems none of the extra requirements do anything against
spam, because the spammers can (and do, see above) easily implement
all of those.


DKIM (and SPF) aren't anti-spam measures, and have never been promoted 
as such. They're anti-forgery measures.


Spam filters handle reputation of things. One thing they can do is track 
reputation of sender domains. When forgery is possible, then that means 
that spammers can piggy-back on the good reputation of big companies 
like Google, Amazon, etc. They send mail pretending to be from 
someth...@amazon.com. There's no reliable way for the recipient to know 
that it's not actually from Amazon, so the recipient has to either:


- let the mail through (because it says it's from Amazon, so must be OK) 
- damage the reputation of Amazon (because spam comes from amazon.com) - 
or don't use the sender domain for reputation tracking, because it's 
unreliable


The first two options are obviously bad, and the third takes away a big 
tool from the anti-spam arsenal.


When you have SPF and/or DKIM, then you've essentially prevented forgery 
(yes, you may have introduced other problems, but that's by-the-by). So, 
it's irrelevant that spammers can implement these features - that's 
actually good - the spammers can't use a trustworthy sending domain to 
try to trick spam filters, so the spam filter can track the reputation 
of the REAL sending domain, and spammers get punished and the 
trustworthy domains (theoretically) don't.


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

Re: [mailop] outlook.com 421 try again later S77719

[Paul Smith* via mailop]

On 11/10/2023 10:12, Andreas via mailop wrote:



since a few hours we have problems with sending to Microsoft. We get 
hundreds of messages like in the subject with the reference to S77719. 
Also colleagues from other companies in germany are seeing the same in 
their logs. All mails that are blocked here are from Microsoft 
customers, but they are redirected through our servers.


Yes, exactly the same thing here. I was worried it was something we'd 
done, but it appears to be a bit more widespread


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

Re: [mailop] outlook.com 421 try again later S77719

[Paul Smith* via mailop]

On 11/10/2023 10:48, Urban Loesch via mailop wrote:

Hi,

same here in north Italy.
Also users on Reddit encounter the same: 
https://www.reddit.com/r/sysadmin/comments/1755npg/anyone_else_seeing_outlook_mail_delivery_problems/



That points to an issue in the M365 admin -> Healt -> service status 
section where this is mentioned


"

EX680695, Last updated: 11 October 2023 at 11:51 BST
Estimated start time: 11 October 2023 at 01:00 BST

More info: Affected users may see a "451 4.7.500 Server busy" error 
message. Current status: We’ve identified that specific IP addresses are 
being unexpectedly limited by our anti-spam procedures, causing inbound 
external email delivery to become throttled and delayed. We're reviewing 
if there have been any recent changes to our anti-spam rules to 
understand why the IP addresses are being limited. In the meantime, 
we're manually adding reported affected IP addresses to an allowed list 
to provide immediate relief."


They're manually adding IP addresses... Sounds a fun job. Just got to 
work out how to report them now



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

Re: [mailop] Guide for setting up a mail server ?

[Paul Smith via mailop]

On 14 July 2023 18:24:45 Dave Crocker via mailop  wrote:


We need to 'encourage' people to run their own mail servers, not scare
them away..


We also need to encourage people to do all the servicing for their car,
to build their own house, and to grow their own food.

Or we might take a somewhat more modern view of life and deal
pragmatically with the realities of the division of labor.


But if someone *wants* to set up a mail server, we shouldn't put them off 
unnecessarily.


Or would you put someone off growing vegetables in their garden as well?

If someone says "I want to receive email", then suggesting they set up 
their own mail server may be inappropriate, but that's not the case here.


Paul

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

Re: [mailop] IP to country?

[Paul Smith via mailop]

Try

https://dev.maxmind.com/geoip/geolite2-free-geolocation-data

On 24 April 2023 16:54:33 Mary via mailop  wrote:


Hello,

Is there a place that provides IP to country location information for free?

Preferably in CIDR format. I am not interested to query a service, I am 
interested to block whole countries at the firewall level. Maybe, refresh 
the data once or twice a year, not more.


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


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

Re: [mailop] How do I break Gmail forwarding?

[Paul Smith via mailop]

The worse thing is with forwarding of non-geographic phone numbers... 
(0345,etc, in the UK). We've had people ring us when they were trying to 
get through to the tax office, ambulance service (not 999), etc, etc. It's 
pretty much impossible to fix that. The dialer is calling the correct 
publicised number, but the NGN is configured to redirect to us, instead of 
the correct number. It seems like we're one of a pool of numbers, so if the 
caller retries, they often get through to a correct person.


You try and get hold of the person whose job is to set up the phone 
forwarding to tell them they've typed a number wrong!


You can't block it either, as the forwarding isn't signalled in any way.

Paul

On 24 October 2022 14:59:32 Tara Natanson via mailop  wrote:
Yup, I do have a way to filter.  I just thought it was an interesting 
problem that the recipient of a systematic forward is not able to stop the 
forwarding of the mail.


Tara


On Mon, Oct 24, 2022 at 9:43 AM Sebastian Nielsen via mailop 
 wrote:



Im not talking if you know the address.

Im talking if the address is present somewhere in the forwarded email.



That’s a fundamental difference, because if you know the address, you 
cannot do so much to it, but if its present in the actual mail somehow 
(header, etc) you can write a filter to dump the crap into the trash.




Från: Tara Natanson via mailop 
Skickat: den 24 oktober 2022 15:30
Till: Sebastian Nielsen 
Kopia: Mailing List 
Ämne: Re: [mailop] How do I break Gmail forwarding?



Yes I know the address  @gmail the messages are being sent to.  I do not 
control that gmail inbox though.




Tara



On Mon, Oct 24, 2022 at 9:23 AM Sebastian Nielsen via mailop 
 wrote:


Does the MAIL FROM (Sender header) contain the gmail address?

Does the MIME From contain the gmail address?



Check the headers if the gmail address is SOMEWHERE there.

Then you could put a rule to block such mails.





Från: Tara Natanson via mailop 
Skickat: den 24 oktober 2022 15:09
Till: mailop 
Ämne: [mailop] How do I break Gmail forwarding?





At some point someone set up a gmail address which forwards automatically 
to our postmaster address.  Yes I realize someone had to have clicked 
something to allow this to happen (multiple people monitor the box).  But I 
cannot undo it.  I do not control the original mailbox the mail is being 
forwarded FROM.




Anyone have any tricks I'm missing?



Tara Natanson

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

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

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




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Reject vs spam folders

[Paul Smith via mailop]

On 15/09/2022 22:51, Jaroslaw Rafa via mailop wrote:

I already described what I think is best. Only *mark* messages as spam and
let the users decide if they want *themselves* filter the marked messages
into the spam folder. Don't *preconfigure* such filtering for them.


OK. I'm sorry for casting aspersions.

I agree with the option to mark messages as spam - but if it's the 
default, then you can guarantee that as soon as someone receives around 
10 spam messages a day, they will implement a filter to move/delete 
them. At which point, the only advantage of not having the junk folder 
as the default is that someone's YouTube tutorial video has got a few 
million more views, but you've also got lots of users who're slightly 
annoyed at having to watch the video, or an IT team who are very annoyed 
at having to implement filters on hundreds of users' PCs.


Unfortunately, there is no good answer that will apply to all users, 
giving a user various choices is the best we can do.


Paul


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Reject vs spam folders

[Paul Smith via mailop]

On 15/09/2022 21:30, Jaroslaw Rafa via mailop wrote:


folders. If it actually worked this way, spam folders wouldn't be any issue.
But this assumption failed: the reality is that 99% of users don't check
their spam folders at all, so directing a message to spam folder effectively
equals blackholing. The sender needs to communicate out-of-band anyway to
ask the recipient to check their spam folder.


Similarly, it can be argued that "99%" of senders don't check NDRs or 
don't use them to try to contact the recipient another way, so rejecting 
a message is functionally equivalent to blackholing as far as the 
recipient is concerned.


Arguing that "a rejection is better" makes sense *when the sender is 
human, technically competent and understands how email works*. Most 
senders don't fall into that category.


It may be argued that the sender knowing a message was rejected is 
better than them not knowing. But, for the recipient, a spam folder is 
much more useful than a rejection for messages sent by those "99%" of 
senders.


If someone asks for a password reset email, there are two options:
- the website pops up saying "we've sent you a message. If you don't 
receive it, check your spam folder". There's a reasonable chance of 
resetting your password today.


- the website pops up saying "we've sent you a message. If you don't 
receive it, open a ticket with whoever administers your email (which may 
be a faceless person at a service provider) and ask them to whitelist 
mail from our domain, wait 2 days for them to respond. Hopefully, they 
will approve that whitelisting, but if they don't, then tough. If they 
do approve it, then request a password reset email again. We hope your 
requirements weren't urgent. Have a nice day!"


Which do you think users would prefer?

Paul


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] The oligopoly has won.

[Paul Smith via mailop]

On 14/09/2022 15:49, Thomas Walter via mailop wrote:
If I send someone an email and get a reject, I know they didn't 
receive it. It's my job to make sure they get the email then or 
contact them using other means.


That only works if someone reads, and acts on, delivery failure reports.

When you ask for a 'password reset' from a website, and it gets filtered 
as junk, I can 99.% guarantee that no one looks at the bounce 
message from that rejected email.


Similarly with booking confirmations, etc, etc.

*Maybe* with a personally sent message, the sender will notice a 
delivery failure report, but, from my experience of 'normal users', (a) 
that likelihood is probably in the very low percentages, and (b) it's 
even less likely that the sender would know what to do then.


With a junk box, at least the user has a way of getting at the message. 
If the message is rejected outright, you can pretty much guarantee they 
will NEVER get the message, unless the sender is very au fait with email 
systems.



I look through my spam filter report once a day. It takes me literally 
about 5-10 seconds to scan. Maybe once or twice a month there's a 
legitimate message in there.


If the messages were delivered to my Inbox, then it'd take a lot longer 
than that



Paul


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Paul Smith via mailop]

On 3 August 2022 23:43:36 Taavi Eomäe via mailop
You can't consider it a lie if nobody is asking the question in the first 
place. Gmail might show when an email was delivered in plaintext as 
insecure it does not display transport-encrypted emails as secure. What 
displays transport encryption as  "secure"?


The (very important) thing is that NO email can be considered "secure" 
unless it is end-to-end encrypted (eg PGP), without any third party service 
knowing the encryption key, or you personally know and trust all the mail 
administrators of all the mail servers involved.


By definition, if you're reading an email on Gmail (or Outlook.com, 
Yahoo.com, etc), it is *not* secure. If your email has passed through your, 
or the recipient's ISP's mail server, or a spam filtering service, or a 
random MTA, it is not secure unless it is end to end encrypted.


Any suggestion otherwise that an email is "secure" is false, even if it's 
been transmitted over all hops using TLS1.3


It is *arguably* more secure to transmit using TLS1.2 than TLS 1.0. It is 
definitely more secure to transmit using TLS 1.0 than plain text


Attacks against TLS1.0 work using HTTP. I am not aware of any viable attack 
method which can be made using SMTP


Paul



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Interesting question from a team member, MX chaining, list-manage.com

[Paul Smith via mailop]

On 01/07/2022 09:52, Laura Atkins via mailop wrote:



It has a single MX record pointed at:

mail.admin.mailchimp.com <http://mail.admin.mailchimp.com>

That hostname exists, but it doesn't have an A RECORD.


Again, what’s the problem? Not every mailserver needs to have a 
corresponding website.


Normally, an MX record would point to an A record.

A records are not exclusively for websites, they have many other uses. 
For instance, *ALL* mail servers intended for incoming mail using the 
standard SMTP system must have an A record pointing to them.


Without an A record here, mail to b...@list-manage.com has nowhere to go.


If you don't want to accept mail for a domain, usually, you'd accomplish 
that by simply not having an MX record. Having an MX record which points 
nowhere is odd, but not illegal - it just means that mail is undeliverable.






It in turn has just a single MX Record.

inbound-mx1.mailchimpapp.net <http://inbound-mx1.mailchimpapp.net>

Kind of a strange MX delegation.. I assume to avoid CNAME's

But it does seem very strange.  Comments anyone? I didn't have an 
answer for him..


What’s so strange about it?


'mail.admin.mailchimp.com' having an MX record is fine, it means that 
mail to 'b...@mail.admin.mailchimp.com' has somewhere to go.


But it doesn't mean that mail to 'b...@list-manage.com' has anywhere to 
go. You can't chain MX records like that.



Paul


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Understanding specific issue with from header field in google bounce reply

[Paul Smith via mailop]

52cbna8kydvLENQgQtChAJ8MhPXbXvhZAyklffRAwX31WV
Y5lWjWxuGSRuxRfiiXKDnS3cS+VcIvEFMphhKzy27dJ+eI97x1+KvbnG5YE5enyccp7RH4WQio3u
Ga0qZK6eP2yJPYHuIR7M4/shEWyJzIkwSFAW0Pw8uiKeltK+MtP+Q+MOaQQT+Vn8BIlSPGIn6LIh
6vfZt6Tuc+uVfVL7ygxIxIEhQBgsu7ia6J1fhOzjF0b4LXcjJZ5loquXN5jFSCbczMwQYmA5Fgmk
3lS1t6QdEPz08qMKOQH7dKFTuGZxy4YnIveHBkunQM3tbGkpI7MoUuyldIYotCoZ2o2u/CrAXLOd
WYnYEYBY7yFM015AwIoiYphoS1BbksZFIaiNfA1zBMRlEGhUgk1m29ZSQVhuDL+eB599vr8wv9JV
jn9o4RbEfAAaUi4E6ZotLE92++nhcRkxchgMy3wccBIk1Sag4dKiqCrF8eZZ6QJJezUWPaFxkAYK
LAdXMiInFuivqX43I6n3Msjvp21riINHgmmecAYSEJNZL831ZtvWUkFYbgy/ngeffb6/MCvyXVr4
HdvxYmxHTDNCZ8bv1XAEUSSYNAj1RlxWAO8Qse0lmQaXQFAK5/0rdNGhms0k82NhtXl7s69uM9s5
/Cb06J8uG+dikNJv32G4gfdf
X-Report-Abuse-To: s...@quarantine11.antispamcloud.com
X-Exim-DSN-Information: Due to administrative limits only headers are returned

Regards
Alexander

Alexander Neilson
Neilson Productions Limited

alexan...@neilson.net.nz
021 329 681022 456 2326
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Who Do You Recommend for Small Business Regular (Non-Bulk) Email?

[Paul Smith via mailop]

On 03/03/2022 23:13, Bill Cole via mailop wrote:



(or is that a pipe dream?)


I am just guessing that you also need it to be price and 
feature-competitive with 2 of the world's largest tech behemoths too? 
That is the big challenge.


I cannot in good conscience recommend either of the mailbox hosters 
that I work for (or any of their non-behemoth competitors) broadly for 
small businesses. That's not just because I'm a terrible 
marketer/salesman: neither one is chasing new mailbox business 
independent of other services.



I agree with all this. I had considered recommending ourselves, and had 
an email all prepared, but decided not to send it, because it probably 
wouldn't be worth the hassle. Our main reason for supplying email 
hosting is for customers of our other products so they don't have to 
deal with bad email hosting elsewhere (it actually reduces our support 
costs for our other products). We make very little money on email 
hosting, and once people start wanting personalised support, that wipes 
out the small profit margin, plus more. Microsoft & Google, etc get away 
without giving good support because people don't expect it from them. 
They do expect it from smaller companies, even though they're not paying 
much more.


I expect many of the smaller email providers are in the same boat.

Paul


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Feasibility of a private DNSBL

[Paul Smith via mailop]

On 03/11/2021 09:42, Nicolas JEAN via mailop wrote:


Unfortunately, it seems that it would require modifications to e.g. 
postfix, or other software, in order to add that identifying string to 
the DNS query.
Still an idea to keep in mind. Because of how DNS works, the source IP 
address isn't available anyway in a usual, unmodified postfix DNS query.


Why would it need modifications? It's for a DNSBL, not general DNS 
queries, so you have to tell Postfix the DNSBL to use anyway.


So, rather than saying 'check the DNSBL called myspamblock.com', you 
'check the DNSBL called hegr27dm31.myspamblock.com' (where 'hegr27dm31' 
is the 'secret key')




--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP AUTH harassment

[Paul Smith via mailop]

On 17/07/2021 21:13, Slavko via mailop wrote:

Please, i want ask others if are these (mostly) Brasil attempts know to
others too or am i "special" target?


In case you don't know about it already, have a look at 
https://www.abuseipdb.com/ . Some people have scripts to report things 
like auth abuse here, so you can see if IP addresses you're getting 
attacked by are attacking others.


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Help debugging an outlook.com reject

[Paul Smith via mailop]

On 27/05/2021 13:14, Fernando MM via mailop wrote:
I'm experiencing a similar problem. Did you get a reply or found 
a solution?


The IP is only used to send invoice emails to customers. Basically 3 
lines of text + attached pdf. Very low volume ( less than 1.000 
invoices per month are sent to @outlook.com <http://outlook.com> ).


Very low volume senders can have problems  because they have limited 
data to build reputation statistics on.


Emails consisting of almost no text with an attachment are also a bit 
suspicious so could be junked by the recipient, and, along with the very 
low volume, that could trigger blocking.


I don't know what the text is, but could you make it more personalised, 
so the recipient can be more certain it's not phishing?


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] paypal.com issues

[Paul Smith via mailop]

On 20/05/2021 15:40, joemailop--- via mailop wrote:

Maybe it was a temporary issue?

Right now I only see one entry -

dig paypal.com txt | findstr "spf"
paypal.com. 3444IN  TXT "v=spf1 include:pp._spf.paypal.com 
include:3ph1._spf.paypal.com include:3ph2._spf.paypal.com include:3ph3._spf.paypal.com 
include:3ph4._spf.paypal.com include:3ph5._spf.paypal.com ~all"


Yes, it looks OK now. I did check it earlier when I saw Javier's 
message, and I got the two SPF records as well


[C:\temp]dig txt paypal.com

; <<>> DiG 9.17.0 <<>> txt paypal.com
...
paypal.com. 3548    IN  TXT "MS=ms95960309"
paypal.com. 3548    IN  TXT "v=spf1 
include:pp._spf.paypal.com include:3ph1._spf.paypal.com 
include:3ph2._spf.paypal.com include:3ph3._sp

f.paypal.com include:3ph4._spf.paypal.com include:3ph5._spf.paypal.com ~all"
paypal.com. 3548    IN  TXT "v=spf1 
include:aspmx.pardot.com ~all"
paypal.com. 3548    IN  TXT 
"workplace-domain-verification=F7ezsH9uapvYDGd2VtPARy1qq9ymN6"

.

but now there's just the one


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Paul Smith via mailop]

On 20/04/2021 10:06, Neil Youngman via mailop wrote:


I have observed that messages from our system are temporarily rejected
as greylisted by one destination but they are never accepted on retry.
The response is logged as "DATA: 451 0.0.0 1 recipients being greylisted
for 5 minutes". We retry after 10 minutes and get the same response.

Normally I would expect the retries to pass greylisting. Does anyone have
any insight into why this is not behaving as expected? The destination is
exeter.ac.uk.
exeter.ac.uk's email administrator is probably the only one who can say 
for certain. Anything else is a guess.


Make sure the retried message is from exactly the same return path email 
address AND IP address as the originally tried message. If either of 
these is different, the receiving server could think that it's a new 
message, so it will start a new greylist delay for that message.


Paul


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Paul Smith via mailop]

On 04/02/2021 14:57, Paul Gregg via mailop wrote:

On Thu, Feb 04, 2021 at 12:03:45PM +, Paul Smith via mailop wrote:

On 04/02/2021 11:39, Paul Gregg via mailop wrote:

It sounds like you are using PIPELINING when the remote doesn't support it 
(properly).
See if you can turn off pipelining (at least to that endpoint) on your client 
side.

What is the server doing incorrectly with the pipelining?

I'd expect the Server response to provide the rcpt to address in the 
address per rfc2920


That's a SHOULD, not a MUST (I presume for a human reader - a computer 
trying to parse the text of a response to detect success or failure is 
setting itself up messing it up). Given the MUST requirement for the 
ordering, I'd presume that any client would rely on that rather than 
doing the risky job of trying to parse human-readable text.



Absent the rcpt address in the server response, the client relies on the server 
MUST respond to commands in the order they are
received - and the original post suggests that isn't the case either.


I didn't read that from the original post. The server gave 6 RCPT 
responses (after the MAIL response), the third and fourth (responses to 
'c' and 'd') were temp fails, but the client treated the third and 
fourth as successes and the fifth and sixth as temp fails.





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Paul Smith via mailop]

On 04/02/2021 11:39, Paul Gregg via mailop wrote:

It sounds like you are using PIPELINING when the remote doesn't support it 
(properly).
See if you can turn off pipelining (at least to that endpoint) on your client 
side.


What is the server doing incorrectly with the pipelining?

--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Paul Smith via mailop]

On 04/02/2021 10:37, Benoît Panizzon via mailop wrote:

So how to reproduce... The focus is on the MAIL FROM / RCPT TO lines in
the SMTP dialogue.

Exim is sending the MAIL FROM and RCPT TO lines in one go, without
waiting for the reply of the recipient server.


That's OK. That's 'Pipelining' - https://tools.ietf.org/html/rfc2920


Now the server in return replies with one line for each of those
commands:


That's also OK (as long as the server replies are the same number and in 
the same order as the pipelined commands)




In this case, the recipients c + d did tempfail.

BUT Exim is logging that emails were delivered 200 OK to c + d and is
putting e + f in the 'retry' queue.
Subsequently, c + d never get the email and e + f are getting
duplicates.


That looks like a bug in Exim in that case. From what you've described, 
it looks like it's got a problem with its pipelining implementation. I'd 
be surprised if that is the case, as this isn't that unusual a 
situation, but stranger things have happened.


What happens if 'c' and 'd' mailboxes don't exist at all, does Exim 
produce an NDR for e + f or for c + d?




 From my observation, I suppose it's a bug in EXIM as it encounters a
situation which probably is somehow unique with our spamfilter.

That is by no means unique to your situation.

What if the commands were:

MAIL FROM: s
RCPT TO: a
RCPT TO: b
RCPT TO: this.mailbox.is.full
RCPT TO: this.mailbox.is.also.full
RCPT TO: e
RCPT TO: f

That doesn't need your spamfilter (or any spamfilter), is valid 
commands, and would have valid 4xx responses


As a test, you could try disabling pipelining in your server to see if 
that makes Exim work properly (it should wait for a response for each 
RCPT command in that case) - eg in Postfix's main.cf, I think this 
should work:


smtpd_discard_ehlo_keywords = pipelining

Or, if you're running the exim server, you could see if there's a way of 
disabling pipelining in that to see if that fixes it as well.


--

Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] RFCs on quoted pairs in From:?

[Paul Smith via mailop]

On 28/01/2021 13:17, Thomas Walter via mailop wrote:

No, it does not. And that is exactly the problem.

If I reply to the above email, it is sent to 'Some Person
' which is neither the Envelope-From, not the
Header-From, but the address in the quoted display-name.


FWIW, I've just tested it here, with a message header like:

From: "Joe " 
Subject: test

and Thunderbird tries to reply to b...@example.com. That is totally 
wrong! It's a bug and needs reporting.


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Paul Smith via mailop]

On 22/01/2021 07:24, Benoît Panizzon via mailop wrote:

What I observed is that EXIM keeps on trying every recipient even after
receiving 452 which signals that we reached the maximum recipients. So
there would be no point in EXIM trying all remaining recipients after
hitting the first such error.


This is what I'd expect. "452" does not mean that you've hit the maximum 
number of recipients. It just means that there's a temporary error with 
that command. (RFC 5321 says it means "Requested action not taken: 
insufficient system storage", but because there are more possible causes 
of errors than possible response codes, codes get re-used for similar 
things)


So, I'd expect the sender to keep trying to send all the recipients, and 
remember which ones got a 2xx response (which will be marked as sent), 
which got a 4xx response (which will be marked for retry), and which got 
a 5xx response (which will be rejected with a delivery failure report)


It is entirely possible for a 4xx response to come part way through a 
list of recipients (eg invalid recipient, recipient mailbox full, etc) 
and later recipients to be accepted.



Given that Exim and Postfix are both very mature, I wouldn't expect them 
to fail on something as basic as this.


If it is appearing to, then I would suspect something *between* Exim and 
the other server. For instance a firewall with an SMTP proxy, or an 
email scanner may be giving the wrong response codes. Maybe the remote 
Postfix is giving a 452, but the email scanner in the firewall is buggy 
and is returning a 200 to Exim. That would explain why the logs are 
differing - because Postfix is giving a 452, but Exim is *really* 
receiving a 200.


If in doubt use packet tracing on the Exim end to see what it is really 
receiving.



--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is it something to worry about?

[Paul Smith via mailop]

On 21/01/2021 14:38, Gregory Heytings via mailop wrote:


That's orthogonal to the point at hand.  The point is that honest 
customers can have their WordPress website hacked.  This might indeed 
happen because of apathy on the part of that customer, but a server 
provider cannot do anything to detect customers that do not upgrade 
their website regularly enough.  The product they sell is a bare 
machine in a datacenter.
Indeed. But when we've had abuse reports against our data centre IP 
addresses, we've immediately had an email from our hosting provider 
demanding to know why. If they don't get a quick response to that, 
they're on the phone to us.


I suspect some hosting providers aren't as diligent (possibly because 
they charge so little that they can't afford staff to handle it, 
possibly because they don't care as long as they are paid)


Either option is valid for the hosting provider, but the apathetic 
hosting providers shouldn't be surprised when their reputation is 
tarnished, and the customers should possibly be more careful about which 
hosting providers they choose to use if they care about their server's 
reputation (as they need to if trying to send email)



--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is it something to worry about?

[Paul Smith via mailop]

On 20/01/2021 11:36, Martin Flygenring via mailop wrote:


As mentioned by Hans-Martin, you can pay them to be whitelisted, which 
means that you will no longer appear in level 2 or 3 according to 
http://www.whitelisted.org/. So if you have sent so much bad mail you 
end up in their level 2 or 3, you can just pay them and then you can 
keep sending all the spam you want without a care in the world.


Not really. You would still be in level 1 if you were sending spam, so 
paying for whitelisting wouldn't help.


If you're in level 2 & 3, but not level 1, it basically means that 
you've made a bad choice of hosting/service provider. You've probably 
bought a cheap VM from a company that doesn't care that their VMs are 
used a lot by spammers. So, you can pay the whitelisting fee to get 
around that (an alternative would be to move to a decent hosting company 
that cares about abuse, so isn't in L2/L3)


I wouldn't block outright based on just an L2/L3 listing, but it does 
give a leg-up to the spam scoring.



--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What's the point of secondary MX servers?

[Paul Smith via mailop]

On 18/12/2020 08:38, ml+mailop--- via mailop wrote:

This is somewhat off-topic here, but I guess you would use multiple
A records for such a case.


Not really.

You can't set precedence for that and there is no fallback system 
defined, so if you set multiple A records for a web site, the browser 
will pick a random server to go to for a connection, and that's the only 
one it will try. The one that's picked may be the one that's broken. 
It's even possible that the web browser will pick a different server for 
each request, meaning sessions don't work normally.


With MX records, there's precedence, and there's a requirement for the 
client to try all available servers - that doesn't exist with HTTP. 
Also, you don't have sessions that last more than one connection in 
SMTP, whereas you do in HTTP(S).



--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What's the point of secondary MX servers?

[Paul Smith via mailop]

On 18/12/2020 01:19, Philip Paeps via mailop wrote:


I use the secondary MX as spammerbait...  If a client connects to a 
lower priority MX before talking to the higher priority MX, I probably 
don't want to hear from them.

There's also the opposite anti-spam trick that I've heard of:

have two MX records. The higher priority MX just doesn't exist and the 
real mail server is the lower priority one. Badly written spam software 
will try the higher one and when that doesn't respond, it'll give up. 
Well written mail senders try the higher one, then use the lower one 
when the higher one doesn't respond.


https://en.wikipedia.org/wiki/Nolisting


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: What's the point of secondary MX servers?

[Paul Smith via mailop]

On 18/12/2020 08:22, Thomas Walter via mailop wrote:

Personally I'd use two A records for one name, but whatever.
That's round robin, not "backup"? Systems will "randomly" connect to
both connections and fail if one line is down - which was not the
intention here.


No. It should try both. The order is random, but it should try both of 
them, so if one is down, it will use the other.


RFC 5321 - section 5.1

"  When the lookup succeeds, the mapping can result in a list of
   alternative delivery addresses rather than a single address, because
   of multiple MX records, multihoming, or both.  To provide reliable
   mail transmission, the SMTP client MUST be able to try (and retry)
   each of the relevant addresses in this list in order, until a
   delivery attempt succeeds."

Note that the requirement to try each of the addresses is for multiple 
MX records *OR* multihoming (multiple A records)


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Paul Smith via mailop]

On 08/12/2020 10:27, Rich Kulawiec via mailop wrote:

- It's no help with phishing: thanks to ICANN, registrars, and
the proliferation of TLDs, phishers have their choice of hundreds of
millions of typographically similar domains.  Or they can just use
freemail providers and rely on the gullibility of recipients.


"Typographically similar" is not "identical". Yes, many people will be 
fooled by "typographically similar", but not everyone. SPF (and DKIM) 
allow you to verify to some level of certainty that the sender is who 
they say they are if you want to try. Without them, you have no chance.


Similarly, if you use a CRM or similar, then "typographically similar" 
won't fool them, but a spoofed sender will.


Verifying the sender is who they say they are is valuable, even if some 
people are fooled by messages from "b...@micr0soft.com".


I've had to deal with customers who have lost large amounts of money 
because of spoofed emails, even though they checked that the sender's 
email address was valid. If the sender had used SPF or DMARC, it 
wouldn't have happened. Yes, in hindsight they should have checked bank 
details offline, but lots of people don't realise that email addresses 
can be forged so easily; anything that makes it harder is a good thing.


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Paul Smith via mailop]

On 07/12/2020 21:47, John Levine via mailop wrote:



Forwarders are one of the things that don't respond well to SPF.  But
honestly, it's 2020 ... why are we forwarding mail to external services?
SRS might be a bandaid for this, but isn't the easiest solution to just
tell people that forwarding mail to external servers is bad (mmkay).

Uh, no. I have lots of users with role accounts who read their mail at
gmail.  Forwarding is as useful as it ever was, even though it is ever
harder to to do successfully.

The fact that SPF can't handle forwarded mail is a failure of SPF, not
a bug in forwarding.


We have to be careful not to prescribe that the old way of doing things 
is sacrosanct. The world changes.


I remember when I could have emailed you by sending a message to 
johnl%taugh.com%microsoft@ibm.com and it would have got to you. No 
one (I hope) nowadays would say that is an acceptable way of doing things.


Forwarding is still useful nowadays, but 'willy nilly' forwarding 
shouldn't be. Nowadays, there needs to be a way to limit forwarding to 
the forwarding you actually want to happen. The risk of spoofed mail can 
be catastrophic for a company, and because forwarded mail looks very 
similar to spoofed mail, there needs to be a way to differentiate them.


If you're forwarding to your own company's mail server, then it should 
be easy to have that forwarding work with SPF, and if you're forwarding 
to someone like gmail, then, to be honest, it should be relatively 
trivial for them to *USE* SPF to allow forwarding to them. I could tell 
Google to allow a specific domain to forward to me (the domain of the 
forwarder), and they use the SPF record for that domain to validate the 
IP addresses that can then forward and override other SPF checks.


Or forwarders could add a digital signature to a header, and the user 
somehow tells the forwarding target the public key to validate that 
signature for forwarders they want to allow that would then bypass SPF 
checks. (This would be better than the IP checking way, but would 
require a new standard)


--

Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Paul Smith via mailop]

On 06/12/2020 13:12, Hans-Martin Mosner via mailop wrote:

In your experience, where does SPF really help? What are the use cases that I 
don't see in my spam-blocker tunnel vision?


One thing we still encounter occasionally is where a spammer has decided 
to send email from one of our customers' domains (not by hacking their 
mail server, just by forging the return path). In this case, our 
customer get loads of backscatter, and autoresponses, etc.


Adding SPF tends to cut down on the backscatter as, presumably, some of 
the spammers' targets will not send failure messages back if the SPF 
fails, and some reject the junk outright. Also, spammers seem to stop 
using their domain and switch to another one without SPF. (We can 
support BATV as well, but that can break in some situations)


This used to happen a LOT more in the past, but it still happens today 
occasionally.


So, I'd suggest having at least a 'soft fail' SPF record for your own 
domain. If a spammer is in the habit of trying to piggy-back off other 
companies' domain reputations, then it seems to encourage them to look 
elsewhere.


For incoming mail: personally, if it was for a personal mail server, or 
I was in charge of a company's mail server, I wouldn't have a problem 
blocking on an SPF hard fail. If the mail system was used for customers, 
then I wouldn't do that, as the support hassle would be too great.


Using SPF as another factor in a more comprehensive spam filtering 
system is reasonable. In my experience, more SPF fails are bad than are 
false positives. But SPF is not an anti-spam mechanism at all, so 'false 
negatives' are actually very rare (those would be where a domain holder 
has an SPF that authorises IP addresses that it shouldn't do and which 
do send forged mails)


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Paul Smith via mailop]

On 27/08/2020 16:53, Tim Bray via mailop wrote:


The same kind of regulations exist in the UK, but everybody forgets 
about them.    You often see business names on websites that don't 
match their legal entity; confusions between sole trader (just a 
person) and a registered company (limited, unlimited or one of the 
other types).


Just to add to the confusion, in the UK a 'sole trader' is NOT 'just a 
person'. A 'sole trader' *legal entity* is 'just a person', but a 'sole 
trader' can perfectly legitimately employ hundreds of people, and still 
be a 'sole trader', and thus not require company registration, and all 
the stuff that goes along with that. (It might be unwise because of the 
unlimited liability, but it's possible - and many 'sole traders' do 
employ 10s of people).


A sole trader or partnership can trade in a different name from the 
owners name(s), but does not need to put anything specific in an email 
footer (a limited company or LLP does). The requirement to do so is part 
of the UK Companies Act 2006, which doesn't apply to sole traders or 
normal partnerships, just as it doesn't apply to non-business emails. 
They do need to put contact details on their website, but do not need to 
put a 'registered address' or anything like that in their emails as 
people from registered companies do.


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Paul Smith via mailop]

On 27/08/2020 12:39, Jaroslaw Rafa via mailop wrote:

It's rather strange that you are comparing this to SPF.
1) SPF has no "default deny" policy; if a domain has no SPF record at all,
then mail is (or at least should be) accepted by default.


No, but it's possible for a receiver to have a policy to not accept mail 
from an unknown server that doesn't match the sending domain's SPF 
record (and that such a record has to exist). If you're going to have 
the sending server have to have some form of 'authorisation', then 
requiring SPF would be better than requiring an one-off ad-hoc 
authorisation method.



2) as the original poster mentioned, once you have authorized your server
with them, you can send mail *with any sender domain*. It does not compare
to SPF in any way.


I missed that. I thought they had to say 'this mail server can send from 
this domain'. If the server can send from *any* domain, then it's a 
useless policy, as well as being unscalable.



--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Paul Smith via mailop]

On 27/08/2020 11:22, Jaroslaw Rafa via mailop wrote:



So if you got some cloud vm with a new IP address, which never before
sent mail to a @t-online.de address, mails will be rejected.
You need to write their postmasters so it gets added to their
whitelist. And for this process you need to have a small web page with
your personal address listed if your server is run privately.

This is so absurd that it's even hard to find words to describe it.


It's the sort of thing that you'd think maybe someone should make a 
standardised way to authorise servers to send email from a domain. Maybe 
they could call it something fancy like 'Sender Policy Framework' or 
something?..



--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Microsoft Block list (S3150)

[Paul Smith via mailop]

On 29/06/2020 13:08, Scott Mutter via mailop wrote:
> On the advice of their lawyers Microsoft doesn’t share that 
information with senders.


And I understand the reasons for that.  But... can't you see how this 
turns into a "he said / she said" argument?


Without giving any message/sender/recipient details away (that the 
sending mail admin can't already see) they could give the ID of the 
message transaction


Their servers respond to the message with something like this:

250 2.6.0  [InternalId=1112312312313, 
Hostname=DB8EUR06HT227.eop-eur06.prod.protection.outlook.com] 1117027 
bytes in 0.520, 2096.624 KB/sec Queued mail for delivery -> 250 2.1.5


So, they could easily give out the "internalid" & "hostname" values 
without divulging any personal information about either the message 
sender or recipient or content, so there is no GDPR or data protection 
breach there. If the person they tell those to can use them to identify 
the message details, then that person could already have seen the 
message details. If not, then it tells them nothing.


Or, maybe, it's because Microsoft's lawyers know that their systems are 
a bit dodgy/arbitrary/random and don't want to risk all the problems 
being discovered?


--
Paul


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] UCEPROTECT-Level1 listing

[Paul Smith via mailop]

On 08/06/2020 16:26, Ewald Kessler | Webpower via mailop wrote:

Hello,

One of our IP addresses (91.197.72.142) got blacklisted at 
UCEPROTECT-Level1 with a "Last Impact" timestamp of 06.06.2020 16:57 
CEST +/- 1min.


But the peculiar thing is, no mail was sent from that IP in at least 
the 48 hours prior to their timestamp.


How do you know no mail was sent from that IP address?

Was the IP address blocked at your firewall, or could a different PC or 
some software have sent that mail without you being aware of it?




--
Paul



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] keeping rejected mails in queue for second attempt acceptable?

[Paul Smith via mailop]

On 06/06/2020 19:40, Stefan Bauer via mailop wrote:

keeping rejected mails in queue for second attempt acceptable?

Hi,


once in a while, some of our outgoing customer mails are rejected by 
remote sites with a 500 code because one of our sending IPs are 
temporary blacklisted. or due to other reasons we are not able to 
deliver the mail. I'm only talking about cases, where the mail itself, 
is not the reject reason.


Well, if the sender has been temporarily blacklisted, they shouldn't get 
a 5xx error - the clue is in the "temporarily". That's what the 4xx 
response codes are for.


Strictly speaking, you shouldn't retry a 5xx-rejected message exactly as 
it was sent the first time, but no one can stop you from doing so.


You can't be certain whether a message was rejected due to the message 
or due to a temporary problem unless you know exact responses that 
you're getting, and can check for those. That's why the receiving MTA 
should return a 4xx for a temporary problem.



--
Paul



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft MSN JMRP SNDS support

[Paul Smith via mailop]

On 27/03/2020 14:05, Dima Gomonyk via mailop wrote:

Hello, does anyone have contacts for the JMRP SNDS support?

We need to change the complaint address for the JMRP FBLs, but the 
SNDS service doesn't allow us to do that for some reason (no option 
edit or manage the existing feed), nor it allows to set up a new feed 
with the same IPs (feed can be added, but then it's automatically(?) 
removed after about five minutes).


Their page refers to the usual outlook ticketing form, which took 
three days of back-and-forth to find out the hotmail support doesn't 
handle JMRP and the msn-s...@microsoft.com 
<mailto:msn-s...@microsoft.com> address should be mailed to instead - 
which is not responding for a week now.


So, trying to figure out either how to manage the existing complaint 
feed at JMRP or how to get in touch with someone at the JMRP SNDS support.



That sounds exactly like the problem I had back in December

https://chilli.nosignal.org/cgi-bin/mailman/private/mailop/2019-December/015431.html

The IP address was in a feed which we didn't own all the IP addresses 
for (we had 'lost' some since we set it up) and those were owned by 
DigitalOcean which didn't have access to some of the other IP addresses 
on the feed. That had the result that *no one* had 'manage' access to 
the feed (not even to delete it) because no one 'owned' all the IP 
addresses on it, and you couldn't add the IP addresses to another feed, 
because an IP address can only be on a single feed.


After a lot of (very slow) back & forthing to SNDS service 
(msn-s...@microsoft.com <mailto:msn-s...@microsoft.com>) where they 
seemed totally unable to understand the problem, they basically said 
'tough, as you don't own all the IP addresses, we won't help you' (even 
though my email address was listed as the person who created the feed). 
I then asked Michael Wise (a very helpful member of this list who works 
at Microsoft) to see if he could help. He understood my problem, unlike 
the msn-sdns people, so he persuaded them to do something. That did help 
a bit, but they still didn't sort it out fully, at which point I gave 
up, because I decided life was too short... (That was partly my fault, 
on the 15th time of repeating the same information to them and getting 
very frustrated, I made a small typo, which was the one time they 
decided to actually read the information I was sending :-( )


You'd think they'd easily be able to "split" a feed if two different 
companies owned different subsets of the IP addresses on it, but no, 
that seems to be impossible. They won't even delete a feed so that you 
can recreate it correctly.


So, not really much help, I'm afraid :-( The msn-s...@microsoft.com 
<mailto:msn-s...@microsoft.com> is the correct email address, but they 
don't seem to really understand their own system or how it's used in 
real life. If that doesn't work, you could try contacting Michael Wise 
and see if he can nudge someone. Maybe you'll have better luck than me.


--
Paul



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [External] Re: Horrible week for email deliverability - Looking for help with RackSpace/Emailsrvr

[Paul Smith via mailop]

On 27/03/2020 09:58, Laura Atkins wrote:



I understand why you consider yourself an ESP. That’s not how i would 
refer to you. You’re an email hosting provider, because you host both 
the inbound and the outbound piece of mail. ESPs handle outbound, and 
the necessary bits of inbound to make SMTP work (delayed bounce 
handling, FBL and sometimes DMARC reporting) but not the 
“conversational” piece of email.


If the original poster meant something different by ESP, I 
misunderstood their terminology.



That's fine. It's worth clarifying terminology.

You see, when they said there were 'a small ESP', *my* immediate thought 
was that they were a larger version of us, rather than a smaller version 
of MailChimp. You obviously thought the opposite. Which is fine. But 
which could do with clarification.



--
Paul



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [External] Re: Horrible week for email deliverability - Looking for help with RackSpace/Emailsrvr

[Paul Smith via mailop]

On 27/03/2020 08:32, Laura Atkins via mailop wrote:
You have folks using a bulk ESP to send friends and family email? Do 
you have a free package or something that makes it appealing for 
individuals to go through all the work of setting up an ESP account 
just to send personal mail to their friends and family?


I'm puzzled by that statement. (And, did Kevin say they were a 'bulk 
ESP'? I thought he just said they were 'a small ESP')


We're (what I would call) a (small) ESP, and have quite a few people who 
pay to use us for personal email.


An ESP is an 'Email Service Provider' (as I understand it). So, if we 
provide an SMTP submission server for customers to use (and we're not a 
more general 'ISP'), then we're an 'ESP'.


We have many customers who use us at work, and like our service and are 
fed up with the non-existent customer service from faceless big freemail 
providers so have asked to pay us a few pounds a year to use our service 
for their personal use as well. It takes all of 5 minutes for them to 
type in a new SMTP mail server & account details into their email 
software/app - it's not exactly onorous. That saves them loads of time 
and stress later when they can actually get through to someone who 
doesn't just reply with useless stock emails when they need help.


--
Paul


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Sendgrid strikes again; zendesk, actually

[Paul Smith via mailop]

On 26/02/2020 12:21, Jaroslaw Rafa via mailop wrote:

I guess the confusion may come from the fact that one would usually not
expect a ticket acknowledgment to be ONLY the exact copy of the message you
have sent and pretty much nothing more. I still think they misconfigured
something.


But it isn't...

It has

## In replies all text above this line is added to the ticket ##
--

above the quoted text

and

-

Your Twilio Ticket ID # 3806345 Encoded ID # [Q54RWY-VROX] Your 
Ticketing System's ID # (if we have recorded one): -


 This email is a service from SendGrid.

below the quoted text. The middle of the message is the ticket history. 
That is quite normal for ticket acknowlegements that I see. It all looks 
normal to me. They can't put anything else at the top of the message 
because "all text above this line is added to the ticket"





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sendgrid strikes again; zendesk, actually

[Paul Smith via mailop]

On 26/02/2020 11:12, Alessandro Vesely via mailop wrote:



That looks remarkably like Sendgrid use ZenDesk for their abuse desk platform, 
and they’re replying to or otherwise acknowledging your ticket. That they 
include the original email body isn’t that surprising for an abuse desk.


Sorry, I thought I had made it clear they're _not_ ticket ack.  I attach the
last one I received, it arrived five minutes after I sent the last complaint.

It looks EXACTLY like a ticket acknowledgement email to me. The "## In 
replies all text above this line is added to the ticket ##" text is 
telling me that it's a ticket acknowledgement and is allowing you to add 
more information to the ticket by email. I'm not entirely sure why the 
confusion???


Try changing the subject/message slightly on the complaint message you 
send. I 100% expect the message you receive in return will have that 
changed subject/message, not the original subject/message content.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Recipe vs fake From: header?

[Paul Smith via mailop]

On 18/02/2020 09:47, Andrew C Aitchison via mailop wrote:


I thought DKIM was supposed to flag such messages;
do these phishing emails satisfy DKIM ? 


DKIM checks that the message matches the DKIM signature - ie that it 
hasn't been modified since sending. That's it.


So, for instance, your message has this DKIM signature

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=aitchison.me.uk; s=mythic-beasts-k1; h=Subject:To:From:Date;
 bh=c8HNHZV6ldDX0jjiGqekUv0kzjSL24pv2r0BoCkgGgk=; b=bjif8/qAk7FQ1MftQ89Fdbp9ej
 SySu0EglcpImChNAvp0fwZBuiuMh4PKtVq4FG66kz7w7yag/eNk72Y7WmmTbecY0uE6gsEagdqBof
 eeY7je/ZWixIh8zXaW3UAOe3+ZoSWGczcH0UZ5o+F2SrSeZjkbKZ4AUie2DD/+wH3t6F9FV1JYEmD
 RreDzx37oyMn/UDoA9dVqXaA06iMigM2h2JVyOSCTx9Q0yl3z7zVS8diAR1ANOs3kxRR+ce3PfxBo
 dHwdGscn19aiWf1V55LGxCXHPCD9K6bH0KTfTr09uT2/7Kb2L2femWwy6nop0MzjicM74v3S9Oxve
 00OyLyYg==;

The recipient gets the DKIM public key at 
'mythic-beasts-k1._domainkey.aitchison.me.uk' (calculated from the 's' 
and 'd' values in the DKIM-Signature line) and checks the message's 
signature matches that


If the DKIM signature had a different 'd=..' value, then the public key 
could be retrieved from anywhere - it doesn't have to relate to the FROM 
header's domain at all.


So, I could send a message with your email address in the From field, 
with the DKIM-Signature being


DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=pscs.co.uk; s=some-gibberish; h=.

and it would pass the DKIM check.

DMARC requires the DKIM 'd' domain value (or the SPF Mail-From domain) 
to relate to the FROM message header.


So, DMARC is what you need (along with DKIM and SPF, to give DMARC 
something to work with)





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Suggestions for mailops.org website - forum?

[Paul Smith via mailop]

On 17/02/2020 19:03, Scott Mutter via mailop wrote:

Regarding the suggestion for "content/questions/answers/links to put on the 
website" - have you ever considered making this mailing list into a forum?

I just like discussion forums a lot better than I do discussion mailing lists.  
In my opinion, it's easier to contribute within a forum environment than it is 
within a mailing list environment.



From past experience of technical mailing lists changing to forums, I'd 
expect participation in a forum to drop dramatically. Mailing list 
messages get pushed to members, forums require you to go and look. Even 
if new posted messages are emailed to members, then it still requires 
the member to click on a link, login etc before replying. From 
experience, fewer people will do that. I was in a very active mailing 
list with multiple messages daily. It changed to a forum a couple of 
years ago. Now, it's unusual for there to be as many as one message a month.


If you can find a system which allows forum replies to be sent by email 
(basically a forum and mailing list in parallel), then that works OK, 
but they're not that common AFAIAA.



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Recipe vs fake From: header?

[Paul Smith via mailop]

On 18/02/2020 09:03, Benoit Panizzon via mailop wrote:

SPF would block the From email addresses if also used as envelope
sender. But the, from the customers perspective 'hidden' envelope
sender is different and does match SPF.


Has anyone come up with a clever recipe for this issue?


This is one thing that DMARC is intended to solve. DMARC checks the 
header 'From' address matches either the DKIM signature domain or the 
SPF domain.






--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] How long to retry?

[Paul Smith via mailop]

On 03/02/2020 22:43, Luis E. Muñoz via mailop wrote:


Since recently – heh, let's call it 5-6 years – I've observed more and 
more that senders are unable to connect the first NDR ("your mail is 
stuck, we're still trying") with their original message. There's some 
cognitive dissonance at play here. If the bounce is not instantaneous, 
that NDR is a waste of resources for them. More or less the same 
happens with the final NDR ("sorry, I give up"), where they seem to be 
unable to grasp that the message was not delivered. 


In my experience, this is very much the case. NDRs are just treated like 
spam for many senders, even if they are written in very simple language.


We often get the case where a sender complains that a message wasn't 
delivered, and is adamant they didn't receive any error message about it 
- then we look in their Trash folder, and there's the NDR.


So, in my view, you need to try for at least 3 days before giving up. If 
there's any reasonable chance of getting the message delivered, it 
should be.


(Maybe MUAs should (where possible) automatically link NDRs to messages 
in the 'Sent' folder, so that the user can see there that the message 
hasn't been delivered yet. Maybe if DSN was more widely supported, that 
would allow better user feedback as well.)



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Abandoning self hosting and moving to Protonmail - experiences?

[Paul Smith via mailop]

On 27/01/2020 14:55, Lennert Van Alboom via mailop wrote:


I was looking at Protonmail because the company doesn't have access to 
the mail it hosts


Have you looked at how to send emails to non-Protonmail recipients?

It doesn't look usable at all to me for anything beyond very trivial use...

https://protonmail.com/support/knowledge-base/encrypt-for-outside-users/

Also, it doesn't look as if that email will be encrypted beyond 
Protonmail's ability to access, otherwise they wouldn't be able to show 
it to the recipient when they've logged into Protonmail's website.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Messages from small personal SMTP server being marked as junk by Google

[Paul Smith via mailop]

On 24/01/2020 09:47, Gregory Heytings via mailop wrote:


jfoo.org. 6 IN MX 0 mx.oustrencats.com.
jfoo.org. 6 IN TXT "v=spf1 ip4:50.116.29.164 
ip6:2600:3c00::f03c:91ff:fe6e:7287 -all"


This is not optimal, your SPF record should be "v=spf1 mx ?all". 


I disagree.

"v=spf1 mx ..." requires a DNS lookup which their existing SPF record 
doesn't. Lots of people telling you how to set up SPF will say 'use 
v=spf1 mx' because they don't want to explain the entire SPF record 
format, and the 'mx' mechanism works for a large proportion of people.


Using specific IP addresses is more 'optimised' than using 'mx'.

?all vs -all is all down to opinion.

Personally, I'd never use '?all' - that seems to be a "we're not sure 
what we're doing yet" rule. ~all or -all is better IMHO.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Messages from small personal SMTP server being marked as junk by Google

[Paul Smith via mailop]

On 24/01/2020 03:24, John Gateley via mailop wrote:


She recently sent email to a group of students for a class she is 
teaching, she had
e-mailed none of them before. Most of them had gmail addresses, and 
most, if

not all, had my wife's e-mail sent to junk.

There were 19 recipients on the To: line.
15 of the recipients were gmail addresses.

Any ideas why? Or how I fix it? 


OK. The problem is that if you have a small mail server, Google won't 
have much reputation data about it.


So, sending a 'bulk' message (OK, on a small scale, but still) may be 
suspicious enough that Gmail decides to junk it. Just as you'd expect it 
to from a recently-set-up spammer's mail server.


The best thing is for the recipients to mark it as a good message. 
That'll feedback to Gmail's systems that the sender is good.


SPF/DKIM aren't enough to cause anyone to treat your messages as good - 
spammers can (and do) set up those things too. But, it gives Google more 
information that will help with building up your good reputation, so 
they are a good thing to do. Also, it means that if you move your domain 
to a new IP address, SPF/DKIM will help to carry over any good 
reputation to the new IP address rather than having to build up the 
reputation from scratch. (With SPF/DKIM the reputation can be built on 
the sender domain itself, rather than just the sender IP address)


Unfortunately, there's no "magic fix" to get messages delivered to Gmail 
(or Outlook.com/etc) - if there were, then spammers would use it too. 
The recipients saying 'we wanted that message' is the best way forward.


Other things such as sender IP address (eg is it in a bad-reputation 
hosting company, on a home broadband connection etc) and message content 
could affect things as well, but you haven't told us anything about 
that, so I can't comment on those.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Reasons to add plain text alternative to email?

[Paul Smith via mailop]

On 09/12/2019 08:50, Maarten Oelering via mailop wrote:

Multipart messages with html and text alternatives are generally considered 
best practice. Senders with html templates should add a text version is the 
common believe.

But it's almost 2020, and we were wondering if there's still a good reason for 
adding plain text to a html message. Is there a significant audience reading in 
plain text? Is plain text important for accessibility? Because SpamAssassin 
says so?


Automated software/filters will find it a lot easier to read plain text 
than HTML. This will include things like screen-readers.


Many people DO read in plain text because of the perceived risk of HTML 
(tracking images etc)


Many 'techies' read in plain text because it's better & cleaner than HTML

Why wouldn't you add a plain text alternative? Software can 
automatically generate a reasonable plain text version quite easily and 
it'll probably be a small fraction of the size of the HTML version, so 
why not do it? (But test it! A lot of automated generation is rubbish - 
I've seen ones where the plain text version is identical to the HTML 
version - tags and all)




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Microsoft JMRP problem

[Paul Smith via mailop]

On 03/12/2019 13:17, Paul Smith via mailop wrote:

On 03/12/2019 13:15, Stephan Fourie wrote:

Hi Paul,

I've had success with mailing msn-s...@microsoft.com for support.


Thanks, I'll try that and see how it goes.

Hey ho, I tried that and the response was basically "prove that you own 
all the IP addresses and we'll delete it for you". Totally missing the 
point that I want it deleted because I *don't* own all the IP addresses 
any more or I'd delete it myself. (Or split the feed into two feeds with 
the different IP addresses accessible by different feed users as 
appropriate, and the IP addresses owned by neither feed user removed)


Is there any contact at Microsoft who can use a bit of logic and common 
sense in their replies? (Michael Wise, can you help at all?)


The feed has 2 IP addresses "owned" by my company (WHOIS shows it owned 
by Daisy Communications, but we have a /26 from them), one owned by 
IOMart, one owned by Zen Internet and five owned by Digital Ocean. So, 
no one person is going to be able to prove that they own all the IP 
addresses. I no longer have access to the addresses owned by IOMart or 
Zen and three of those owned by Digital Ocean, so I can't reclaim access 
to those and them remove them from the JMRP.


It just seems to be broken with no permissible way to fix it.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft JMRP problem

[Paul Smith via mailop]

On 03/12/2019 13:15, Stephan Fourie wrote:

Hi Paul,

I've had success with mailing msn-s...@microsoft.com for support.


Thanks, I'll try that and see how it goes.




Kind Regards,
Stephan

On 2019/12/03 14:33, Paul Smith via mailop wrote:
Hi, does anyone know any contact details for someone who can fix 
Microsoft's JMRP. 




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Microsoft JMRP problem

[Paul Smith via mailop]

Hi, does anyone know any contact details for someone who can fix 
Microsoft's JMRP.


I seem to have broken it... I added various DigitalOcean IP addresses 
that we used to the SNDS and JMRP and all was fine. Then I added various 
of our leased line IP addresses to the SNDS and JMRP and all was fine.


Then, we stopped using DigitalOcean as much, so removed those IP 
addresses from SNDS, and now it's all broken. The problem is that it 
doesn't seem to have removed those IP addresses from JMRP, so now *we* 
have 'view only' access to the JMRP feed (because we don't have access 
to the DigitalOcean IP addresses) and DigitalOcean also only have 'view 
only' access to the JMRP feed (because they don't have access to our IP 
addresses)...


So *no one* can manage the feed, because no one has access to all the IP 
addresses. I'm down as the 'contact email address' for the feed, but 
can't delete it or remove the unwanted IP addresses from it.


I've trawled the SNDS pages looking for who to contact for problems with 
it, but all it seems to say is "it's fully automated so do it all 
yourself" - I wish I could...




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] ItaliaOnLine (@libero.it, +) now interpreting DMARC p=none as p=quarantine

[Paul Smith via mailop]

On 26/11/2019 12:41, Stefano Bagnara via mailop wrote:

I don't know if ItaliaOnLine postmaster follow this list and if they
consider this new behaviour a feature or a bug, but I wanted to share
this finding/news with you.

What do you think about this? Do you know other providers making this
"deliberate guess"?


It's bad for an ISP to do that. 'p=none' is often used for the case of 
"we've just started using DMARC and don't know if we've got it set up 
correctly yet", so treating it as p=quarantine is going to lead to lots 
of false positives.



On the other hand, if this is JUST for mail from msn.com, they may have 
decided that that domain is established enough that hopefully the admins 
know what they're doing, so may have an exception to treat mail FROM 
THAT DOMAIN as p=quarantine (similarly with gmail.com, which also has 
p=none)



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] [EXTERNAL] Re: Reasons ISPs (Microsoft) ignore DMARC policy?

[Paul Smith via mailop]

On 22/11/2019 08:46, Alessandro Vesely via mailop wrote:

Plain forwarding, that is without changes except trace header fields, needs no
From: munging.


Only if the original message is also DKIM signed. I see quite a few 
people using DMARC with only SPF. I guess that they haven't worked out 
how to use DKIM with their mail server yet, and, since 'normal' messages 
will pass DMARC with just SPF, then they leave it at that.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Reasons ISPs (Microsoft) ignore DMARC policy?

[Paul Smith via mailop]

On 20/11/2019 13:17, Jon Burke via mailop wrote:
 I know ISPs can enforce a stricter policy (e.g. reject although 
policy is p=quarantine) but I don’t often see ISPs applying a more 
lenient response than stated in the DMARC policy. I can think of one 
reason for doing so (user added the sender to his / her safe-sender 
list) and wanted to ask if you know of some other reasons?


Forwarded messages will fail SPF checks, so mail servers may decide to 
accept messages that have failed SPF checks in case they've been forwarded.


Users still use MTA-level forwarding now, especially to free email 
addresses like Hotmail & Gmail, so I guess those providers are stuck 
between a rock and a hard place - either reject spoofed and forwarded 
mail and upset users, or accept it and upset users.





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] reputation with DKIM when d= differs from sender domain?

[Paul Smith via mailop]

On 14/11/2019 16:38, Stefan Bauer via mailop wrote:

reputation with DKIM when d= differs from sender domain?

Is it bad - in terms of reputation - when domain in dkim-header 
(d=...) differs from senders address?


signing is done correctly and pub-key is present at domain of corse - 
specified with d=...



like d=mydomain.com

Sender is Stefan 

I could not find anything in the RFC.


There's a reason for that.

DKIM itself has nothing to do with reputation. It's simply a way of 
proving that the message was 'authorised' by someone.


People who use it for reputation could potentially do all sorts of 
different things - from just assigning a 'trustworthiness' rating to a 
signing domain, or a combination of signing domain & sender or whatever. 
So, you will probably get as many answers as people who choose to answer.


If you use DMARC, then the signing domain is ignored for DMARC's 
purposes if it's not associated with the 'From' header address domain.


Here we do something very simple, and decide to trust signing domains if 
they don't send spam, and aren't ISPs, ESPs, or hosting companies (eg a 
generic AmazonSES signature), but other people probably do different things.


That doesn't mean we distrust DKIM signatures from ISPs, ESPs or hosting 
companies, just that we ignore them if the signature verifies, because 
that tells us nothing useful.





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Avoiding bounces - custom spamfilter behind real-spamfilter that reject mails

[Paul Smith via mailop]

On 24/10/2019 14:12, Benoit Panizzon via mailop wrote:

I also considered hacking together a small 'relay' MTA which would
receive the email but not reply OK to the final DATA command (RFC
states you can take up to 60 seconds to reply to the DATA command)


60 seconds? I thought the timeout there SHOULD be at least 10 minutes

https://tools.ietf.org/html/rfc5321#section-4.5.3.2.6

I'm not saying anyone sticks to that - but that's what the RFC says, so 
you have a reasonable excuse for observing that. In fact the RFC doesn't 
have any suggested timeouts being as low as 1 minute.



Because the biggest problem in this scenario is backscatter, the other 
option is not to bounce messages, but use a spam folder instead at the 
destination server.


Even if you pass through, you have to decide what to do if the remote 
server isn't responding for some reason - do you queue the message (in 
which case you have to handle backscatter anyway) or reject it (in which 
case, you may have to do duplicated work, and your customer may prefer 
that you queued the message to prevent the risk of them losing it)




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] FW: Junk filtering as a tool for unfair competition

[Paul Smith via mailop]

On 24/10/2019 04:56, Noel Butler via mailop wrote:


On 24/10/2019 05:16, Michael Wise via mailop wrote:




Also, trivial messages look like probes, and are probably going to be 
junked.


Therein lies the problem, what if we all decided to junk everybodys 
email because it looks trivial, we might as well junk everybodys email 
and be done with it.


There's 'trivial' and then there's 'trivial'.

"Should we meet at the pub tonight" is trivial, but (probably) not what 
Michael means.


"Test" is trivial, and possibly what Michael means.

I have seen cases where we have received thousands of emails with the 
word 'test' (or 'hello', or similar) to different random email addresses 
on our systems in a very short period of time. It seems to be an attempt 
to try to work out which email addresses are valid and which aren't. The 
problem is that there's very little in that message that can be used for 
content filtering and it's a common way to do a legitimate test as 
well.  So, to filter it effectively, you need to use other means (sender 
reputation, looking at all received messages across the whole system 
looking for patterns etc).


To be honest, given the message content, you have to wonder if it's 
worth going to a lot of effort just for that.


I've simply learned never to send a test message with just something 
like 'test' in the message body. Put more content in the message to give 
the content filter something to look at. (eg "This is a test message 
from Bob at Bobtech Ltd. Please let Jim in your IT department know if it 
worked or not"). Also, make each test message different, or that can 
look spammy as well, and don't send zillions at once.





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Do we need Spam folders?

[Paul Smith via mailop]

On 16/10/2019 12:30, Jaroslaw Rafa via mailop wrote:

Second case is when you want to*send*  mail to someone. Someone is selling
something on the Internet, you want to buy it, but in order to do it, you
have to send e-mail to the seller's address provided in the ad.


If the person is wanting to receive emails from you (as in the case of 
them selling something) they should be regularly checking their spam 
folders - if not, they are losing out on sales. That's their loss.



If the message
ends in his/her spam folder, he/she has no clue to look there for it -
unless you have another way to contact the recipient and tell him to look
there. That's a more problematic case.


So, if you don't have another way to contact the recipient, how is it 
better that the recipient has zero chance of seeing the message than it 
going into their spam folder where they do have a chance of seeing it?



We can think of two quite opposite cases here.
The problem is that the receiving system can't tell the difference. So, 
you either accept "spam" and semi-hide it, or you reject it meaning that 
the user has no chance of finding the message (or you break SMTP and 
fake a rejection when you have really accepted it). In your first 
situation, rejecting the messages is very bad. In the second situation, 
rejecting the messages *may* be better than accepting and semi-hiding - 
but only if you have another viable way of contacting the recipient. So, 
in general, rejecting is the worse option.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Do we need Spam folders?

[Paul Smith via mailop]

On 14/10/2019 19:39, Philip Paeps via mailop wrote:

On 2019-10-14 06:07:31 (-0700), Thomas Walter via mailop wrote:

Do we even need Junk/Spam-Folders?

I mean how much mail gets through the first "block directly" level on 
your site? Every now and then a wave comes through and results in a 
bad mail or two more, but can't people handle 3 or 5 spams in their 
inbox per day?


While I'm clearly not a representative sample of the average email user,
3 or 5 spam messages per day is two orders of magnitude short of the
mark on a bad day for me.

So ... Yes: we need spam folders. 


Ditto. Yesterday, I got 400 emails. About 200 were spam that was 
filtered, about 15 were spam that wasn't filtered, the rest I wanted at 
one level or another.  No way do I want 200 spam messages shoved into my 
Inbox.


However, our spam filter actually sends me an email containing a list of 
filtered emails every day, to prod me to take a look. It's sorted and 
colourised by 'spamminess', so the most likely to be false positives are 
shown at the top. So, two seconds before I delete that message lets me 
look for something that may not be actual spam. I don't have to do 
anything (like click on a 'spam folder') to check this, I get it thrown 
at me. Now, I do know that some people don't like this (we actually get 
some people reporting this daily email as spam), but we keep telling 
them that one day they'll be happy they were prompted to take a look - 
usually they are.


So, I think a similar 'daily spam report' should at least be a default 
option, even if people can turn it off if it annoys them. I've seen many 
systems that don't even have it as an option that can be turned on. The 
sorting by spamminess is important - a spam folder is generally sorted 
by date or whatever, which means you have to look through it all. If 
it's sorted by spamminess, then a quick glance can catch the majority of 
false positives.



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Gmail marking email from me as spam

[Paul Smith via mailop]

On 14/10/2019 10:17, Laura Atkins via mailop wrote:


When we closed down our colo and moved to a VPS I was slightly 
concerned about delivery of our mail, given the history of the last 
time we moved IPs. This time, we saw no interruption or problems with 
email.


Small senders do just fine getting into Google.



We're a small sender as well, and rarely have problems with Gmail 
(Microsoft is, historically, more of an issue for us). But, we consider 
the reputation of the hosting company when choosing a VPS for email.


However, there is a perception that it's hard, so if Google can improve 
that perception, it wouldn't harm them.


However, any changes that Google make would have to be scaleable and not 
affect their existing service - and that's outside my experience, so I'm 
reluctant to give them 'advice' ;-)




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Gmail marking email from me as spam

[Paul Smith via mailop]

On 10/10/2019 13:43, Jaroslaw Rafa wrote:

However, if you announce your e-mail address publicly, by eg. putting it on
a website as your contact address, or participating in a mailing list like
this one using this address, you are actually inviting people to contact you
at this address


Indeed. So anyone using an advertised email address should be checking 
spam folders regularly. Failure to do so means that they're not really 
that interested in receiving emails.


This is not Google's fault. It's the fault of the people who publish 
gmail email addresses and then don't check them properly. If they cared 
about receiving unsolicited emails, then they'd either (a) use their own 
mail server with their own rules, or (b) learn to use the email service 
they've chosen so as to eliminate the chance of false positives.


If Google *blocked* your mail or, worse, silently discarded it, then you 
may have more of a point, but putting your mail into a spam folder seems 
a perfectly legitimate action to me, especially given that you've chosen 
to associate with spammers (albeit, possibly unknowingly).


Again - if you want to solve the problem, stop paying a spammer-friendly 
company, and look for a new hosting service or a reputable SMTP relay 
service. There are many out there who take abuse of their services 
seriously.


You aren't going to get anywhere by arguing that people are being 
unfair. The last I saw, Google were blocking/filtering 10 million spam 
messages *A MINUTE*. Yes, you read that right. I can't even imagine 
that, but that's what they're doing. They have to use lots of tricks to 
achieve that.


I believe they aim to keep false positives below 0.05% and I believe 
they're quite good at achieving that. However, 0.05% out of of billions 
of emails, means that some legitimate ones will be blocked. You need to 
do what you can to stay out of that 0.05%, so choose a reputable service 
for sending emails.


Gmail isn't my favourite service for various reasons, but badly blocking 
legitimate mail isn't one of the reasons. (It is one of the reasons I 
don't like a certain other big ESP). Gmail has blocked us in the past, 
but we've understood why and sorted it out. You've been told the 
probably reason why your mail is being blocked, so you know what you can 
do about it.



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Gmail marking email from me as spam

[Paul Smith via mailop]

On 10/10/2019 13:10, Jaroslaw Rafa via mailop wrote:

It's a basic mistake to operate on whole netblocks and not individual
senders. It's like you would ban all citizens of a particular country X from
coming to another country Y, because a lot of people from country X are
terrorists.


If 99.9% of people from a country were terrorists, then you may allow 
someone in if they're not obviously a terrorist, but you'd certainly 
keep a close eye on them. Trusting someone just because they say they're 
not a terrorist would be too dangerous.


That's the equivalent of putting their mail in the spam folder. You're 
not rejecting it, because you're not 100% sure, but you're almost 
certain it's bad.


If you rejected it, the recipient could do nothing, but because you put 
it into their spam folder, the recipient can find it and choose to 
whitelist you.


As I've said before, if someone uses a gmail account (or other free 
cloud account) for important business email, they should at least giving 
their spam folder a cursory check every few days.



You have to understand that these netblocks are immensely bad, and there 
seems to be no abuse control at all. They're not just so-so - they are 
really bad, and the spammers change IP addresses frequently, which means 
that you can't assume that an IP address from the block which hasn't 
sent spam before won't send spam later on today.


The best thing is for you to move to a hosting company which actually 
takes abuse seriously.  It's pretty pointless arguing about it - it's 
the way it is. If you use a spammer haven to host your emails, you're 
likely to be blocked, so don't do that.



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Gmail marking email from me as spam

[Paul Smith via mailop]

On 09/10/2019 20:36, Jaroslaw Rafa via mailop wrote:

Dnia  9.10.2019 o godz. 13:23:16 John Levine via mailop pisze:

If you're not willing to pay 10€ for a real domain name, why should anyone
put any effort into accepting your mail?

Just because you should by default accept mail from everyone *unless* the
sender proved to be nasty/harmful/mailicious etc.?
Otherwise you are breaking the very purpose of e-mail.


They are 'accepting' mail from you, just putting it into the spam folder.

Nowadays, you'd be daft to accept mail from anywhere unless the sender 
'proves' to be nasty. Generally, you'll find it more likely to work the 
other way. If you're an unknown sender, you're likely to be filtered 
until you're proven to be good. This is especially the case if you're 
using a TLD or network with a bad reputation. In that case, simply by 
using those low-rep things, you are broadcasting that you're *likely* to 
be bad. It's the same as walking into a war zone wearing the enemy's 
uniform. You may not be the enemy, but you're very likely to be, so 
don't be surprised if you get shot.


Content filtering isn't 100% accurate, and is CPU intensive, so large 
receivers will work off reputation (which is low-CPU) as well as content 
filtering.




Well, Gmail is basically "free stuff" as well. Yahoo is "free stuff". In my
country, Onet, WP and Interia are big free e-mail providers as well. Should
nobody accept mail from them just because they are free?


No, but they are often treated with suspicion because of that. No one 
will say 'Oh, it's from gmail, we'll accept it blindly'.


I know I'd never use a free email account for an important account - you 
get what you pay for. If you use a gmail (or Hotmail, or Yahoo) email 
address for business, then you shouldn't be surprised if you lose emails.


OTOH, from experience, Google do take note of spam reports to them, 
either about gmail spammers or about gmail dropboxes. So, the proportion 
of bad gmail email addresses to good ones is probably quite low. Compare 
that to the proportion of bad/good domains on certain TLDs and you'll 
see that gmail email addresses are far more trustworthy.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Gmail marking email from me as spam

[Paul Smith via mailop]

On 07/10/2019 15:47, Graeme Fowler via mailop wrote:


Also you're on OVH, about which a quick look through the list's archives will 
possibly prove instructive. It's reasonably likely (as likely as not) that 
you're running on an IP in a neighbourhood with some poor neighbours.


From personal experience, the 'bad neighbour' syndrome is a bitch...

It's also quite hard to get around as a small mailserver operator. All 
the cheap hosting companies are likely to suffer from 'bad neighbour' 
problems, and you often can't run a sending MTA from a home/SMB 
broadband connection.


You could stick with it. As a few recipients start removing you from 
their spam folders, your reputation may improve slowly.


An easier (but more expensive) 'solution' would be to pay to send your 
mail through an SMTP relay service operated by someone else. Maybe your 
ISP has such a service you can use, or there are companies out there 
that'll do it for you, and part of what you're paying for is their 
efforts to manage their servers' reputations.


On 07/10/2019 15:58, Jaroslaw Rafa via mailop wrote:

No, it's not their network. It's our common network. If anybody imposes own
rules on their part of the network, we are losing interoperability. Internet
loses any sense.


But Gmail is their system. They can decide which emails to accept and 
which not to (or which to put into a user's spam folder). If the 
recipients don't like it, they can complain to Gmail (or go elsewhere).


From my experience, Gmail is actually not that bad - at least they put 
your message into a spam folder where it may possibly be found. I know 
other big email service providers who will just silently discard your 
messages, never to be seen again.





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Weird blocking by outlook.com (S3150)

[Paul Smith via mailop]

On 22/08/2019 16:08, Benoit Panizzon via mailop wrote:

One of our mail platform IP has once more been hit by an outlook.com
blocking:

host outlook-com.olc.protection.outlook.com[104.47.4.33] said: 550 5.7.1
Unfortunately, messages from [157.161.12.116] weren't sent. Please contact
your Internet service provider since part of their network is on our block
list (S3150). You can also refer your provider to



It's probably the "bad neighbour" problem

You may not have been spamming, but Microsoft have seen lots of spam 
from rest of the 157.161.0.0/16 network which your IP address is in. So, 
Microsoft have decided to block the entire block, which includes you.


If you contact the Outlook.com team they may be able to put an exception 
in for your IP address. (They've done that in the past for us, but not 
every time).


https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75

Alternatively, change your hosting company to one which takes more care 
to stop spammers using their servers/network.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] live.fr admin required

[Paul Smith via mailop]

> 
> I've had people do that to my Gmail account.  After a few rounds of
> politely asking them to stop which they ignored, I started using the
> notices to close accounts and cancel plane tickets.
> 
> I realize that's rude, but what do they expect if they insist on
> sending their mail to an unwilling stranger.
> 

I’ve had people do it to accounts on our main domain. I’ve eventually done 
things like that as well.

What I’ve also done is found an email address (enquiries/support/etc) at the 
forwarding company and re-forwarded the mail on to that, in the hope that by 
annoying them, they’d take action because polite requests didn’t work.




-- 


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe


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

Re: [mailop] Hotmail: Moving Email to 'spam' folder generates ISP complaint?

[Paul Smith via mailop]

On 16/08/2019 09:47, Benoit Panizzon via mailop wrote:


Yes, this is exactly the 'feature' one of the customers described to
me. He moves read emails he does not want to keep to the 'spam' folder,
because they disappear after a couple of days.



Don't 'deleted' messages disappear after a few days as well? I honestly 
don't know because I've not used Hotmail for ages or Office365 at all, 
but it seems like a fairly standard thing to happen.



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] SPF: What happens if includes specify different 'all' settings?

[Paul Smith via mailop]

On 27/06/2019 11:15, Andrew C Aitchison via mailop wrote:


For RFC7208, section 5.2
   In hindsight, the name "include" was poorly chosen.  Only the
   evaluated result of the referenced SPF record is used, rather than
   literally including the mechanisms of the referenced record in the
   first.  For example, evaluating a "-all" directive in the referenced
   record does not terminate the overall processing and does not
   necessarily result in an overall "fail".  (Better names for this
   mechanism would have been "if-match", "on-match", etc.)

In practice this means that any "all" records in the include: are 
ignored.



Actually that's not true (AIUI)

If the included record said "all" (or "+all" rather than -all, ~all, 
?all) then that "all" record *would* be evaluated.


Basically any "+" matches from the include will trigger the qualifier 
associated with the "include" (which is normally "+")


It's actually that any "-", "?" or "~" qualified mechanisms in the 
included record are essentially ignored (except as early exit conditions 
when processing the record)


So, if the included record said "-ip4:123.0.0.0/16" then that would be 
(sort of) ignored just as "-all" is.


(See the table on page 22 of RFC 7208)

(An included record of "-ip4:123.123.123.123 ip4:123.123.123.0/24" would 
match every 123.123.123.x IP address except 123.123.123.123)




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] The utility of spam folders

[Paul Smith]

On 24/04/2019 10:51, Laura Atkins wrote:



You cut the portion of the previous post I was specifically responding 
to. Specifically this sentence:


“[MS employees should] be able to guess if you're a probable spammer 
or a legitimate sender who's been caught out, and then be helpful or 
not based on that.”


I was pointing out that it’s not that easy . And, given they're 
guessing, perhaps they guessed wrong.


I wasn't suggesting that they unblock an IP address based on a 'guess', 
but that if the recent mail from that IP address looks legit, they could 
spend a bit more time on it, and maybe give the sending admin a bit more 
advice - eg 'your SPF records are wrong' or 'the IP address has a bad 
reputation, this is a link to how to resolve that' or something rather 
than their current useless 'not eligible for mitigation, now go away, 
and don't reply to this message' response.


If they DO unblock an IP address, then they're quick enough to block it 
again if necessary (which is the right thing to do).




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] The utility of spam folders

[Paul Smith]

On 24/04/2019 02:22, John Levine wrote:


But the vast majority of people who would use a system like that would
be spammers to try to get their unwanted mail delivered.  That's never
going to happen.


The thing is that Microsoft have the SDNS system already.

But for small senders it's of limited use.

The '100 messages a day' threshold they have means that small senders 
get zero information from it. We have multiple smarthosts which send 
several thousand messages a day, but because they send <100 to Microsoft 
email addresses, they're not listed.


I've had cases where their 'View IP Status' shows no problems, but some 
of our IP addresses are blocked. Even the next day it shows no problems, 
so if it's meant to show the previous day's status, it's still not 
showing it.


Occasionally we have had IP addresses shown up as blocked on 'View IP 
Status', but it shows no reason or information to help get it unblocked 
- so it tells us nothing we didn't already know.


If something showed a basic reason for blocking - "too much reported 
spam", "IP reputation" etc, then it would at least give a bit of help.


We've had IP addresses show as 'green' on their 'View Data' list for 
days, and then suddenly be blocked, and we have no idea why (they 
weren't sending spam - we log all the messages sent) and no useful way 
to get them unblocked.



Outlook has no idea who you are, and they have no way to tell you from
any other mailer whose mail they're not delivering.


When you contact Microsoft about an IP address, THEY should be able to 
see what some recent messages from that IP address were, and why it's 
been blocked, to be able to guess if you're a probable spammer or a 
legitimate sender who's been caught out, and then be helpful or not 
based on that.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Anyone from Mandrill/Mailchimp here?

[Paul Smith]

On 27/02/2019 20:56, Matt Gilbert via mailop wrote:
I understand how frustrating this can be for you who have received one 
of these emails, and I personally thank you for keeping those tinfoil 
hats on tight.



It wasn't that frustrating for me - it's phishing, I see them all the 
time, but I thought it was clever to use an email platform to perform a 
phishing attack against itself.


This meant that it passed basic 'is this forged' checks because of that 
(eg it was DKIM signed by Mailchimp). Thankfully, (a) I've learned to be 
ultra-suspicious, and (b) I'm fairly sure I just have a free Mailchimp 
account, so why I'd be asked to check my billing details was suspicious.


I didn't know it was already known about, so I reported it :-) Normally 
I don't bother because I know there's nothing that the phishee can 
reasonably do about it, but in this case there was.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

[mailop] Anyone from Mandrill/Mailchimp here?

[Paul Smith]

We've just received what I'm 99% sure is a phishing email - sent through 
the Mandrill/Mailchimp infrastructure, claiming there's a problem with 
our Mailchimp account. The links go to landing pages on MailChimp, and 
it's clever.


So, it needs sorting, ASAP, because it's quite likely to catch people 
out, given that it's claiming to be from Mailchimp, the links go to 
Mailchimp pages (which look like Mailchimp login pages, but aren't 
quite), etc.


I've reported it to ab...@mandrillapp.com as well, but that may take a 
while to get through, so thought I'd try a different channel as well...


Headers:

Return-Path: 


DomainKey-Status: non-participant from=nore...@drsha.net; domainkeys=fail
Authentication-Results: lmail.pscs.co.uk; spf=Pass
 
smtp.mailfrom=bounce-md_30903452.5c76c31e.v1-cef683aebe194acebd48d0ee66249...@mandrillapp.com
 smtp.helo=mail136-28.atl41.mandrillapp.com; dkim=pass (signature verified)
 header.i=nore...@drsha.net; dkim=pass (signature verified)
 header.i=@mandrillapp.com; auth=none
Received-SPF: Pass client-ip=198.2.136.28; 
envelope-from=bounce-md_30903452.5c76c31e.v1-cef683aebe194acebd48d0ee66249...@mandrillapp.com; 
helo=mail136-28.atl41.mandrillapp.com; identity=mailfrom
Received: from mail136-28.atl41.mandrillapp.com ([198.2.136.28] 
(mail136-28.atl41.mandrillapp.com)) by lmail.pscs.co.uk ([192.168.66.70] 
running VPOP3) with ESMTPS (TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384) for 
; Wed, 27 Feb 2019 17:04:37 -
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=mandrill; 
d=drsha.net;
 h=From:Subject:Message-Id:To:Date:MIME-Version:Content-Type; 
i=nore...@drsha.net;

 bh=bjT9fpLnOr3an+CY799OLe4k3utaSPU5laFCWT8pwCg=;
 b=gQinse9xWTicS6IrV9weXt2IV1IcoZfAU7bSiuz+iVUqUs4FbEwORfiYx3xatb1VPmjHq2PSeYbR
bEYOgo/YmI87WzJMOgCIdBFQoNMzYmRg8pmJiQKAWzaTv8kT14AJzChsZbnsT0/H9tiQ/N5rqjU3
   x2G+/fYQ/zkjhbW95JM=
Received: from pmta04.mandrill.prod.atl01.rsglab.com (127.0.0.1) by 
mail136-28.atl41.mandrillapp.com id her1ia1sb1ku for 
; Wed, 27 Feb 2019 17:04:30 + (envelope-from 
)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
 i=@mandrillapp.com; q=dns/txt; s=mandrill; t=1551287070; h=From :
 Subject : Message-Id : To : Date : MIME-Version : Content-Type : From :
 Subject : Date : X-Mandrill-User : List-Unsubscribe;
 bh=bjT9fpLnOr3an+CY799OLe4k3utaSPU5laFCWT8pwCg=;
 b=Ftc1ffes3M9osTYrxu23+LeE++UDNvFpKZMEUjD1F6FuYJIQ2gp0rUgiLqQy4TUM9VI9Qr
 1jL/nIskU8jImnlHy6jyv//1mlU2W+FoJ5KJTTr09SkWzdQ03EFexi2Gv3zIK0MerQxED/rR
 SPhuTsNtFXI2kBhK7OsbgWra44C5M=
From: MailChimp Billing 
Subject: MailChimp Billing Dispute In Progress
Return-Path: 

Received: from [138.68.74.240] by mandrillapp.com id 
cef683aebe194acebd48d0ee662499fe; Wed, 27 Feb 2019 17:04:30 +

X-Mailer: Apple Mail (2.2104)
Message-Id: <2b2604b9-8adc-e769-5633-d2471df00...@drsha.net>
To: 
X-Report-Abuse: Please forward a copy of this message, including all 
headers, to ab...@mandrill.com
X-Report-Abuse: You can also report abuse here: 
http://mandrillapp.com/contact/abuse?id=30903452.cef683aebe194acebd48d0ee662499fe

X-Mandrill-User: md_30903452
Date: Wed, 27 Feb 2019 17:04:30 +
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="_av-tmIbwtKaFByrlcctRqVPTg"


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

[mailop] Confusing error message from outlook.com

[Paul Smith]

Just had someone report this error to me, and I'm unsure what *actually* 
happened:


Reported error:
550 5.4.355 Remote server returned recipient domain does not exist -> 
550 #5.1.8 Domain of sender address  does not exist


DSN generated by: CWXP265MB1333.GBRP265.PROD.OUTLOOK.COM

Remote server: avasin02.plus.net


I've hidden the email address because it looks like it was a glitch 
somewhere because it's all working fine now, so the domain details don't 
matter - but it's the meaning of this error message that's puzzling me 
slightly.


The sender's domain ("example.co.uk") is hosted with Outlook.com and 
that's where the message was sent from.


The error says that both the sender domain AND recipient domain don't exist.

My guess is that the outlook.com mail server tried to send the message 
to "avasin02.plus.net" and that server responded with "550 #5.1.8 Domain 
of sender address  does not exist"


Then Microsoft's Outlook.com mail server decided to be "clever" and 
interpret the received error message to try to make things "easier" - 
and re-interpreted it to a quite different meaning of the *recipient's* 
domain not existing.


Does that sound like what's happened?

The misinterpreted error message caused confusion and consternation by 
our customer (the recipient) because they thought their domain had 
vanished somehow.



(BTW - the sender's domain does exist, but I guess that PlusNet's DNS 
servers glitched at that moment)





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] TLS Statistics

[Paul Smith]

On 18/12/2018 13:54, Benjamin BILLON wrote:

One of the basic principles of GDPR however is that whatever doable should be 
done to keep personal information safe. So if you have the feature to use 
encryption, you must use it. Nowadays in Europe, opportunistic TLS would be the 
bare minimum.


You do not have to do what is "doable". You have to do whatever is 
*practical*. Investing in armoured vehicles to transfer your data is 
certainly "doable", but not really "practical".


So, yes, if strong email encryption is available, use it, but if it's 
not, then, unless it's sensitive information, it is probably fine to 
send it unencrypted or using a lesser encryption. Your data risk 
assessments should let you know whether that's OK or not. GDPR is quite 
pragmatic in that way.


Most emails do NOT contain sensitive information. Email addresses & 
names are not 'sensitive information'. Financial & medical details are 
'sensitive information'.


If you had to use encryption, then using session encryption will most 
definitely NOT keep sensitive data safe. The mail could be processed by 
or stored by multiple servers, including those which may not be subject 
to GDPR and those will have access to the message data if you are only 
using session encryption. The details & locations of the servers which 
can access the mail data will not be known to most email users (in fact, 
unless both sender and recipient mail admins get together to discuss it, 
NO ONE will know which servers have access to a particular message)


People often think 'Ooh, my emails are sent using TLS1.3 encryption - no 
one can see them, they're safe'. Nothing could be further from the truth.



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] TLS Statistics

[Paul Smith]

On 18/12/2018 10:52, Sidsel Jensen wrote:
What Frands is referring to, is the local Danish requirements by our 
national Danish Data Protection Agency called “Datatilsynet” - their 
statement by which Danish companies need to comply by January 2019 can 
be read



Ah, so it's a Danish thing, not actually GDPR.

There's a reason GDPR itself never actually says "use encryption". It 
just says that encryption is something you may decide to use if it's 
technically possible and you feel it's appropriate. For email, it's 
arguable that it's not technically possible to enforce the use of 
encryption - because even if only 5% or so won't be deliverable in that 
case, that's a LOT of emails.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] TLS Statistics

[Paul Smith]

On 18/12/2018 07:00, Frands Bjerring Hansen wrote:

TL;DR: GDPR requires TLS 1.2. Do you have stats of TLS delivery?


GDPR doesn't require any sort of encryption...

Someone may have told you it does - the chances are they were trying to 
sell their services to you, or didn't understand what GDPR actually says.


GDPR requires 'risk-based measures', so if you are emailing out a 
general newsletter to people, then no encryption is needed, but if you 
are emailing medical records, you should probably use end-to-end 
encryption (eg PGP or similar)


Remember that SMTP TLS doesn't encrypt the message at all while it's 
stored on servers. So, it's OK sending your email using the strongest 
encryption available, but once it reaches that gmail account, Google can 
read it with no problem at all (they may say they won't, but there's no 
technical reason they can't). So, unless you are sure there are no third 
party providers involved in the end-to-end ROUTE of that email, you 
should use end-to-end encryption for sensitive personal information. Or, 
you need to get data processor agreements from all the people involved 
in that email's route.



PCI-DSS requires TLS 1.2 (AFAIAA), but then, for email, it's also OK to 
use no encryption at all, so take from that what you will...




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] What should an MTA do when receiving 452 4.5.3 (aka too many recipients)

[Paul Smith]

On 13/12/2018 08:29, Benoit Panizzon wrote:

Hi List
So based on my observation I wonder...

Upon receiving a 452 4.5.3 error, what should the sending MTA do?
Reconnect immediately and re-try the soft failed recipients as would
be done with the usual 'too many recipients' situation? Or is it
correct to wait for the backoff timer?



The ONLY thing the sending MTA is required to do is to try the message 
again later.


It does not have to interpret the error message beyond the initial '4' 
character meaning 'try again later'.


Read RFC 5321 section 4.2.1.

https://tools.ietf.org/html/rfc5321#section-4.2.1


Even if a sender does interpret more characters, then according to RFC 
5321, the 452 response code means (section 4.2.2):


 452  Requested action not taken: insufficient system storage

So, an immediate retry is probably not warranted by that response code.


The 4.5.3 extended status code may give more information, but there's no 
need for an email sender to even know that those extended status codes 
exist. Note that according to the IANA 
(https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml) 
, the 4.5.3 should be preceded by 451, not 452 (SMTP defines 451 as 
'Requested action aborted; error in processing')






--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] GDPR and SMTP in general

[Paul Smith]

On 25/05/2018 11:22, Stefano Bagnara wrote:

On Fri, 25 May 2018 at 11:55, Paul Smith  wrote:

[...]
If someone sends a message from the UK to someone in the USA, by
definition, we must send that email outside of the EU. When we send the
email, we are sending personal data (eg usually the name/email address
of the sender never mind the content which could be anything (outside
our control)). That causes issues for GDPR.

NO, you are not transferring them as processor.

Why not? We are 'processing' personal data on behalf of the controller.

"Processor means a natural or legal person, public authority, agency or 
other body which processes personal data on behalf of the controller."


"Processing means*any operation* or set of operations which is performed 
on personal data or on sets of personal data", including such basic 
things as storage and erasure of data. If simply storing data on 
someone's behalf is 'processing', then distributing an email certainly 
is (at the very least, the data is temporarily stored, and then erased, 
both of which are explicitly listed as 'processing')





It's not YOU, it's the sender that is sending and in "control" of this
operation and perfectly aware that the email moves informations around the
world to be sent to a specific target, IMHO.


Yes, they're 'in control', so they're the Data Controller. Under GDPR a 
'Processor' is defined as pretty much anyone who touches that data on 
behalf of the Controller (and doesn't make decisions about it) - which 
is any SMTP server (and possibly network) which the messages passes through.


(I'm fairly sure this isn't the intention, but it's what the GDPR words 
say, and trying to explain to a worried customer that the words don't 
mean what they say isn't going to get very far)



When (outside the domestic use case) you use Gmail or Hotmail (just to name
2) to host your job emails/contact lists, you are using Google or Microsoft
as processor of your contact list data (for which you are the controller).
You would need a DPA from Microsoft or Google about that, but they don't
give this for free inboxes. You'll need Office365 or GSuite for your
business even if you are a personal business.
Oh, I agree with that totally. But people like gmail, and it's free so 
they won't even think about that.





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Paul Smith]

On 25/05/2018 11:14, Rolf E. Sonneveld wrote:


Yes, dealing with exactly the same kind of problem(s). One of my 
customers asks me to sign for the fact that mail is encrypted when 
handling it. However, using standard MTA software, messages that are 
in the queue waiting to get delivered, are unencrypted. Am I forced to 
use disk encryption? 


For that, I've just told people that the mail is held unencrypted 
locally, and if they want them to be encrypted, then I've told them to 
use end-to-end encryption (eg PGP, password-protected ZIP/DOC file etc)


I've explained that even if the mail is encrypted here, we have no way 
to make sure it's encrypted anywhere else, unless they use end-to-end 
encryption.


To be honest, there's little point using disk encryption for this, but 
it's hard to explain that to people. If someone can hack into the 
server, the disk encryption achieves nothing. If the server can restart 
automatically and "enter it's own" decryption key, then disk encryption 
achieves nothing. If it needs the key to be manually entered at reboot, 
then that's a disaster waiting to happen. If the software can decrypt 
its own encrypted data automatically, then the decryption key/method is 
on the PC, so not going to stop a determined attacker.


Disk encryption is great on a laptop. Not sure it is anywhere else.


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] GDPR and SMTP in general

[Paul Smith]

On 25/05/2018 11:33, Graeme Fowler wrote:

On 25 May 2018, at 10:46, Paul Smith  wrote:

But, how it interacts with email, it all seems to get very horrible. I suspect 
the *intention* is OK, but I'm struggling with the actual regulations.

Whilst this specific article (written by Andrew Cormack of Jisc UK) pertains to 
packet-pushing, it's conceptually identical to the SMTP "issue" you raise:

https://community.jisc.ac.uk/blogs/regulatory-developments/article/are-networks-data-processors

In your context, the processor is the sender (or sending organisation). It's 
not you. They're the ones making the decision to shift data from A to B, you 
are only the conduit (or one of many).


I wish that was the case, but it's not what GDPR says, certainly for 
SMTP relay services


Article 28: (1) "Where processing is to be carried out on behalf of a 
controller, the controller shall use only processors providing 
sufficient guarantees to implement appropriate technical and 
organisational measures in such a manner that processing will meet the 
requirements of this Regulation and ensure the protection of the rights 
of the data subject."


Article 4: (2) "Processing means *a**ny operation* or set of operations 
which is performed on personal data or on sets of personal data, whether 
or not by automated means, such as collection, recording, organisation, 
structuring, *storage*, adaptation or alteration, retrieval, 
consultation, use, *disclosure by transmission*, *dissemination* or 
*otherwise making available*, alignment or combination, restriction, 
*erasure* or destruction;"


SMTP relay services do the highlighted operations on personal data. Thus 
they are Data Processors. Whether a pure network operator is is more 
debatable, but 'any operation' is a broad brush.





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] GDPR and SMTP in general

[Paul Smith]

I've been going through some GDPR stuff. Amongst other things, we 
provide SMTP relay services to some customers, so are a 'Data Processor' 
under GDPR. In itself, that's OK as our own operations are GDPR compliant.


But, how it interacts with email, it all seems to get very horrible. I 
suspect the *intention* is OK, but I'm struggling with the actual 
regulations.


If someone sends a message from the UK to someone in the USA, by 
definition, we must send that email outside of the EU. When we send the 
email, we are sending personal data (eg usually the name/email address 
of the sender never mind the content which could be anything (outside 
our control)). That causes issues for GDPR.


When we send the outgoing message to another mail server, that other 
server's operator is also a Data Processor. According to Article 28 of 
GDPR, we have to get prior approval of the Data Controller before using 
them, and a responsibility to check that they are GDPR compliant. 
Obviously that isn't going to happen in any feasible way...


Then there's the question about whether Internet connectivity/Wifi 
hotspt providers are also Data Processors as they potentially have 
access to the message data (including personal data) and could be 
classed as 'processing' it.


Also, if a user is on holiday in the USA and downloads email to their 
phone or in an Internet cafe, we are 'sending it outside the EU', so 
again, GDPR has issues.



I thought it was all OK, but one of our customers asked us to sign a 
contract for GDPR which prevents us from sending data outside of the UK 
and from sending it to any other companies without prior written 
permission. I've pointed out the problems to them, but wondered if 
anyone else had come across this.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Disabling TLS1.0 for SMTP

[Paul Smith]

On 22/05/2018 15:47, Al Iverson wrote:

Are folks disabling TLS1.0 support in SMTP? Our security team has
asked, but I'm a bit concerned about potential failure cases when
trying to deliver mail to smaller corporate sites that might be doing
stuff like requiring TLS but supporting 1.0 onlyis that really
much of a concern?


Given that email will drop back to unencrypted if it can't be sent using 
encryption, being too enthusiastic at disabling encryption 
protocols/ciphers will probably just mean that messages end up being 
sent totally unencrypted.


So, is it better to send using a weak encryption or no encryption at 
all? Unless the weak encryption discloses things like private keys which 
could compromise the stronger encryption options, then it's usually 
better to use weak encryption rather than none.


Personally, I'd leave TLS 1.0 enabled unless you're also preventing 
unencrypted traffic and know you will only be dealing with people where 
that won't be a problem (eg on an intranet).




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] spf and mx: tokens

[Paul Smith]

On 11/04/2018 22:41, Carl Byington wrote:

So we could (do what they want) interpret mx:mail.example.com as if it
were a:mail.example.com - we won't be rejecting mail that the sending
domain intended for us to accept. But that just hides their error and
possibly increases the chances of yet more folks making the same
mistake.

What does your code do when it sees mx:mail.example.com, where there is
no mx record, but there is an a record?

Do what the RFC says.

From RFC 7208

   "Note regarding implicit MXes: If the  has no MX record,
   check_host() MUST NOT apply the implicit MX rules of [RFC5321 
] by
   querying for an A or  record for the same name."

That's not ambiguous ;-)



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

Re: [mailop] Anyone from Fasthosts.co.uk on here?

[Paul Smith]

On 25/01/2018 21:46, Carl Byington wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2018-01-24 at 09:30 -0500, Al Iverson wrote:

Smells like a Fasthosts misconfiguration from here.

If they are doing ip queries against the DBL for all connections, they
will be refusing all incoming email. One might think that would be
quickly noticed and corrected. Perhaps they only do those queries for
some subset of the inbound mail.


We haven't had any more instances of this happening since Monday. We 
also had had other (good) mail that had worked before suddenly being 
blocked due to other DNSBLs. So, my suspicion is that over the weekend 
someone decided to 'improve' their spam filter and went a bit too far, 
and then at least some of those 'improvements' were rolled back on Monday.


(Our server doesn't use an IP address literal in EHLO, so I don't think 
it's that).





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

Re: [mailop] Anyone from Fasthosts.co.uk on here?

[Paul Smith]

On 24/01/2018 13:43, Olaf Petry - Hornetsecurity wrote:

dbl.spamhaus.org is a domain blacklist,

So I guess the email contains a link which is listed there and the reject code 
is an unfortunate phrase.


You'd hope so - but, no. The email contains no links and the sender's 
domain is not in the DBL (at the moment). I suppose the sender's domain 
could have been in the DBL at the time the message was sent, but there's 
no way to tell.





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

[mailop] Anyone from Fasthosts.co.uk on here?

[Paul Smith]

We've had some messages rejected from Fasthosts' MX mail servers with an 
error like this:


--
550 5.7.1 Service unavailable; client [188.65.177.237] blocked using 
dbl.spamhaus.org


--

dbl.spamhaus.org doesn't list IP addresses, so I'm not sure what's going 
on. I don't know if someone has gone a bit mad and added all the DNS 
blacklists they can find to their spamfilter, not realising that 
dbl.spamhaus.org is a domain blacklist, not an IP blacklist.


When you do query dbl.spamhaus.org with an IP address, it gives a 
response which could be interpreted as meaning the IP address is listed, 
so that could be why the messages are being blocked.





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

Re: [mailop] Best rate limiting response?

[Paul Smith]

On 12/09/2017 22:36, Brandon Long via mailop wrote:
So, looking at our code, for our daily send limits for consumers, we 
do use a 550 response.


Thinking about this, it makes sense.  It's not a short term temporary 
condition, it's something that could take hours to resolve, and having 
your mail sit in your outbox for who knows how long retrying, and 
maybe the user doesn't notice and shuts down the computer or whatever, 
it never goes out.


This changes if you have another MSA submitting to yours. We have this 
here when we have customers running our mail server software on their 
networks and send through our relay service. (They can't have their 
local mail server send direct because they don't want the hassle of 
handling all the stuff involved with doing that). We charge for this 
service based on usage, so they have a monthly allowance.


So, they may have 100 people sending mail to their MSA which then sends 
it to ours.


If they reach their send allowance, and we reject with a 4xx response 
then their MSA queues them up. Then, the local mail admin can contact us 
and say 'oops, we need to increase our sending allowance', we charge 
them a few quid more, and their MSA then sends all the messages with no 
more user interaction.


If we reject with a 5xx response, then their MSA sends NDRs to all the 
users, who then have to re-send all the failed messages. That may be a 
lot of messages depending on how they have their MSA set up and how busy 
they are. The users won't know what is going on (you can't expect them 
to read the NDR), so they'll waste their time trying to resend when it's 
just going to fail again. So, the mail admin gets hassled by users, and 
has to get in touch with each of them and walk them through how to read 
NDRs, how to check whether messages were sent or not, and how to re-send 
messages, the user may even have to rewrite messages from scratch 
depending on how they have things set up.


So, we use 4xx when rejecting due to send limits, because it's less 
hassle for the users (and admins) in this situation.


To be honest, whether an MSA rejects a message with a 4xx or a 5xx 
response, I'd expect the MUA to alert a user that the message can't be 
sent. I wouldn't expect an MUA to queue up messages which failed with a 
4xx response because that's not what the user would expect to happen. 
But, maybe that's a bit optimistic of me.


So, I'd say reject with a 4xx response because MUAs should tell the user 
immediately and MSAs should automatically resend the messages when the 
problem is resolved.


Paul


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

Re: [mailop] Sender MX pointing to *.registrar-servers.com => 100% Spam!

[Paul Smith]

On 31/08/2017 16:15, Benoit Panizzon wrote:


Strange, todays active domain is: apparty.bid

apparty.bid descriptive text "v=spf1 ip4: -all"

We do check SPF, so why did this email pass? Is 'ip4:' equivalent to
the whole IPv4 space?


No, that's an invalid rule. Maybe your SPF checker is letting mail 
through if the result is 'PermError' (which is what that rule should 
result in) rather than 'Fail'.


(try it in http://www.kitterman.com/spf/validate.html )


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

Re: [mailop] Sender MX pointing to *.registrar-servers.com => 100% Spam!

[Paul Smith]

On 31/08/2017 15:20, Benoit Panizzon wrote:

Now I found one thing in common to those spam mails. All of them point
to MX Records from:

eforward1.registrar-servers.com.
to
eforward5.registrar-servers.com.

run by a registrar service. Interestingly not the same used to register
the domains in question. Does anyone know, if those MX are used for non
spam? Or could this be taken as spam criteria?


I expect that those MX servers are used when the customer has told the 
registrar (Namecheap?) to forward mail for the domain on to a different 
email address. In which case, they'll be used for a lot of legitimate 
domains.


If you google for "eforward1.registrar-servers.com" (including the 
quotes) you'll see lots of people have those set as their MX records.


Now, if the domain isn't registered with the same registrar, that might 
not be legitimate, but they may be related registrars, who are sharing 
services.





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

Re: [mailop] btinternet.com blacklist

[Paul Smith]

On 13/07/2017 03:06, steve wrote:


Depending on how it's carved up, there are at least 50k IP addresses 
in a /16. One line, or... 


From my experience, it's not so much that it's hard work blocking 
individual IP addresses, it's that the spammers move around.


I don't know if the hosting company lets the customer request a new IP 
address, or the customer just orders a new virtual server or something, 
but we'll see similar incoming spam from the same hosting company from 
IP addresses that change several times a day. After a few days of 
chasing this around, it's tempting to just decide to block bigger ranges 
to block the spam before it arrives from a new IP address, rather than 
playing catch-up and blocking IP addresses after they've already been 
abandoned by the spammer.





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

Re: [mailop] btinternet.com blacklist

[Paul Smith]

On 10/07/2017 12:53, Dom Latter wrote:


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



Another thought - you could always have your web hosting with Hetzner 
and have a cheap server with much less storage somewhere else which you 
use for sending mail (so the web server on the untrustable IP address 
sends mail via a relay with an IP address in a nicer neighbourhood).





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

Re: [mailop] btinternet.com blacklist

[Paul Smith]

On 10/07/2017 12:53, Dom Latter wrote:

but other than that a fairly modest server will suffice.  It would be
nice to find a UK provider with, say, 4 x 4TB disk, for < 100USD / yr. 


Do you really mean $100/yr?

That doesn't even cover the cost of 4 x 4TB disks, never mind the rest 
of the server, electricity, bandwidth, redundancy, backups etc


If you mean $100/mth, then I'd look at getting your own server and pay 
to store it in a data centre somewhere. You should be able to get 1U 
colocation in the UK for about that price.



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

Re: [mailop] btinternet.com blacklist

[Paul Smith]

On 10/07/2017 11:11, Dom Latter wrote:


And they are not saying they will blacklist it again if they get
spam from it.  They are saying they might blacklist it again if
they get spam from a *different* IP address - which happens to be
in a similar range.

It's like I move into a house and find that I am banned from having
visitors because somebody once held a noisy party in the house next
door.


To be honest, they're saying "You've chosen to use a badly behaved 
hosting company which helps spammers, so we can't guarantee your address 
won't get blocked again"


You can always change to a hosting company with a better reputation 
which deals properly with spammers. That'll solve your problem.


The only way bad hosting companies will change their ways is if 
legitimate customers go elsewhere. BT are just trying to encourage that. 
I don't generally agree with BT, but this seems reasonable to me. I wish 
Google, Microsoft etc would do the same...





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

Re: [mailop] What are "printing ASCII characters" RFC 850/2822

[Paul Smith]

On 09/06/2017 15:22, Benoit Panizzon wrote:

Well § is a printable character, but it is above the first 127 bytes
(8-bit). So is ASCII defined as being only the first 127 characters, or
is ASCII the full 255 character set, and the upper 127 ones containing
certain control characters and some localized code-table specific
characters.


ASCII is just the first 128 characters (0-127). Above that it is 
something else - Extended ASCII, ISO-8859-1, CP860 etc.


https://en.wikipedia.org/wiki/ASCII

IF Lotus Notes is is using a non-ASCII character in a Message-ID, it's 
wrong.


RFC 5322 has the grammar for a Message-ID. It definitely doesn't allow 
any characters above 127 (and some characters below 127 are only allowed 
in a certain format).


I'd say it's unusual to reject a message because of an invalid 
Message-ID, but a § definitely makes the Message-ID invalid, so the 
receiver can do what it wants and still conform to the standards.


Are you sure that Lotus Notes is using that character? Have you got an 
example?





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

Re: [mailop] Google Postmaster Tools: spam rates

[Paul Smith]

On 31/05/2017 10:29, Anna Ward wrote:
I've talked to a bunch of different industry folks at this point, and 
no one seems to understand the difference between "user reported spam" 
and "feedback loop spam" in Google Postmaster Tools 
.


A notable example for me was May 8th when a client's DKIM domain 
showed a 100% "feedback loop spam rate" but only a 0.1% "user reported 
spam rate" (screenshots ).
They sent to about 4000 Gmail addresses that day, and the one 
identifier in the Feedback Loop graph was "broadcast" (represents the 
message type, a bulk-send newsletter). All of their outgoing mail used 
the "broadcast" identifier like this: Feedback-Id: 
::broadcast:getresponse


I just can't think of a scenario where the Feedback Loop could be at 
100% but the Spam Rate ("user reported") would be at only 0.1%. How 
are such drastic differences possible?


If the feedback loop includes messages caught by their spam filter, then 
if their spam blocked everything, that would show 100% as spam, but most 
users wouldn't see the spam or bother reporting it as spam (because it's 
already been caught) so the user reported spam rate would be approaching 
zero.




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

Re: [mailop] SPF record

[Paul Smith]

On 21/05/2017 14:52, frnk...@iname.com wrote:

sm,

Do you think the sending domain was not aware of that when they wrote the 
policy?


I think a lot of the disagreement comes from differing views on priorities.

For some people, the danger of receiving forged messages is paramount, 
so rejecting messages that could potentially be forged (eg due to SPF 
failures) is important to them.


For other people, the chance of lost messages (especially due to 
forwarding) is important, so you shouldn't reject based on SPF.


I often hear people say that email is "broken" because it's easy for 
people to forge sender addresses, and I know it makes people more 
reluctant to rely on email. Unfortunately, MTA mail forwarding is very 
similar to forging a message (unless DKIM is also used)


Personally, I think forwarding should have died out years ago, but it 
seems a hard habit to wean people off, despite it not working well in 
today's 'reputation-based' email system (any MTA which automatically 
forwards mail WILL forward spam). I know some people disagree with me.


I think if you are running a common forward target (gmail, Hotmail, 
Yahoo etc or even a big ISP) then you should probably be more forgiving 
of SPF 'fail' results than a small mail server operator which is much 
less likely to have random people forwarding mail to them.


Apart from forwarding, you often get mail administrators who haven't got 
a clue about how SPF works, and/or haven't got a clue about which mail 
servers may send mail from their domains.




I know that compared to a year or two ago, we are now getting more and 
more people reporting deliverability problems of their own sent mail due 
to SPF errors they've made. This suggests to me that the general view is 
shifting towards "potentially forged messages are bad" and away from 
"deliver at all costs".


Personally, I think I'd rather have SPF PermError or Fail generate 
delivery failure reports rather than just have messages end up being 
quarantined. At least that way the sender could have a chance to fix the 
problem rather than believing that their messages have been delivered 
successfully. Again, I realize people disagree with me. I'm not saying 
I'm right, just that that's my opinion. I certainly wouldn't configure a 
receiving mail server that way without the responsible people of the 
recipient domain agreeing and being aware of the consequences.



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