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

[Hans-Martin Mosner via mailop]

Am 07.12.20 um 23:51 schrieb Thomas Walter via mailop:
>
> I fully agree, but gmail is a bad example, because they actually support
> importing remote mailboxes with pop3 which does not require forwarding.
> We never tried that, but it is an option:

Well if giving The Goog all kinds of information via search history and gmail 
account isn't enough, we hand them the
passwords to our accounts at other providers on a silver platter. Yup.

Cheers,
Hans-Martin

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

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

[Al Iverson via mailop]

On Mon, Dec 7, 2020 at 3:51 PM John Levine via mailop  wrote:
>
> People do use them as part of a scoring spam filter.  But no sensible person
> uses SPF alone to do mail filtering.

Nobody should, but some do. Whether or not it's sensible, it's
something that some people deal with.

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

It doesn't matter if it's a failure of SPF or not. SPF is something
one has to deal with if one wants to get as much of the mail delivered
as possible.

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

ITYM "harder to do it the old way successfully." Pull instead of push,
or use SRS or other header rewriting and don't try to stretch a
domain's SPF accountability beyond the IPs they publish, and it
actually isn't that hard. Heck, I SMTP auth relay my role account mail
into Gmail to bypass all of that and it works just fine.

Email forwarding itself isn't bad, we agree. External old school
dot-forwarding is outdated and too prone to failure. Tilt at that
windmill all you want, but that doesn't really change anything.

Cheers,
Al Iverson



-- 
Al Iverson // Wombatmail // Chicago
Song a day! https://www.wombatmail.com
Deliverability! https://spamresource.com
And DNS Tools too! https://xnnd.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [FEEDBACK] Azure Spammer Activity

[Michael Peddemors via mailop]

I know, I know.. most already are looking at Azure sourced email with 
suspicion, but kind of wanted to wait until others chimed in on this one..


Took a bit to actually find examples that made it through our filters, 
even to sandbox addresses.. because the email's are so obvious..


Return-Path: <>
 Fake Bounce

Received: from adsfsdfeh96cpyn375xf8s.eastus.cloudapp.azure.com (HELO 
7184.peelregion.ca) (13.90.137.227)

by ...
^^^ No PTR, fake EHLO or stolen Azure resources?

Date: Mon, 07 Dec 2020 23:36:02 +0100
Message-ID: 

^^^ Yeah, like this.. red herring, or an Azure App, allowing email relay

From: "U P S "

^^^ Uh, yeah. someone up to no good, they even tried to obfuscate UPS

To: 
Content-Type: text/html; charset=ISO-8859-1
X-Gm-Message-State: EF8IE3PPU0NK+tZ/EF8IE3PPU0NK+EF8IE3PPU0NK
Subject: Take part in our marketing survey and get $90 : 

 Can you say phishing lure?
X-BeenThere: oa...@co.uk

 Sure you have..

X-Mailman-Version: 2.1.12

 Red Herring, or ??

Precedence: list
List-Id: EF8IE3PPU0NK 


href="https://optimized-by.rubiconproject.com/t/[nu6_15]/[nu_6_15]/[nu_6]-57.[nu_9].[nu_8]?url=https://mysp.ac/TLCHWYXSCVEEKGNIWTDDPGFLPHKJXE/../4kSz3#LxSzzPuRRw;>src="https://mysp.ac/TLCHWYXSCVEEKGNIWTDDPGFLPHKJXE/../4kSzJ; alt="" 
/>
href="https://optimized-by.rubiconproject.com/t/[nu6_15]/[nu_6_15]/[nu_6]-57.[nu_9].[nu_8]?url=https://mysp.ac/TLCHWYXSCVEEKGNIWTDDPGFLPHKJXE/../4kSz4#LxSzzPuRRw;>src="https://mysp.ac/TLCHWYXSCVEEKGNIWTDDPGFLPHKJXE/../4kSzL; alt="" 
/>



And.. of course the link resolves to...

whois fantasticsurvey.com
   Domain Name: FANTASTICSURVEY.COM
   Registry Domain ID: 2568737389_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.name.com
   Registrar URL: http://www.name.com
   Updated Date: 2020-10-28T12:42:56Z
   Creation Date: 2020-10-28T12:42:55Z
   Registry Expiry Date: 2021-10-28T12:42:55Z
   Registrar: Name.com, Inc.
   Registrar IANA ID: 625
   Registrar Abuse Contact Email: ab...@name.com
   Registrar Abuse Contact Phone: 7202492374
   Domain Status: clientTransferProhibited 
