Re: [mailop] Microsoft JMRP feed broken?

[Eduardo Silvestre]

Our is still coming in however with "internal" microsoft ips like
10.xxx.xxx.xxx which is useless.

Best Regards,

On Wed, Jan 4, 2017 at 1:57 PM, Vick Khera  wrote:

>
> On Tue, Jan 3, 2017 at 9:40 PM, Tim Starr  wrote:
>
>> Is it just us, or others, too?
>
>
> Ours are still coming in.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google blocked senders list

[Michael Peddemors]

While both the MAIL FROM and the From: can of course be forged by 
spammers, you are right that the MAIL FROM is more difficult to forge 
from a properly configured email server.


But it is more difficult for end users to act on the MAIL FROM as it is 
not visible normally.


In our own systems, we have opted for a solution that if a person 
decides to either 'blacklist' or 'whitelist', that we allow it to take 
affect at both levels, but we do it in the sense of 'Block Sender'.


Now, as Brandon pointed out, a lot of the spam will come from obfuscated 
MAIL FROM's, and in some cases some bulk emailers intentionally tend to 
use a similar pattern for ALL email, no matter who the sender, and in 
the case of Gmail with resources to burn, it isn't about performance 
(less of a need to block during the SMTP transaction, and can be dealt 
with later in the filtering levels), so the idea of blocking based on 
what is 'visible', for end users it makes sense probably.  Only problem 
is that it doesn't help when you get emails from the same sender, with 
randomized From addresses, or those spammers who forge someone who's 
address you are familiar with..


Eg.. your bank ;)

However, since the idea of having a blacklist/whitelist at the user 
level is normally a 'last resort', after all other efforts at spam 
protection have been exhausted, and especially since Gmail isn't in the 
customer support business, making clear and simple to understand methods 
rather than technically perfect methods, will reduce customer frustrations.


"I never want to 'SEE' an email which is indicated that it is from this 
person/domain again"


However, having said all that, I feel for you, and personally would like 
to see more ESP's using the real originating email in the email MAIL 
FROM, rather than all emails' coming out as "bou...@espname.com", in a 
perfect world.  In that case, blacklisting both would have more value.


But maybe Gmail needs an advanced option, for the more tech savvy 
individuals, who wish to expressly block based on the address used in 
the MAIL FROM. (eg, maybe I want to block everything from @espname.com, 
no matter what the From: appears to be)


For instance, one of the most requested questions we have on one of our 
spam products, "How do I block all emails from .top domains".  Now, of 
course we would be loathe to simply say anything from one registrar is 
bad, for a tech savvy end user, that could be "his choice" to do at the 
MAIL FROM: level but then again, it could end up being a support 
headache, and even then can be forged.


But in the end, there are always more tools that a tech savvy person 
could use, but in Gmails' case you can understand a one-size fits all 
model is much easier to maintain.


So, as Brandon pointed out, in the odd case where the MAIL FROM is real, 
and the From: is faked, eg in the example of a compromised email account 
being used to appear to send as @fedex.com, something you don't want to 
blacklist, even if you did block the MAIL FROM, it would be 
whack-a-mole, as another address would be used next time. So, unless it 
is to choose to block all email from some large provider there might 
be more efficient ways..


By reporting 'as spam', you help the overall system stop that type of 
spam in the future.


Just my 2 bits to start 2017..



On 17-01-04 09:50 AM, Brandon Long via mailop wrote:

This seems like an odd place to raise this, but ok.

Yes, the blocked sender could be applied to both, I'm not sure if/why it
wasn't done that way.

That said, I actually think if you're going to check one, then it's the
RFC5322.From address which is the more logical choice.  It's also the
more user visible choice.

In many instances, messages are sent with VERP like RFC5321.From
addresses, in the case of most mailing list software and commercial
marketing mail, not to mention several forwarding systems.

In the case of spam, I imagine that both the RFC5322.From and
RFC5321.From are highly variable, we don't expect blocked senders to be
used for the type of spam which mutates in an attempt to evade spam
filters.  In general, playing whack-a-mole using filters or blocked
senders for the worst type of spam is a fool's errand, you're much
better off using the report spam feature and letting our systems handle it.

As for the case where you only want to block the RFC5321.From and not
the RFC5322.From, making the user have to choose which of the addresses
to block seems poor, and blocking the RFC5321.From only seems unlikely
to make sense to users either.

Brandon

On Wed, Jan 4, 2017 at 3:30 AM, Richard Gilbert
> wrote:

I have become aware that the Google blocked senders list is only
applied to the From: address, and that we cannot use it to block an
envelope sender address.  Is it just me who finds this surprising
(especially given its name)?  Why not check both?  It seems illogical
to accept a 

Re: [mailop] Google blocked senders list

[Brandon Long via mailop]

This seems like an odd place to raise this, but ok.

Yes, the blocked sender could be applied to both, I'm not sure if/why it
wasn't done that way.

That said, I actually think if you're going to check one, then it's the
RFC5322.From address which is the more logical choice.  It's also the more
user visible choice.

In many instances, messages are sent with VERP like RFC5321.From addresses,
in the case of most mailing list software and commercial marketing mail,
not to mention several forwarding systems.

In the case of spam, I imagine that both the RFC5322.From and RFC5321.From
are highly variable, we don't expect blocked senders to be used for the
type of spam which mutates in an attempt to evade spam filters.  In
general, playing whack-a-mole using filters or blocked senders for the
worst type of spam is a fool's errand, you're much better off using the
report spam feature and letting our systems handle it.

