On 17 Oct 2006, at 23:23, Renaud Allard wrote:
> Hi,
>
> Stuart Gall wrote:
>> Hello,
>> I have just came across two servers that are blocking empty envelope
>> to's
>>
>> VIZ
>> telnet mail.ophosting.net 25
>> Trying 63.246.16.254...
>> Connected to mail.ophosting.net.
>> Escape character is '^]'.
>> 220 ophosting.net (IMail 8.00 37307-38) NT-ESMTP Server X1
>> helo itsme
>> 250 hello ophosting.net
>> mail from:<>
>> 501 bogus mail from
>> quit
>> 221 Goodbye
>> Connection closed by foreign host.
>>
> Please report them to http://www.rfc-ignorant.org
Excellent RBL. First I heard of them.
ophosting are already listed a little while ago, did you do that?
>
>
>>
>> I assume that this is some kind of anti spam measure
>> So this means
>> 1. They will never get a DSN
>> 2. sender callout will fail
>
> This is a dumb so-called antispam feature which is not rfc
> compliant and
> stops about nothing.
I can remember about 8-10 years ago most spam was empty envelope
from, but mostly now they use random stolen email addresses. So this
is a really arcane idea.
I get about 10 DSN's per day on my sacrificial email account.
>
>>
>>
>> Now obviously if they do not accept DSN's undeliverable messages will
>> be frozen on our server and so this should be rejected. Personally I
>> would be quite happy to leave it at that. However one of my clients
>> wants to be able to receive mail from two such domains.
>>
>> So I was wondering if anyone else has came across this strange
>> tactic. ?
>> If it becomes more widespread then perhaps we need an option to
>> specify the from address in sender callouts.
>
> I did come into such a problem. The resolution is quite simple, just
> contact the owner of these domains (IE: cc the postmaster of these
> domain when you send the evidence of their non compliance to
> rfc-ignorant.org) and ask them to correct their mail servers.
I sent them a mail already, asking them if they actually know that
they are blocking DSN's. I can't imagine anyone would block <>
knowing that it would block all DSN's
> For an example of a warning mail, you can look at
> http://www.rfc-ignorant.org/tools/detail.php?
> domain=asicorp.com&submitted=1161039519&table=dsn
> (yes, I do submit them automatically and there are many per day)
>
>
> Another (bad) solution is to do something like this in your rules:
> deny
> condition = ${if match
> {$sender_address_domain}{domain1.tld|domain2.tls}{no}{yes}}
> message = <$sender_address> does not appear to be a valid sender
> address.
> !verify = sender/callout=20s,defer_ok,random
Yes, my solution - because only two users complained was to bypass
callout checking completely for them.
Also I dont have to keep adding non compliant domains. And most
importantly the users might change their mind when they lose the
benefits of the callout
My biggest problem is that I provide a secondary MX service for that
domain and so now I have to bypass callout on my server for the
clients domain. and let the recipient callout do the job. Which is
really gross, because it also means that I cant cache the receiver
callouts
The only other solution is for me to do a per email except to the
sender callout but that is awkward to manage, but the more I think
about it this must be the way to do it.
In fact I am going to edit the configure now. Ill just have to
remember to edit the exception lists on each server.
>
>
>>
>> That way if you are using callouts as an anti spam measure then you
>> can use postmaster as the sender.
>> and retain some of the advantages.
>> The only problem with having a from address in the callout is that
>> you might get a mail callout loop if the other server is doing call
>> backs. Hmmm thats a big problem.
>>
>> Perhaps there should be a way to defer if the from is rejected as
>> opposed to the rcpt to:
>>
>>
>> Comments ?
>>
>>
>> Stuart Gall
>>
>>
> --
> ## List details at http://www.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