https://icann.org/epp#clientTransferProhibited

   Name Server: NS1HWY.NAME.COM
   Name Server: NS2BTZ.NAME.COM
   Name Server: NS3QTY.NAME.COM
   Name Server: NS4BFY.NAME.COM


Hundreds of Azure IP(s) used in this one.. MS, you need to spend a 
little more money on threats from 'within' your networks..




--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Grant Taylor via mailop]

On 12/7/20 2:47 PM, John Levine via mailop wrote:
People do use them as part of a scoring spam filter.  But no sensible 
person uses SPF alone to do mail filtering.


Well ... maybe I'm not a sensible person then.  In the spirit of truth 
and kickings -- thank you Taylor Mali for "What Teachers Make"[1] -- if 
you ask for it, I'm obliged to give it to you.  So if you send me email 
from an unapproved IP and you have asked me to reject unapproved emails 
via -all, them I'm going to reject your email flat out.  After all, 
that's what /you/ as the domain owner / administrator /asked/ me to do.


My personal option is that being soft and not rejecting on -all is 
nothing short of coddling people that seemingly don't know how to 
administer their email infrastructure.


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.


Forwarding may be useful, but is it proper?

Consider the policy standpoint of from the sender's point of view.  I, 
as a domain owner / administrator / operator, provided you information 
on the servers that *I* authorize to send email claiming to be from my 
domain -and- asked you to /reject/ anything that is not from the 
server(s) that /I/ authorized to send email on my behalf.


To me, that very simple /policy/ (who's allowed to send and what to do 
with the riffraff) does indeed conflict with forwarding.  But here's the 
kicker, /forwarding/ in general /conflicts/ with my /published/ desire. 
So, I'm /happy/ that SPF -- when implemented properly by receivers -- 
supports my stated / published goal.


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


Obviously I disagree.  Thankfully SPF w/ -all allows second order 
receivers to know that I have not authorized the first order receiver to 
re-send email on behalf of my domain name.


I can't prevent people from forwarding emails from my domain.  But I 
sure can make it more difficult for them to do so.


[1] http://www.taylormali.com/poems-online/what-teachers-make/



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Jaroslaw Rafa via mailop]

Dnia  7.12.2020 o godz. 15:21:45 Scott Mutter via mailop pisze:
> 
> 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?

Just because having one main mail account and forward mail from auxilliary
accounts to it is more natural (you only have to look at one account) than
having a mail client configured for multiple accounts. I would rather call a
multi-account configuration a poor workaround for e-mail accounts incapable
of forwarding ;).

> For SPF to be effective, if you ask me, the -all modifier has to be used.
> If you can't define a list of IP addresses where legitimate mail from your
> domain is going to be coming from, then what's the point of SPF?

That proves that SPF has no point at all. Exactly because of forwarding.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Thomas Walter via mailop]

On 07.12.20 22:47, John Levine via mailop wrote:
> People do use them as part of a scoring spam filter.  But no sensible person
> uses SPF alone to do mail filtering.

I also thought that no sensible person would discard messages even
though the SPF entry owner asks them to do a softfail, but I guess I was
wrong.
> 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.

I fully agree, but gmail is a bad example, because they actually support
importing remote mailboxes with pop3 which does not require forwarding.
We never tried that, but it is an option:

https://support.google.com/mail/answer/21289

But yes, please do not bash forwarding, just because someone invented a
mechanism that ignored the basics of email traffic.

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Michael Peddemors via mailop]

For us, we encourage SPF usage in DNS, simply because the 'big guys' 
want it or penalize you...


As far as inbound, while SPF can be treated as a marker for various 
forgeries, and also sometimes a specific spam vector, we usually ONLY 
reject based on SPF if...


 * The companies SPF is sane
 * The company has a higher risk when the domain is forged (eg banks)
 * The company has a history of being the target of malicious forgery
 * The email system administrator chooses to for domains hosted on 
their own systems



We usually extrapolate the SPF information into a 'Known Sender Forgery 
(KSF)' format, for blocking at the SMTP transport layer, as well as 
outbound checking (infected/compromised email accounts)


