--On 24 March 2011 14:50:22 +0000 "Dave Restall - System Administrator,,,"
<dave@???> wrote:
> Hi,
>
> I use exim to receive and process my emails - have done for years.
> I also use sender callouts - have done for years. Occasionally emails
> get rejected because they are sent from non-existent addresses and sender
> callouts don't like that.
I'm with you on this. With the proviso that you should check SPF first.
Callouts are entirely legitimate if you get an SPF pass, but arguably
redundant. They're not required if you get an SPF fail. For softfail and
neutral, I'd avoid doing the callout on the basis that one should be nice
to people that are helping you to evaluate the legitimacy of mail from
sender addresses in their domains.
In my view, refusing bounce messages for an address that's used in the
"RETURN PATH" is contrary to RFC 5321 "The primary purpose of the
Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures
are to be sent. For this to be unambiguous, exactly one return path
SHOULD be present when the message is delivered. "
You can parse this as reading "exactly one return path (an address to
which messages indicating non-delivery or other mail system failures
are to be sent) SHOULD be present when the message is delivered. "
And "SHOULD" means that you should be aware of the consequences of failing
to do so. For rfc5322, ignoring a recommendation means that you risk
failing to deliver email. If plusnet want to deliver their email, then they
should follow all recommendations in RFC5322.
Oh, and you don't need callouts in order to reject their email.
> Recently plusnet (www.plus.net) (an ISP !!!) sent me some administrative
> emails that were rejected due to sender callouts, so - I raised a support
> call and asked them to fix their systems and change the envelope addresses
> to something sensible - I don't care what they change it to as long as
> it resolves to a valid address. After much toing and froing, I got the
> following back, basically they're telling me to whitelist their broken
> addresses because 'the system is currently working as it was designed'.
>
> I realise I'm not strictly sticking to the RFC's 'be liberal in what
> you accept' in this case but why should I whitelist for their brain dead
> configs ?
>
> Before I go and really bend their ear on why they shouldn't be sending
> emails with invalid addresses, and that I shouldn't really have to
> whitelist their addresses because how can I know what the next failing
> address will be if their systems are designed to be broken and that for
> an ISP to have broken systems is really unacceptable, is there anybody
> on the list that works for plusnet who can point me at the right email
> address for their mail admins so I can make an appeal to the right people
> instead of... ? I'm resisting adjectives here because I've worked for
> a lot of years in a support environment and I don't want to label the
> whole plusnet team.
>
> ISTR in one of the earlier RFC's that there was a 'should not send from a
> non-existent email address' and also a 'be conservative in what you send'
> but I can't find them in recent RFC's, have things changed so much that
> they can configure servers this way and ignore the problems ? (I don't
> assiduously read RFC's nowadays). What are the current RFC's regarding
> good mail server etiquette ?
>
> I must admit plusnet have normally been good in responding to queries
> and support calls - but I'm amazed at their attitude over this and it
> makes me wonder what other corners they are cutting in order to provide
> their service.
>
>> We are pleased to be able to inform you that a member of our Customer
>> Support Centre has now escalated your Question [number 40296690 ]
>> for further investigation.
>>
>> The following comment was added to the Question
>>
>> The Question 40296690 has been released from hold in the CSC - G pool
>> and returned to the customer
>>
>> Dear Mr Restall,
>>
>> This has now been reviewed, and the system is currently working as it
>> was designed.
>>
>> To resolve this issue, you are able to whitelist the addresses that you
>> have given to us previously or disable the callback verification.
>>
>> Please note that Callback verification has no effect if spammers spoof
>> real email addresses or use the null bounce address.
>>
>> Please take a look at the link below for further information on the
>> limitations:
>>
>> http://en.wikipedia.org/wiki/Callback_verification
>>
>> Kind regards,
>>
>> Kevin Mawson
>>
>> Read or respond to your Question -
>> http://portal.plus.net/my.html?action=questions
>>
>> IMPORTANT: Do not reply to this email, our Support Team can only deal
>> with inquiries through the Help Assistant
>>
>>
>> Regards,
>> Customer Support
>>
>> --
>> http://portal.plus.net
>>
>>
>> PlusNet plc
>> Registered Office: Internet House, 2 Tenter Street, Sheffield, S1 4BY
>> Registered in England no: 3279013
>> VAT registration number: 842254440
>>
>
> Sorry about the looong rant :(
>
>
> Regards,
>
>
>
>
>
> D
> lists/exi,/users/2011-03-24.tx exim-users
> +------------------------------------------------------------------------
> ----+
>| Dave Restall, Computer Nerd, Cyclist, Radio Amateur G4FCU, Bodger
>| | Mob +44 (0) 7973 831245 Skype: dave.restall Radio:
>| G4FCU | email : dave@??? Web : Not Ready
>| Yet :-( |
> +------------------------------------------------------------------------
> ----+
>| The more complex the mind, the greater the need for the simplicity
>| | of play.
>| | -- Kirk, "Shore Leave", stardate 3025.8 |
> +------------------------------------------------------------------------
> ----+
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see
http://www.sussex.ac.uk/its/help/