As for the case where you only want to block the RFC5321.From and not the
RFC5322.From, making the user have to choose which of the addresses to
block seems poor, and blocking the RFC5321.From only seems unlikely to make
sense to users either.

Brandon

On Wed, Jan 4, 2017 at 3:30 AM, Richard Gilbert 
wrote:

> I have become aware that the Google blocked senders list is only
> applied to the From: address, and that we cannot use it to block an
> envelope sender address.  Is it just me who finds this surprising
> (especially given its name)?  Why not check both?  It seems illogical
> to accept a message from an envelope sender address which is in the
> list.  Am I wrong in thinking that in the case of spam the From:
> address is more variable than the envelope sender?  There will be
> cases where we want to block an envelope sender address but unable to
> block the (different) From: address because it is used by legitimate
> mail.
>
> --
> Richard Gilbert
> Corporate Information and Computing Services
> University of Sheffield, Sheffield, S10 2FN, UK
> Phone: +44 114 222 3028
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Jaren Angerbauer]

Responded offline.

Thanks,

--Jaren



On Tue, Jan 3, 2017 at 6:13 PM, Bryan Vest  wrote:

> We have been blocked for 48 hours by SORBS for an email that was in no way
> spam. It did not look like spam and was sent to a small group of email
> addresses. The ip address in question only has this one entry in their
> system and of course no replies to request for answer as to why we have to
> wait 48 hours even though this was not spam nor as to what triggered it as
> spam.
>
> If someone from SORBS could contact me off list or on list I don't care,
> either way we need to get this block removed.
>
>
> --Bryan
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Andris Reinman]

Getting blacklisted too easily by Sorbs et al. was one of the reasons why I 
built a custom MTA instead of using Postfix to deliver mail. 

We have lots of accounts to serve and from time to time someone gets hacked and 
their account credentials are used to send spam. We try to catch outbound spam 
but it gets really tricky because dropping suspicious mail immediately breaks 
automated messages that usually have very poor quality in regards of formatting 
and tend to trigger spam points (eg. your home NAS using your SMTP credentials 
sends a warning message that space is running out on the hard drive).

Anyhow we now use home-brewed MTA (open sourced here: 
https://github.com/zone-eu/zone-mta  ) to 
get past the blacklist blockings - the software is able to use multiple IP 
addresses for sending and if it detects that some host has blacklisted 
currently used sending IP then this IP is temporarily disabled for that 
destination, a warning is raised and the message is routed through some other 
IP as in most cases the message that was blocked had nothing to do with the 
spam that triggered blacklisting. This gives enough time to get delisted while 
not blocking the sending of new messages.

Best regards,
Andris Reinman


> On 4. jaan 2017, at 15:49, Vick Khera  wrote:
> 
> 
> On Tue, Jan 3, 2017 at 8:13 PM, Bryan Vest  > wrote:
> If someone from SORBS could contact me off list or on list I don't care, 
> either way we need to get this block removed.
> 
> How much trouble is it causing you? I find it doesn't cause all that much 
> trouble in terms of mail being blocked. SORBS does not seem interested in 
> solving problems, but in punishing people.
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

Re: [mailop] SORBS help

[Vick Khera]

On Tue, Jan 3, 2017 at 8:13 PM, Bryan Vest  wrote:

> If someone from SORBS could contact me off list or on list I don't care,
> either way we need to get this block removed.
>

How much trouble is it causing you? I find it doesn't cause all that much
trouble in terms of mail being blocked. SORBS does not seem interested in
solving problems, but in punishing people.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Google blocked senders list

[Richard Gilbert]

I have become aware that the Google blocked senders list is only
applied to the From: address, and that we cannot use it to block an
envelope sender address.  Is it just me who finds this surprising
(especially given its name)?  Why not check both?  It seems illogical
to accept a message from an envelope sender address which is in the
list.  Am I wrong in thinking that in the case of spam the From:
address is more variable than the envelope sender?  There will be
cases where we want to block an envelope sender address but unable to
block the (different) From: address because it is used by legitimate
mail.

-- 
Richard Gilbert
Corporate Information and Computing Services
University of Sheffield, Sheffield, S10 2FN, UK
Phone: +44 114 222 3028

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

Re: [mailop] UPC / Liberty Global: No retries after tempfail (greylisting)?

[David Hofstee]

Hi Benoit,

I have forwarded your email to an email admin @UPC. He is a busy man, not sure 
if he will respond. 

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Benoit Panizzon" 
Aan: mailop@mailop.org
Verzonden: Dinsdag 3 januari 2017 10:51:29
Onderwerp: [mailop] UPC / Liberty Global: No retries after tempfail 
(greylisting)?

Hello

Due customer complaints I started inspecting our logfiles for UPC
anomalies.

Indeed, UPC seems to have migrated it's email services from austria
(chello.at ip range) to a Liberty Global IP range in NL

This range is not yet whitelisted by SWINOG or DNSWL.org so our
infrastructure applies greylisting.

And I also see, that delivery is attempted only once, never overcoming
greylisting unless the sender tries again within the right time window.
Worse! The sender does not get any kind of error back, that his email
did not get delivered.

Opening at trouble ticket at UPC switzerland is probably useless as in
the past they were unable to forward those ticket to the mail
infrastructure operators. Also email to the 'postmaster' of the
affected customer domain never get replied.

So does anyone have a direct contact to the operators of the UPC email
infrastructure in the netherlands?

Does anyone know the IP range UPC uses for it's upcmail.net service?
They don't use SPF where I could extract the ranges and whitelist them.

Kind regards

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

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

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