And yes, it is a pain when customers allow forwarding, however more and 
more email operators are getting it, and the pain of blocking forwarding 
is less than the pain when users exposed to forgeries. Even our own 
invoices sometimes hit systems with aggressive SPF filtering, where the 
customer has forwarded it another mailbox.. So if you don't get an 
invoice, simply stop email forwarding ;)


Often it is a large phishing bot that uses the domain, (eg forgeries of 
wetransfer.com at hetzner are better stopped at SMTP layer, and pretty 
good evidence that the system should be recommended for inclusion in 
spam outbreak RBL's)


On another note.. anyone else seeing a large increase in Azure based 
spammers over the weekend?







On 2020-12-07 1:21 p.m., Scott Mutter via mailop wrote:
 > 1. You must have an SPF record in order for the big mail providers to 
even think about accepting your mail (softfail seems sufficient).


 > 2. It's not worth rejecting incoming mail simply because it fails 
SPF.There are too many badly configured servers out there


This has been my observation as well.  You have to have an SPF record... 
but because nobody apparently knows how to configure them accurately and 
there's no desire to educate people ... nobody really cares what the SPF 
record says.  But you've gotta have one!


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


For SPF to be effective, if you ask me, the -all modifier has to be 
used.  If you can't define a list of IP addresses where legitimate mail 
from your domain is going to be coming from, then what's the point of 
SPF?  So a message gets denied because you forgot to add that IP to your 
SPF list... now you know to add it.



On Sun, Dec 6, 2020 at 8:03 AM Paul Waring via mailop > wrote:


On Sun, Dec 06, 2020 at 02:12:25PM +0100, 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?

In my experience:

1. You must have an SPF record in order for the big mail providers to
even think about accepting your mail (softfail seems sufficient).

2. It's not worth rejecting incoming mail simply because it fails SPF.
There are too many badly configured servers out there - one example I
see a lot is where a company has not added their web servers to their
SPF record, but they send out transactional emails such as password
resets. You end up not receiving mail or trying to convince the company
that they should fix their SPF record (to which the response is the same
as broken TLS - "problem must be on your end as it works for us").

3. It does seem to be worthwhile having SpamAssassin take SPF failure
into account, not as an absolute rejection but a factor which indicates
that the mail might be spam.

-- 
Paul Waring

Freelance PHP developer
https://www.phpdeveloper.org.uk
___
mailop mailing list
mailop@mailop.org 
https://list.mailop.org/listinfo/mailop


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





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of 

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

[John Levine via mailop]

In article  
you write:
>This has been my observation as well.  You have to have an SPF record...
>but because nobody apparently knows how to configure them accurately and
>there's no desire to educate people ... nobody really cares what the SPF
>record says.  But you've gotta have one!

People do use them as part of a scoring spam filter.  But no sensible person
uses SPF alone to do mail filtering.

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

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Scott Mutter via mailop]

> 1. You must have an SPF record in order for the big mail providers to
even think about accepting your mail (softfail seems sufficient).

> 2. It's not worth rejecting incoming mail simply because it fails
SPF.There are too many badly configured servers out there

This has been my observation as well.  You have to have an SPF record...
but because nobody apparently knows how to configure them accurately and
there's no desire to educate people ... nobody really cares what the SPF
record says.  But you've gotta have one!

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

For SPF to be effective, if you ask me, the -all modifier has to be used.
If you can't define a list of IP addresses where legitimate mail from your
domain is going to be coming from, then what's the point of SPF?  So a
message gets denied because you forgot to add that IP to your SPF list...
now you know to add it.


On Sun, Dec 6, 2020 at 8:03 AM Paul Waring via mailop 
wrote:

> On Sun, Dec 06, 2020 at 02:12:25PM +0100, 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?
>
> In my experience:
>
> 1. You must have an SPF record in order for the big mail providers to
> even think about accepting your mail (softfail seems sufficient).
>
> 2. It's not worth rejecting incoming mail simply because it fails SPF.
> There are too many badly configured servers out there - one example I
> see a lot is where a company has not added their web servers to their
> SPF record, but they send out transactional emails such as password
> resets. You end up not receiving mail or trying to convince the company
> that they should fix their SPF record (to which the response is the same
> as broken TLS - "problem must be on your end as it works for us").
>
> 3. It does seem to be worthwhile having SpamAssassin take SPF failure
> into account, not as an absolute rejection but a factor which indicates
> that the mail might be spam.
>
> --
> Paul Waring
> Freelance PHP developer
> https://www.phpdeveloper.org.uk
> ___
> 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] 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